Re: [PATCH 06/23] ARM: OMAP: add OMAP5 DSI muxing

* Tomi Valkeinen [off-list ref] [140429 09:33]:

On 29/04/14 19:19, Tomi Valkeinen wrote:

quoted

On 29/04/14 18:05, Tony Lindgren wrote:

quoted

quoted

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.

Right, but it means that the driver will contain platform specific code
for all the omap revisions it supports. Isn't that wrong?

I already have a patch for DSI that uses the syscon-method, and it works
fine. But it's quite ugly, imo, to fiddle with the OMAP control
registers in a driver.

Anything using the system control module registers should be a separate
driver. And it should ideally be implemeting some Linux generic framework
that the consumer driver can then use. That leaves out the need to export
custom functions.

I guess we don't have a PHY framework for displays though, so how about
just a separate minimal driver under drivers/video/omap2 that uses the
syscon?
 

Oh, also, if I do that, I need to know both the SoC version and the DSS
version in the driver.

Don't you get all you need in the compatible string? Something like
compatible ti,dss-phy-omap5?

Regards,

Tony