* Tomi Valkeinen <tomi.valkeinen@xxxxxx> [140429 09:33]: > On 29/04/14 19:19, Tomi Valkeinen wrote: > > On 29/04/14 18:05, Tony Lindgren wrote: > > > >>> 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 -- 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
