On Monday 21 January 2008, Dave Young wrote:
> +static int __spi_master_match(struct device *dev, void *data)
> +{
> + struct spi_master *m;
> + u16 *bus_num = (u16 *)data;
That's "void *data" so "u16 *bus_num = data" is preferred.
--
To unsubscribe from this list: send the line
On Monday 21 January 2008, Dave Young wrote:
>
> +/**
> + * class_for_each_device - device iterator
> + * @class: the class we're iterating
> + * @data: data for the callback
> + * @fn: function to be called for each device
> + *
> + * Iterate over @class's list of devices, and call
On Monday 21 January 2008, Peter Zijlstra wrote:
>
> On Fri, 2008-01-18 at 14:29 -0800, David Brownell wrote:
> > EXPERIMENTAL and incomplete patch to make LOCKDEP behave better in
> > the face of irq chaining, by annotating irqs with a lock_class which
> > ca
On Monday 21 January 2008, Peter Zijlstra wrote:
On Fri, 2008-01-18 at 14:29 -0800, David Brownell wrote:
EXPERIMENTAL and incomplete patch to make LOCKDEP behave better in
the face of irq chaining, by annotating irqs with a lock_class which
can reflect that hierarchy.
This is too
On Monday 21 January 2008, Dave Young wrote:
+/**
+ * class_for_each_device - device iterator
+ * @class: the class we're iterating
+ * @data: data for the callback
+ * @fn: function to be called for each device
+ *
+ * Iterate over @class's list of devices, and call @fn for
On Monday 21 January 2008, Dave Young wrote:
+static int __spi_master_match(struct device *dev, void *data)
+{
+ struct spi_master *m;
+ u16 *bus_num = (u16 *)data;
That's void *data so u16 *bus_num = data is preferred.
--
To unsubscribe from this list: send the line unsubscribe
On Monday 21 January 2008, Dave Young wrote:
Convert to use the class iteration api.
Signed-off-by: Dave Young [EMAIL PROTECTED]
Ack.
---
drivers/spi/spi.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff -upr linux/drivers/spi/spi.c
EXPERIMENTAL and incomplete patch to make LOCKDEP behave better in
the face of irq chaining, by annotating irqs with a lock_class which
can reflect that hierarchy.
This version of the patch is incomplete in at least two respects:
- There's no spin_lock_irq_nested() primitive, so that locking
On Thursday 17 January 2008, Nicolas Ferre wrote:
> static void at91_lcdc_power_control(int on)
> {
> if (on)
> - at91_set_gpio_value(AT91_PIN_PD12, 0); /* power up */
> + at91_set_gpio_value(AT91_PIN_PA30, 1); /* power up */
> else
> -
On Thursday 17 January 2008, Jan Beulich wrote:
> >This stuff isn't for "distro" kernels; it's for embedded
> >environments of the "only this hardware exists" sort.
> >Space matters, and having small code matters. Nobody has
> >been interested enough in an "embedded distro" model to
> >provide
On Thursday 17 January 2008, Jan Beulich wrote:
This stuff isn't for distro kernels; it's for embedded
environments of the only this hardware exists sort.
Space matters, and having small code matters. Nobody has
been interested enough in an embedded distro model to
provide patches enabling
On Wednesday 16 January 2008, Jan Beulich wrote:
> >>> Randy Dunlap <[EMAIL PROTECTED]> 20.10.07 05:21 >>>
>
> Sorry for only now getting back to this.
>
> >On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
> >
> ...
>
> I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really
>
On Wednesday 16 January 2008, Jan Beulich wrote:
Randy Dunlap [EMAIL PROTECTED] 20.10.07 05:21
Sorry for only now getting back to this.
On Fri, 19 Oct 2007 19:55:35 -0700 Randy Dunlap wrote:
...
I'm pretty convinced that drivers/usb/gadget/Kconfig isn't really
written properly:
> > > So, to get the ball rolling, here are some factors that IMHO
> > > help decide in which side to implement a driver:
> > >
> > > - if the driver ties a hardware device to an existing
> > >in-kernel interface (network, block, serial, bluetooth,
> > >video4linux, etc.), it should
So, to get the ball rolling, here are some factors that IMHO
help decide in which side to implement a driver:
- if the driver ties a hardware device to an existing
in-kernel interface (network, block, serial, bluetooth,
video4linux, etc.), it should probably be implemented
The /sys/devices/.../power/state files have been gone for a while
now, but I just noticed some documentation that still refers to
them. (Fortunately described as DEPRECATED and WILL REMOVE).
Time to remove that obsolete documentation too ...
Signed-off-by: David Brownell <[EMAIL PROTEC
The /sys/devices/.../power/state files have been gone for a while
now, but I just noticed some documentation that still refers to
them. (Fortunately described as DEPRECATED and WILL REMOVE).
Time to remove that obsolete documentation too ...
Signed-off-by: David Brownell [EMAIL PROTECTED
On Monday 07 January 2008, Greg KH wrote:
> Most of the non-driver core code should be converted to not use the
> lock in the class at all. They should use a local lock instead.
Or better yet, that yet-to-be-written class_for_each_instance()
iterator ... :)
--
To unsubscribe from this list:
On Monday 07 January 2008, Greg KH wrote:
Most of the non-driver core code should be converted to not use the
lock in the class at all. They should use a local lock instead.
Or better yet, that yet-to-be-written class_for_each_instance()
iterator ... :)
--
To unsubscribe from this list: send
On Sunday 06 January 2008, Yi Yang wrote:
>
> > How about not changing a userland-visible interface gratuitously?
>
> "empty" can't tell a user the state of wakeup of a device, so it is
> necessary to change it.
Words don't say anything at all in isolation. For example,
here the current
On Sunday 06 January 2008, Yi Yang wrote:
How about not changing a userland-visible interface gratuitously?
empty can't tell a user the state of wakeup of a device, so it is
necessary to change it.
Words don't say anything at all in isolation. For example,
here the current tristate
On Saturday 05 January 2008, Haavard Skinnemoen wrote:
> On Sat, 5 Jan 2008 12:10:56 -0800
> David Brownell <[EMAIL PROTECTED]> wrote:
>
> > From: David Brownell <[EMAIL PROTECTED]>
> >
> > Teach AVR32 to use the "GPIO Library" when exposing its G
From: David Brownell <[EMAIL PROTECTED]>
Update Documentation/gpio.txt, primarily to include the new
"gpiolib" infrastructure.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Incorporates cleanup as suggested by Sam Ravnborg.
Documen
From: David Brownell <[EMAIL PROTECTED]>
Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that
signals on external chips (like GPIO expanders) can easily be used.
This mostly reorganizes some existing logic, with two minor changes
in behavior:
- The PSR re
From: David Brownell <[EMAIL PROTECTED]>
This is a new-style I2C driver for most common 8 and 16 bit I2C based
"quasi-bidirectional" GPIO expanders: pcf8574 or pcf8575, and several
compatible models (mostly faster, supporting I2C at up to 1 MHz).
The driver exposes the GP
From: David Brownell <[EMAIL PROTECTED]>
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO
From: David Brownell <[EMAIL PROTECTED]>
Add an empty drivers/gpio directory for gpiolib infrastructure
and GPIO expanders. It will be populated by later patches.
This won't be the only place to hold such gpio_chip code. Many
external chips add a few GPIOs as secondary functio
easier to hook up GPIOs provided by external chips like
ASICs and CPLDs.
Signed-off-by: Philipp Zabel <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Acked-by: Russell King <[EMAIL PROTECTED]>
---
Incorporates minor cleanup suggested by Sam Ravn
has no current known
users). This is faster and simpler; it uses 16-bit register access,
and cache the OUTPUT and DIRECTION registers for fast access
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Incorporates cleanups noted by Jean Delvare
> --- 23.a/arch/arm/Kconfig
> +++ 23.b/arch/arm/Kconfig
> @@ -1049,6 +1049,8 @@ source "drivers/hid/Kconfig"
>
> source "drivers/usb/Kconfig"
>
> +source "drivers/usb/gadget/Kconfig"
> +
> source "drivers/mmc/Kconfig"
>
> source "drivers/rtc/Kconfig"
>
Better IMO to include such
On Saturday 05 January 2008, Al Boldi wrote:
> +comment "NOTE: USB_STORAGE selects SCSI, but 'SCSI disk support' may"
> +comment "also be needed; see USB_STORAGE Help for more information"
> +
> config USB_STORAGE_DEBUG
Better ... but wouldn't something like
comment "You probably also
). This is faster and simpler; it uses 16-bit register access,
and cache the OUTPUT and DIRECTION registers for fast access
Signed-off-by: eric miao [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Incorporates cleanups noted by Jean Delvare.
drivers/gpio/Kconfig| 10 +
drivers
--- 23.a/arch/arm/Kconfig
+++ 23.b/arch/arm/Kconfig
@@ -1049,6 +1049,8 @@ source drivers/hid/Kconfig
source drivers/usb/Kconfig
+source drivers/usb/gadget/Kconfig
+
source drivers/mmc/Kconfig
source drivers/rtc/Kconfig
Better IMO to include such updates with the patch that
On Saturday 05 January 2008, Al Boldi wrote:
+comment NOTE: USB_STORAGE selects SCSI, but 'SCSI disk support' may
+comment also be needed; see USB_STORAGE Help for more information
+
config USB_STORAGE_DEBUG
Better ... but wouldn't something like
comment You probably also need to
From: David Brownell [EMAIL PROTECTED]
Update Documentation/gpio.txt, primarily to include the new
gpiolib infrastructure.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Incorporates cleanup as suggested by Sam Ravnborg.
Documentation/gpio.txt | 133
From: David Brownell [EMAIL PROTECTED]
Teach AVR32 to use the GPIO Library when exposing its GPIOs, so that
signals on external chips (like GPIO expanders) can easily be used.
This mostly reorganizes some existing logic, with two minor changes
in behavior:
- The PSR registers are used instead
From: David Brownell [EMAIL PROTECTED]
This is a new-style I2C driver for most common 8 and 16 bit I2C based
quasi-bidirectional GPIO expanders: pcf8574 or pcf8575, and several
compatible models (mostly faster, supporting I2C at up to 1 MHz).
The driver exposes the GPIO signals using
From: David Brownell [EMAIL PROTECTED]
Add an empty drivers/gpio directory for gpiolib infrastructure
and GPIO expanders. It will be populated by later patches.
This won't be the only place to hold such gpio_chip code. Many
external chips add a few GPIOs as secondary functionality (such
as MFD
to hook up GPIOs provided by external chips like
ASICs and CPLDs.
Signed-off-by: Philipp Zabel [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
Acked-by: Russell King [EMAIL PROTECTED]
---
Incorporates minor cleanup suggested by Sam Ravnborg.
arch/arm/Kconfig
From: David Brownell [EMAIL PROTECTED]
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should be less
On Saturday 05 January 2008, Haavard Skinnemoen wrote:
On Sat, 5 Jan 2008 12:10:56 -0800
David Brownell [EMAIL PROTECTED] wrote:
From: David Brownell [EMAIL PROTECTED]
Teach AVR32 to use the GPIO Library when exposing its GPIOs, so that
signals on external chips (like GPIO expanders
> This patch changes empty output to "unsupported" in order that a user knows
> wakeup feature isn't supported by this device when he/she
> 'cat /sys/devices/.../power/wakeup', please consider to apply, thanks.
I don't much like this patch. Not just for the technical reasons
mentioned in my
> > This patch changes empty output to "unsupported" in order that a user knows
> > wakeup feature isn't supported by this device when he/she
> > 'cat /sys/devices/.../power/wakeup', please consider to apply,
> > thanks.
>
> What about simply removing "wakuep" file if wakeup is not supported?
It
This patch changes empty output to unsupported in order that a user knows
wakeup feature isn't supported by this device when he/she
'cat /sys/devices/.../power/wakeup', please consider to apply, thanks.
I don't much like this patch. Not just for the technical reasons
mentioned in my previous
This patch changes empty output to unsupported in order that a user knows
wakeup feature isn't supported by this device when he/she
'cat /sys/devices/.../power/wakeup', please consider to apply,
thanks.
What about simply removing wakuep file if wakeup is not supported?
It may not *stay*
Le 02 Janvier 2008, Jean Delvare a écrit:
>
> Hi David, hi Eric,
>
> Le 29/12/2007, "David Brownell" <[EMAIL PROTECTED]> a écrit:
> >From: eric miao <[EMAIL PROTECTED]>
> >
> >This adds a new-style I2C driver with basic s
Le 02 Janvier 2008, Jean Delvare a écrit:
Hi David, hi Eric,
Le 29/12/2007, David Brownell [EMAIL PROTECTED] a écrit:
From: eric miao [EMAIL PROTECTED]
This adds a new-style I2C driver with basic support for the sixteen
bit PCA9539 GPIO expanders.
...
Random
On Wednesday 02 January 2008, Bryan Wu wrote:
> B.T.W, 2 questions about the MUSB driver:
> 1. What's the plan for mainline merge of the whole MUSB driver? maybe
> I can cleanup current Blackfin ports to you guys.
It might as well merge in 2.6.25-early. It'll be easier to integrate
patches that
On Wednesday 02 January 2008, Robin Getz wrote:
> On Wed 2 Jan 2008 13:47, David Brownell pondered:
> > On Wednesday 02 January 2008, Robin Getz wrote:
> > > From: Robin Getz <[EMAIL PROTECTED]>
> > >
> > > Allow embedded developers to turn support for U
On Wednesday 02 January 2008, Alan Stern wrote:
>
> > The transaction translators in external high speed hubs require
> > hosts to issue particular USB transactions. If the host controller
> > doesn't implement the that split transaction support, then it won't
> > be supporting external hubs.
>
On Wednesday 02 January 2008, Ingo Molnar wrote:
>
> then please provide a kernel config option for the new driver to take
> over 10:135 too. There's nothing worse to the adoption of new kernel
> features necessiating user-space attention. I've got several images of
> old distros that i dont
On Wednesday 02 January 2008, Alan Stern wrote:
> On Wed, 2 Jan 2008, Mike Frysinger wrote:
>
> > perhaps the code size is arguable as to whether it really matters.
> > the reason we want it is that we have a USB host controller that will
> > not work with USB hubs, so we want to make sure the
On Wednesday 02 January 2008, Mike Frysinger wrote:
> > >
> > > Allow embedded developers to turn support for USB Hubs off even if they
> > > have a
> > > full root hub. This saves the overhead (RAM and Flash size).
> >
> > ISTR that it won't save very much code though ... the Linux USB
> > stack
On Wednesday 02 January 2008, Felipe Balbi wrote:
>The problem I see here is that my only
> "user" is musb driver, currently only available on linux-omap git tree.
>
> Maybe it's time to send it to mainline, what do you think Dave?
Probably time, yes. ISTR the main open issues are on
On Wednesday 02 January 2008, Alan Stern wrote:
> BTW, I don't recall ever seeing Tony's patch announced on
> linux-usb or linux-usb-devel. Did I simply miss it?
I think he didn't post it. I got some questions from him at
one point, which I answered, but as I recall he decided for
some
On Wednesday 02 January 2008, Robin Getz wrote:
> From: Robin Getz <[EMAIL PROTECTED]>
>
> Allow embedded developers to turn support for USB Hubs off even if they have
> a
> full root hub. This saves the overhead (RAM and Flash size).
ISTR that it won't save very much code though ... the Linux
> > It'd need to have some NTP sync solution for RTC_LIB devices, but
> > ISTR the gentime stuff still assumes an update_persistent_clock()
> > that doesn't sleep ... and hence can't be used with I2C based RTCs.
>
> I still believe NTP sync stuff should be done outside of the kernel.
> given the
> > > shouldnt we provide a Kconfig way of replacing dev 10:135 with the
> > > new driver's 254:0 device? (while keeping all the current modes of
> > > operation as well, of course.) It's all supposed to be 100% ioctl
> > > ABI compatible with the old driver, right?
> >
> > It's not compatible
(Alessandro Zummo Cc:-ed too -- RTC subsystem maintainer)
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Well, we have the following test script in the userland suspend
> > package that is supposed to work right now:
> >
> > #!/bin/bash
> > date
> > cd /sys/class/rtc/rtc0
> > echo $((
(Alessandro Zummo Cc:-ed too -- RTC subsystem maintainer)
* Rafael J. Wysocki [EMAIL PROTECTED] wrote:
Well, we have the following test script in the userland suspend
package that is supposed to work right now:
#!/bin/bash
date
cd /sys/class/rtc/rtc0
echo $(( $(cat since_epoch)
shouldnt we provide a Kconfig way of replacing dev 10:135 with the
new driver's 254:0 device? (while keeping all the current modes of
operation as well, of course.) It's all supposed to be 100% ioctl
ABI compatible with the old driver, right?
It's not compatible enough to fake
It'd need to have some NTP sync solution for RTC_LIB devices, but
ISTR the gentime stuff still assumes an update_persistent_clock()
that doesn't sleep ... and hence can't be used with I2C based RTCs.
I still believe NTP sync stuff should be done outside of the kernel.
given the mean
On Wednesday 02 January 2008, Robin Getz wrote:
From: Robin Getz [EMAIL PROTECTED]
Allow embedded developers to turn support for USB Hubs off even if they have
a
full root hub. This saves the overhead (RAM and Flash size).
ISTR that it won't save very much code though ... the Linux USB
On Wednesday 02 January 2008, Alan Stern wrote:
BTW, I don't recall ever seeing Tony's patch announced on
linux-usb or linux-usb-devel. Did I simply miss it?
I think he didn't post it. I got some questions from him at
one point, which I answered, but as I recall he decided for
some
On Wednesday 02 January 2008, Felipe Balbi wrote:
The problem I see here is that my only
user is musb driver, currently only available on linux-omap git tree.
Maybe it's time to send it to mainline, what do you think Dave?
Probably time, yes. ISTR the main open issues are on host
On Wednesday 02 January 2008, Mike Frysinger wrote:
Allow embedded developers to turn support for USB Hubs off even if they
have a
full root hub. This saves the overhead (RAM and Flash size).
ISTR that it won't save very much code though ... the Linux USB
stack structures all
On Wednesday 02 January 2008, Alan Stern wrote:
On Wed, 2 Jan 2008, Mike Frysinger wrote:
perhaps the code size is arguable as to whether it really matters.
the reason we want it is that we have a USB host controller that will
not work with USB hubs, so we want to make sure the system
On Wednesday 02 January 2008, Ingo Molnar wrote:
then please provide a kernel config option for the new driver to take
over 10:135 too. There's nothing worse to the adoption of new kernel
features necessiating user-space attention. I've got several images of
old distros that i dont want
On Wednesday 02 January 2008, Robin Getz wrote:
On Wed 2 Jan 2008 13:47, David Brownell pondered:
On Wednesday 02 January 2008, Robin Getz wrote:
From: Robin Getz [EMAIL PROTECTED]
Allow embedded developers to turn support for USB Hubs off even if
they have a full root hub
On Wednesday 02 January 2008, Alan Stern wrote:
The transaction translators in external high speed hubs require
hosts to issue particular USB transactions. If the host controller
doesn't implement the that split transaction support, then it won't
be supporting external hubs.
So in
On Wednesday 02 January 2008, Bryan Wu wrote:
B.T.W, 2 questions about the MUSB driver:
1. What's the plan for mainline merge of the whole MUSB driver? maybe
I can cleanup current Blackfin ports to you guys.
It might as well merge in 2.6.25-early. It'll be easier to integrate
patches that
On Monday 31 December 2007, Randy Dunlap wrote:
> CC drivers/input/keyboard/gpio_keys.o
> In file included from
> /local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:27:
> include2/asm/gpio.h:4:18: error: gpio.h: No such file or directory
Find whatever broken patch
On Monday 31 December 2007, Randy Dunlap wrote:
CC drivers/input/keyboard/gpio_keys.o
In file included from
/local/linsrc/linux-2.6.24-rc6-mm1/drivers/input/keyboard/gpio_keys.c:27:
include2/asm/gpio.h:4:18: error: gpio.h: No such file or directory
Find whatever broken patch selected
On Saturday 29 December 2007, Alan Stern wrote:
> lockdep warns whenever a task acquires a mutex while holding another
> mutex of the same kind (that is, the same member in another structure
> of the same type). But there are lots of places where the kernel needs
> to acquire dev->sem for one
notations. Heck, /usr/include is full of them...
- Dave
CUT HERE
Minor gpiolib.c cleanup: remove most #ifdefs for CONFIG_FS.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/gpiolib.c | 22 +++---
1 file changed, 11 insertions(+), 1
t
- Descend into drivers/gpio unconditionally, letting the Makefile
sort out the differences
- Use "ccflags-$(CONGIF_DEBUG_GPIO) += -DDEBUG" instead of
those ugly (but traditional) conditionals.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
arch/arm/Kconf
- Use ccflags-$(CONGIF_DEBUG_GPIO) += -DDEBUG instead of
those ugly (but traditional) conditionals.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
arch/arm/Kconfig |4 +-
arch/avr32/Kconfig |2 +-
drivers/Makefile |2 +-
drivers/gpio/Kconfig
CUT HERE
Minor gpiolib.c cleanup: remove most #ifdefs for CONFIG_FS.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/gpio/gpiolib.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
--- at91.orig/drivers/gpio/gpiolib.c
+++ at91/drivers/gpio
On Saturday 29 December 2007, Alan Stern wrote:
lockdep warns whenever a task acquires a mutex while holding another
mutex of the same kind (that is, the same member in another structure
of the same type). But there are lots of places where the kernel needs
to acquire dev-sem for one device
From: eric miao <[EMAIL PROTECTED]>
Use drivers/gpio/pca9539.c instead.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Acked-by: Ben Gardner <[EMAIL PROTECTED]>
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Document
From: David Brownell <[EMAIL PROTECTED]>
Basic driver for 8-bit SPI based MCP23S08 GPIO expander, without support for
IRQs or the shared chipselect mechanism.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig |7
drivers/gpio/Makefile
ses 16-bit register access,
and caches the OUTPUT and DIRECTION registers for fast access.
Signed-off-by: eric miao <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/gpio/Kconfig| 10 +
drivers/gpio/Makefile |
ASICs and CPLDs, as used on various product and developer boards.
Signed-off-by: Philipp Zabel <[EMAIL PROTECTED]>
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Acked-by: Russell King <[EMAIL PROTECTED]>
---
arch/arm/Kconfig|1
arch/arm/mach-pxa/Makefil
From: David Brownell <[EMAIL PROTECTED]>
This is a new-style I2C driver for most common 8 and 16 bit I2C based
"quasi-bidirectional" GPIO expanders: pcf8574 or pcf8575, and several
compatible models (mostly faster, supporting I2C at up to 1 MHz).
The driver exposes the GP
From: David Brownell <[EMAIL PROTECTED]>
Update Documentation/gpio.txt, primarily to include the new
optional "gpiolib" implementation infrastructure.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
Documentation/gpio.txt | 133 +++
From: David Brownell <[EMAIL PROTECTED]>
Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that
signals on external chips (like GPIO expanders) can easily be used.
This mostly just reorganizes some existing logic, with two minor changes
in behavior:
- The PSR re
From: David Brownell <[EMAIL PROTECTED]>
Provide new implementation infrastructure that platforms may choose to use
to support the GPIO programming interface. Platforms can update current
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should b
From: David Brownell <[EMAIL PROTECTED]>
Add an empty drivers/gpio directory for gpiolib infrastructure
and GPIO expanders. It is populated by subsequent patches.
This won't be the only place to hold such gpio_chip code. Many
external chips add a few GPIOs as secondary functio
This patchset is intended to replace the ones currently in the MM tree:
generic-gpio-gpio_chip-support.patch
generic-gpio-gpio_chip-support-fix.patch
generic-gpio-gpio_chip-support-gpiolib-locking-simplified.patch
avr32-uses-gpio_chip.patch
On Friday 28 December 2007, Dave Young wrote:
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
ACK ... if the driver core is changing, this is obvious.
> ---
> drivers/spi/spi.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff -upr linux/drivers/spi/spi.c
On Friday 28 December 2007, Dave Young wrote:
Signed-off-by: Dave Young [EMAIL PROTECTED]
ACK ... if the driver core is changing, this is obvious.
---
drivers/spi/spi.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -upr linux/drivers/spi/spi.c
From: David Brownell [EMAIL PROTECTED]
Add an empty drivers/gpio directory for gpiolib infrastructure
and GPIO expanders. It is populated by subsequent patches.
This won't be the only place to hold such gpio_chip code. Many
external chips add a few GPIOs as secondary functionality (such
as MFD
From: David Brownell [EMAIL PROTECTED]
Provide new implementation infrastructure that platforms may choose to use
to support the GPIO programming interface. Platforms can update current
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should be less than
From: David Brownell [EMAIL PROTECTED]
Update Documentation/gpio.txt, primarily to include the new
optional gpiolib implementation infrastructure.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
Documentation/gpio.txt | 133 -
1 file changed
From: David Brownell [EMAIL PROTECTED]
Teach AVR32 to use the GPIO Library when exposing its GPIOs, so that
signals on external chips (like GPIO expanders) can easily be used.
This mostly just reorganizes some existing logic, with two minor changes
in behavior:
- The PSR registers are used
and CPLDs, as used on various product and developer boards.
Signed-off-by: Philipp Zabel [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
Acked-by: Russell King [EMAIL PROTECTED]
---
arch/arm/Kconfig|1
arch/arm/mach-pxa/Makefile |2
arch/arm/mach
This patchset is intended to replace the ones currently in the MM tree:
generic-gpio-gpio_chip-support.patch
generic-gpio-gpio_chip-support-fix.patch
generic-gpio-gpio_chip-support-gpiolib-locking-simplified.patch
avr32-uses-gpio_chip.patch
From: David Brownell [EMAIL PROTECTED]
This is a new-style I2C driver for most common 8 and 16 bit I2C based
quasi-bidirectional GPIO expanders: pcf8574 or pcf8575, and several
compatible models (mostly faster, supporting I2C at up to 1 MHz).
The driver exposes the GPIO signals using
From: David Brownell [EMAIL PROTECTED]
Basic driver for 8-bit SPI based MCP23S08 GPIO expander, without support for
IRQs or the shared chipselect mechanism.
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/gpio/Kconfig |7
drivers/gpio/Makefile|1
drivers
,
and caches the OUTPUT and DIRECTION registers for fast access.
Signed-off-by: eric miao [EMAIL PROTECTED]
Signed-off-by: David Brownell [EMAIL PROTECTED]
---
drivers/gpio/Kconfig| 10 +
drivers/gpio/Makefile |1
drivers/gpio/pca9539.c | 264
201 - 300 of 1706 matches
Mail list logo
