On Wed, 2013-10-16 at 00:02 +0200, Linus Walleij wrote:
> On Mon, Oct 14, 2013 at 7:29 PM, Darren Hart wrote:
>
> > In the case of the gpio-sch driver, each operation for direction and
> > value require a lock/unlock. There is no API in gpiolib to lock the chip
> > as a whole and then make lockle
On Mon, Oct 14, 2013 at 7:29 PM, Darren Hart wrote:
> In the case of the gpio-sch driver, each operation for direction and
> value require a lock/unlock. There is no API in gpiolib to lock the chip
> as a whole and then make lockless calls.
I don't see why the gpiolib should handle a lock? The l
On Fri, 2013-10-11 at 16:02 +0200, Linus Walleij wrote:
> On Mon, Sep 30, 2013 at 7:29 PM, Darren Hart wrote:
>
> > I'm currently working with a graphics driver that makes use of 2 GPIO
> > pins for EDID communication (clock and data). In order to coexist
> > peacefully with the driver for the GP
On Mon, Sep 30, 2013 at 7:29 PM, Darren Hart wrote:
> I'm currently working with a graphics driver that makes use of 2 GPIO
> pins for EDID communication (clock and data). In order to coexist
> peacefully with the driver for the GPIO chip, it must use gpiolib to
> request the lines, set direction
On Mon, Sep 30, 2013 at 10:29:26AM -0700, Darren Hart wrote:
> Is there a best practice for dealing with this kind of configuration?
> If not, would it make sense to add optional gpiochip-level lock/unlock
> and lockless direction and value operations to the gpiochip function
> block?
Another th
I'm currently working with a graphics driver that makes use of 2 GPIO
pins for EDID communication (clock and data). In order to coexist
peacefully with the driver for the GPIO chip, it must use gpiolib to
request the lines, set direction, and set values. This results in a
spinlock/unlock for every
6 matches
Mail list logo
