Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi Rajendra, On 7/21/2011 10:55 AM, Nayak, Rajendra wrote: On 7/20/2011 3:04 AM, Grant Likely wrote: On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: * Grant Likely [110716 22:08]: The way I see it, you've got two options: 1) modify the of_platform_bus_create() to call some kind of of_platform_bus_create_omap() for devices that match "ti,omap3-device" or something. 2) Leave of_platform_bus_create(), and instead us a notifier to attach hwmod data to normal platform devices. omap_device_build() is actually pretty simple. It allocated a device, it attaches platform_data and hwmod pointers to the device and registers it. omap_device_register() is just a wrapper around platform_device_register(). My preference is definitely #2, but there is a wrinkle in this approach. Unfortunately omap_devices are not simply plain platform_devices with extra data attached, an omap_device actually embeds the platform_device inside it, which cannot be attached after the fact. I think I had talked with Kevin (cc'd) about eliminating the embedding, but I cannot remember clearly on this point. As long as platform_device remains embedded inside struct omap_device, #2 won't work. In either case, looking up the correct hwmod data should be easy for any device provided the omap code maintains a lookup table of compatible strings and base addresses of devices (much like auxdata). In fact, I'd be okay with extending auxdata to include OMAP fields if that would be easiest since the whole point of auxdata is to ease the transition to DT support. When a matching device is created, the hwmod pointer can easily be attached. This should work transparently for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) Right! That's the solution I'd like to see. How about if we just have the hwmod code call omap_device_build for each device tree entry? I think that is pretty much equivalent to suggestion #1 above, only I'm suggesting to take advantage of the infrastructure already available in driver/of/platform.c in the form of of_platform_populate(). The "of_platform_bus_create_omap()" function suggested above I assumed would directly call omap_device_build(). In fact a lot of what omap_device_build() does today might not even be needed anymore. A lot of what it does is populate the platform_device structure by looking up the hwmod structs. Most of that information would now come from DT and hence all of that can be taken off from the hwmod structs. What will still be needed in hwmod is other data needed to runtime enable/idle the devices. That data however still needs to be linked with the platform_device's that DT would create which is what I guess could be done in something like a of_platform_bus_create_omap(). Paul/Benoit, do you guys agree we can get rid of some of the data from hwmod, whatever would now get passed in from DT, and keep only the PRCM/OCP related stuff for runtime handling? We need to discuss that further, but last time we discussed with Paul and Tony, we were considering starting with a DT that will just contain the list of devices and a reference to one of several hwmod name. That will allow us to get rid of all the crappy devices init code we have here and there in OMAP today. That phase can already keep us busy for some time :-) The DT format has some limitation today to describe a device that is connected to several buses and thus have several addresses. The DT format is providing only the CPU view of the system, meaning that we cannot take advantage of it to give the memory map of the DSP, or the CortexM3 inside OMAP4 for example. OK, I know, hwmod is not providing that information either today... but that was the plan:-) Because of that we will miss a lot of data we are retrieving today from hwmod. So for sure, we can define any kind of data in DT, but it will be much better to support that kind of details in the format directly instead of adding some custom TI nodes. For my point of view, the DT format should evolve toward a full hierarchical HW representation from the board level instead of a CPU centric one. But that just my .2 cents. Meanwhile, maybe we can start moving basic data from hwmod to DT. At first we should probably just do the device -> hwmod binding using DT. There is so much stuff to do, that the hardest part is to figure out where to start:-) Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Grant Likely writes: [...] > The way I see it, you've got two options: > > 1) modify the of_platform_bus_create() to call some kind of > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > or something. > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > hwmod data to normal platform devices. omap_device_build() is > actually pretty simple. It allocated a device, it attaches > platform_data and hwmod pointers to the device and registers it. > omap_device_register() is just a wrapper around > platform_device_register(). > > My preference is definitely #2, but there is a wrinkle in this > approach. Unfortunately omap_devices are not simply plain > platform_devices with extra data attached, an omap_device actually > embeds the platform_device inside it, which cannot be attached after > the fact. I think I had talked with Kevin (cc'd) about eliminating > the embedding, but I cannot remember clearly on this point. As long > as platform_device remains embedded inside struct omap_device, #2 > won't work. I agree with #2, and I think we need to go down this de-coupling route also. I just sent an RFC series that starts down this path to at least demonstrate that it's possible. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi Grant,
On Wed, Jul 20, 2011 at 3:07 AM, Grant Likely wrote:
> On Tue, Jul 19, 2011 at 11:28:53AM +0530, G, Manjunath Kondaiah wrote:
>> Grant/Kevin,
>>
>> On Sun, Jul 17, 2011 at 10:43 AM, Grant Likely
>> wrote:
>> > Hi Manjunath,
>> >
>> > Comments below. I left in a lot of context for the new folks that
>> > I've cc'd (Tony and Kevin).
>> >
>> > On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah
>> > wrote:
>> >> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely
>> >> wrote:
>> > +static void __init omap3_init(void)
>> > +{
>> [...]
>> >> + omap_register_i2c_bus(id, speed, i2c_board_info, 1);
>> >
>> > While this does in a sense work, and creates an omap_device for the
>> > i2c bus that does get probed, it ends up encoding an awful lot of
>> > device specific details into the generic devicetree support code. The
>> > i2c bus driver itself must be responsible for decoding the speed and
>> > child nodes, and in fact it can easily be modified to do so (I've
>> > already demonstrated how to do so). The real problem is making sure
>> > the platform_device is created in a way that attaches the correct
>> > hwmod data. For this context, the current omap_register_i2c_bus()
>> > isn't a useful method for doing so.
>> >
>> > So what is to be done? omap_register_i2c_bus() does three things;
>> > 1) register an i2c board info for the bus with i2c_register_board_info(),
>> > 2) fill platform_data for the device, and
>> > 3) use omap_i2c_add_bus to create the platform_device with attached hwmod.
>> >
>> > Of these three, 1 & 2 must not be done when using the DT. Only
>> > omap_i2c_add_bus() does something useful, but that is still specific
>> > to the i2c device.
>> >
>> > omap_i2c_add_bus() splits to omap{1,2}_add_bus().
>> >
>> > omap1_i2c_add_bus() sets up pinmux and calls platform_device register.
>> > pinmux setup needs to be factored out anyway for generic DT platform
>> > device registration, which just leaves platform_device creation which
>> > is already handled by of_platform_populate().
>> >
>> > omap2_i2c_add_bus() does the same thing, except it also looks up the
>> > hwmod data (*oh) and uses it to call omap_device_build().
>> > omap_device_build() or something equivalent needs to be called for
>> > every omap device in the system, which is to create platform_devices
>> > with hwmod attached. Now we're starting to hit generic code. :-)
>> >
>> > The way I see it, you've got two options:
>> >
>> > 1) modify the of_platform_bus_create() to call some kind of
>> > of_platform_bus_create_omap() for devices that match "ti,omap3-device"
>> > or something.
>> >
>> > 2) Leave of_platform_bus_create(), and instead us a notifier to attach
>> > hwmod data to normal platform devices. omap_device_build() is
>> > actually pretty simple. It allocated a device, it attaches
>> > platform_data and hwmod pointers to the device and registers it.
>> > omap_device_register() is just a wrapper around
>> > platform_device_register().
>> >
>> > My preference is definitely #2, but there is a wrinkle in this
>> > approach. Unfortunately omap_devices are not simply plain
>> > platform_devices with extra data attached, an omap_device actually
>> > embeds the platform_device inside it, which cannot be attached after
>> > the fact. I think I had talked with Kevin (cc'd) about eliminating
>> > the embedding, but I cannot remember clearly on this point. As long
>> > as platform_device remains embedded inside struct omap_device, #2
>> > won't work.
>>
>> Can you please elaborate more on this issue?
>
> Look at the of_platform_populate() call path (in devicetree/next) and
> see how it handles amba devices. Do the same thing for omap_devices.
As per the discussion so far, I am trying to take following approach:
|--->of_platform_populate(...)
|--->of_platform_bus_create_omap()-->Here notifiers are added
|--->platform_device_register() ---> calls registered notifiers
|--->notifier_callback - look up hwmod entry by name
- call omap_device_build(need to pass
platform_device pointer)
- get all the details such as resource
structures, irqs,platform_data
etc from hwmod database and auxdata
and assign it to platform_device
pointer received from notifier
callback function.
- there will be no
platform_device_register from omap_device_build
since it is already called
from "of_platform_bus_create_omap"
Please note that, with the above approach, the platform_device pointer
which is embedded
inside omap_device is not used and omap_device_build api will expect
platform device pointer.
-M
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi, On Thu, Jul 21, 2011 at 03:03:24PM +0530, Rajendra Nayak wrote: > >IMHO, all omap_hwmod_*_data.c files become pretty much useless if we > >move completely to DT. All hwmod data is passing today, can be passed > >via DT and in a similar Hierarchical manner. > > Would the data representation be equally readable? > That's one of the problems I faced when I started > looking at it initially trying to move a lot of these > structures. not to my eyes, heh. I'm too used to C, though. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
On 7/21/2011 2:39 PM, Felipe Balbi wrote: Hi, On Thu, Jul 21, 2011 at 02:25:03PM +0530, Rajendra Nayak wrote: On 7/20/2011 3:04 AM, Grant Likely wrote: On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: * Grant Likely [110716 22:08]: The way I see it, you've got two options: 1) modify the of_platform_bus_create() to call some kind of of_platform_bus_create_omap() for devices that match "ti,omap3-device" or something. 2) Leave of_platform_bus_create(), and instead us a notifier to attach hwmod data to normal platform devices. omap_device_build() is actually pretty simple. It allocated a device, it attaches platform_data and hwmod pointers to the device and registers it. omap_device_register() is just a wrapper around platform_device_register(). My preference is definitely #2, but there is a wrinkle in this approach. Unfortunately omap_devices are not simply plain platform_devices with extra data attached, an omap_device actually embeds the platform_device inside it, which cannot be attached after the fact. I think I had talked with Kevin (cc'd) about eliminating the embedding, but I cannot remember clearly on this point. As long as platform_device remains embedded inside struct omap_device, #2 won't work. In either case, looking up the correct hwmod data should be easy for any device provided the omap code maintains a lookup table of compatible strings and base addresses of devices (much like auxdata). In fact, I'd be okay with extending auxdata to include OMAP fields if that would be easiest since the whole point of auxdata is to ease the transition to DT support. When a matching device is created, the hwmod pointer can easily be attached. This should work transparently for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) Right! That's the solution I'd like to see. How about if we just have the hwmod code call omap_device_build for each device tree entry? I think that is pretty much equivalent to suggestion #1 above, only I'm suggesting to take advantage of the infrastructure already available in driver/of/platform.c in the form of of_platform_populate(). The "of_platform_bus_create_omap()" function suggested above I assumed would directly call omap_device_build(). In fact a lot of what omap_device_build() does today might not even be needed anymore. A lot of what it does is populate the platform_device structure by looking up the hwmod structs. Most of that information would now come from DT and hence all of that can be taken off from the hwmod structs. What will still be needed in hwmod is other data needed to runtime enable/idle the devices. That data however still needs to be linked with the platform_device's that DT would create which is what I guess could be done in something like a of_platform_bus_create_omap(). Paul/Benoit, do you guys agree we can get rid of some of the data from hwmod, whatever would now get passed in from DT, and keep only the PRCM/OCP related stuff for runtime handling? IMHO, all omap_hwmod_*_data.c files become pretty much useless if we move completely to DT. All hwmod data is passing today, can be passed via DT and in a similar Hierarchical manner. Would the data representation be equally readable? That's one of the problems I faced when I started looking at it initially trying to move a lot of these structures. Now WRT omap_device_build() and PM, I think that's still necessary because it simplifies a lot PM handling. But the data files themselves can "easily" be purged from kernel and converted into DT. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi, On Thu, Jul 21, 2011 at 02:25:03PM +0530, Rajendra Nayak wrote: > On 7/20/2011 3:04 AM, Grant Likely wrote: > >On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: > >>* Grant Likely [110716 22:08]: > >>> > >>>The way I see it, you've got two options: > >>> > >>>1) modify the of_platform_bus_create() to call some kind of > >>>of_platform_bus_create_omap() for devices that match "ti,omap3-device" > >>>or something. > >>> > >>>2) Leave of_platform_bus_create(), and instead us a notifier to attach > >>>hwmod data to normal platform devices. omap_device_build() is > >>>actually pretty simple. It allocated a device, it attaches > >>>platform_data and hwmod pointers to the device and registers it. > >>>omap_device_register() is just a wrapper around > >>>platform_device_register(). > >>> > >>>My preference is definitely #2, but there is a wrinkle in this > >>>approach. Unfortunately omap_devices are not simply plain > >>>platform_devices with extra data attached, an omap_device actually > >>>embeds the platform_device inside it, which cannot be attached after > >>>the fact. I think I had talked with Kevin (cc'd) about eliminating > >>>the embedding, but I cannot remember clearly on this point. As long > >>>as platform_device remains embedded inside struct omap_device, #2 > >>>won't work. > >>> > >>>In either case, looking up the correct hwmod data should be easy for > >>>any device provided the omap code maintains a lookup table of > >>>compatible strings and base addresses of devices (much like auxdata). > >>>In fact, I'd be okay with extending auxdata to include OMAP fields if > >>>that would be easiest since the whole point of auxdata is to ease the > >>>transition to DT support. When a matching device is created, the > >>>hwmod pointer can easily be attached. This should work transparently > >>>for all omap devices, not just the i2c bus. > >> > >>Well we should be able to automgagically build the omap_device for > >>each device tree entry. > >> > >>And then the device driver probe and runtime PM should be able to take > >>care of the rest for the driver. And then there's no more driver > >>specific platform init code needed ;) > > > >Right! That's the solution I'd like to see. > > > >>How about if we just have the hwmod code call omap_device_build for > >>each device tree entry? > > > >I think that is pretty much equivalent to suggestion #1 above, only > >I'm suggesting to take advantage of the infrastructure already > >available in driver/of/platform.c in the form of > >of_platform_populate(). The "of_platform_bus_create_omap()" function > >suggested above I assumed would directly call omap_device_build(). > > In fact a lot of what omap_device_build() does today might not even be > needed anymore. A lot of what it does is populate the platform_device > structure by looking up the hwmod structs. > Most of that information would now come from DT and hence all of that > can be taken off from the hwmod structs. What will still be needed in > hwmod is other data needed to runtime enable/idle the devices. That > data however still needs to be linked with the platform_device's that > DT would create which is what I guess could be done in something > like a of_platform_bus_create_omap(). > > Paul/Benoit, do you guys agree we can get rid of some of the data > from hwmod, whatever would now get passed in from DT, and keep > only the PRCM/OCP related stuff for runtime handling? IMHO, all omap_hwmod_*_data.c files become pretty much useless if we move completely to DT. All hwmod data is passing today, can be passed via DT and in a similar Hierarchical manner. Now WRT omap_device_build() and PM, I think that's still necessary because it simplifies a lot PM handling. But the data files themselves can "easily" be purged from kernel and converted into DT. -- balbi signature.asc Description: Digital signature
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
On 7/20/2011 3:04 AM, Grant Likely wrote: On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: * Grant Likely [110716 22:08]: The way I see it, you've got two options: 1) modify the of_platform_bus_create() to call some kind of of_platform_bus_create_omap() for devices that match "ti,omap3-device" or something. 2) Leave of_platform_bus_create(), and instead us a notifier to attach hwmod data to normal platform devices. omap_device_build() is actually pretty simple. It allocated a device, it attaches platform_data and hwmod pointers to the device and registers it. omap_device_register() is just a wrapper around platform_device_register(). My preference is definitely #2, but there is a wrinkle in this approach. Unfortunately omap_devices are not simply plain platform_devices with extra data attached, an omap_device actually embeds the platform_device inside it, which cannot be attached after the fact. I think I had talked with Kevin (cc'd) about eliminating the embedding, but I cannot remember clearly on this point. As long as platform_device remains embedded inside struct omap_device, #2 won't work. In either case, looking up the correct hwmod data should be easy for any device provided the omap code maintains a lookup table of compatible strings and base addresses of devices (much like auxdata). In fact, I'd be okay with extending auxdata to include OMAP fields if that would be easiest since the whole point of auxdata is to ease the transition to DT support. When a matching device is created, the hwmod pointer can easily be attached. This should work transparently for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) Right! That's the solution I'd like to see. How about if we just have the hwmod code call omap_device_build for each device tree entry? I think that is pretty much equivalent to suggestion #1 above, only I'm suggesting to take advantage of the infrastructure already available in driver/of/platform.c in the form of of_platform_populate(). The "of_platform_bus_create_omap()" function suggested above I assumed would directly call omap_device_build(). In fact a lot of what omap_device_build() does today might not even be needed anymore. A lot of what it does is populate the platform_device structure by looking up the hwmod structs. Most of that information would now come from DT and hence all of that can be taken off from the hwmod structs. What will still be needed in hwmod is other data needed to runtime enable/idle the devices. That data however still needs to be linked with the platform_device's that DT would create which is what I guess could be done in something like a of_platform_bus_create_omap(). Paul/Benoit, do you guys agree we can get rid of some of the data from hwmod, whatever would now get passed in from DT, and keep only the PRCM/OCP related stuff for runtime handling? There are already hooks in the _populate call path to handle the creation of amba_devices. I have no problem doing the same thing for omap devices. g. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
* Grant Likely [110719 14:29]: > On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: > > * Grant Likely [110716 22:08]: > > > > > > The way I see it, you've got two options: > > > > > > 1) modify the of_platform_bus_create() to call some kind of > > > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > > > or something. > > > > > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > > > hwmod data to normal platform devices. omap_device_build() is > > > actually pretty simple. It allocated a device, it attaches > > > platform_data and hwmod pointers to the device and registers it. > > > omap_device_register() is just a wrapper around > > > platform_device_register(). > > > > > > My preference is definitely #2, but there is a wrinkle in this > > > approach. Unfortunately omap_devices are not simply plain > > > platform_devices with extra data attached, an omap_device actually > > > embeds the platform_device inside it, which cannot be attached after > > > the fact. I think I had talked with Kevin (cc'd) about eliminating > > > the embedding, but I cannot remember clearly on this point. As long > > > as platform_device remains embedded inside struct omap_device, #2 > > > won't work. > > > > > > In either case, looking up the correct hwmod data should be easy for > > > any device provided the omap code maintains a lookup table of > > > compatible strings and base addresses of devices (much like auxdata). > > > In fact, I'd be okay with extending auxdata to include OMAP fields if > > > that would be easiest since the whole point of auxdata is to ease the > > > transition to DT support. When a matching device is created, the > > > hwmod pointer can easily be attached. This should work transparently > > > for all omap devices, not just the i2c bus. > > > > Well we should be able to automgagically build the omap_device for > > each device tree entry. > > > > And then the device driver probe and runtime PM should be able to take > > care of the rest for the driver. And then there's no more driver > > specific platform init code needed ;) > > Right! That's the solution I'd like to see. > > > How about if we just have the hwmod code call omap_device_build for > > each device tree entry? > > I think that is pretty much equivalent to suggestion #1 above, only > I'm suggesting to take advantage of the infrastructure already > available in driver/of/platform.c in the form of > of_platform_populate(). The "of_platform_bus_create_omap()" function > suggested above I assumed would directly call omap_device_build(). OK > There are already hooks in the _populate call path to handle the > creation of amba_devices. I have no problem doing the same thing for > omap devices. OK Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
On Tue, Jul 19, 2011 at 11:28:53AM +0530, G, Manjunath Kondaiah wrote:
> Grant/Kevin,
>
> On Sun, Jul 17, 2011 at 10:43 AM, Grant Likely
> wrote:
> > Hi Manjunath,
> >
> > Comments below. I left in a lot of context for the new folks that
> > I've cc'd (Tony and Kevin).
> >
> > On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah
> > wrote:
> >> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely
> >> wrote:
> > +static void __init omap3_init(void)
> > +{
> [...]
> >> + omap_register_i2c_bus(id, speed, i2c_board_info, 1);
> >
> > While this does in a sense work, and creates an omap_device for the
> > i2c bus that does get probed, it ends up encoding an awful lot of
> > device specific details into the generic devicetree support code. The
> > i2c bus driver itself must be responsible for decoding the speed and
> > child nodes, and in fact it can easily be modified to do so (I've
> > already demonstrated how to do so). The real problem is making sure
> > the platform_device is created in a way that attaches the correct
> > hwmod data. For this context, the current omap_register_i2c_bus()
> > isn't a useful method for doing so.
> >
> > So what is to be done? omap_register_i2c_bus() does three things;
> > 1) register an i2c board info for the bus with i2c_register_board_info(),
> > 2) fill platform_data for the device, and
> > 3) use omap_i2c_add_bus to create the platform_device with attached hwmod.
> >
> > Of these three, 1 & 2 must not be done when using the DT. Only
> > omap_i2c_add_bus() does something useful, but that is still specific
> > to the i2c device.
> >
> > omap_i2c_add_bus() splits to omap{1,2}_add_bus().
> >
> > omap1_i2c_add_bus() sets up pinmux and calls platform_device register.
> > pinmux setup needs to be factored out anyway for generic DT platform
> > device registration, which just leaves platform_device creation which
> > is already handled by of_platform_populate().
> >
> > omap2_i2c_add_bus() does the same thing, except it also looks up the
> > hwmod data (*oh) and uses it to call omap_device_build().
> > omap_device_build() or something equivalent needs to be called for
> > every omap device in the system, which is to create platform_devices
> > with hwmod attached. Now we're starting to hit generic code. :-)
> >
> > The way I see it, you've got two options:
> >
> > 1) modify the of_platform_bus_create() to call some kind of
> > of_platform_bus_create_omap() for devices that match "ti,omap3-device"
> > or something.
> >
> > 2) Leave of_platform_bus_create(), and instead us a notifier to attach
> > hwmod data to normal platform devices. omap_device_build() is
> > actually pretty simple. It allocated a device, it attaches
> > platform_data and hwmod pointers to the device and registers it.
> > omap_device_register() is just a wrapper around
> > platform_device_register().
> >
> > My preference is definitely #2, but there is a wrinkle in this
> > approach. Unfortunately omap_devices are not simply plain
> > platform_devices with extra data attached, an omap_device actually
> > embeds the platform_device inside it, which cannot be attached after
> > the fact. I think I had talked with Kevin (cc'd) about eliminating
> > the embedding, but I cannot remember clearly on this point. As long
> > as platform_device remains embedded inside struct omap_device, #2
> > won't work.
>
> Can you please elaborate more on this issue?
Look at the of_platform_populate() call path (in devicetree/next) and
see how it handles amba devices. Do the same thing for omap_devices.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
On Mon, Jul 18, 2011 at 03:45:57PM +0530, G, Manjunath Kondaiah wrote:
> Hi Grant,
>
> On 17 July 2011 10:43, Grant Likely wrote:
> > Hi Manjunath,
> >
> > Comments below. I left in a lot of context for the new folks that
> > I've cc'd (Tony and Kevin).
> >
> > On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah
> > wrote:
> >> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely
> >> wrote:
> > +static void __init omap3_init(void)
> > +{
> > + struct device_node *node;
> > +
> [...]
> >> +static struct omap_device *of_omap_i2c_device_create(struct device_node
> >> *node,
> >> + const char *bus_id,
> >> + void *platform_data,
> >> + struct device *parent)
> >> +{
> >> + struct platform_device *pdev;
> >> + struct i2c_board_info *i2c_board_info;
> >> + u8 id;
> >> +
> >> + printk("Creating omap i2c device %s\n", node->full_name);
> >> +
> >> + if (!of_device_is_available(node))
> >> + return NULL;
> >> +
> >> + id = simple_strtol(bus_id, NULL, 0);
> >> + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
> >> + pdev->dev.of_node = of_node_get(node);
> >> + if (!pdev->dev.of_node) {
> >> + speed = 100;
> >> + } else {
> >> + u32 prop;
> >> + if (!of_property_read_u32(pdev->dev.of_node,
> >> "clock-frequency",
> >> +
> >> &prop))
> >> + speed = prop/100;
> >> + else
> >> + speed = 100;
> >> + }
> >> + printk("%s : speed->%d\n",__func__, speed);
> >> +
> >> + for_each_child_of_node(bus, child) {
> >> + u32 prop;
> >> +
> >> + printk(" create child: %s\n", child->full_name);
> >> + i2c_board_info = kzalloc(sizeof(*i2c_board_info),
> >> GFP_KERNEL);
> >> + if (!of_property_read_u32(pdev->dev.of_node, "reg",
> >> + &prop))
> >> + i2c_board_info->addr = prop;
> >> + if (!of_property_read_u32(pdev->dev.of_node, "interrupts",
> >> + &prop))
> >> + i2c_board_info->irq = prop;
> >> + i2c_board_info->platform_data = platform_data;
> >> + strncpy(i2c_board_info->type, child->name,
> >> + sizeof(i2c_board_info->type));
> >> + }
> >> + omap_register_i2c_bus(id, speed, i2c_board_info, 1);
> >
> > While this does in a sense work, and creates an omap_device for the
> > i2c bus that does get probed, it ends up encoding an awful lot of
> > device specific details into the generic devicetree support code. The
> > i2c bus driver itself must be responsible for decoding the speed and
> > child nodes, and in fact it can easily be modified to do so (I've
>
> Decoding speed in i2c driver seems to be fine. But the i2c child nodes are
> board specific. We might bring board specific handling code into i2c driver
> with this approach.
It shouldn't. They're just i2c devices, and the child nodes will
always follow the i2c device binding.
> BTW, I have observed that, if we create i2c device node in omapx-soc.dtsi
> file and the define i2c bus clock-frequency in beagle.dts, the clock-frequency
> is not available in driver probe. Is this expected behavior?
No, it sounds like something isn't getting set up correctly. Send me
your current beagle.dts and omap3-soc.dtsi files.
g.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
On Mon, Jul 18, 2011 at 02:07:10AM -0700, Tony Lindgren wrote: > * Grant Likely [110716 22:08]: > > > > The way I see it, you've got two options: > > > > 1) modify the of_platform_bus_create() to call some kind of > > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > > or something. > > > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > > hwmod data to normal platform devices. omap_device_build() is > > actually pretty simple. It allocated a device, it attaches > > platform_data and hwmod pointers to the device and registers it. > > omap_device_register() is just a wrapper around > > platform_device_register(). > > > > My preference is definitely #2, but there is a wrinkle in this > > approach. Unfortunately omap_devices are not simply plain > > platform_devices with extra data attached, an omap_device actually > > embeds the platform_device inside it, which cannot be attached after > > the fact. I think I had talked with Kevin (cc'd) about eliminating > > the embedding, but I cannot remember clearly on this point. As long > > as platform_device remains embedded inside struct omap_device, #2 > > won't work. > > > > In either case, looking up the correct hwmod data should be easy for > > any device provided the omap code maintains a lookup table of > > compatible strings and base addresses of devices (much like auxdata). > > In fact, I'd be okay with extending auxdata to include OMAP fields if > > that would be easiest since the whole point of auxdata is to ease the > > transition to DT support. When a matching device is created, the > > hwmod pointer can easily be attached. This should work transparently > > for all omap devices, not just the i2c bus. > > Well we should be able to automgagically build the omap_device for > each device tree entry. > > And then the device driver probe and runtime PM should be able to take > care of the rest for the driver. And then there's no more driver > specific platform init code needed ;) Right! That's the solution I'd like to see. > How about if we just have the hwmod code call omap_device_build for > each device tree entry? I think that is pretty much equivalent to suggestion #1 above, only I'm suggesting to take advantage of the infrastructure already available in driver/of/platform.c in the form of of_platform_populate(). The "of_platform_bus_create_omap()" function suggested above I assumed would directly call omap_device_build(). There are already hooks in the _populate call path to handle the creation of amba_devices. I have no problem doing the same thing for omap devices. g. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Grant/Kevin,
On Sun, Jul 17, 2011 at 10:43 AM, Grant Likely
wrote:
> Hi Manjunath,
>
> Comments below. I left in a lot of context for the new folks that
> I've cc'd (Tony and Kevin).
>
> On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah wrote:
>> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely
>> wrote:
> +static void __init omap3_init(void)
> +{
[...]
>> + omap_register_i2c_bus(id, speed, i2c_board_info, 1);
>
> While this does in a sense work, and creates an omap_device for the
> i2c bus that does get probed, it ends up encoding an awful lot of
> device specific details into the generic devicetree support code. The
> i2c bus driver itself must be responsible for decoding the speed and
> child nodes, and in fact it can easily be modified to do so (I've
> already demonstrated how to do so). The real problem is making sure
> the platform_device is created in a way that attaches the correct
> hwmod data. For this context, the current omap_register_i2c_bus()
> isn't a useful method for doing so.
>
> So what is to be done? omap_register_i2c_bus() does three things;
> 1) register an i2c board info for the bus with i2c_register_board_info(),
> 2) fill platform_data for the device, and
> 3) use omap_i2c_add_bus to create the platform_device with attached hwmod.
>
> Of these three, 1 & 2 must not be done when using the DT. Only
> omap_i2c_add_bus() does something useful, but that is still specific
> to the i2c device.
>
> omap_i2c_add_bus() splits to omap{1,2}_add_bus().
>
> omap1_i2c_add_bus() sets up pinmux and calls platform_device register.
> pinmux setup needs to be factored out anyway for generic DT platform
> device registration, which just leaves platform_device creation which
> is already handled by of_platform_populate().
>
> omap2_i2c_add_bus() does the same thing, except it also looks up the
> hwmod data (*oh) and uses it to call omap_device_build().
> omap_device_build() or something equivalent needs to be called for
> every omap device in the system, which is to create platform_devices
> with hwmod attached. Now we're starting to hit generic code. :-)
>
> The way I see it, you've got two options:
>
> 1) modify the of_platform_bus_create() to call some kind of
> of_platform_bus_create_omap() for devices that match "ti,omap3-device"
> or something.
>
> 2) Leave of_platform_bus_create(), and instead us a notifier to attach
> hwmod data to normal platform devices. omap_device_build() is
> actually pretty simple. It allocated a device, it attaches
> platform_data and hwmod pointers to the device and registers it.
> omap_device_register() is just a wrapper around
> platform_device_register().
>
> My preference is definitely #2, but there is a wrinkle in this
> approach. Unfortunately omap_devices are not simply plain
> platform_devices with extra data attached, an omap_device actually
> embeds the platform_device inside it, which cannot be attached after
> the fact. I think I had talked with Kevin (cc'd) about eliminating
> the embedding, but I cannot remember clearly on this point. As long
> as platform_device remains embedded inside struct omap_device, #2
> won't work.
Can you please elaborate more on this issue?
-Manjunath
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi Grant,
On 17 July 2011 10:43, Grant Likely wrote:
> Hi Manjunath,
>
> Comments below. I left in a lot of context for the new folks that
> I've cc'd (Tony and Kevin).
>
> On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah wrote:
>> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely
>> wrote:
> +static void __init omap3_init(void)
> +{
> + struct device_node *node;
> +
[...]
>> +static struct omap_device *of_omap_i2c_device_create(struct device_node
>> *node,
>> + const char *bus_id,
>> + void *platform_data,
>> + struct device *parent)
>> +{
>> + struct platform_device *pdev;
>> + struct i2c_board_info *i2c_board_info;
>> + u8 id;
>> +
>> + printk("Creating omap i2c device %s\n", node->full_name);
>> +
>> + if (!of_device_is_available(node))
>> + return NULL;
>> +
>> + id = simple_strtol(bus_id, NULL, 0);
>> + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
>> + pdev->dev.of_node = of_node_get(node);
>> + if (!pdev->dev.of_node) {
>> + speed = 100;
>> + } else {
>> + u32 prop;
>> + if (!of_property_read_u32(pdev->dev.of_node,
>> "clock-frequency",
>> +
>> &prop))
>> + speed = prop/100;
>> + else
>> + speed = 100;
>> + }
>> + printk("%s : speed->%d\n",__func__, speed);
>> +
>> + for_each_child_of_node(bus, child) {
>> + u32 prop;
>> +
>> + printk(" create child: %s\n", child->full_name);
>> + i2c_board_info = kzalloc(sizeof(*i2c_board_info),
>> GFP_KERNEL);
>> + if (!of_property_read_u32(pdev->dev.of_node, "reg",
>> + &prop))
>> + i2c_board_info->addr = prop;
>> + if (!of_property_read_u32(pdev->dev.of_node, "interrupts",
>> + &prop))
>> + i2c_board_info->irq = prop;
>> + i2c_board_info->platform_data = platform_data;
>> + strncpy(i2c_board_info->type, child->name,
>> + sizeof(i2c_board_info->type));
>> + }
>> + omap_register_i2c_bus(id, speed, i2c_board_info, 1);
>
> While this does in a sense work, and creates an omap_device for the
> i2c bus that does get probed, it ends up encoding an awful lot of
> device specific details into the generic devicetree support code. The
> i2c bus driver itself must be responsible for decoding the speed and
> child nodes, and in fact it can easily be modified to do so (I've
Decoding speed in i2c driver seems to be fine. But the i2c child nodes are
board specific. We might bring board specific handling code into i2c driver
with this approach.
BTW, I have observed that, if we create i2c device node in omapx-soc.dtsi
file and the define i2c bus clock-frequency in beagle.dts, the clock-frequency
is not available in driver probe. Is this expected behavior?
-M
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
* Grant Likely [110716 22:08]: > > The way I see it, you've got two options: > > 1) modify the of_platform_bus_create() to call some kind of > of_platform_bus_create_omap() for devices that match "ti,omap3-device" > or something. > > 2) Leave of_platform_bus_create(), and instead us a notifier to attach > hwmod data to normal platform devices. omap_device_build() is > actually pretty simple. It allocated a device, it attaches > platform_data and hwmod pointers to the device and registers it. > omap_device_register() is just a wrapper around > platform_device_register(). > > My preference is definitely #2, but there is a wrinkle in this > approach. Unfortunately omap_devices are not simply plain > platform_devices with extra data attached, an omap_device actually > embeds the platform_device inside it, which cannot be attached after > the fact. I think I had talked with Kevin (cc'd) about eliminating > the embedding, but I cannot remember clearly on this point. As long > as platform_device remains embedded inside struct omap_device, #2 > won't work. > > In either case, looking up the correct hwmod data should be easy for > any device provided the omap code maintains a lookup table of > compatible strings and base addresses of devices (much like auxdata). > In fact, I'd be okay with extending auxdata to include OMAP fields if > that would be easiest since the whole point of auxdata is to ease the > transition to DT support. When a matching device is created, the > hwmod pointer can easily be attached. This should work transparently > for all omap devices, not just the i2c bus. Well we should be able to automgagically build the omap_device for each device tree entry. And then the device driver probe and runtime PM should be able to take care of the rest for the driver. And then there's no more driver specific platform init code needed ;) How about if we just have the hwmod code call omap_device_build for each device tree entry? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
Hi Manjunath,
Comments below. I left in a lot of context for the new folks that
I've cc'd (Tony and Kevin).
On Sat, Jul 16, 2011 at 2:07 PM, G, Manjunath Kondaiah wrote:
> On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely
> wrote:
>>> > +static void __init omap3_init(void)
>>> > +{
>>> > + struct device_node *node;
>>> > +
>>> > + node = of_find_matching_node_by_address(NULL, omap3_dt_intc_match,
>>> > + OMAP34XX_IC_BASE);
>>> > + if (node)
>>> > + irq_domain_add_simple(node, 0);
>>> > +
>>> > + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>>> > + omap3_beagle_init_rev();
>>> > + omap3_beagle_i2c_init();
>>> > + platform_add_devices(omap3_beagle_devices,
>>> > + ARRAY_SIZE(omap3_beagle_devices));
>>> > + omap_display_init(&beagle_dss_data);
>>> > + omap_serial_init();
>>> > +
>>> > + omap_mux_init_gpio(170, OMAP_PIN_INPUT);
>>> > + /* REVISIT leave DVI powered down until it's needed ... */
>>> > + gpio_request_one(170, GPIOF_OUT_INIT_HIGH, "DVI_nPD");
>>> > +
>>> > + usb_musb_init(NULL);
>>> > + usbhs_init(&usbhs_bdata);
>>> > + omap_nand_flash_init(NAND_BUSWIDTH_16,
>>> > omap3beagle_nand_partitions,
>>> > + ARRAY_SIZE(omap3beagle_nand_partitions));
>>> > +
>>> > + /* Ensure msecure is mux'd to be able to set the RTC. */
>>> > + omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
>>> > +
>>> > + /* Ensure SDRC pins are mux'd for self-refresh */
>>> > + omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
>>> > + omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
>>> > +
>>> > + beagle_display_init();
>>> > + beagle_opp_init();
>>> > + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>>>
>>> Hmmm, I don't think this will work for OMAP because it will not create
>>> the i2c bus as an omap_device. It will only be a plane
>>> platform_deevice. You'll need to have a hook in
>>> of_platform_populate() to create devices the way omap3 infrastructure
>>> expects.
>>>
>>
> This dependency is mentioned in patch series. Since you pointed out this
> issue, I would like to propose following approach for hooking up omap hwmod·
> framework with dt. Though, the current approach focus only on i2c driver, it
> can be extended and generalized as it evolves with other board and
> driver cleanup
> activities. The following changes are not tested and also not compiled, it is
> only proposal I am thinking to implement.
>
> Let me know if you see any serious issues with the approach.
>
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index c1773456..104ef31 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -457,6 +457,8 @@ void of_platform_prepare(struct device_node *root,
> }
> }
>
> +
> +
> #ifdef CONFIG_ARM_AMBA
> static struct amba_device *of_amba_device_create(struct device_node *node,
> const char *bus_id,
> @@ -537,13 +539,60 @@ static const struct of_dev_auxdata
> *of_dev_lookup(const struct of_dev_auxdata *l
> continue;
> if (res.start != lookup->phys_addr)
> continue;
> - pr_debug("%s: devname=%s\n", np->full_name,
> lookup->name);
> + printk("%s: devname=%s\n", np->full_name,
> lookup->name);
> return lookup;
> }
> }
> return NULL;
> }
>
> +static struct omap_device *of_omap_i2c_device_create(struct device_node
> *node,
> + const char *bus_id,
> + void *platform_data,
> + struct device *parent)
> +{
> + struct platform_device *pdev;
> + struct i2c_board_info *i2c_board_info;
> + u8 id;
> +
> + printk("Creating omap i2c device %s\n", node->full_name);
> +
> + if (!of_device_is_available(node))
> + return NULL;
> +
> + id = simple_strtol(bus_id, NULL, 0);
> + pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
> + pdev->dev.of_node = of_node_get(node);
> + if (!pdev->dev.of_node) {
> + speed = 100;
> + } else {
> + u32 prop;
> + if (!of_property_read_u32(pdev->dev.of_node,
> "clock-frequency",
> +
> &prop))
> + speed = prop/100;
> + else
> + speed = 100;
> + }
> + printk("%s : speed->%d\n",__func__, speed);
> +
> + for_each_child_of_node(bus, child) {
> + u32 prop;
> +
> + printk(" create child: %s\n", child->full_name);
> + i2c_board_info =
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
ps: posting again since my mailer has triggered the mail in html format hence
it does not reach some mailing lists.
Hi Grant,
>
On Thu, Jul 14, 2011 at 4:45 AM, Grant Likely wrote:
>>
>> On Thu, Jul 14, 2011 at 7:06 AM, G, Manjunath Kondaiah
>> wrote:
>> >
>> > The generic board file is created and derived from beagle board file.
>> > The beagle board file is migrated to boot from flattened device tree and
>> > the cleanup of generic board file will happen in different stages.
>> >
>> > The changes here focus on i2c device registration through dt and upcoming
>> > patches in the series will adopt i2c driver to use dt registered i2c
>> > devices.
>>
>> Since this is a new board file instead of a modification of an
>> existing one, I recommend *not* trying to completely duplicate the
>> behaviour of the beagle board. Start small with only the registration
>> of the UART and i2c drivers from the device tree and build up
>> functionality until it can be used for all the OMAP3 boards.
>> Otherwise the patch just adds a lot of code that needs to be removed
>> again.
>
agreed. Started with minimal board file with only serial and i2c.
>>
>> >
>> > Signed-off-by: G, Manjunath Kondaiah
>> > ---
>> > arch/arm/mach-omap2/Kconfig | 12 +
>> > arch/arm/mach-omap2/Makefile|2 +
>> > arch/arm/mach-omap2/board-omap3-dt.c| 623
>> > +++
>> > arch/arm/mach-omap2/board-omap3beagle.c | 13 -
>> > 4 files changed, 637 insertions(+), 13 deletions(-)
>> > create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
>> >
>> > diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
>> > index 19d5891..174f6d1 100644
>> > --- a/arch/arm/mach-omap2/Kconfig
>> > +++ b/arch/arm/mach-omap2/Kconfig
>> > @@ -302,6 +302,18 @@ config MACH_OMAP_3630SDP
>> >default y
>> >select OMAP_PACKAGE_CBP
>> >
>> > +config MACH_OMAP3_DT
>> > + bool "Generic OMAP3 board(FDT support)"
>> > + depends on ARCH_OMAP3
>> > + select OMAP_PACKAGE_CBB
>> > + select USE_OF
>> > + select PROC_DEVICETREE
>>
>> Don't select PROC_DEVICETREE
>
ok
>>
>> > +
>> > + help
>> > + Support for generic TI OMAP3 boards using Flattened Device Tree.
>> > + Say Y here to enable OMAP3 device tree support
>> > + More information at Documentation/devicetree
>> > +
>> > config MACH_TI8168EVM
>> >bool "TI8168 Evaluation Module"
>> >depends on SOC_OMAPTI816X
>> > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
>> > index b148077..86e66f7 100644
>> > --- a/arch/arm/mach-omap2/Makefile
>> > +++ b/arch/arm/mach-omap2/Makefile
>> > @@ -178,6 +178,8 @@ obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
>> > obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \
>> > hsmmc.o
>> > obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o
>> > +obj-$(CONFIG_MACH_OMAP3_DT)+= board-omap3-dt.o \
>> > + hsmmc.o
>> > obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \
>> > hsmmc.o
>>
>> This is an odd construct. Tony, why does each board add hsmmc to the
>> oby-y variable instead of it having its own kconfig symbol?
>>
>> > +static void __init omap3_init(void)
>> > +{
>> > + struct device_node *node;
>> > +
>> > + node = of_find_matching_node_by_address(NULL, omap3_dt_intc_match,
>> > + OMAP34XX_IC_BASE);
>> > + if (node)
>> > + irq_domain_add_simple(node, 0);
>> > +
>> > + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
>> > + omap3_beagle_init_rev();
>> > + omap3_beagle_i2c_init();
>> > + platform_add_devices(omap3_beagle_devices,
>> > + ARRAY_SIZE(omap3_beagle_devices));
>> > + omap_display_init(&beagle_dss_data);
>> > + omap_serial_init();
>> > +
>> > + omap_mux_init_gpio(170, OMAP_PIN_INPUT);
>> > + /* REVISIT leave DVI powered down until it's needed ... */
>> > + gpio_request_one(170, GPIOF_OUT_INIT_HIGH, "DVI_nPD");
>> > +
>> > + usb_musb_init(NULL);
>> > + usbhs_init(&usbhs_bdata);
>> > + omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions,
>> > +ARRAY_SIZE(omap3beagle_nand_partitions));
>> > +
>> > + /* Ensure msecure is mux'd to be able to set the RTC. */
>> > + omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
>> > +
>> > + /* Ensure SDRC pins are mux'd for self-refresh */
>> > + omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
>> > + omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
>> > +
>> > + beagle_display_init();
>> > + beagle_opp_init();
>> > + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
>>
>> Hmmm, I don't t
Re: [PATCH 3/4] dt: omap3: add generic board file for dt support
On Thu, Jul 14, 2011 at 7:06 AM, G, Manjunath Kondaiah wrote:
>
> The generic board file is created and derived from beagle board file.
> The beagle board file is migrated to boot from flattened device tree and
> the cleanup of generic board file will happen in different stages.
>
> The changes here focus on i2c device registration through dt and upcoming
> patches in the series will adopt i2c driver to use dt registered i2c
> devices.
Since this is a new board file instead of a modification of an
existing one, I recommend *not* trying to completely duplicate the
behaviour of the beagle board. Start small with only the registration
of the UART and i2c drivers from the device tree and build up
functionality until it can be used for all the OMAP3 boards.
Otherwise the patch just adds a lot of code that needs to be removed
again.
>
> Signed-off-by: G, Manjunath Kondaiah
> ---
> arch/arm/mach-omap2/Kconfig | 12 +
> arch/arm/mach-omap2/Makefile | 2 +
> arch/arm/mach-omap2/board-omap3-dt.c | 623
> +++
> arch/arm/mach-omap2/board-omap3beagle.c | 13 -
> 4 files changed, 637 insertions(+), 13 deletions(-)
> create mode 100644 arch/arm/mach-omap2/board-omap3-dt.c
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 19d5891..174f6d1 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -302,6 +302,18 @@ config MACH_OMAP_3630SDP
> default y
> select OMAP_PACKAGE_CBP
>
> +config MACH_OMAP3_DT
> + bool "Generic OMAP3 board(FDT support)"
> + depends on ARCH_OMAP3
> + select OMAP_PACKAGE_CBB
> + select USE_OF
> + select PROC_DEVICETREE
Don't select PROC_DEVICETREE
> +
> + help
> + Support for generic TI OMAP3 boards using Flattened Device Tree.
> + Say Y here to enable OMAP3 device tree support
> + More information at Documentation/devicetree
> +
> config MACH_TI8168EVM
> bool "TI8168 Evaluation Module"
> depends on SOC_OMAPTI816X
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index b148077..86e66f7 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -178,6 +178,8 @@ obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o
> obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \
> hsmmc.o
> obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o
> +obj-$(CONFIG_MACH_OMAP3_DT) += board-omap3-dt.o \
> + hsmmc.o
> obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \
> hsmmc.o
This is an odd construct. Tony, why does each board add hsmmc to the
oby-y variable instead of it having its own kconfig symbol?
> +static void __init omap3_init(void)
> +{
> + struct device_node *node;
> +
> + node = of_find_matching_node_by_address(NULL, omap3_dt_intc_match,
> + OMAP34XX_IC_BASE);
> + if (node)
> + irq_domain_add_simple(node, 0);
> +
> + omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
> + omap3_beagle_init_rev();
> + omap3_beagle_i2c_init();
> + platform_add_devices(omap3_beagle_devices,
> + ARRAY_SIZE(omap3_beagle_devices));
> + omap_display_init(&beagle_dss_data);
> + omap_serial_init();
> +
> + omap_mux_init_gpio(170, OMAP_PIN_INPUT);
> + /* REVISIT leave DVI powered down until it's needed ... */
> + gpio_request_one(170, GPIOF_OUT_INIT_HIGH, "DVI_nPD");
> +
> + usb_musb_init(NULL);
> + usbhs_init(&usbhs_bdata);
> + omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions,
> + ARRAY_SIZE(omap3beagle_nand_partitions));
> +
> + /* Ensure msecure is mux'd to be able to set the RTC. */
> + omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
> +
> + /* Ensure SDRC pins are mux'd for self-refresh */
> + omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
> + omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
> +
> + beagle_display_init();
> + beagle_opp_init();
> + of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
Hmmm, I don't think this will work for OMAP because it will not create
the i2c bus as an omap_device. It will only be a plane
platform_deevice. You'll need to have a hook in
of_platform_populate() to create devices the way omap3 infrastructure
expects.
> +}
> +
> +static const char *omap3_dt_match[] __initdata = {
> + "ti,omap3-beagle",
> + NULL
"ti,omap3" should be sufficient.
> +};
> +
> +DT_MACHINE_START(OMAP3_DT, "TI OMAP3 (Flattened Device Tree)")
> + .boot_params = 0x8100,
Drop boot_params.
> + .reserve = omap_reserve,
> + .map_io
