* Linus Walleij <linus.wall...@linaro.org> [130613 08:35]:
> On Thu, Jun 13, 2013 at 4:41 PM, Balaji T K <balaj...@ti.com> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to