Thread (36 messages) 36 messages, 7 authors, 2013-04-04
STALE4849d

[PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data

From: tony@atomide.com (Tony Lindgren)
Date: 2013-01-21 18:01:14
Also in: linux-omap

* Santosh Shilimkar [off-list ref] [130121 07:09]:
quoted
So I looked at this one with help of Rajendra. We can get rid of the
IRQ and DMA data(needs DMA biding updates) easily. The address
space though is needed since hwmod code uses it to setup the
sysconfig registers.
OK great. The address space tinkering in hwmod code should be
moved to be done in the drivers.

As discussed earlier, there should be a driver specific reset
function driver_xyz_reset() in the driver header file so the
hwmod code can call it too in a late_initcall if no driver is
loaded.
Extracting that from DT code seems to be really expensive and
ugly [1]. I am yet to try out DMA lines removal but that seems
to be doable by pulling Vinod'd DMA engine branch and updating
DT file.
The overhead here does not matter as it should only happen in a
late_initcall and only for some of the drivers. For that to
happen we just need to go through the list of modules not yet
probed. We also need to have some locking in the driver specific
reset function to avoid races with the loadable modules.
Whats your suggestion on address space part ?
Let's add the code to hwmod to extract it from DT so hwmod code
can call the driver specific reset function defined in the driver
header. That way we can start moving the driver code out of hwmod
one driver at a time.

Note that the ioremapping should be done in the driver specific
reset function, not in hwmod code. We just need to pass the
iorange in a struct resource to the driver specific reset function.

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