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<grant.lik...@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?
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
