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@xxxxxxxxxxxx> [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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
