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

[Nishanth Menon]

Tom,


On Fri, Feb 26, 2016 at 6:27 PM, Tom Rini <trini at konsulko.com> 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 at konsulko.com> 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..

---
Regards,
Nishanth Menon