Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

2.6.33-rc3 regression: leds_alix2: can't allocate I/O for GPIO

11 views
Skip to first unread message

Arnd Hannemann

unread,
Jan 7, 2010, 5:30:03 AM1/7/10
to
Hi,

with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31

relevant dmesg output of 2.6.33-rc3:

[ 0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253

[ 2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
[ 2.228678] leds_alix2: can't allocate I/O for GPIO


For reference dmesg of 2.6.31.3:

[ 0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253

[ 2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
[ 2.399097] Registered led device: alix:1
[ 2.411404] Registered led device: alix:2
[ 2.423720] Registered led device: alix:3

Best regards,
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Richard Purdie

unread,
Jan 7, 2010, 6:10:02 AM1/7/10
to
On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
>
> relevant dmesg output of 2.6.33-rc3:
>
> [ 0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>
> [ 2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
> [ 2.228678] leds_alix2: can't allocate I/O for GPIO
>
>
> For reference dmesg of 2.6.31.3:
>
> [ 0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>
> [ 2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
> [ 2.399097] Registered led device: alix:1
> [ 2.411404] Registered led device: alix:2
> [ 2.423720] Registered led device: alix:3

Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
looks like the request_region() call is failing. Daniel, any idea why?

Cheers,

Richard

Arnd Hannemann

unread,
Jan 7, 2010, 7:00:02 AM1/7/10
to
Richard Purdie schrieb:

> On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
>> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
>> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
>>
>> relevant dmesg output of 2.6.33-rc3:
>>
>> [ 0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>
>> [ 2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
>> [ 2.228678] leds_alix2: can't allocate I/O for GPIO
>>
>>
>> For reference dmesg of 2.6.31.3:
>>
>> [ 0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>
>> [ 2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
>> [ 2.399097] Registered led device: alix:1
>> [ 2.411404] Registered led device: alix:2
>> [ 2.423720] Registered led device: alix:3
>
> Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
> looks like the request_region() call is failing. Daniel, any idea why?

Some additional debug information:

elara:~# rdmsr 0x5140000C
f00100006100

/proc/ioports says:
6100-61ff : 0000:00:0f.0
6100-61ff : cs5535_gpio

BTW: why is request_region() needed there after all?

Best regards,
Arnd

Arnd Hannemann

unread,
Jan 7, 2010, 7:20:01 AM1/7/10
to
Arnd Hannemann schrieb:

> Richard Purdie schrieb:
>> On Thu, 2010-01-07 at 11:26 +0100, Arnd Hannemann wrote:
>>> with 2.6.33-rc3 the LEDs are not working anymore on my Geode embedded board:
>>> If I remember correctly this was working fine with 2.6.32, but certainly with 2.6.31
>>>
>>> relevant dmesg output of 2.6.33-rc3:
>>>
>>> [ 0.709643] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>>
>>> [ 2.207947] leds_alix2: system is recognized as "PC Engines ALIX.2 v0.99h"
>>> [ 2.228678] leds_alix2: can't allocate I/O for GPIO
>>>
>>>
>>> For reference dmesg of 2.6.31.3:
>>>
>>> [ 0.611953] cs5535_gpio: base=0x6100 mask=0xb003c66 major=253
>>>
>>> [ 2.379114] leds_alix2: system is recognized as "PC Engines ALIX.2"
>>> [ 2.399097] Registered led device: alix:1
>>> [ 2.411404] Registered led device: alix:2
>>> [ 2.423720] Registered led device: alix:3
>> Its likely to be commit 7f131cf3ed96c969d7b092bf629e25c3df50901e. It
>> looks like the request_region() call is failing. Daniel, any idea why?
>
> Some additional debug information:
>
> elara:~# rdmsr 0x5140000C
> f00100006100
>
> /proc/ioports says:
> 6100-61ff : 0000:00:0f.0
> 6100-61ff : cs5535_gpio
>
> BTW: why is request_region() needed there after all?

Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?

Daniel Mack

unread,
Jan 7, 2010, 7:50:01 AM1/7/10
to

That is the problem indeed. The problem is that three of these GPIOs are
connected to LEDs, so if both drivers are enabled, they will both alter
the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
should use the GPIO interface and that's it?

Daniel

Arnd Hannemann

unread,
Jan 7, 2010, 9:10:02 AM1/7/10
to
Hi,

Daniel Mack schrieb:

I'm not sure that this configuration needs to be supported at all,
so disallowing that both drivers are configured via Kconfig could be a simple solution.

If I understand correctly, for off-the-shelf ALIX2 boards, beside the LEDs,
there is only one other GPIO pin being usable (the "mode switch"), anyway.

Best regards,
Arnd

Daniel Mack

unread,
Jan 7, 2010, 9:30:01 AM1/7/10
to
Hi,

True.

> If I understand correctly, for off-the-shelf ALIX2 boards, beside the LEDs,
> there is only one other GPIO pin being usable (the "mode switch"), anyway.

Yes. I also wrote a simple polled input device driver to support this
switch, but it was too much of a hack as it ended up being part of
the LED driver. The idea discussed back then was to clean up the code
so that the entire MSR lookup thing is only done once, and a platform
support for ALIX board then adds support for the LEDs via the leds-gpio
LED driver and for the button via gpio-buttons input driver. That would
be much nicer, but I haven't found the time yet to implement it.

Daniel

Richard Purdie

unread,
Jan 7, 2010, 12:30:03 PM1/7/10
to
On Thu, 2010-01-07 at 15:00 +0100, Arnd Hannemann wrote:
> Daniel Mack schrieb:
> > On Thu, Jan 07, 2010 at 01:11:31PM +0100, Arnd Hannemann wrote:
> >> Arnd Hannemann schrieb:
> >> Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?
> >
> > That is the problem indeed. The problem is that three of these GPIOs are
> > connected to LEDs, so if both drivers are enabled, they will both alter
> > the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
> > should use the GPIO interface and that's it?
>
> I'm not sure that this configuration needs to be supported at all,
> so disallowing that both drivers are configured via Kconfig could be a simple solution.

Agreed, Kconfig dependencies for this until the code is improved look
like the best option. Does someone want to send me a patch?

Cheers,

Richard

--
Richard Purdie
Intel Open Source Technology Centre

Daniel Mack

unread,
Jan 7, 2010, 10:10:02 PM1/7/10
to
On Thu, Jan 07, 2010 at 05:27:21PM +0000, Richard Purdie wrote:
> On Thu, 2010-01-07 at 15:00 +0100, Arnd Hannemann wrote:
> > Daniel Mack schrieb:
> > > On Thu, Jan 07, 2010 at 01:11:31PM +0100, Arnd Hannemann wrote:
> > >> Arnd Hannemann schrieb:
> > >> Oh, maybe using cs5535_gpio AND leds_alix2 together was never supposed to work?
> > >
> > > That is the problem indeed. The problem is that three of these GPIOs are
> > > connected to LEDs, so if both drivers are enabled, they will both alter
> > > the same GPIOs. Hmm, don't know how to handle this. Maybe the LED driver
> > > should use the GPIO interface and that's it?
> >
> > I'm not sure that this configuration needs to be supported at all,
> > so disallowing that both drivers are configured via Kconfig could be a simple solution.
>
> Agreed, Kconfig dependencies for this until the code is improved look
> like the best option. Does someone want to send me a patch?

Does the one below look ok?

Thanks,
Daniel


From ebb89d7d1908e85587f3e64bcea0dd77a92cc744 Mon Sep 17 00:00:00 2001
From: Daniel Mack <dan...@caiaq.de>
Date: Fri, 8 Jan 2010 02:22:10 +0800
Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335

The ALIX2 LED driver and the CS5535 GPIO driver share the same I/O
range which causes a conflict if they're both enabled. Fix this for now
by adding a Kconfig dependency. While at it, also drop the EXPERIMENTAL
flag, as the code has been around for awhile already.

Note that this is a hack. At some point, a real platform support for
this board should be added which handles the LEDs via the leds-gpio
driver.

Signed-off-by: Daniel Mack <dan...@caiaq.de>
Cc: Richard Purdie <rpu...@rpsys.net>
Cc: Arnd Hannemann <hann...@nets.rwth-aachen.de>
---
drivers/leds/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8a0e1ec..7f292ae 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -72,7 +72,7 @@ config LEDS_WRAP

config LEDS_ALIX2
tristate "LED Support for ALIX.2 and ALIX.3 series"
- depends on LEDS_CLASS && X86 && EXPERIMENTAL
+ depends on LEDS_CLASS && X86 && !GPIO_CS5535
help
This option enables support for the PCEngines ALIX.2 and ALIX.3 LEDs.
You have to set leds-alix2.force=1 for boards with Award BIOS.
--
1.6.3.3

Arnd Hannemann

unread,
Jan 8, 2010, 3:40:01 AM1/8/10
to

You should add && !CS5535_GPIO, too. In fact CS5535_GPIO
was the one that I had issues with. Though, I wonder why
there are multiple drivers... Buts thats another issue.

> help
> This option enables support for the PCEngines ALIX.2 and ALIX.3 LEDs.
> You have to set leds-alix2.force=1 for boards with Award BIOS.

Best regards,
Arnd

Daniel Mack

unread,
Jan 10, 2010, 7:30:02 AM1/10/10
to
On Fri, Jan 08, 2010 at 09:32:33AM +0100, Arnd Hannemann wrote:
> Daniel Mack schrieb:

[...]

Ah, right, thanks for noticing. New patch below.

Daniel


From 0ce35578c6705dd1c44d076529df6dba889b7b76 Mon Sep 17 00:00:00 2001


From: Daniel Mack <dan...@caiaq.de>
Date: Fri, 8 Jan 2010 02:22:10 +0800
Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335

The ALIX2 LED driver and the CS5535 GPIO drivers share the same I/O


range which causes a conflict if they're both enabled. Fix this for now

by adding Kconfig dependencies. While at it, also drop the EXPERIMENTAL


flag, as the code has been around for awhile already.

Note that this is a hack. At some point, a real platform support for
this board should be added which handles the LEDs via the leds-gpio
driver.

Signed-off-by: Daniel Mack <dan...@caiaq.de>
Cc: Richard Purdie <rpu...@rpsys.net>
Cc: Arnd Hannemann <hann...@nets.rwth-aachen.de>
---
drivers/leds/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 8a0e1ec..fef1cf4 100644


--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -72,7 +72,7 @@ config LEDS_WRAP

config LEDS_ALIX2
tristate "LED Support for ALIX.2 and ALIX.3 series"
- depends on LEDS_CLASS && X86 && EXPERIMENTAL

+ depends on LEDS_CLASS && X86 && !GPIO_CS5535 && !CS5535_GPIO


help
This option enables support for the PCEngines ALIX.2 and ALIX.3 LEDs.
You have to set leds-alix2.force=1 for boards with Award BIOS.

--
1.6.3.3

Daniel Mack

unread,
Jan 16, 2010, 2:00:02 PM1/16/10
to
ping?

Richard Purdie

unread,
Jan 18, 2010, 9:00:02 AM1/18/10
to
On Sun, 2010-01-10 at 13:27 +0100, Daniel Mack wrote:
> Subject: [PATCH] LEDS: ALIX2: Add dependency to !GPIO_CS5335
>
> The ALIX2 LED driver and the CS5535 GPIO drivers share the same I/O
> range which causes a conflict if they're both enabled. Fix this for now
> by adding Kconfig dependencies. While at it, also drop the EXPERIMENTAL
> flag, as the code has been around for awhile already.
>
> Note that this is a hack. At some point, a real platform support for
> this board should be added which handles the LEDs via the leds-gpio
> driver.

Queued in the LED tree, thanks. I'll push this one to Linus shortly for
2.6.33.

Richard

--
Richard Purdie
Intel Open Source Technology Centre

--

0 new messages