* Suman Anna <s-anna@xxxxxx> [170822 11:45]: > On 08/22/2017 12:37 PM, Tony Lindgren wrote: > > I think a better way to fix this would be to make sure the module > > is enabled during the unmapping phase of the MMUs. If there is no > > driver left at that point to call pm_runtime_get() on the module, > > do it via pdata-quirks.c using struct iommu_platform_data? > > The problem is because there is no reference counting on modulemode > programming unlike clocks or omap_device pm_domain callbacks. The IOMMU > driver already has an active pm_runtime_get() invoked earlier and > invoking another wouldn't result in any change. Hmm iommu driver has pm_runtime_get() on which modules? Can you please point me to that code too so I can follow.. Or is there maybe a single module shared across multiple devices? If so, we need a minimal module wrapper driver. You can do what we already do for musb on am335x in drivers/usb/musb/musb_am335x.c. A single module has two musb instances and a shared cppi41 dma instance. See also it's related entries in am33xx.dtsi. Note that the clkctrl clocks are available now as clocks, so they could be directly enabled for testing. See omap4_tesla_clkctrl_regs and omap4_ducati_clkctrl_regs if that helps. > The remoteproc driver is only dealing with its resets and hwmod while > the IOMMU driver is dealing with its dedicated reset. The PRCM registers > though are a single set between the two. Sorry but I'm having hard time following which driver claims which modules :) Regards, Tony -- 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
