On Fri, Sep 6, 2019 at 9:45 AM Geert Uytterhoeven
wrote:
> This patch series contains various API boundary cleanups for gpiolib:
> - The first two patches make two functions private,
> - The last two patches switch the remaining gpiolib exported functions
> from EXPORT_SYMBOL() to EXPORT_
Hi Bartosz,
On Tue, Sep 10, 2019 at 10:51 AM Bartosz Golaszewski
wrote:
> pt., 6 wrz 2019 o 10:45 Geert Uytterhoeven
> napisał(a):
> > This patch series contains various API boundary cleanups for gpiolib:
> > - The first two patches make two functions private,
> > - The last two patches swi
pt., 6 wrz 2019 o 10:45 Geert Uytterhoeven napisał(a):
>
> Hi Linus, Bartosz,
>
> This patch series contains various API boundary cleanups for gpiolib:
> - The first two patches make two functions private,
> - The last two patches switch the remaining gpiolib exported functions
> f
Hi Linus, Bartosz,
This patch series contains various API boundary cleanups for gpiolib:
- The first two patches make two functions private,
- The last two patches switch the remaining gpiolib exported functions
from EXPORT_SYMBOL() to EXPORT_SYMBOL_GPL().
After this there is only
This commit eliminate all uses of legacy integer base GPIO API in
olpc_dcon_xo_1_5.c and replace them with new descriptor GPIO API like
those in olpc_dcon_xo_1.c.
Also pull some common code with olpc_dcon_xo_1.c to olpc_dcon.h for code
sharing.
Signed-off-by: Jerry Lin
---
drivers/staging
ezillon.
> > > >
> > > > Janusz Krzysztofik (4):
> > > > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data
> > > > port
> > > > mtd: rawnand: ams-delta: Request data port GPIO resource
> > > > m
1: ams-delta: Provide GPIO lookup table for NAND data port
> > > mtd: rawnand: ams-delta: Request data port GPIO resource
> > > mtd: rawnand: ams-delta: Use GPIO API for data I/O
> > > ARM: OMAP1: ams-delta: Drop obsolete NAND resour
mem_region() failure"). Use pure GPIO consumer API, as reqested
> > by Boris Brezillon.
> >
> > Janusz Krzysztofik (4):
> > ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> > mtd: rawnand: ams-delta: Request data port GPIO re
reqested
> by Boris Brezillon.
>
> Janusz Krzysztofik (4):
> ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
> mtd: rawnand: ams-delta: Request data port GPIO resource
> mtd: rawnand: ams-delta: Use GPIO API for data I/O
> ARM: OMAP1:
On Wed, 21 Nov 2018 12:08:05 +0100
Janusz Krzysztofik wrote:
> Don't readw()/writew() data directly from/to GPIO port which is under
> control of gpio-omap driver, use GPIO consumer API instead.
>
> The driver should now work with any 8-bit bidirectional GPIO port, not
> only OMAP.
>
> Signed-o
Don't readw()/writew() data directly from/to GPIO port which is under
control of gpio-omap driver, use GPIO consumer API instead.
The driver should now work with any 8-bit bidirectional GPIO port, not
only OMAP.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Linus Walleij
---
drivers/mtd/nand/
a: Provide GPIO lookup table for NAND data port
mtd: rawnand: ams-delta: Request data port GPIO resource
mtd: rawnand: ams-delta: Use GPIO API for data I/O
ARM: OMAP1: ams-delta: Drop obsolete NAND resources
arch/arm/mach-omap1/board-ams-delta.c | 22 ++
drivers/mtd/nand/raw/a
On Tue, 14 Aug 2018 00:34:48 +0200
Janusz Krzysztofik wrote:
> Don't readw()/writew() data directly from/to GPIO port which is under
> control of gpio-omap driver, use GPIO API instead.
>
> Degrade of performance on Amstrad Delta is significant, can be
> recognized as a re
Don't readw()/writew() data directly from/to GPIO port which is under
control of gpio-omap driver, use GPIO API instead.
Degrade of performance on Amstrad Delta is significant, can be
recognized as a regression, that's why I'm still submitting this patch
as RFC.
The driver should
Implement the idea suggested by Artem Bityutskiy and Tony Lindgren,
described in commit b027274d2e3a ("mtd: ams-delta: fix
request_mem_region() failure"). Use pure GPIO API as suggested by
Boris Brezillon.
Janusz Krzysztofik (7):
mtd: rawnand: ams-delta: show parent devic
Ulf Hansson writes:
> On 26 September 2015 at 21:41, Robert Jarzmik wrote:
> Thanks, applied for fixes!
>
> Kind regards
> Uffe
Thanks.
--
Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On 26 September 2015 at 21:41, Robert Jarzmik wrote:
> Move pxamci to mmc slot-gpio API to fix interrupt request.
>
> It fixes the case where the card detection is on a gpio expander, on I2C
> for example on zylonite board. In this case, the card detect netsted
> interrupt i
Move pxamci to mmc slot-gpio API to fix interrupt request.
It fixes the case where the card detection is on a gpio expander, on I2C
for example on zylonite board. In this case, the card detect netsted
interrupt is called from a threaded interrupt. The request_irq() fails,
because a hard irq
Ulf Hansson writes:
>> + if (gpio_is_valid(gpio_ro))
>> + ret = mmc_gpio_request_ro(mmc, gpio_ro);
>
> Would it be possible for you to use the mmc_gpiod_request_ro() instead?
I don't think so.
Most of pxamci users are old platform data based machine code, which passes an
integ
On 16 September 2015 at 21:16, Robert Jarzmik wrote:
> Move pxamci to mmc slot-gpio API to fix interrupt request.
>
> It fixes the case where the card detection is on a gpio expander, on I2C
> for example on zylonite board. In this case, the card detect netsted
> interrupt i
Move pxamci to mmc slot-gpio API to fix interrupt request.
It fixes the case where the card detection is on a gpio expander, on I2C
for example on zylonite board. In this case, the card detect netsted
interrupt is called from a threaded interrupt. The request_irq() fails,
because a hard irq
On Tue, 2013-11-26 at 10:38 +0100, Linus Walleij wrote:
> On Wed, Nov 20, 2013 at 3:31 PM, Andy Shevchenko
> wrote:
>
> > Instead of custom implementation of the SFI GPIO API let's use one provided
> > by
> > gpiolib.
> >
> > Signed-off-by: Andy She
On Wed, Nov 20, 2013 at 3:31 PM, Andy Shevchenko
wrote:
> Instead of custom implementation of the SFI GPIO API let's use one provided by
> gpiolib.
>
> Signed-off-by: Andy Shevchenko
So is it possible to move this to just do gpiod_get() from the drivers
and abstract away
On Thu, Nov 21, 2013 at 5:29 PM, Andy Shevchenko
wrote:
> On Thu, 2013-11-21 at 12:40 +0200, Mika Westerberg wrote:
>> On Wed, Nov 20, 2013 at 04:31:35PM +0200, Andy Shevchenko wrote:
>> > +struct gpio_desc *sfi_get_gpiod_by_name(const char *name);
>>
>> I'm wondering should this function be expo
On Wed, Nov 20, 2013 at 04:31:35PM +0200, Andy Shevchenko wrote:
> diff --git a/include/linux/gpio/sfi.h b/include/linux/gpio/sfi.h
> new file mode 100644
> index 000..3e111ad
> --- /dev/null
> +++ b/include/linux/gpio/sfi.h
> @@ -0,0 +1,37 @@
> +#ifndef _LINUX_SFI_GPIO_H_
> +#define _LINUX_SFI
Hi Andy,
Thanks for the patch.
On 11/20/2013 06:31 AM, Andy Shevchenko wrote:
> Instead of custom implementation of the SFI GPIO API let's use one provided by
> gpiolib.
>
> Signed-off-by: Andy Shevchenko
Acked-by: David Cohen
> ---
> arch/x86/include/asm/intel-mid.h
(legacy) firmwares and platforms let's make life
> >>> easier for
> >>> their customers.
> >>>
> >>> This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
> >>>
> >>> Signed-off-by: Andy Shevchenko
> >&g
Here is a second [1] version of the SFI GPIO API. This series contains SFI GPIO
API layer along with the update of intel-mid platform to use it instead of
internal copy.
It has been tested on Medfield device with linux-next 20131118.
[1] https://lkml.org/lkml/2013/6/5/316
Andy Shevchenko (3
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
This patch extracts SFI GPIO API from arch/x86/platform/intel-mid/sfi.c and
moves it to GPIO descriptor API.
Signed-off-by: Andy Shevchenko
Cc: Len Brown
Cc: Grant Likely
Cc: Linus Wa
Instead of custom implementation of the SFI GPIO API let's use one provided by
gpiolib.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/intel-mid.h | 1 -
.../intel-mid/device_libs/platform_emc1403.c | 8 ++--
.../intel-mid/device_libs/platform_gpio_k
On Tue, 2013-11-19 at 09:32 -0800, David Cohen wrote:
[]
> >> Maybe that header could move to instead.
> >> Alexandre what do you think?
> >
> > Agreed - all the GPIO drivers into drivers/gpio, all the headers into
> > include/linux/gpio. Logical. :)
>
> Sounds nice.
> Andy, would you like to u
On 11/19/2013 01:27 AM, Alex Courbot wrote:
> On 11/19/2013 06:24 PM, Linus Walleij wrote:
>> On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko
>> wrote:
>>
>>> To support some (legacy) firmwares and platforms let's make life
>>> easier for
>>>
On 11/19/2013 06:24 PM, Linus Walleij wrote:
On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko
wrote:
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
Signed-off-by:
On Fri, Jun 7, 2013 at 9:14 AM, Linus Walleij wrote:
> On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko
> wrote:
>
>> To support some (legacy) firmwares and platforms let's make life easier for
>> their customers.
>>
>> This patch extracts SFI GPIO
On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko
wrote:
> To support some (legacy) firmwares and platforms let's make life easier for
> their customers.
>
> This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
>
> Signed-off-by: Andy Shevchenko
So since t
On 11/13/2013 04:16 AM, Andy Shevchenko wrote:
On Tue, 2013-11-12 at 19:55 +0100, Linus Walleij wrote:
On Thu, Oct 17, 2013 at 2:41 PM, Andy Shevchenko
wrote:
On Wed, 2013-10-16 at 20:03 -0700, David Cohen wrote:
From: Andy Shevchenko
To support some (legacy) firmwares and platforms let's m
On Tue, 2013-11-12 at 19:55 +0100, Linus Walleij wrote:
> On Thu, Oct 17, 2013 at 2:41 PM, Andy Shevchenko
> wrote:
> > On Wed, 2013-10-16 at 20:03 -0700, David Cohen wrote:
> >> From: Andy Shevchenko
> >>
> >> To support some (legacy) firmwares and platforms let's make life easier for
> >> their
On Thu, Oct 17, 2013 at 2:41 PM, Andy Shevchenko
wrote:
> On Wed, 2013-10-16 at 20:03 -0700, David Cohen wrote:
>> From: Andy Shevchenko
>>
>> To support some (legacy) firmwares and platforms let's make life easier for
>> their customers.
>
>> +int sfi_get_gpio_by_name(const char *name)
>> +{
>>
On 10/17/2013 05:41 AM, Andy Shevchenko wrote:
On Wed, 2013-10-16 at 20:03 -0700, David Cohen wrote:
From: Andy Shevchenko
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
+int sfi_get_gpio_by_name(const char *name)
+{
+ struct sfi_gpio_ta
On Wed, 2013-10-16 at 20:03 -0700, David Cohen wrote:
> From: Andy Shevchenko
>
> To support some (legacy) firmwares and platforms let's make life easier for
> their customers.
>
> +int sfi_get_gpio_by_name(const char *name)
> +{
> + struct sfi_gpio_table_entry *pentry = sfi_gpio_table;
>
sfi.c b/drivers/gpio/gpiolib-sfi.c
new file mode 100644
index 000..2f15a81
--- /dev/null
+++ b/drivers/gpio/gpiolib-sfi.c
@@ -0,0 +1,76 @@
+/*
+ * SFI helpers for GPIO API
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Andy Shevchenko
+ *
+ * Based on work done for Intel MID plat
On Wed, Jun 5, 2013 at 3:58 PM, Andy Shevchenko
wrote:
> To support some (legacy) firmwares and platforms let's make life easier for
> their customers.
>
> This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
>
> Signed-off-by: Andy Shevchenko
> Acked-
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
Signed-off-by: Andy Shevchenko
Acked-by: Len Brown
Cc: Grant Likely
Cc: Linus Walleij
---
Since v1.1:
- use contain
On Mon, Jun 3, 2013 at 3:26 PM, Joe Perches wrote:
> On Mon, 2013-06-03 at 11:16 +0300, Andy Shevchenko wrote:
>> On Sun, 2013-06-02 at 19:06 -0700, Joe Perches wrote:
>> > On Mon, 2013-06-03 at 11:59 +1000, Ryan Mallon wrote:
>> > > On 31/05/13 19:27, Andy Shevchenko wrote:
>> > > > + sfi_g
On Mon, 2013-06-03 at 11:16 +0300, Andy Shevchenko wrote:
> On Sun, 2013-06-02 at 19:06 -0700, Joe Perches wrote:
> > On Mon, 2013-06-03 at 11:59 +1000, Ryan Mallon wrote:
> > > On 31/05/13 19:27, Andy Shevchenko wrote:
> > > > + sfi_gpio_table = kmalloc(num * sizeof(*pentry), GFP_KERNEL);
>
On Sun, 2013-06-02 at 19:06 -0700, Joe Perches wrote:
> On Mon, 2013-06-03 at 11:59 +1000, Ryan Mallon wrote:
> > On 31/05/13 19:27, Andy Shevchenko wrote:
> > Some trivial coding style comment below.
Thank you, Joe, for commenting this.
> > > + for (i = 0; i < sfi_gpio_num_entry; i++, pentry++)
On Fri, May 31, 2013 at 11:27 AM, Andy Shevchenko
wrote:
> To support some (legacy) firmwares and platforms let's make life easier for
> their customers.
>
> This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
>
> Signed-off-by: Andy Shevchenko
>
On Mon, 2013-06-03 at 11:59 +1000, Ryan Mallon wrote:
> On 31/05/13 19:27, Andy Shevchenko wrote:
> Some trivial coding style comment below.
[]
> > + for (i = 0; i < sfi_gpio_num_entry; i++, pentry++) {
> > + if (!strncmp(name, pentry->pin_name, SFI_NAME_LEN))
> > + re
On 31/05/13 19:27, Andy Shevchenko wrote:
> To support some (legacy) firmwares and platforms let's make life easier for
> their customers.
>
> This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
>
> Signed-off-by: Andy Shevchenko
> Acked-by: Len Brown
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
Signed-off-by: Andy Shevchenko
Acked-by: Len Brown
Cc: Grant Likely
Cc: Linus Walleij
---
Since v1:
- address Linus'
possible.
> Change-Id: I39a0e3e0ed4e04a0d733801f59d46d76189195e8
We don't put Google Gerrit change-IDs into the kernel log.
But fun to know you're using it...
(...)
> +++ b/drivers/gpio/gpiolib-sfi.c
> @@ -0,0 +1,76 @@
> +/*
> + * SFI helpers for GPIO API
Spell out "Simple Firmware Interface helpers
Drop this one away, Sathyanarayanan Kuppuswamy takes care about it in
his patchset.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
Drop this one away, Sathyanarayanan Kuppuswamy takes care about it in
his patchset.
--
With Best Regards,
Andy Shevchenko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
iolib-sfi.c
new file mode 100644
index 000..2f15a81
--- /dev/null
+++ b/drivers/gpio/gpiolib-sfi.c
@@ -0,0 +1,76 @@
+/*
+ * SFI helpers for GPIO API
+ *
+ * Copyright (C) 2013, Intel Corporation
+ * Author: Andy Shevchenko
+ *
+ * Based on work done for Intel MID platforms (mrst.c)
+ *
+ *
Let's use the common SFI helpers for GPIO API.
Change-Id: I7aba6e61af7df3e34ffc4dfe161ab6ea2d723691
Signed-off-by: Andy Shevchenko
Signed-off-by: Sathyanarayanan Kuppuswamy
---
arch/x86/include/asm/intel-mid.h |2 +-
.../intel-mid/device_libs/platform_emc1
To support some (legacy) firmwares and platforms let's make life easier for
their customers.
This patch extracts SFI GPIO API from arch/x86/platform/mrst/mrst.c.
Signed-off-by: Andy Shevchenko
Acked-by: Len Brown
Cc: Grant Likely
Cc: Linus Walleij
---
drivers/gpio/Kconfig
Let's use the common SFI helpers for GPIO API.
Signed-off-by: Andy Shevchenko
Acked-by: Len Brown
Cc: H. Peter Anvin
Cc: x...@kernel.org
---
arch/x86/platform/mrst/mrst.c | 94 ++-
1 file changed, 22 insertions(+), 72 deletions(-)
diff --git a/arc
On Tue, 15 Jan 2013 12:51:52 +0100, Roland Stigge wrote:
> This patch adds sysfs support to the block GPIO API.
>
> Signed-off-by: Roland Stigge
Hi Roland.
I'm going to ignore this patch for the time being because I think my
comments on the first patch basically obsolete what
On Tue, 15 Jan 2013 12:51:51 +0100, 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 simultaneo
On Tue, 15 Jan 2013 12:51:51 +0100, 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 simultaneo
On Mon, Jan 28, 2013 at 12:30 PM, Stijn Devriendt wrote:
> This is one of the warts of the GPIO API, if you ask me (and probably
> others too).
> Using a resource without allocating it first is just asking for
> trouble. It's one of those
> things pinctl was designed t
On 01/28/2013 12:39 PM, Stijn Devriendt wrote:
>>> In the device-tree this is specified as:
>>>
>>> powr@0x20 {
>>>// other properties
>>>
>>> gpios = <&gpio 4 0
>>>&gpio 5 0>;
>>> };
>>>
>>> Is this kind of integration also possible?
>>
>> You can reference the gpio block via
On Sun, Jan 27, 2013 at 3:29 PM, Roland Stigge wrote:
> On 27/01/13 14:07, Stijn Devriendt wrote:
>>> +Example:
>>> +
>>> +blockgpio {
>>> +compatible = "linux,gpio-block";
>>> +
>>> +block0 {
>>> +gpios = <&gpio 3 0 0>,
>>> +
se note that you need to request the GPIOs
>>> +separately via gpio_request(). Similarly, the direction of the used GPIOs
>>> need
>>> +to be set by the user before using the block.
>>
>> Is there anything holding you back from letting gpio_block_create() do
>&
On 27/01/13 14:07, Stijn Devriendt wrote:
>> +Example:
>> +
>> +blockgpio {
>> +compatible = "linux,gpio-block";
>> +
>> +block0 {
>> +gpios = <&gpio 3 0 0>,
>> +<&gpio 3 1 0>;
>> +};
>>
On 27/01/13 14:19, Stijn Devriendt wrote:
>> +Block GPIO
>> +--
>> +
>> +The above described interface concentrates on handling single GPIOs.
>> However,
>> +in applications where it is critical to set several GPIOs at once, this
>> +interface doesn't work well, e.g. bit-banging protocols
On Tue, Jan 22, 2013 at 1:06 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
>
On Tue, Jan 22, 2013 at 1:06 PM, Roland Stigge wrote:
> This patch adds device tree support to the block GPIO API.
>
> Signed-off-by: Roland Stigge
>
> ---
> Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 ++
> drivers/gpio/Makefile
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 252 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
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
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 ++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 100
Hi Stijn,
On 01/18/2013 01:13 PM, Stijn Devriendt wrote:
> Hi Roland,
>
> This mail has been long overdue due to issues with some internal
> permission-tool.
> Just to be clear, this is not a competing implementation, it's what we
> currently use as-is. I'm just posting this as a reference to see
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 252 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
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
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 ++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 100
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
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 252 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 ++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 100
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 252 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 ++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 100
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
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
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 250 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 ++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 100
On Tue, Dec 18, 2012 at 02:30:23PM +, Roland Stigge wrote:
> Hi Mark,
>
> On 12/17/2012 04:51 PM, Mark Rutland wrote:
> >> +static int __devinit gpioblock_of_probe(struct platform_device *pdev)
> >> +{
> >> + struct device_node *block;
> >> + unsigned *gpios;
> >> + int ngpio;
> >> + int r
Hi Mark,
On 12/17/2012 04:51 PM, Mark Rutland wrote:
>> +static int __devinit gpioblock_of_probe(struct platform_device *pdev)
>> +{
>> +struct device_node *block;
>> +unsigned *gpios;
>> +int ngpio;
>> +int ret;
>> +struct gpio_block *gb;
>> +
>> +for_each_available_child_
Hi,
I have a few comments on the parsing code.
On Fri, Dec 14, 2012 at 02:26:24PM +, Roland Stigge wrote:
> This patch adds device tree support to the block GPIO API.
>
> Signed-off-by: Roland Stigge
>
> ---
> Documentation/devicetree/bindings/gpio/gpi
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 250 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 +++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 84
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
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
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 250 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 +++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 84
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 250 ++-
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
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
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 +++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 84
This patch adds sysfs support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/ABI/testing/sysfs-gpio | 20 ++
drivers/gpio/gpiolib.c | 247 +++
include/asm-generic/gpio.h | 11 +
include/linux/gpio.h
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
This patch adds device tree support to the block GPIO API.
Signed-off-by: Roland Stigge
---
Documentation/devicetree/bindings/gpio/gpio-block.txt | 36 +++
drivers/gpio/Makefile |1
drivers/gpio/gpioblock-of.c | 84
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
1 - 100 of 290 matches
Mail list logo
