lkml.org 
[lkml]   [2011]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: pinctrl discussions @ Linaro Connect, and also requesting GPIOs
    From
    On 12 November 2011 19:47, Linus Walleij <linus.walleij@linaro.org> wrote:
    > On Sat, Nov 12, 2011 at 12:22 PM, Thomas Abraham
    > <thomas.abraham@linaro.org> wrote:
    >
    >> Samsung SoC's use two pin functions out of 4/8/16 pin functions to
    >> represent that a pin is used as a gpio. For instance, function 0 means
    >> pin is used as a gpio input, and function 1 means pin is used as gpio
    >> output. A pin cannot support both input and output mode at the same
    >> time.
    >>
    >> The existing pinmux_[request|free]_gpio() functions can specify that a
    >> pin has to be set in gpio function mode, but lack the provision to
    >> select input or output mode for the gpio.
    >
    > OK then this needs fixing if this API is to persist.
    >
    >> The alternative approach of
    >> using pin functions to select gpio-input or gpio-output will be used
    >> for samsung pinmux drivers.
    >>
    >> This means the gpio_direction_[input|output] api's would remain unused
    >> on samsung platforms. And existing platforms already using this api
    >> will have to be modified to use the pinmux api to select the direction
    >> of the gpio pin. And the role of gpio_request will seem redundant when
    >> used along with pinmux_get().
    >
    > This does not seem right. Why should it not use
    > gpio_direction_[input|output] to select whether the pin is used
    > for input or output like everyone else?

    The gpio_direction_[input|output]() internally sets the pin function
    (by writing to pin function register) to either gpio input|output.
    Since the gpio calls should stop writing to the pin function registers
    (since we have pinmux driver now), there should be way for
    gpio_direction_[input|output]() to inform pinmux driver to set gpio in
    input|output mode.

    But this cannot be achieved with existing pinctrl/pinmux api and so
    gpio_direction_[input|output]() will not be used and separate pin
    function for gpio input/output setup and used in the pinmux driver.

    >
    > This will just lead to trouble with shared HW blocks where
    > one use gpio_direction_[input|output] to select the direction
    > while another one will use some pinctrl API.

    Yes, that is true. So gpio_direction_[input|output]() would not be
    used to setup the gpio direction anymore.

    >
    > We need one of two things:
    >
    > 1. pinmux_[request|free]_gpio() to pass direction to the
    >  core and driver, or

    This approach seems to be better.

    >
    > 2. A use pattern like this:
    >  pmx = pinmux_get(dev, "gpio-1-in");
    >  /* Use as input */
    >  pinmux_put(pmx);
    >  pmx = pinmux_get(dev, "gpio-1-out");
    >  /* Use as output */
    >  etc
    >
    > The latter seems hopeless to maintain. So the external call
    > pinmux_[request|free]_gpio() needs to be kept around,
    > and it needs to be called *internally* by GPIO drivers to set
    > up pins, so as to avoid hazzle.
    >
    > In my opinion atleast...

    Yes. I agree with that.

    >
    > Linus Walleij
    >

    Thank you LinusW.

    Regards,
    Thomas.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2011-11-12 15:45    [W:0.027 / U:147.912 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site