gpio-sch GPIO_SYSFS access

gpio-sch GPIO_SYSFS access

[Darren Hart]

I'm working with a TunnelCreek + EG20T platform which has two GPIO drivers:

gpio-sch - for the CPU GPIO lines
gpio-pch - for the EG20T GPIO lines

I can see the PCH GPIO lines in /sys/class/gpio, but not the CPU lines:

# dmesg | grep -i gpio
pch_gpio 0000:03:00.2: enabling device (0000 -> 0002)

gpiochip_find_base: found new base at 244

gpiochip_add: registered GPIOs 244 to 255 on device: 0000:03:00.2

gpiochip_add: registered GPIOs 0 to 4 on device: sch_gpio_core

gpiochip_add: registered GPIOs 5 to 13 on device: sch_gpio_resume

gpio_request: gpio-0 (sysfs) status -22

gpio_request: gpio-243 (sysfs) status -22

gpio_request: gpio-256 (sysfs) status -22


# ls /sys/class/gpio
export       gpiochip244  unexport

I can export 244-255 and manipulate and read them through the
sys interface. I cannot seem to access 0-13, although the dmesg
above seems to have successfully added them (and the core/resume
pin mapping is correct for a TunnelCreek CPU).

I'm not seeing any obvious difference in how the two drivers probe and
setup the chip that explains why one is accessible and the other is not.

I've enabled the following GPIO CONFIG* options:
$ cat config-minnow.gpio | grep -e "^CONFIG_.*GPIO"
CONFIG_GENERIC_GPIO=y
CONFIG_KEYBOARD_GPIO=y
CONFIG_KEYBOARD_GPIO_POLLED=y
CONFIG_SPI_GPIO=y
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIOLIB=y
CONFIG_DEBUG_GPIO=y
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_GENERIC=y
CONFIG_GPIO_GENERIC_PLATFORM=y
CONFIG_GPIO_SCH=y
CONFIG_GPIO_PCH=y
CONFIG_LEDS_GPIO=y

I'm working with 3.4.26, but I have not seen anything in the gpio-sch.c
driver commit log that would suggest a fix has landed. I suspect I am
missing something fundamental about how these lines get exported.

Any ideas on what I might be missing?

Is it that some other driver has claimed these GPIO lines? If so, how do
I determine which one?

Thanks!

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: gpio-sch GPIO_SYSFS access

[Linus Walleij]

On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvhart@linux.intel.com> wrote:

> Is it that some other driver has claimed these GPIO lines? If so, how do
> I determine which one?

Yes I think that could be it, the driver would need to call
gpio_export() for it to also be accessible in sysfs.

Configure in debugfs and check the file "gpio" in debugfs
to figure out the client.

Yours,
Linus Walleij

Re: gpio-sch GPIO_SYSFS access

[Darren Hart]

On 02/07/2013 02:09 AM, Linus Walleij wrote:
> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> 
>> Is it that some other driver has claimed these GPIO lines? If so, how do
>> I determine which one?
> 
> Yes I think that could be it, the driver would need to call
> gpio_export() for it to also be accessible in sysfs.

Do you mean gpiochip_export()?

Hrm, neither gpio-pch nor gpio-sch call gpiochip_export() directly. They
both call gpiochip_add() and that calls gpiochip_export() unconditionally.
As far as I could tell, both drivers call gpiochip_export().

I thought maybe the sch happened to early, maybe hitting the the
pre-driver-model-support note in gpiochip_export(), but it runs after
the pch chip for some reason, and that one is fine. I suppose I could be
failing on device_create or sysfs_create_group and just not seeing the
output. I'll try to get DYNAMIC_DEBUG and pr_debug in gpiolib.c working
(that always seems to be an unnecessarily arduous exercise).

> 
> Configure in debugfs and check the file "gpio" in debugfs
> to figure out the client.

That file contained only the gpiochip244 from the gpio-pch driver,
nothing from the sch.

Thanks!

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: gpio-sch GPIO_SYSFS access

[Darren Hart]

On 02/07/2013 02:09 AM, Linus Walleij wrote:
> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> 
>> Is it that some other driver has claimed these GPIO lines? If so, how do
>> I determine which one?
> 
> Yes I think that could be it, the driver would need to call
> gpio_export() for it to also be accessible in sysfs.
> 
> Configure in debugfs and check the file "gpio" in debugfs
> to figure out the client.

I added dynamic printk and queried the relevant files. I didn't see any
dev_* or pr_* messages.

# dmesg | grep -i gpio
Kernel command line: BOOT_IMAGE=/vmlinuz root=/dev/sda2
console=ttyPCH0,115200 cons
ole=tty0 vmalloc=256MB "dyndbg=file gpiolib.c +p;file gpio-sch.c +p;
file gpio-pch.
c +p" dynamic_debug.verbose=1 debug loglevel=8

dynamic_debug:ddebug_add_module: 17 debug prints in module gpiolib
dynamic_debug:ddebug_add_module: 2 debug prints in module gpio_pch
pch_gpio 0000:02:00.2: enabling device (0000 -> 0002)
gpiochip_find_base: found new base at 244
gpiochip_add: registered GPIOs 244 to 255 on device: 0000:02:00.2
gpiochip_add: registered GPIOs 0 to 4 on device: sch_gpio_core
gpiochip_add: registered GPIOs 5 to 13 on device: sch_gpio_resume

The GPIO debugfs and SYSFS interfaces only show the GPIO from the PCH,
nothing from the SCH (CPU):

# cat /debug/gpio
GPIOs 244-255, 0000:02:00.2:

# ls /sys/class/gpio/
export       gpiochip244  unexport

Instrumenting gpiochip_export, I see:

gpiochip_export: base=0 ngpio=5 label=sch_gpio_core
gpiochip_add: registered GPIOs 0 to 4 on device: sch_gpio_core

gpiochip_export: base=5 ngpio=9 label=sch_gpio_resume
gpiochip_add: registered GPIOs 5 to 13 on device: sch_gpio_resume

So the calls to gpiochip_export for the sch driver are being made, and
my on-error instrumentation did not trigger.

Finally, I do see an "irq 16: nobody cared" with the sch driver as
the handler. It isn't clear to me that this would cause the chip not
to appear in sysfs, but I'm including it here for completeness:

irq 16: nobody cared (try booting with the "irqpoll" option)

Pid: 0, comm: swapper/0 Not tainted 3.4.26-yocto-standard #2

Call Trace:

 [<c1648288>] ? printk+0x2e/0x30

 [<c1093cfa>] __report_bad_irq+0x2a/0xd0
 [<c1389719>] ? add_interrupt_randomness+0x19/0x150

 [<c1093fd4>] note_interrupt+0x174/0x1c0
 [<c1009fbf>] ? cpu_idle+0x1f/0xb0

 [<c1091da2>] handle_irq_event_percpu+0xb2/0x220

 [<c1653fc9>] ? add_preempt_count+0x9/0xb0

 [<c1091f4b>] handle_irq_event+0x3b/0x60

 [<c1094940>] ? unmask_irq+0x30/0x30

 [<c1094990>] handle_fasteoi_irq+0x50/0xe0

 <IRQ>  [<c16576b3>] ? do_IRQ+0x43/0xb0

 [<c1056f04>] ? scheduler_ipi+0x74/0xd0

 [<c16575e9>] ? common_interrupt+0x29/0x30

 [<c1009fbf>] ? cpu_idle+0x1f/0xb0
 [<c1632518>] ? rest_init+0x6c/0x74
 [<c193b71d>] ? start_kernel+0x30c/0x313

 [<c193b243>] ? repair_env_string+0x51/0x51

 [<c193b078>] ? i386_start_kernel+0x78/0x7d

handlers:

[<c130aec0>] pch_gpio_handler

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: gpio-sch GPIO_SYSFS access

[Darren Hart]

On 02/07/2013 02:09 AM, Linus Walleij wrote:
> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> 
>> Is it that some other driver has claimed these GPIO lines? If so, how do
>> I determine which one?
> 
> Yes I think that could be it, the driver would need to call
> gpio_export() for it to also be accessible in sysfs.
> 
> Configure in debugfs and check the file "gpio" in debugfs
> to figure out the client.
> 
> Yours,
> Linus Walleij
> 

I found gpio_export() as you suggested above and instrumented it. What I
found was that it was not getting called at all. As I understand it,
calling gpiochip_export() should make the gpiochip# appear in
/sys/class/gpio and then I should be able to configure which lines are
exported via the /sys/class/gpio/export file.

I haven't yet found how gpio-pch differs from gpio-sch that causes the
gpio-pch chip to appear in sysfs and the gpio-sch one not to. I did
patch gpio-sch with a request and export loop:

$ git diff drivers/gpio/gpio-sch.c
diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 8cadf4d..79783c1 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -188,7 +188,7 @@ static struct gpio_chip sch_gpio_resume = {
 static int __devinit sch_gpio_probe(struct platform_device *pdev)
 {
        struct resource *res;
-       int err, id;
+       int err, id, gpio;

        id = pdev->id;
        if (!id)
@@ -243,10 +243,24 @@ static int __devinit sch_gpio_probe(struct
platform_device *p
        if (err < 0)
                goto err_sch_gpio_core;

+       /* DEBUG: export all the core GPIOS */
+       for (gpio = sch_gpio_core.base;
+            gpio < sch_gpio_core.base + sch_gpio_core.ngpio; gpio++) {
+               gpio_request(gpio, "gpio-sch");
+               gpio_export(gpio, true);
+       }
+
        err = gpiochip_add(&sch_gpio_resume);
        if (err < 0)
                goto err_sch_gpio_resume;

+       /* DEBUG: export all the resume GPIOS */
+       for (gpio = sch_gpio_resume.base;
+            gpio < sch_gpio_resume.base + sch_gpio_resume.ngpio; gpio++) {
+               gpio_request(gpio, "gpio-sch");
+               gpio_export(gpio, true);
+       }
+
        return 0;

 err_sch_gpio_resume:


With this both the gpiochip# and gpio# entries appear in sysfs. However,
unlike those for the gpio-pch lines, these report an error in the sysfs
interface:

/sys/class/gpio# ls *
ls: gpio0: No such file or directory

ls: gpio1: No such file or directory

ls: gpio10: No such file or directory

ls: gpio11: No such file or directory

ls: gpio12: No such file or directory

ls: gpio13: No such file or directory

ls: gpio2: No such file or directory

ls: gpio3: No such file or directory

ls: gpio4: No such file or directory

ls: gpio5: No such file or directory

ls: gpio6: No such file or directory

ls: gpio7: No such file or directory

ls: gpio8: No such file or directory

ls: gpio9: No such file or directory

ls: gpiochip0: No such file or directory

ls: gpiochip5: No such file or directory

export    unexport



gpiochip244:

base       label      ngpio      power      subsystem  uevent

Clearly I'm still missing something. I've read through gpio.txt a couple
times and each time piece a bit more together. I'll do that again, but I
still suspect I'm missing something fundamental here. In particular, I
still don't understand how the gpio-pch and gpio-sch drivers are create
such different results.


Ultimately what I'm looking to do is configure a new board such that 8
of the gpio-sch lines are configured as buttons and LEDs which are
physically attached to the board (4 of each). I was hoping to use this
interface to understand the ins and outs (haha) of the GPIO subsystem.
Ultimately I believe I need either a "platform-device" or possibly an
ACPI DSDT from the firmware to properly describe the GPIO lines and
their direction. Ultimately, these should be driven by the gpio-keys and
gpio-led drivers - at least that's my current understanding.

Any help clarifying some of this would be greatly appreciated.

Thanks for the time!

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: gpio-sch GPIO_SYSFS access

[Darren Hart]

On 02/07/2013 08:40 PM, Darren Hart wrote:
> 
> 
> On 02/07/2013 02:09 AM, Linus Walleij wrote:
>> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>
>>> Is it that some other driver has claimed these GPIO lines? If so, how do
>>> I determine which one?
>>
>> Yes I think that could be it, the driver would need to call
>> gpio_export() for it to also be accessible in sysfs.
>>
>> Configure in debugfs and check the file "gpio" in debugfs
>> to figure out the client.
>>
>> Yours,
>> Linus Walleij
>>
> 
> I found gpio_export() as you suggested above and instrumented it. What I
> found was that it was not getting called at all. As I understand it,
> calling gpiochip_export() should make the gpiochip# appear in
> /sys/class/gpio and then I should be able to configure which lines are
> exported via the /sys/class/gpio/export file.
> 
> I haven't yet found how gpio-pch differs from gpio-sch that causes the
> gpio-pch chip to appear in sysfs and the gpio-sch one not to. I did
> patch gpio-sch with a request and export loop:
> 
> $ git diff drivers/gpio/gpio-sch.c
> diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
> index 8cadf4d..79783c1 100644
> --- a/drivers/gpio/gpio-sch.c
> +++ b/drivers/gpio/gpio-sch.c
> @@ -188,7 +188,7 @@ static struct gpio_chip sch_gpio_resume = {
>  static int __devinit sch_gpio_probe(struct platform_device *pdev)
>  {
>         struct resource *res;
> -       int err, id;
> +       int err, id, gpio;
> 
>         id = pdev->id;
>         if (!id)
> @@ -243,10 +243,24 @@ static int __devinit sch_gpio_probe(struct
> platform_device *p
>         if (err < 0)
>                 goto err_sch_gpio_core;
> 
> +       /* DEBUG: export all the core GPIOS */
> +       for (gpio = sch_gpio_core.base;
> +            gpio < sch_gpio_core.base + sch_gpio_core.ngpio; gpio++) {
> +               gpio_request(gpio, "gpio-sch");
> +               gpio_export(gpio, true);
> +       }
> +
>         err = gpiochip_add(&sch_gpio_resume);
>         if (err < 0)
>                 goto err_sch_gpio_resume;
> 
> +       /* DEBUG: export all the resume GPIOS */
> +       for (gpio = sch_gpio_resume.base;
> +            gpio < sch_gpio_resume.base + sch_gpio_resume.ngpio; gpio++) {
> +               gpio_request(gpio, "gpio-sch");
> +               gpio_export(gpio, true);
> +       }
> +
>         return 0;
> 
>  err_sch_gpio_resume:
> 
> 
> With this both the gpiochip# and gpio# entries appear in sysfs. However,
> unlike those for the gpio-pch lines, these report an error in the sysfs
> interface:
> 
> /sys/class/gpio# ls *
> ls: gpio0: No such file or directory
> 

Well, this happens when the driver in question gets removed by another
driver. In this case the mfd/lpc_sch.c driver fails reading some PCI
config after it has added the gpio-pch device to a list:

lpc_sch 0000:00:1f.0: Decode of the WDT I/O range disabled


It then proceeds to remove all the devices it added - including gpio-pch.c.

Dragging Samuel in as his name is on some of the commits, maybe he can
help here.

Samuel, does it make sense for CONFIG_GPIO_SCH to require
CONFIG_LPC_SCH? I'm building for a Queensbay (Atom E6xx + EG20T PCH).
There is no SCH as I understand things. Can these be decoupled?

I should note that if I just refuse to remove the gpio-sch with -EBUSY,
the gpiochip files show up in /sys:

# ls /sys/class/gpio/
export       gpiochip0    gpiochip244  gpiochip5    unexport

and debugfs/gpio shows the sch gpio ranges:

GPIOs 0-4,platform/sch_gpio.33158,sch_gpio_core:
GPIOs 5-13, platform/sch_gpio.33158, sch_gpio_resume:

GPIOs 244-255, 0000:02:00.2:


Unfortunatley, they still fail to export:

# echo 0 > /sys/class/gpio/export
gpio_export: gpio0 status -2
export_store: status -2
sh: write error: No such file or directory

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: gpio-sch GPIO_SYSFS access

[Samuel Ortiz]

Hi Darren,

On Thu, Feb 07, 2013 at 11:08:03PM -0800, Darren Hart wrote:
> On 02/07/2013 08:40 PM, Darren Hart wrote:
> > 
> > 
> > On 02/07/2013 02:09 AM, Linus Walleij wrote:
> >> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> >>
> >>> Is it that some other driver has claimed these GPIO lines? If so, how do
> >>> I determine which one?
> >>
> >> Yes I think that could be it, the driver would need to call
> >> gpio_export() for it to also be accessible in sysfs.
> >>
> >> Configure in debugfs and check the file "gpio" in debugfs
> >> to figure out the client.
> >>
> >> Yours,
> >> Linus Walleij
> >>
> > 
> > I found gpio_export() as you suggested above and instrumented it. What I
> > found was that it was not getting called at all. As I understand it,
> > calling gpiochip_export() should make the gpiochip# appear in
> > /sys/class/gpio and then I should be able to configure which lines are
> > exported via the /sys/class/gpio/export file.
> > 
> > I haven't yet found how gpio-pch differs from gpio-sch that causes the
> > gpio-pch chip to appear in sysfs and the gpio-sch one not to. I did
> > patch gpio-sch with a request and export loop:
> > 
> > $ git diff drivers/gpio/gpio-sch.c
> > diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
> > index 8cadf4d..79783c1 100644
> > --- a/drivers/gpio/gpio-sch.c
> > +++ b/drivers/gpio/gpio-sch.c
> > @@ -188,7 +188,7 @@ static struct gpio_chip sch_gpio_resume = {
> >  static int __devinit sch_gpio_probe(struct platform_device *pdev)
> >  {
> >         struct resource *res;
> > -       int err, id;
> > +       int err, id, gpio;
> > 
> >         id = pdev->id;
> >         if (!id)
> > @@ -243,10 +243,24 @@ static int __devinit sch_gpio_probe(struct
> > platform_device *p
> >         if (err < 0)
> >                 goto err_sch_gpio_core;
> > 
> > +       /* DEBUG: export all the core GPIOS */
> > +       for (gpio = sch_gpio_core.base;
> > +            gpio < sch_gpio_core.base + sch_gpio_core.ngpio; gpio++) {
> > +               gpio_request(gpio, "gpio-sch");
> > +               gpio_export(gpio, true);
> > +       }
> > +
> >         err = gpiochip_add(&sch_gpio_resume);
> >         if (err < 0)
> >                 goto err_sch_gpio_resume;
> > 
> > +       /* DEBUG: export all the resume GPIOS */
> > +       for (gpio = sch_gpio_resume.base;
> > +            gpio < sch_gpio_resume.base + sch_gpio_resume.ngpio; gpio++) {
> > +               gpio_request(gpio, "gpio-sch");
> > +               gpio_export(gpio, true);
> > +       }
> > +
> >         return 0;
> > 
> >  err_sch_gpio_resume:
> > 
> > 
> > With this both the gpiochip# and gpio# entries appear in sysfs. However,
> > unlike those for the gpio-pch lines, these report an error in the sysfs
> > interface:
> > 
> > /sys/class/gpio# ls *
> > ls: gpio0: No such file or directory
> > 
> 
> Well, this happens when the driver in question gets removed by another
> driver. 
removed by another driver ? I'm not sure I understand what that means.

> In this case the mfd/lpc_sch.c driver fails reading some PCI
> config after it has added the gpio-pch device to a list:
> 
> lpc_sch 0000:00:1f.0: Decode of the WDT I/O range disabled
> 
> 
> It then proceeds to remove all the devices it added - including gpio-pch.c.
> 
> Dragging Samuel in as his name is on some of the commits, maybe he can
> help here.
> 
> Samuel, does it make sense for CONFIG_GPIO_SCH to require
> CONFIG_LPC_SCH? I'm building for a Queensbay (Atom E6xx + EG20T PCH).
> There is no SCH as I understand things. Can these be decoupled?
They actually don't have code dependency, GPIO_SCH selects LPC_SCH beacause
the MFD parts actually creates the GPIO device.
So you're saying Queensbay use the same GPIO IP block without actually having
SCH ?

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: gpio-sch GPIO_SYSFS access

[Darren Hart]

On 02/08/2013 12:49 AM, Samuel Ortiz wrote:
> Hi Darren,
> 
> On Thu, Feb 07, 2013 at 11:08:03PM -0800, Darren Hart wrote:
>> On 02/07/2013 08:40 PM, Darren Hart wrote:
>>>
>>>
>>> On 02/07/2013 02:09 AM, Linus Walleij wrote:
>>>> On Thu, Feb 7, 2013 at 1:58 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>>>
>>>>> Is it that some other driver has claimed these GPIO lines? If so, how do
>>>>> I determine which one?
>>>>
>>>> Yes I think that could be it, the driver would need to call
>>>> gpio_export() for it to also be accessible in sysfs.
>>>>
>>>> Configure in debugfs and check the file "gpio" in debugfs
>>>> to figure out the client.
>>>>
>>>> Yours,
>>>> Linus Walleij
>>>>
>>>
>>> I found gpio_export() as you suggested above and instrumented it. What I
>>> found was that it was not getting called at all. As I understand it,
>>> calling gpiochip_export() should make the gpiochip# appear in
>>> /sys/class/gpio and then I should be able to configure which lines are
>>> exported via the /sys/class/gpio/export file.
>>>
>>> I haven't yet found how gpio-pch differs from gpio-sch that causes the
>>> gpio-pch chip to appear in sysfs and the gpio-sch one not to. I did
>>> patch gpio-sch with a request and export loop:
>>>
>>> $ git diff drivers/gpio/gpio-sch.c
>>> diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
>>> index 8cadf4d..79783c1 100644
>>> --- a/drivers/gpio/gpio-sch.c
>>> +++ b/drivers/gpio/gpio-sch.c
>>> @@ -188,7 +188,7 @@ static struct gpio_chip sch_gpio_resume = {
>>>  static int __devinit sch_gpio_probe(struct platform_device *pdev)
>>>  {
>>>         struct resource *res;
>>> -       int err, id;
>>> +       int err, id, gpio;
>>>
>>>         id = pdev->id;
>>>         if (!id)
>>> @@ -243,10 +243,24 @@ static int __devinit sch_gpio_probe(struct
>>> platform_device *p
>>>         if (err < 0)
>>>                 goto err_sch_gpio_core;
>>>
>>> +       /* DEBUG: export all the core GPIOS */
>>> +       for (gpio = sch_gpio_core.base;
>>> +            gpio < sch_gpio_core.base + sch_gpio_core.ngpio; gpio++) {
>>> +               gpio_request(gpio, "gpio-sch");
>>> +               gpio_export(gpio, true);
>>> +       }
>>> +
>>>         err = gpiochip_add(&sch_gpio_resume);
>>>         if (err < 0)
>>>                 goto err_sch_gpio_resume;
>>>
>>> +       /* DEBUG: export all the resume GPIOS */
>>> +       for (gpio = sch_gpio_resume.base;
>>> +            gpio < sch_gpio_resume.base + sch_gpio_resume.ngpio; gpio++) {
>>> +               gpio_request(gpio, "gpio-sch");
>>> +               gpio_export(gpio, true);
>>> +       }
>>> +
>>>         return 0;
>>>
>>>  err_sch_gpio_resume:
>>>
>>>
>>> With this both the gpiochip# and gpio# entries appear in sysfs. However,
>>> unlike those for the gpio-pch lines, these report an error in the sysfs
>>> interface:
>>>
>>> /sys/class/gpio# ls *
>>> ls: gpio0: No such file or directory
>>>
>>
>> Well, this happens when the driver in question gets removed by another
>> driver. 
> removed by another driver ? I'm not sure I understand what that means.

In my case, the gpio-sch probe function runs and creates the gpiochip
with 14 GPIO lines. Later lpc-sch probe runs, adds devices to the mfd
device list, fails the WDT base address as described below, and then
removes the devices in the mfd device list, which triggers the removal
of the gpio-sch device.

If I just skip the WDT lookup and not abort, then things work as I had
expected. Sooo... does it make sense to remove ALL the MFD device when
the read of the WDTBA registers indicates "Disabled"? Seems extreme to me.

> 
>> In this case the mfd/lpc_sch.c driver fails reading some PCI
>> config after it has added the gpio-pch device to a list:
>>
>> lpc_sch 0000:00:1f.0: Decode of the WDT I/O range disabled
>>
>>
>> It then proceeds to remove all the devices it added - including gpio-pch.c.
>>
>> Dragging Samuel in as his name is on some of the commits, maybe he can
>> help here.
>>
>> Samuel, does it make sense for CONFIG_GPIO_SCH to require
>> CONFIG_LPC_SCH? I'm building for a Queensbay (Atom E6xx + EG20T PCH).
>> There is no SCH as I understand things. Can these be decoupled?
> They actually don't have code dependency, GPIO_SCH selects LPC_SCH beacause
> the MFD parts actually creates the GPIO device.
> So you're saying Queensbay use the same GPIO IP block without actually having
> SCH ?

That is how I currently understand it. These drivers appear to have been
originaly written for the Silverthorne (Z5xx) CPUs and the Intel SCH
chipset.
TunnelCreek (E6xx) support was added later, but apparently the LPC
bridge is onboard the CPU and it still contains the registers to setup
the gpio-sch base address and such as you suggest - so still needed. The
Queensbay platform is an E6xx CPU and the EG20T PCH (no SCH).

The driver is failing when looking for the watchdog base address (bit 31
isn't 1 apparently). I suppose this could be a firmware issue?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: gpio-sch GPIO_SYSFS access

[Samuel Ortiz]

On Fri, Feb 08, 2013 at 02:36:16AM -0800, Darren Hart wrote:
> On 02/08/2013 12:49 AM, Samuel Ortiz wrote:
> >> Well, this happens when the driver in question gets removed by another
> >> driver. 
> > removed by another driver ? I'm not sure I understand what that means.
> 
> In my case, the gpio-sch probe function runs and creates the gpiochip
> with 14 GPIO lines. Later lpc-sch probe runs, 
That's weird: The lpc-sch probe should run first. Then the gpio-sch probe
should be called when lpc-sch adds the MFD cells as platform devices, from
lpc_sch_probe().
So someone is adding gpio-sch as a platform device, and that is wrong.

> adds devices to the mfd
> device list, fails the WDT base address as described below, and then
> removes the devices in the mfd device list, which triggers the removal
> of the gpio-sch device.
> 
> If I just skip the WDT lookup and not abort, then things work as I had
> expected. Sooo... does it make sense to remove ALL the MFD device when
> the read of the WDTBA registers indicates "Disabled"? Seems extreme to me.
Yes, that's a bit rough. But I think you have a more fundamental problem where
you're probing both LPC and your GPIO driver.

> >> Samuel, does it make sense for CONFIG_GPIO_SCH to require
> >> CONFIG_LPC_SCH? I'm building for a Queensbay (Atom E6xx + EG20T PCH).
> >> There is no SCH as I understand things. Can these be decoupled?
> > They actually don't have code dependency, GPIO_SCH selects LPC_SCH beacause
> > the MFD parts actually creates the GPIO device.
> > So you're saying Queensbay use the same GPIO IP block without actually having
> > SCH ?
> 
> That is how I currently understand it. These drivers appear to have been
> originaly written for the Silverthorne (Z5xx) CPUs and the Intel SCH
> chipset.
If your lpc_sch_probe routine runs, you basically have an LPC on your PCI bus
here. As I said, PCI probes lpc_sch _and_ gpio_sch is probed as well (As a
platform device, probably coming from your SFI tables or so). Probing both is
problematic, especially since you do have an LPC sitting on your PCI bus.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

Re: gpio-sch GPIO_SYSFS access

[Darren Hart]

On 02/08/2013 03:07 AM, Samuel Ortiz wrote:
> On Fri, Feb 08, 2013 at 02:36:16AM -0800, Darren Hart wrote:
>> On 02/08/2013 12:49 AM, Samuel Ortiz wrote:
>>>> Well, this happens when the driver in question gets removed by another
>>>> driver. 
>>> removed by another driver ? I'm not sure I understand what that means.
>>
>> In my case, the gpio-sch probe function runs and creates the gpiochip
>> with 14 GPIO lines. Later lpc-sch probe runs, 
> That's weird: The lpc-sch probe should run first. Then the gpio-sch probe
> should be called when lpc-sch adds the MFD cells as platform devices, from
> lpc_sch_probe().
> So someone is adding gpio-sch as a platform device, and that is wrong.
> 
>> adds devices to the mfd
>> device list, fails the WDT base address as described below, and then
>> removes the devices in the mfd device list, which triggers the removal
>> of the gpio-sch device.
>>
>> If I just skip the WDT lookup and not abort, then things work as I had
>> expected. Sooo... does it make sense to remove ALL the MFD device when
>> the read of the WDTBA registers indicates "Disabled"? Seems extreme to me.
> Yes, that's a bit rough. But I think you have a more fundamental problem where
> you're probing both LPC and your GPIO driver.
> 
>>>> Samuel, does it make sense for CONFIG_GPIO_SCH to require
>>>> CONFIG_LPC_SCH? I'm building for a Queensbay (Atom E6xx + EG20T PCH).
>>>> There is no SCH as I understand things. Can these be decoupled?
>>> They actually don't have code dependency, GPIO_SCH selects LPC_SCH beacause
>>> the MFD parts actually creates the GPIO device.
>>> So you're saying Queensbay use the same GPIO IP block without actually having
>>> SCH ?
>>
>> That is how I currently understand it. These drivers appear to have been
>> originaly written for the Silverthorne (Z5xx) CPUs and the Intel SCH
>> chipset.
> If your lpc_sch_probe routine runs, you basically have an LPC on your PCI bus
> here. As I said, PCI probes lpc_sch _and_ gpio_sch is probed as well (As a
> platform device, probably coming from your SFI tables or so). Probing both is
> problematic, especially since you do have an LPC sitting on your PCI bus.


Upon closer inspection what is really happening is the lpc_sch probe
runs and adds the sch_gpio device with the mfd_add_devices call which
creates the platform device. At that time the gpio_sch probe runs and
sets up the gpio stuff. Control returns to the lpc_sch which then tries
to find the WDT, fails, and removes all the mfd devices it had added
previously.

I'm working with firmware (UEFI, ACPI - not SFI) on why WDTBA is 0, but
in the meantime I'll work up a patch to not destroy all the valid devices
when that one fails.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel