* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [140428 22:26]: > On 28/04/14 19:45, Tony Lindgren wrote: > > * Tomi Valkeinen <tomi.valkeinen@xxxxxx> [140427 23:53]: > >> On 25/04/14 18:31, Tony Lindgren wrote: > >> > >>> 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 -- 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
