[PATCH 3/4] dt: omap3: add generic board file for dt support

[Rajendra Nayak]

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<grant.likely at secretlab.ca>   [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.
>