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 <dvh...@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
--
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.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
