[U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property

[Masahiro Yamada]

Hi Simon,



On Tue, 18 Nov 2014 14:37:33 +0000
Simon Glass <sjg at chromium.org> wrote:

> Hi Masahiro,
> 
> On 18 November 2014 12:51, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> > Hi Simon,
> >
> >
> >
> > On Mon, 17 Nov 2014 18:17:43 +0000
> > Simon Glass <sjg at chromium.org> wrote:
> >
> >> Hi Masahiro,
> >>
> >> On 17 November 2014 08:19, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> >> > The driver model provides two ways to pass the device information,
> >> > platform data and device tree.  Either way works to bind devices and
> >> > drivers, but there is inconsistency in terms of how to pass the
> >> > pre-reloc flag.
> >> >
> >> > In the platform data way, the pre-reloc DM scan checks if each driver
> >> > has DM_FLAG_PRE_RELOC flag (this was changed to use U_BOOT_DRIVER_F
> >> > just before).  That is, each **driver** has the pre-reloc attribute.
> >> >
> >> > In the device tree control, the existence of "u-boot,dm-pre-reloc" is
> >> > checked for each device node.  The driver flag "DM_FLAG_PRE_RELOC" is
> >> > never checked.  That is, each **device** owns the pre-reloc attribute.
> >> >
> >> > Drivers should generally work both with platform data and device tree,
> >> > but this inconsistency has made our life difficult.
> >>
> >> I feel we should use device tree where available, and only fall back
> >> to platform data when necessary (no device tree available for
> >> platform, for example).
> >
> > No, it is true that device tree is a useful tool, but it should be optional.
> >
> > All the infrastructures of drivers must work perfectly without device tree.
> >
> > The device tree is just one choice of how to give device information.
> >
> 
> Which platform(s) are we talking about here?


I am talking about the general design policy of drivers
in U-Boot and Linux.



> >
> >
> >> >
> >> > This commit abolishes "u-boot,dm-pre-reloc" property because:
> >> >
> >> >  - Having a U-Boot specific property makes it difficult to share the
> >> >    device tree sources between Linux and U-Boot.
> >> >
> >> >  - The number of devices is generally larger than that of drivers.
> >> >    Each driver often has multiple devices with different base
> >> >    addresses.  It seems more reasonable to add the pre-reloc attribute
> >> >    to drivers than devices.
> >>
> >> The inability for platform data to specify which devices need to be
> >> pre-relocation is certainly a limitation. But I'm not sure that the
> >> solution is to remove that feature from the device tree. Prior to
> >> relocation memory may be severely limited. Things like GPIO and serial
> >> can create quite a few devices (e.g. Tegra has 16 for GPIO and 4 for
> >> serial), but only a subset may be needed before relocation (on Tegra
> >> only 2!).
> >>
> >> I'm actually pretty comfortable with platform data having a limited
> >> subset of functionality, since I believe most platforms will use
> >> device tree for one reason or another.
> >>
> >> Thoughts?
> >>
> >
> > No, it is not justified to compel to use device tree
> > unless Linux is the target OS.
> >
> > Even in Linux, limited numbers of architrectures use device trees.
> 
> Fair enough, but let's look at this when the case comes up. So far the
> platforms that use I2C and SPI with DM do use device tree in Linux and
> probably should do in U-Boot.

OK, so let's think about it when a problem happens.


Let's get back talking about this patch.
If 8/8 is not acceptable, I do not have motivation for 6/8 and 7/8, either.


I still believe that the top priority of the design policy is
to share the same device tree source between U-Boot and Linux.

I am really unhappy about having such a u-boot specific property.

So, my suggestion is this patch, and one possible alternative is
to bind all the devices even before relocation.
Only binding won't use much memory because U-Boot does not probe devices
until they are actually used.
Both "u-boot,dm-pre-reloc" and DM_FLAG_PRE_RELOC will go away.


What do you think?


Best Regards
Masahiro Yamada