Thread (19 messages) 19 messages, 3 authors, 2017-10-12
STALE3173d

[PATCH 5/8] ARM: OMAP4: hwmod_data: Remove modulemode from IPU/DSP hwmods

From: tony@atomide.com (Tony Lindgren)
Date: 2017-08-22 19:24:27
Also in: linux-omap

* Suman Anna [off-list ref] [170822 11:45]:
On 08/22/2017 12:37 PM, Tony Lindgren wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help