Thread (96 messages) 96 messages, 9 authors, 2012-06-26
STALE5085d

[RFC PATCH 06/11] OMAP2+: use control module mfd driver in omap_type

From: tony@atomide.com (Tony Lindgren)
Date: 2012-06-01 11:35:30
Also in: linux-omap, linux-pm

* Eduardo Valentin [off-list ref] [120528 04:28]:
On Mon, May 28, 2012 at 03:32:50PM +0530, Shilimkar, Santosh wrote:
quoted
On Fri, May 25, 2012 at 6:23 PM, Cousson, Benoit [off-list ref] wrote:
quoted
OK, not really related to that patch, but the previous cpu_is_omap24xx makes
me think of that :-)

What about the omap<X>_check_revision used by cpu_is_XXX?

This call is the very first one to require the control module access in
order to get the ID_CODE inside the control module.

So far it still use that ugly hard coded phys -> virtual address macro that
is sued for that.
Agree with Benoits comment. One way to deal with this is,
store the register offset with init and then just use it here.

That way you can get rid of all cpu_is_XXXX() from this function.
I see. I need to check how this storing would look like.
Probably we can do the storing when the early device gets probed.
As this needs to be initialized very early I'd rather avoid dependencies
to drivers for this. Maybe that register can be read and saved when the
device gets built? It's ioremapped anyways at that point.

That is assuming we don't need to export it to drivers or constantly
read it..

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