[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACRpkdb0+uaRpC7GwWGjPoQMd=re2-BNPY5ritq3HNMJWKOKpg@mail.gmail.com>
Date: Mon, 30 Nov 2020 09:15:49 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Aaro Koskinen <aaro.koskinen@....fi>
Cc: Tony Lindgren <tony@...mide.com>,
Alan Stern <stern@...land.harvard.edu>,
Linux-OMAP <linux-omap@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [BISECTED REGRESSION] Broken USB/GPIO on OMAP1 OSK
On Sun, Nov 29, 2020 at 12:57 PM Aaro Koskinen <aaro.koskinen@....fi> wrote:
> On Sun, Nov 29, 2020 at 01:51:54AM +0200, Aaro Koskinen wrote:
> > I tried to upgrade my OMAP1 OSK board to v5.9, but the rootfs cannot
> > be accessed anymore due to broken USB. It fails to probe with the
> > following logs:
> >
> > [ 9.219940] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring
> > [ 9.250366] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring
> > [ 9.731445] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring
> > [ 10.342102] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring
> > [ 10.966430] ohci ohci: cannot find GPIO chip i2c-tps65010, deferring
> >
> > Bisected to:
> >
> > commit 15d157e874437e381643c37a10922388d6e55b29
> > Author: Linus Walleij <linus.walleij@...aro.org>
> > Date: Mon Jul 20 15:55:24 2020 +0200
> >
> > usb: ohci-omap: Convert to use GPIO descriptors
> >
> > I suspect one of the issues is the name "i2c-tps65010" vs "tps65010":
> >
> > # cat /sys/devices/platform/omap_i2c.1/i2c-1/i2c-tps65010/gpio/gpiochip208/label
> > tps65010
> >
> > However changing that in the lookup table still doesn't help much; I got rid
> > of the "deferring" message but the USB still doesn't work. So far the only
> > workaround I have is to revert the whole commit.
>
> GPIO numbering goes wrong... It's now trying to poke GPIO2.
Hm the old code looked like this:
#define GPIO1 1
tps65010_set_gpio_out_value(GPIO1, LOW);
And I missed that the code inside the tps65010 driver subtracts 1 from
the passed parameter and the standard gpiolib accessors add 1 before
calling the same function. I missed this.
> Also gpiod_set_value_cansleep() probably should be used as tps65010
> can sleep.
OK I'll send a combined patch fixing all issues (I hope).
Yours,
Linus Walleij
Powered by blists - more mailing lists