Hi Masahiro, On 24 November 2014 at 20:18, Masahiro Yamada <yamad...@jp.panasonic.com> wrote: > Hi Simon, > > > > On Mon, 24 Nov 2014 15:29:23 -0700 > Simon Glass <s...@chromium.org> wrote: > >> HI Masahiro, >> >> On 21 November 2014 at 02:59, Masahiro Yamada <yamad...@jp.panasonic.com> >> wrote: >> > Hi Simon, >> > >> > >> > >> > On Thu, 20 Nov 2014 16:44:22 +0000 >> > Simon Glass <s...@chromium.org> wrote: >> > >> >> Hi Masahiro, >> >> >> >> On 19 November 2014 09:21, Masahiro Yamada <yamad...@jp.panasonic.com> >> >> wrote: >> >> > Hi Simon, >> >> > >> >> > >> >> > >> >> > On Tue, 18 Nov 2014 14:37:33 +0000 >> >> > Simon Glass <s...@chromium.org> wrote: >> >> > >> >> >> Hi Masahiro, >> >> >> >> >> >> On 18 November 2014 12:51, Masahiro Yamada <yamad...@jp.panasonic.com> >> >> >> wrote: >> >> >> > Hi Simon, >> >> >> > >> >> >> > >> >> >> > >> >> >> > On Mon, 17 Nov 2014 18:17:43 +0000 >> >> >> > Simon Glass <s...@chromium.org> wrote: >> >> >> > >> >> >> >> Hi Masahiro, >> >> >> >> >> >> >> >> On 17 November 2014 08:19, Masahiro Yamada >> >> >> >> <yamad...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot