[lkml]   [2011]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction
    On Mon, Feb 14, 2011 at 07:35:02PM +0000, Alan Cox wrote:
    > > What is the use-case for alt_func? From the point of view of a GPIO
    > > driver, I don't think it cares if the pin has been dedicated to
    > Currently it doesn't.
    > However the moment it starts setting input and output itself on requests
    > then it does because it may kick the pin out of alt_func mode when you
    > merely want to request it so you know which pin to stick into alt_func
    > mode, or to find a mapping. The current situation is an "ignorance is
    > bliss" one, but making it smarter backfires. We have the same problem
    > with unknown state - if I have a set of pins some of whose state is known
    > at boot time then I can't now provide a get_direction interface because
    > of the lack of states. At the very least we need input/output/godknows
    > where the latter means the gpio_request code keeps its nose out.

    Not quite; the gpio api is only about discrete gpios. If a particular
    pin is dedicated to another non-gpio purpose, then from the POV of the
    gpio api, the pin is disconnected from the outside world and any
    twiddling of it just won't do anything. If an alt_func has any driver
    behaviour impact, then it needs to be handled internal to the driver.

    > reconfigure_resource();
    > see_if_we_own_it()
    > is simply the wrong order for a resource.

    Yes, this is broken. gpio_request() should not change the state of
    the resource. I don't see anything in gpiolib that currently does

    > The second problem is that in many cases you need to call gpio_request to
    > know you have the pin yourself before you can set the direction. That
    > means forcing the direction in gpio_request is daft - you force an
    > undefined value that cannot yet safely be set in all cases.
    > At the moment the lack of alt_func also has some strange effects and you
    > end up with code like
    > foo_firmware_update()
    > {
    > /* Reserve the line for alt_func use for the moment */
    > gpio_request(GPIO_FOO, "blah");
    > random_gpio_driver_specific_altfunc_foo();
    > do stuff();
    > random_gpio_driver_specific_altfunc_foo();
    > gpio_free(GPIO_FOO);
    > /* Now available again for its normal GPIO use */
    > }
    > and that means you can't generalise dynamic access to a shared GPIO pin
    > without extra hardcoded knowledge.

    I don't follow the argument. Of course you have to do weird hardcoded
    things when a gpio pin has to be shared between multiple purposes, but
    that is also a weird corner case that won't fit any kind of common
    pattern. I don't see the above code snippet as a problem.


     \ /
      Last update: 2011-03-06 11:23    [W:0.028 / U:1.104 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site