... 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 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 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: