On 04/13/2013 05:25 PM, Mauro Carvalho Chehab wrote:
Em Sat, 13 Apr 2013 16:15:39 +0300
Antti Palosaari <cr...@iki.fi> escreveu:
On 04/13/2013 12:48 PM, Frank Schäfer wrote:
Patch 1 removes the unneeded and broken gpio register caching code.
Patch 2 adds the gpio register defintions for the em25xx/em276x/7x/8x
and patch 3 finally adds a new helper function for gpio ports with separate
registers for read and write access.
I have nothing to say directly about those patches - they looked good at
the quick check. But I wonder if you have any idea if it is possible to
use some existing Kernel GPIO functionality in order to provide standard
interface (interface like I2C). I did some work last summer in order to
use GPIOLIB and it is used between em28xx-dvb and cxd2820r for LNA
control. Anyhow, I was a little bit disappointed as GPIOLIB is disabled
by default and due to that there is macros to disable LNA when GPIOLIB
is not compiled.
I noticed recently there is some ongoing development for Kernel GPIO. I
haven't looked yet if it makes use of GPIO interface more common...
I have conflicting opinions myself weather we should use gpiolib or not.
I don't mind with the fact that GPIOLIB is disabled by default. If all
media drivers start depending on it, distros will enable it to keep
media support on it.
I never took the time to take a look on what methods gpiolib provides.
Maybe it will bring some benefits. I dunno.
Compare to benefits of I2C bus. It offers standard interface. Also it
offers userspace debug interface - like I2C also does.
Just looking at the existing drivers (almost all has some sort of GPIO
config), GPIO is just a single register bitmask read/write. Most drivers
need already bitmask read/write operations. So, in principle, I can't
foresee any code simplification by using a library.
Use of lib interface is not very practical inside of module, however it
could be used. Again, as compared to I2C there is some bridge drivers
which do some I2C access using I2C interface, even bridge could do it
directly (as it offers I2C adapter). I think it is most common to do it
directly to simplify things.
Also, from a very pragmatic view, changing (almost) all existing drivers
to use gpiolib is a big effort.
It is not needed to implement for all driver as one go.
However, for that to happen, one question should be answered: what
benefits would be obtained by using gpiolib?
Obtain GPIO access between modules using standard interface and offer
handy debug interface to switch GPIOs from userspace.
You could ask why we use Kernel I2C library as we could do it directly
:) Or clock framework. Or SPI, is there SPI bus modeled yet?
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
