* Linus Walleij <linus.walleij@xxxxxxxxxx> [130613 08:35]: > On Thu, Jun 13, 2013 at 4:41 PM, Balaji T K <balajitk@xxxxxx> wrote: > > > You mean regulator via pinctrl APIs, I think It will just move the code > > from omap_hsmmc to a new regulator file with it own init data for pinctrl. > > No I'm not saying you should use pinctrl as a "back-end" for this. > I mean you shall instantiate a regulator and let the callback ops > vtable for that regulator poke these bits. The interface to omap_hsmmc.c should be the regulator framework. This is because it allows us to clean up all the messed up before and after functions that really implement various GPIO regulators etc. > > It thought pinctrl-single,bits in pinctrl-single.c is introduced > > precisely for such misc control register which has bit configuration > > affecting different module i/o pads. > > No. If we go down that road *anything* that is connected to a > pad becomes part of the pinctrl subsystem, then pinctrl-single > becomes some kind of hardware abstraction or BIOS, and that > is *not* the intent. It is only supposed to deal with the bits > there that are 100% related to what pinctrl does, nothing else. Sounds like the way to go is to do a standalone regulator driver that optionally uses pinctrl-single,bits. But only for the bits in the PBIAS register that are 100% related to pinctrl. In any case the PBIAS regulator driver should be a separate driver as it may need to be a child of the SCM driver for PM needs in the future. 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
