Messages in this thread | | | From | Linus Walleij <> | Date | Thu, 28 Jun 2018 16:25:46 +0200 | Subject | Re: [PATCH 2/3] pinctrl: msm: Mux out gpio function with gpio_request() |
| |
On Fri, Jun 22, 2018 at 8:29 PM Bjorn Andersson <bjorn.andersson@linaro.org> wrote: > On Fri 22 Jun 10:58 PDT 2018, Bjorn Andersson wrote: > > On Mon 18 Jun 13:52 PDT 2018, Stephen Boyd wrote: > > > > > We rely on devices to use pinmuxing configurations in DT to select the > > > GPIO function (function 0) if they're going to use the gpio in GPIO > > > mode. Let's simplify things for driver authors by implementing > > > gpio_request_enable() for this pinctrl driver to mux out the GPIO > > > function when the gpio is use from gpiolib. > > > > > > Cc: Bjorn Andersson <bjorn.andersson@linaro.org> > > > > Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> (...) > While both patch 2 and 3 are convenient ways to get around the annoyance > of having to specify a pinmux state both patches then ends up relying on > some default pinconf state; which I think is bad.
Nothing stops you from setting up a default conf in this callback though.
But admittedly this call was added for simpler hardware.
> Further more in situations like i2c-qup (downstream), where the pins are > requested as gpios in order to "bitbang" a reset this would mean that > the driver has to counter the convenience; by either switching in the > default pinmux at the end of probe or postponing the gpio_request() to > the invocation of reset and then, after issuing the gpio_release, > switching in the default pinmux explicitly again.
That's a bigger problem. If the system is using device and GPIO mode orthogonally, it'd be good to leave like this.
Yours, Linus Walleij
| |