+ Tero, Rajendra, Kevin
On Friday 15 February 2013 12:16 PM, Felipe Balbi wrote:
On Thu, Feb 14, 2013 at 02:47:10PM -0800, Tony Lindgren wrote:
* Paul Walmsley <paul@xxxxxxxxx> [130214 13:44]:
Hi,
On Thu, 14 Feb 2013, Paul Walmsley wrote:
So instead of something bus-specific like that, a better way would be to
use something like:
va = dev->bus->ioremap( ... );
va = dev->bus->iounmap( ... );
Something like this is what I was thinking. Obviously there would be more
patches needed, for the various arches, etc.; and I'm not convinced that
the function pointer init is done at the right time yet. Comments welcome.
- Paul
From: Paul Walmsley <paul@xxxxxxxxx>
Date: Thu, 14 Feb 2013 13:49:58 -0700
Subject: [PATCH] EXPERIMENTAL: device/ARM: allow buses to override ioremap*()
and iounmap()
On some hardware, such as OMAP, the bus abstraction code needs to call
ioremap(), since some SoC-integration registers are located in the
device address space. But generic device drivers should be able to
call ioremap() from driver code, for the majority of situations where
this isn't necessary. This experimental patch allows Linux bus abstraction
code to override all of the ioremap*() and iounmap() functions. In the OMAP
case, this would be used to return the previously-mapped address range from
the bus code, when called for the device's register area. This would avoid
a duplicate TLB mapping for that space.
This might also be useful as a generic replacement for pci_ioremap_bar().
Compile-tested only.
The other option could be to allow custom ioremap function pointers
based on address range in __arm_ioremap_pfn_caller() the same way as
the SoC specific static mappings are allowed. That would require adding
a function pointer to struct map_desc.
Maybe that would do the trick?
I'm not sure we should even try that. I mean, eventually (maybe in 100
years) we wouldn't mach-* at all and even struct map_desc would be
dynamically initialized by data passed in via DTB, right ? Just consider
Arnd's patch for the "machine_desc-less" DT boot. If we add a function
pointer to struct map_desc, it will just become yet another function
pointer to be removed later.
On the same thread, it was also mentioned that, "machine_desc-less" DT
boot is for simple machines. I have looked that aspect bit more.
Considering the amount of callbacks OMAP uses, it is not practical.
Ofcourse am also not in favor of adding another function pointer
stuff here.
We should get rid of dual ioremap() and the method suggested by Paul
seems to be reasonable.
Sysconfig handling is very tightly coupled with PRCM. I agree with Paul
that hardware should have mapped it in separate address space. So
whichever framework manages the PRCM, should also manage sysconfig.
Refer all the issues around sysconfig for IP's like USB, UART
and they are directly PRCM issues.
We should be able to work around the IP integration issues
around problematic IPs like UART, USB with some profile knowledge
which can be handled by runtime PM transparently. It should have
been done that way in first place instead of functions pointers
which today break the Device Tree builds directly.
As I mentioned in OMAP5 data series, we are now able to remove the
IO_resource information ( Address space, IRQ data, DMA lines) from
from hwmod data and extract it from device Tree. Thats a good
point.
Next one is getting rid off sysconfig function pointers which drivers
are using and handle those issues using runtime_pm APIs. Idea is, IP
gives profile like...
e.g
McSPI1 -> Smart Idle always
UART -> no_idle(runtime_get) and smart_idle(runtime_put)
mUSB --> no_idle(runtime_get) and force_idle(runtime_put)
Then the last one is custom reset function for broken IPs. For this
one as well if we can add a hook in runtime framework, then it
can be handled without direct function calls.
Regards,
Santosh
Regards
Santosh
--
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
