On Friday 11 October 2013 09:06 PM, Tony Lindgren wrote:
What the pin control driver should do is control the pins. Whether the registers
are spread out in the entire IO-memory does not matter. We did have one system
which placed the IO-muxing together with each peripheral (!) and I did
still want
that to be handled by a single pinctrl driver picking out windows to all these
IO-ranges.
Things like the PRM which has (my guess) a gazillion registers related to its
deep-core SoC stuff should be handled by things like
drivers/mfd/syscon.c, which means it is dead simple for some other driver
using "just this one register" in that range to get a handle at it and poke it
using syscon_node_to_regmap() (just derference an ampersand ref)
syscon_regmap_lookup_by_compatible() (use a compatible string)
all returning a regmap * that you can use to poke these registers.
The register handling is fine. But how do we deal with resource handling?
e.g. the block that has the deep-core registers might need to be clocked or powered
before the registers can be accessed.
Right, that's the key issue here. The register access would have to be conditional
based on the hardware modules PM state. Otherwise we'll have hard to trace hangs
and oopses.
Hi Tony,
How are the clocks/power state currently handled in case of omap4_pmx_core,
omap4_pmx_wkup register access via pinctrl-single ?
Thanks and Regards,
Balaji T K
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
