Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
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 + 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 + 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 + 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
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
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 + 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 + 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 + 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
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
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 + 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 + 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 + 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
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
Hi Simon, On Thu, 20 Nov 2014 16:44:22 + 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 + 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 + 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. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
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 + 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 + 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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
On 11/20/2014 09:44 AM, Simon Glass 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 + 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 + 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? As a blanket statement, that isn't true. Some architectures (e.g. ARM) have moved to DT. That move is something done by the ARM maintainers, not something that's necessarily being forced upon every single architecture. I know of no move to force everyone to convert to DT. What makes sense for Linux doesn't always make sense for everything else anyway. In my opinion, DT in Linux isn't actually doing much that's useful, and DT in a boot loader is likely to be even less useful. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
Hi Simon, On Tue, 18 Nov 2014 14:37:33 + 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 + 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. 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
Hi Simon, On Mon, 17 Nov 2014 18:17:43 + 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. 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. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
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 + 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? 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. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
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.
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.
Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com
---
arch/arm/dts/exynos5.dtsi | 1 -
doc/driver-model/README.txt | 5 ++---
drivers/core/lists.c| 6 +++---
drivers/core/root.c | 6 ++
drivers/core/simple-bus.c | 2 +-
include/dm/lists.h | 13 ++---
include/dm/root.h | 4 ++--
test/dm/test-fdt.c | 2 +-
test/dm/test.dts| 2 --
9 files changed, 21 insertions(+), 20 deletions(-)
diff --git a/arch/arm/dts/exynos5.dtsi b/arch/arm/dts/exynos5.dtsi
index e539068..dc5405b 100644
--- a/arch/arm/dts/exynos5.dtsi
+++ b/arch/arm/dts/exynos5.dtsi
@@ -244,7 +244,6 @@
compatible = samsung,exynos4210-uart;
reg = 0x12C3 0x100;
interrupts = 0 54 0;
- u-boot,dm-pre-reloc;
id = 3;
};
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index e4114d5..06f6515 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -739,9 +739,8 @@ Pre-Relocation Support
--
For pre-relocation we simply call the driver model init function. Only
-drivers declared with U_BOOT_DRIVER_F or the device tree
-'u-boot,dm-pre-reloc' flag are initialised prior to relocation. This helps
-to reduce the driver model overhead.
+drivers declared with U_BOOT_DRIVER_F are initialised prior to relocation.
+This helps to reduce the driver model overhead.
Then post relocation we throw that away and re-init driver model again.
For drivers which require some sort of continuity between pre- and
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 5b61ab5..2109a9f 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -106,11 +106,11 @@ static int driver_check_compatible(const void *blob, int
offset,
return -ENOENT;
}
-int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
- struct udevice **devp)
+int __lists_bind_fdt(struct udevice *parent, const void *blob, int offset,
+struct udevice **devp, bool pre_reloc_only)
{
struct driver *entry = ll_entry_start(struct driver, driver1);
- struct driver *end = ll_entry_end(struct driver, driver2);
+ struct driver *end = driver_entry_end(pre_reloc_only);
struct udevice *dev;
bool found = false;
const char *name;
diff --git a/drivers/core/root.c b/drivers/core/root.c
index 02970c8..2f0c409 100644
--- a/drivers/core/root.c
+++ b/drivers/core/root.c
@@ -87,10 +87,8 @@ int dm_scan_fdt_node(struct udevice *parent, const void
*blob, int offset,
for (offset = fdt_first_subnode(blob, offset);
offset 0;
offset = fdt_next_subnode(blob, offset)) {
- if (pre_reloc_only
- !fdt_getprop(blob, offset, u-boot,dm-pre-reloc, NULL))
- continue;
- err = lists_bind_fdt(parent, blob, offset, NULL);
+ err = __lists_bind_fdt(parent, blob, offset, NULL,
+ pre_reloc_only);
if (err !ret)
ret = err;
}
diff --git a/drivers/core/simple-bus.c b/drivers/core/simple-bus.c
index 3ea4d82..483f8e2 100644
--- a/drivers/core/simple-bus.c
+++ b/drivers/core/simple-bus.c
@@ -26,7 +26,7 @@ static const struct udevice_id generic_simple_bus_ids[] = {
{ }
};
-U_BOOT_DRIVER(simple_bus_drv) = {
+U_BOOT_DRIVER_F(simple_bus_drv) = {
.name = generic_simple_bus,
.id = UCLASS_SIMPLE_BUS,
.of_match = generic_simple_bus_ids,
diff --git a/include/dm/lists.h b/include/dm/lists.h
index fbd428d..56bf6a7 100644
--- a/include/dm/lists.h
+++ b/include/dm/lists.h
@@ -53,7 +53,7 @@ struct uclass_driver *lists_uclass_lookup(enum
Re: [U-Boot] [PATCH 8/8] dm: core: abolish u-boot, dm-pre-reloc property
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). 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? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
