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

[Simon Glass]

Hi Masahiro,

On 24 November 2014 at 20:18, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> Hi Simon,
>
>
>
> On Mon, 24 Nov 2014 15:29:23 -0700
> Simon Glass <sjg at chromium.org> wrote:
>
>> HI Masahiro,
>>
>> On 21 November 2014 at 02:59, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
>> > Hi Simon,
>> >
>> >
>> >
>> > On Thu, 20 Nov 2014 16:44:22 +0000
>> > Simon Glass <sjg at chromium.org> wrote:
>> >
>> >> Hi Masahiro,
>> >>
>> >> On 19 November 2014 09:21, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
>> >> > 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.
>> >>
>> >> Well Linux has moved away from platform data, right?
>> >>
>> >> >
>> >> >
>> >> >
>> >> >> >
>> >> >> >
>> >> >> >> >
>> >> >> >> > 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.
>> >>
>> >> Agreed, and we really need to line up so we are using the same source.
>> >> I do want to point out that we mostly do, the differences are small.
>> >>
>> >> >
>> >> > 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?
>> >>
>> >> That's a waste of time since we won't use them and the goal is to do
>> >> as little as possible before relocation.
>> >>
>> >> I don't see that the pre-reloc property is a huge problem. In the case
>> >> of serial I found a way around it (using aliases). I hope that it will
>> >> be possible more generally and we can review that at some point in the
>> >> future. There are bigger fish to fry in driver model I think - so many
>> >> uclasses to write.
>> >
>> >
>> >
>> > OK.  I've marked 6/8 thru 8/8 as Rejected.
>> > No point for 6/8 and 7/8 without 8/8, I think.
>>
>> I'm not so sure. Your method reduces the number of drivers that are
>> considered for pre-reloc use which is a benefit.
>
>
> If you insist on "u-boot,dm-pre-reloc" property (= each device has
> the pre-reloc attribute), I think the DM_FLAG_PRE_RELOC flag should be
> moved from U_BOOT_DRIVER to U_BOOT_DEVICE for consistency.
> (Or 6/8 should introduce U_BOOT_DEVICE_F instead of U_BOOT_DRIVER_F)
>
> That is why I thought 6/8 and 7/8 should not be applied.

Let's do nothing for now. I don't like that property and would to get
rid of it too.

>
>
>> Maybe we should require that all pre-reloc devices have an alias. Then
>> we can bind devices as they are needed as we do for serial. Needs more
>> thought though.
>
> I want to see first how this will work
> because I believe platform data should be implemented consistently with that.

I'm thinking about it. If I take a look at adding more functions to
the GPIO uclass (automatically handing gpio nodes in the device tree)
then I might try to solve this one too.

For platform data I suppose it is just the order in the executable
that determines the numbering. Pretty ugly.

Regards,
Simon