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
