On 10/31/2012 07:59 PM, Grant Likely wrote:
>> Pin direction currently needs to be set up separately, analogous to
>> requesting gpios. Need to document this better, right. The assumption is
>> that I/O needs to be efficient primarily, before bloating the API with
>> direction functions. Or should
On Wed, Oct 31, 2012 at 8:30 PM, Mark Brown
wrote:
> On Wed, Oct 31, 2012 at 04:00:17PM +0100, Grant Likely wrote:
>
>> For the API, I don't think it is a good idea at all to try and
>> abstract away gpios on multiple controllers. I understand that it
>> makes life a lot easier for userspace to ab
On 19:59 Wed 31 Oct , Grant Likely wrote:
> Hi Roland
>
> On Wed, Oct 31, 2012 at 6:19 PM, Roland Stigge wrote:
> > On 10/31/2012 04:00 PM, Grant Likely wrote:
> >> For the API, I don't think it is a good idea at all to try and
> >> abstract away gpios on multiple controllers. I understand th
On Wed, Oct 31, 2012 at 04:00:17PM +0100, Grant Likely wrote:
> For the API, I don't think it is a good idea at all to try and
> abstract away gpios on multiple controllers. I understand that it
> makes life a lot easier for userspace to abstract those details away,
> but the problem is that it hi
Hi Roland
On Wed, Oct 31, 2012 at 6:19 PM, Roland Stigge wrote:
> On 10/31/2012 04:00 PM, Grant Likely wrote:
>> For the API, I don't think it is a good idea at all to try and
>> abstract away gpios on multiple controllers. I understand that it
>> makes life a lot easier for userspace to abstract
Hi Linus,
thanks for your notes, comments below:
On 10/31/2012 03:06 PM, Linus Walleij wrote:
>> +struct gpio_block *gpio_block_create(unsigned *gpios, size_t size,
>> +const char *name)
>> +{
>> + struct gpio_block *block;
>> + struct gpio_block_ch
Hi Grant,
thank you for your feedback!
Notes below.
On 10/31/2012 04:00 PM, Grant Likely wrote:
> Linus and I just sat down and talked about your changes. I think I
> understand what you need to do, but I've got concerns about the
> approach. I'm already not a big fan of the sysfs gpio interface
On Sun, Oct 28, 2012 at 9:46 PM, Roland Stigge wrote:
> The recurring task of providing simultaneous access to GPIO lines (especially
> for bit banging protocols) needs an appropriate API.
>
> This patch adds a kernel internal "Block GPIO" API that enables simultaneous
> access to several GPIOs. T
On Sun, Oct 28, 2012 at 9:46 PM, Roland Stigge wrote:
Just a quick few things I spotted:
> +struct gpio_block *gpio_block_create(unsigned *gpios, size_t size,
> +const char *name)
> +{
> + struct gpio_block *block;
> + struct gpio_block_chip *gbc;
The recurring task of providing simultaneous access to GPIO lines (especially
for bit banging protocols) needs an appropriate API.
This patch adds a kernel internal "Block GPIO" API that enables simultaneous
access to several GPIOs. This is done by abstracting GPIOs to an n-bit word:
Once requeste
10 matches
Mail list logo
