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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Thu, 14 Feb 2013, Tony Lindgren wrote:

> * Paul Walmsley <paul@xxxxxxxxx> [130214 12:51]:
> > On Thu, 14 Feb 2013, Tony Lindgren wrote:
> > 
> > > I don't think so as hwmod should only touch the sysconfig space
> > > when no driver has claimed it.
> > 
> > hwmod does need to touch the SYSCONFIG register during pm_runtime suspend 
> > and resume operations, and during device enable and disable operations.  
> > Here's the relevant code:
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/omap_hwmod.c;h=4653efb87a2721ea20a9fe06a30a6c204d6d2282;hb=HEAD#l2157
> > 
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=arch/arm/mach-omap2/omap_hwmod.c;h=4653efb87a2721ea20a9fe06a30a6c204d6d2282;hb=HEAD#l2195
> 
> But that's triggered by runtime PM from the device driver, right?

Yes - for devices with drivers, it will hopefully be called by the 
driver.

> I think it's fine for hwmod to do that as requested by the device
> driver via runtime PM since hwmod is the bus glue making the drivers arch
> independent.
> 
> I think the only piece we're missing for that is for driver to run
> something like pm_runtime_init() that initializes the address space
> to hwmod. 

In the current design, we might be able to do this during the driver's 
first call to pm_runtime_get*().  I think that's the first point that we 
can hook into the PM runtime code.

Once the hwmod code is moved out to be a bus, I'm hoping we can do this 
through the driver making a dev->bus->enable_device() call - similar to 
the way PCI drivers call pci_enable_device(), but not bus-specific.  That 
should remove our current dependency on CONFIG_PM_RUNTIME for OMAP devices 
to work correctly :-(

> Just to recap what we've discussed earlier, the reasons why we want
> reset and idle functions should be in the driver specific header are:
> 
> 1. There's often driver specific logic needed in addition to the
>    syconfig tinkering in the reset/idle functions.

It's been a while since I last tabulated this.  But my recollection was 
that some kind of IP block-specific reset code is needed for about 7% to 
10% of the OMAP IP blocks.

One thing that's unclear to me for the DT case is how we'll bind the 
driver-specific parts of the reset code to the device, particularly in the 
case where there's no driver present.  It should be possible to place an 
initcall in the driver-specific header, but that seems like a hack.  Any 
thoughts on this?

> 2. We need to be able to reset and idle some hardware even if the
>    driver is not compiled in.

Yep.


- Paul
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux