[RFC/NOT FOR MERGING 2/3] serial: omap: remove hwmod dependency

[Felipe Balbi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130216/6506aeec/attachment.sig>