From: Kun Yi <kunyi@google.com>
To: benh@kernel.crashing.org
Cc: Andrew Jeffery <andrew@aj.id.au>,
robh@kernel.org, Eugene.Cho@dell.com, a.amelkin@yadro.com,
mark.rutland@arm.com, devicetree@vger.kernel.org,
gregkh@linuxfoundation.org,
OpenBMC Maillist <openbmc@lists.ozlabs.org>,
linux-kernel@vger.kernel.org, stewart@linux.ibm.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC control fields
Date: Thu, 9 Aug 2018 17:22:42 -0700 [thread overview]
Message-ID: <CAGMNF6XCSdif5=kAQ4eh_6+nmHLAu9Fva403EU2Ji2w27H9R0A@mail.gmail.com> (raw)
In-Reply-To: <483b76bac7cb8043d9d780d5ffa5e43438279887.camel@kernel.crashing.org>
Andrew, Benjamin, Rob,
Thanks for bringing up the set of patches and a great discussion.
After going through the thread I figured that I'd like to share a few
things we needed to hack when programming several BMC boards:
- Debug UART enable/mux
- Disable GPIO D/E passthrough (I think this is supported by the
current pinctrl driver)
- RMII/RGMII strapping
- iLPC2AHB control
- SPI master mux select
- Various SuperIO configurations
As for the discussion whether these belong to a platform driver or
device tree nodes, I think in an ideal world all these configurations
could be nicely grouped and abstracted in a platform kernel driver (or
drivers). However in reality think this as an "M * N" problem: there
are M variants of BMCs and N different platforms built with these
BMCs. Each platform-BMC combination is going to have its own quirks
and slightly different requirements in BMC "tunables". Were there a
kernel driver for the M BMC variants, it would inevitably have a lot
of churn due to the different needs of the platforms.
What I like about the device tree approach is the expressiveness of
the format and the ability to specify non-conflicting initial values
easily. Sometimes we need initial values for these parameters set
before running userspace, and setting such values in device tree is
easier than using #defines or kernel parameters.
On Thu, Jul 19, 2018 at 9:57 PM Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> On Fri, 2018-07-20 at 09:37 +0930, Andrew Jeffery wrote:
> > >
> > > Andrew, can you start with a list that shows what you expect us to need
> > > on our systems ?
> > >
> >
> > Okay, our Witherspoon and Romulus platforms containing the ASPEED AST2500 currently need the following tuneables exposed:
> >
> > > From the SCU:
> >
> > - Debug UART enable
> > - VGA DAC mux
> > - VGA scratch registers 0-7
> > - LPC SuperIO decode enable
> > - VGA MMIO decode enable
> >
> > > From the LPC controller:
> >
> > - iLPC2AHB enable
> > - SuperIO scratch registers 0x20-0x2f
> >
> > (The LPC controller is just as much of a collection of random bits as the SCU)
> >
> > Lastly, our Palmetto platform uses an AST2400 which has fewer features compared to the AST2500. Its tuneable list is the same as the above with the exception of "Debug UART enable".
> >
> > Tuneables that we may need to expose in the future include:
> >
> > > From the SCU:
> >
> > - PCI VID/DID for the BMC PCIe device
> > - VGA device enable (may need to be disabled if the platform contains a discrete graphics processor)
>
> Additionally there's a bunch of resigters controlling the mapping of
> various MMIO regions of the BMC PCIe device to portions of the BMC
> address space. I'm not sure what's the best way to handle that.
>
> This specific set might require a dedicated device as a subnode of
> the SCU in the DT that contains all the mappings as properties...
>
> That or we consider them static enough and just whack it in u-boot.
>
> > > From the LPC controller:
> >
> > - UART mux
> >
> > Alexander, Eugene, can you chime in with your platforms' needs?
> >
> > Cheers,
> >
> > Andrew
--
Regards,
Kun
next prev parent reply other threads:[~2018-08-10 0:23 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-11 5:31 [RFC PATCH v2 0/4] sysfs interface to miscellaneous BMC controls and fields Andrew Jeffery
2018-07-11 5:31 ` [RFC PATCH v2 1/4] dt-bindings: misc: Add bindings for misc. BMC control fields Andrew Jeffery
2018-07-11 20:04 ` Rob Herring
2018-07-12 0:14 ` Benjamin Herrenschmidt
2018-07-12 0:53 ` Andrew Jeffery
2018-07-12 15:11 ` Rob Herring
2018-07-13 0:55 ` Benjamin Herrenschmidt
2018-07-13 6:31 ` Andrew Jeffery
2018-07-13 15:14 ` Alexander Amelkin
2018-07-13 18:49 ` Eugene.Cho
2018-07-13 19:03 ` Greg KH
2018-07-13 19:06 ` Eugene.Cho
2018-07-15 14:21 ` Avi Fishman
2018-07-16 0:57 ` Andrew Jeffery
2018-07-16 13:55 ` Rob Herring
2018-07-17 1:04 ` Andrew Jeffery
2018-07-17 4:56 ` Benjamin Herrenschmidt
2018-07-17 23:28 ` Andrew Jeffery
2018-07-18 19:07 ` Rob Herring
2018-07-19 1:57 ` Andrew Jeffery
2018-07-18 19:50 ` Rob Herring
2018-07-18 23:58 ` Benjamin Herrenschmidt
2018-07-19 2:28 ` Andrew Jeffery
2018-07-19 4:35 ` Benjamin Herrenschmidt
2018-07-20 0:07 ` Andrew Jeffery
2018-07-20 4:56 ` Benjamin Herrenschmidt
2018-08-10 0:22 ` Kun Yi [this message]
2018-08-23 15:32 ` Alexander Amelkin
2018-07-11 5:31 ` [RFC PATCH v2 2/4] Documentation: ABI: Add sysfs-devices-platform-field to testing Andrew Jeffery
2018-07-11 5:31 ` [RFC PATCH v2 3/4] misc: Add bmc-misc-ctrl Andrew Jeffery
2018-07-11 5:31 ` [RFC PATCH v2 4/4] dts: aspeed-g5: Describe VGA, SIO scratch and DAC mux fields Andrew Jeffery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGMNF6XCSdif5=kAQ4eh_6+nmHLAu9Fva403EU2Ji2w27H9R0A@mail.gmail.com' \
--to=kunyi@google.com \
--cc=Eugene.Cho@dell.com \
--cc=a.amelkin@yadro.com \
--cc=andrew@aj.id.au \
--cc=benh@kernel.crashing.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=openbmc@lists.ozlabs.org \
--cc=robh@kernel.org \
--cc=stewart@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).