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@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. 
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/
--
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/