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@xxxxxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/