Re: [PATCH 05/14] tegra: fdt: Add Tegra2x device tree file

Hi Stephen,

On Fri, Dec 2, 2011 at 7:58 AM, Stephen Warren [off-list ref] wrote:

On 12/01/2011 06:24 PM, Simon Glass wrote:

quoted

Hi Stephen,

On Mon, Nov 28, 2011 at 10:56 AM, Stephen Warren [off-list ref] wrote:

quoted

On 11/23/2011 08:54 PM, Simon Glass wrote:

quoted

This was taken from commit 1ea6b8f at:
git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git

...

quoted

quoted

In particular, linux-next now includes a minimal USB binding. Should we
just use this in U-Boot for now? We should get review on the kernel
lists before bringing in this more advanced USB binding in U-Boot, and
perhaps even add the binding into the kernel at the same time?

I copied my email to the device-tree mailing list. Hopefully that is
enough to get a review there. It feels wrong to send U-Boot patches to
the kernel list...?

I think the kernel and U-boot need to co-ordinate on the DT bindings.
Posting at least to linux-tegra, the Tegra maintainers, and perhaps even
the kernel's domain-specific list (i.e. linux-usb) seems appropriate to
me. DT is a cross-functional thing, and really needs cross-functional
discussion and review. devicetree-discuss will cover the DT experts, but
probably not the CPU and subsystem experts.

I worry about the implication that I am blazing a trail here. I would
prefer to take the bindings as set down by the kernel and make them
work within U-Boot. The reasoning here is that Linux has more
demanding requirements, and more flexibility, so it is unlikely that
U-Boot would need more features in its fdt. The one exception might be
due to efficiency. If it takes 10ms and 50KB of code to figure out the
system state from the fdt then U-Boot people might get upset, so I do
want to make sure the bindings can be efficiently parsed by U-Boot
(hence my peripheral id approach).

Where those bindings don't exist yet, I would prefer to use a
place-holder until they are set, then change the U-Boot code later.
That process can take many months and we don't want to hold back
actual functionality in U-Boot just because we haven't finalized the
fdt definitions for a particular peripheral.

I will certainly widen my distribution list for fdt patches in the
hope that resolution can be reached then and there, but it will be
hard for kernel people to agree a binding until they have written /
modified the driver. IMO it would probably be a good idea for people
to subscribe to device-tree-discuss if they are interested in fdt
things, kernel or U-Boot or other. LKML already gets a huge amount of
traffic.

Regards,
Simon

--
nvpublic