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. > >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. -- balbi
Attachment:
signature.asc
Description: Digital signature
