Commit Graph

9 Commits

Author SHA1 Message Date
Luiz Otavio O Souza
9d35acacd3 Fix the gpiobus locking by using a more sane model where it isn't necessary
hold the gpiobus lock between the gpio calls.

gpiobus_acquire_lock() now accepts a third parameter which tells gpiobus
what to do when the bus is already busy.

When GPIOBUS_WAIT wait is used, the calling thread will be put to sleep
until the bus became free.

With GPIOBUS_DONTWAIT the calling thread will receive EWOULDBLOCK right
away and then it can act upon.

This fixes the gpioiic(4) locking issues that arises when doing multiple
concurrent access on the bus.
2014-10-31 19:15:14 +00:00
Luiz Otavio O Souza
e72f32cd0f Add a bounds verification to the SCL and SDA pin values.
At attach, print the SCL and SDA pin numbers.

Remove a stray blank line.

Remove the GPIOBUS locking from gpioiic_reset(), it is already called with
this lock held.  This fixes a crash when you try to scan the iicbus with
i2c(8).
2014-05-31 14:27:50 +00:00
Luiz Otavio O Souza
9a2a079a51 Add OFW support to the in tree gpio compatible devices: gpioiic(4) and
gpioled(4).

Tested on RPi and BBB (using the hardware I2C controller and gpioiic(4) for
the I2C tests).  It was also verified for regressions on RSPRO (MIPS/ar71xx)
used as reference for a non OFW-based system.

Update the gpioled(4) and gpioiic(4) man pages with some details and
examples about the FDT/OFW support.

Some compatibility details pointed out by imp@ will follow in subsequent
commits.

Approved by:	adrian (mentor, implicit)
2014-02-13 17:58:52 +00:00
Luiz Otavio O Souza
41ec463c1e Remove unnecessary includes and an unused softc variable. While here apply
two minor style(9) fixes.

Approved by:	adrian (mentor)
2013-12-06 17:49:34 +00:00
Adrian Chadd
74ab90b71e Fix broken locking that I introduced in the previous commit. 2011-12-20 03:25:11 +00:00
Adrian Chadd
ddd7699151 Remove these locks - they aren't strictly needed and cause measurable
performance issues.

* Access to the GPIO bus is already locked by requesting
  and releasing the bus - thus the lock isn't really needed
  for each GPIO pin change.
* Don't lock and unlock the GPIO bus for -each- i2c access -
  the i2c bus code is already doing this by calling the upper
  layer callback to request/release the bus. This thus locks
  the bus for the entirety of the transaction.

TODO:

* Further verify that everything is correctly requesting/
  releasing the GPIO bus.
* Look at how to lock the GPIO pin configuration stuff,
  potentially by locking/unlocking the bus at the gpiobus
  layer.
2011-12-20 00:33:56 +00:00
Adrian Chadd
935225501b Modify the GPIO i2c bus code to allow for arbitrary data/clock
pins, rather than defaulting to 0 and 1.

This way the pin order can be reversed.  It is reversed with the
TP-Link TL-WR1043nd.

Submitted by:	Stefan Bethke <stb@lassitu.de>
2011-12-04 12:10:24 +00:00
Oleksandr Tymoshenko
5f958b8534 Fix legal staff in GPIO sources:
- license clause now contains "AUTHOR AND CONTRIBUTORS"
        instead of just "AUTHOR"
    - Add license/copyright to gpioc.c

Spotted by: Edward Tomasz Napierala, Andrew Turner
2010-09-29 20:53:33 +00:00
Oleksandr Tymoshenko
6b34b16ea5 Initial GPIO bus support. Includes:
- GPIO bus controller interface
  - GPIO bus interface
  - Implementation of GPIO led(4) compatible device
  - Implementation of iic(4) bus over GPIO (author: Luiz Otavio O Souza)

Tested by: Luiz Otavio O Souza, Alexandr Rybalko
2010-09-28 03:24:53 +00:00