* Tomi Valkeinen [off-list ref] [140428 22:26]:

On 28/04/14 19:45, Tony Lindgren wrote:

quoted

* Tomi Valkeinen [off-list ref] [140427 23:53]:

quoted

On 25/04/14 18:31, Tony Lindgren wrote:

quoted

Chances are any mux register in the syscon area already works with
pinctrl-single,pins or pinctrl-single,bits option. The ones in the
padconf area should be already mapped so the driver just has to
request them.

If using the padconf (say omap4_padconf_global for omap4), doesn't that
mean we need to have platform specific bits in the driver? Isn't that
something we've been trying to remove all the time?

No, it's all done in a Linux generic way during driver probe, see
drivers/base/pinctrl.c. You just need to define the default pins
in the .dts files. If you need dynamic remuxing in the driver,
you can define other named states that the driver can then toggle
with pinctrl_select_state().

omap4_padconf_global is a syscon node, not pinctrl. As syscon just gives
a raw regmap to its memory area, the driver needs to know about the OMAP
control registers to use it.

That would be probably best set up the same way we have already set up
for example omap4_padconf_global: tisyscon@4a1005a0. Then drivers can
access it using regmap, see how drivers/regulator/pbias-regulator.c
sets up the pbias regulator with regmap for MMC.
 

Pinctrl-single cannot be used for CONTROL_DSIPHY register, as the
register contents are a bit funny and DSI1 and DSI2 bits are mixed
together. And CONTROL_DSIPHY is already in the memory region defined by
the omap4_padconf_global, so I guess it wouldn't be good to map parts of
the same memory region in a pinctrl node.

If it's more than a mux, then it should not be set up as a pinctrl
register. Looks like CONTROL_DSIPHY is already available for drivers
via regmap as it falls into the *_padconf_global mappings for omap4
and omap5.

Regards,

Tony