linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Frank Schäfer" <fschaefer.oss@googlemail.com>
To: Antti Palosaari <crope@iki.fi>,
	Mauro Carvalho Chehab <mchehab@redhat.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>
Subject: Re: [PATCH 0/3] em28xx: clean up end extend the GPIO port handling
Date: Sat, 13 Apr 2013 17:30:49 +0200	[thread overview]
Message-ID: <51697A29.5030307@googlemail.com> (raw)
In-Reply-To: <20130413112517.40833d48@redhat.com>

Am 13.04.2013 16:25, schrieb Mauro Carvalho Chehab:
> Em Sat, 13 Apr 2013 16:15:39 +0300
> Antti Palosaari <crope@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.

Right.

> I never took the time to take a look on what methods gpiolib provides.
> Maybe it will bring some benefits. I dunno.
>
> 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.
...
> However, for that to happen, one question should be answered: what
> benefits would be obtained by using gpiolib?
>

I've checked the documentation about the gpio and led frameworks a few
weeks ago to find out if it makes sense to use them for the
gpio/buttons/led stuff of the VAD Laplace webcam.
AFAICS, there are no benfits as long as you are dealing with these
things internally. It just increases the code size and adds an
additional dependency in this case.
Of course, the situation is different when there is an interaction with
other modules or userspace. In that case using gpiolib could make sense.
I don't know which case applies to the LAN stuff, but for the
buttons/leds it's the first case.

Regards,
Frank



  parent reply	other threads:[~2013-04-13 15:29 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-13  9:48 [PATCH 0/3] em28xx: clean up end extend the GPIO port handling Frank Schäfer
2013-04-13  9:48 ` [PATCH 1/3] em28xx: give up GPIO register tracking/caching Frank Schäfer
2013-04-13 14:41   ` Mauro Carvalho Chehab
2013-04-13 15:33     ` Frank Schäfer
2013-04-13 17:04       ` Mauro Carvalho Chehab
2013-04-13 17:46         ` Frank Schäfer
2013-04-13 18:08           ` Mauro Carvalho Chehab
2013-04-14 20:35             ` Frank Schäfer
2013-04-15 12:51               ` Mauro Carvalho Chehab
2013-04-15 14:11                 ` Antti Palosaari
2013-04-15 16:26                 ` Frank Schäfer
2013-04-15 23:01                   ` Mauro Carvalho Chehab
2013-04-23 16:58                     ` Frank Schäfer
2013-04-13 18:19           ` Frank Schäfer
2013-04-13 18:41             ` Frank Schäfer
2013-04-13  9:48 ` [PATCH 2/3] em28xx: add register defines for em25xx/em276x/7x/8x GPIO registers Frank Schäfer
2013-04-13  9:48 ` [PATCH 3/3] em28xx: add helper function for handling the GPIO registers of newer devices Frank Schäfer
2013-04-13 13:15 ` [PATCH 0/3] em28xx: clean up end extend the GPIO port handling Antti Palosaari
2013-04-13 14:25   ` Mauro Carvalho Chehab
2013-04-13 14:37     ` Antti Palosaari
2013-04-14  1:32       ` Mauro Carvalho Chehab
2013-04-14 19:32         ` Antti Palosaari
2013-04-15 14:40           ` Mauro Carvalho Chehab
2013-04-13 15:30     ` Frank Schäfer [this message]
2013-04-13 15:34       ` Devin Heitmueller
2013-04-13 16:21         ` Antti Palosaari
2013-04-13 16:54           ` Devin Heitmueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51697A29.5030307@googlemail.com \
    --to=fschaefer.oss@googlemail.com \
    --cc=crope@iki.fi \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).