Hi, On Fri, Feb 15, 2013 at 12:14:29, Balbi, Felipe wrote: > Hi, > > On Thu, Feb 14, 2013 at 08:47:53PM +0000, Paul Walmsley wrote: > > Hi, > > > > 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 > > > > Drivers shouldn't touch their IP block's SYSCONFIG registers. They don't > > why not ? It's part of the driver's address space anyway. It's not part > of the IP in question (usb, ethernet, etc) but it's part of the TI > wrapper which usually involves a bridge (ocp2scp, ocp2axi, etc) plus the > TI-specific integration registers (revision, sysc, syss...). > > So they're not part of the licensed IP, but they're part of the TI > wrapper around those. > That's all the more reason to not allow the drivers to touch the SYSCONFIG register. We have IPs like EDMA, PWMSS, McASP etc which are common to Davinci and OMAP. The integration approach was different in the past and now if we want the same driver to work on both the platforms we have to keep the code for taking care of the integration details out of the drivers. IMO omap_hwmod does an excellent job of taking care of all or rather most of the IP integration idiosyncrasies. I really don't understand why people make a big fuss about hwmod. With the right SoC data things just work. Most of the driver authors don't take the pains to understand how the SoC PM gets impacted by toggling a few bits in SYSCONFIG and hence it's best to abstract away all the critical pieces out of drivers. For specific cases like custom reset handling I think it make much more sense to extend runtime PM that already build upon the hwmod code for OMAP. The drivers shouldn't have to worry about the integration details. Trying to shove a common piece of code into all the drivers is equivalent to taking a huge step backwards in the ongoing consolidation not just across OMAP and AMxx parts but also across Davinci and OMAP. Regards, Vaibhav -- 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
