Re: [U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

Re: [U-Boot] [PATCH V2 5/6] ARM: dts: k2g: Add support for PMMC

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3563 bytes --]

... adding in devicetree-spec,
http://lists.denx.de/pipermail/u-boot/2016-February/246542.html for the
first part of this

On Fri, Feb 26, 2016 at 07:10:23PM -0600, Nishanth Menon wrote:
> Tom,
> 
> 
> On Fri, Feb 26, 2016 at 6:27 PM, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
> > On Fri, Feb 26, 2016 at 06:18:30PM -0600, Nishanth Menon wrote:
> >> On Fri, Feb 26, 2016 at 12:18 PM, Tom Rini <trini-OWPKS81ov/FWk0Htik3J/w@public.gmane.org> wrote:
> >> > On Thu, Feb 25, 2016 at 12:53:46PM -0600, Nishanth Menon wrote:
> [...]
> >> >
> >> > ... and this will match whatever is in the kernel, right?
> >>
> >> The Linux kernel will not need to access PMMC similar to how bootloader has to.
> >>
> >> Bootloader looks to load up the peripheral - so, it's view of the
> >> hardware is as a programmable core (similar to how we'd look at a
> >> DSP/other remote proc), however, linux kernel only cares about the
> >> communication link (which is the message manager) and the protocol on
> >> top to communicate and does not need to access PMMC directly (it is
> >> only done once by bootloader).
> >>
> >> So the the current u-boot dt binding will not even need to be send
> >> upstream kernel, instead a protocol level definition (similar to SCPI)
> >> will be exposed to linux kernel.
> >
> > So is the kernel community going to be unhappy about getting what it
> > might consider extraneous information in the device tree?  The goal here
> > is to be able to just copy in the DT files from $upstream and really
> > really not have local changes without a good reason (and yes, we need to
> > revisit u-boot,dm-pre-reloc at some point).  Maybe a question for one of
> > the higher level DT lists...
> 
> Hmmm... I can switch to platform data if maintenance is an concern. I
> dont think PMMC will be an unique experience for DT view of the
> hardware where every  piece of software looks at things differently.
> For example: if we move DDR configuration to device tree (which dt is
> pretty capable of doing), then we are stuck with the same issue yet
> again. DDR configuration is not necessary for kernel device tree since
> it has nothing to do there - and we dont provide that information
> (since it becomes a maintenance pain in kernel world as well), but
> u-boot SPL will need to have that information.
> 
> Device tree is a representation of hardware is exactly what we do,
> except that view depends on what we need to expose to each software
> solution. Even in Linux, in a hypervisor world, a guest OS may only
> have access to certain peripherals of the SoC - we dont expose all the
> peripherals to the OS via dt, instead a custom guest OS dt view of the
> world is created. This is one problem we all have with DT -> the
> extent to which we "describe hardware" - there is no objective rules
> for the same that can get blindly applied..
> 
> Do let me know if I need to bring this device outside of dt into
> platform data world. It wont be my first preference, but if it does
> create a severe maintenance burden, then maybe that is what needs to
> happen -> only resources that are shared between kernel and bootloader
> can reside in dt... just my 2 cents..

So, I would like to see this particular bit stay in the DT, and I would
like to see this part of the DT not be only in the U-Boot tree but
rather the authorative DT which today resides in the Linux kernel.  But
I'm not the person to make that final call, so adding in more people
here.

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]