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
5 matches
Mail list logo
