On Saturday 16 February 2013 02:52 PM, Felipe Balbi wrote:
Hi,
On Sat, Feb 16, 2013 at 02:47:45PM +0530, Santosh Shilimkar wrote:
On Sat, Feb 16, 2013 at 11:31:21AM +0530, Santosh Shilimkar wrote:
The main goal is to avoid duplicating data both in hwmod and DT.
That's pretty much solved as we can have the driver probe populate
the common data for hwmod from DT as Santosh has already demonstrated.
Then we also want the driver specific idle and reset code to be done
in the drivers rather than in hwmod and glue it together with hwmod
using runtime PM. The biggest issue there is how do we reset and idle
some piece of hardware for PM purposes when there's no driver loaded.
right, this will be a tough nut to crack.
I guess the only way would be reset all IPs early in the boot process,
before even creating the platform-devices. Can we do that ? I mean, from
omap_device_build_from_dt() we have access to address space of all
devices, through ti,hwmods we can figure out which hwmods are linked to
that particular device, so whenever you build a device, you could just
call _reset().
Thats what we do today and it works perfectly. As per Tony's suggestion,
we need to move the non-probed devices reset and idle setup to late_init
which is also doable.
In that case when probed driver calls runtime_get(), we reset that
device and setup the idle settings. And remainder of the devices
are managed in late_init().
what's the point in moving it to late_initcall() ? It makes no
difference, if no driver binds to that device it will stay in reset
anyway. Maybe what we're missing is properly idling (not exactly) all
devices before driver probe kicks in.
I think it is largely reducing the early init dependencies and also
reducing the role of platform code who today takes care of every
device idle and reset initialization. That way late_init() will
only have to care about the devices which are not probed by
drivers.
Tony, Is that right ?
Makes not much difference, except that you will have to keep track of
which devices have gotten a driver probed and which haven't.
IMO, it sounds a lot better to reset everything early on, so we know
we're starting at a known stage (and thus drop all bootloader
dependencies) then to follow the other route.
I tend to agree with you. This was exactly the reason Paul and Benoit
added that support first up as part of early init code.
The difficult part is handling special reset requirements for devices
without drivers as there'd be no ->runtime_reset() to call.
I don't think that requirement exists so if we address the driver
requirement, we are good. Even otherwise also, it can be managed
Look back at what you want to do at late_initcall() time. You want to
reset all devices which haven't gotten a driver bound to them.
from platform code.
right, the you will need even more data in hwmod to let it know about
the special devices. /me wonders when the amount of data will actually
decrease.
Well that is already supported. There is no need to add any additional
information. Device which are initialized, there state is set as
initialized. So the late_init() will just have to iterate over
un-initialised devices.
Just to be clear, I am also in favor of just keeping that part as it
is today but we were exploring other options based on comments from
Tony during OMAP5 data review.
Regards,
Santosh
--
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
