From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Linux GPIO List" <linux-gpio@vger.kernel.org>,
"Ludovic Desroches" <ludovic.desroches@microchip.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Romain Izard" <romain.izard.pro@gmail.com>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: GPIOs not correctly exported via sysfs on ATSAMA5D2
Date: Mon, 2 Mar 2020 16:44:43 +0000 [thread overview]
Message-ID: <20200302164443.GI25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <CACRpkdbADQ5+Tp9NDgQx20Y0QTcE_go2qzi7dJL9HLu8PU1Smg@mail.gmail.com>
On Mon, Mar 02, 2020 at 05:34:19PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 10:36 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Mon, Mar 02, 2020 at 09:39:59AM +0100, Uwe Kleine-König wrote:
>
> > > - Sometimes it is useful to make use of a GPIO and a dedicated function
> > > on the same pin in a driver (e.g. an i2c driver might need to switch
> > > to gpio to do a bus recovery). The automatic pinmuxing then has
> > > strange side effect because you have to remux the pins after
> > > requesting the GPIOs even if you didn't drive the pins as GPIO and
> > > there is a short time where the pin function isn't the dedicated
> > > one.
> >
> > It's worse than that for the i2c driver. The pins are muxed to the i2c
> > function when the driver binds. When the i2c driver claims the GPIOs
> > corresponding with those pins, they get switched to GPIO mode behind
> > the back of pinctrl. You then have to _explicitly_ switch pinctrl to
> > GPIO mode and back to I2C mode to get them back to I2C mode.
>
> That's especially annoying. I would consider adding a specific
> consumer flag for GPIOs used this way, in additon to
> GPIOD_ASIS, something like GPIOD_ASIS_NOMUX
> (thinking of better names).
It's very annoying, and I believe something I did point out in my email
about it when I discovered it towards the end of last year.
Having a way to avoid the muxing would be a very good idea, as there
are cases where we really should not be taking the I2C pins away from
the controller during driver initialisation. In the case of i2c-pxa,
when the pins are taken away, the controller sees the disconnected SCL
and SDA lines go low, and it can assume that the bus is busy as a
result, or worse see it as a START condition if SDA goes low while SCL
is high.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "Alexandre Belloni" <alexandre.belloni@bootlin.com>,
"Linux GPIO List" <linux-gpio@vger.kernel.org>,
"Ludovic Desroches" <ludovic.desroches@microchip.com>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Romain Izard" <romain.izard.pro@gmail.com>,
"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: GPIOs not correctly exported via sysfs on ATSAMA5D2
Date: Mon, 2 Mar 2020 16:44:43 +0000 [thread overview]
Message-ID: <20200302164443.GI25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <CACRpkdbADQ5+Tp9NDgQx20Y0QTcE_go2qzi7dJL9HLu8PU1Smg@mail.gmail.com>
On Mon, Mar 02, 2020 at 05:34:19PM +0100, Linus Walleij wrote:
> On Mon, Mar 2, 2020 at 10:36 AM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > On Mon, Mar 02, 2020 at 09:39:59AM +0100, Uwe Kleine-König wrote:
>
> > > - Sometimes it is useful to make use of a GPIO and a dedicated function
> > > on the same pin in a driver (e.g. an i2c driver might need to switch
> > > to gpio to do a bus recovery). The automatic pinmuxing then has
> > > strange side effect because you have to remux the pins after
> > > requesting the GPIOs even if you didn't drive the pins as GPIO and
> > > there is a short time where the pin function isn't the dedicated
> > > one.
> >
> > It's worse than that for the i2c driver. The pins are muxed to the i2c
> > function when the driver binds. When the i2c driver claims the GPIOs
> > corresponding with those pins, they get switched to GPIO mode behind
> > the back of pinctrl. You then have to _explicitly_ switch pinctrl to
> > GPIO mode and back to I2C mode to get them back to I2C mode.
>
> That's especially annoying. I would consider adding a specific
> consumer flag for GPIOs used this way, in additon to
> GPIOD_ASIS, something like GPIOD_ASIS_NOMUX
> (thinking of better names).
It's very annoying, and I believe something I did point out in my email
about it when I discovered it towards the end of last year.
Having a way to avoid the muxing would be a very good idea, as there
are cases where we really should not be taking the I2C pins away from
the controller during driver initialisation. In the case of i2c-pxa,
when the pins are taken away, the controller sees the disconnected SCL
and SDA lines go low, and it can assume that the bus is busy as a
result, or worse see it as a START condition if SDA goes low while SCL
is high.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-03-02 16:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-28 10:58 GPIOs not correctly exported via sysfs on ATSAMA5D2 Romain Izard
2020-02-28 10:58 ` Romain Izard
2020-02-28 12:39 ` Ludovic Desroches
2020-02-28 12:39 ` Ludovic Desroches
2020-02-28 12:46 ` Russell King - ARM Linux admin
2020-02-28 12:46 ` Russell King - ARM Linux admin
2020-02-28 13:36 ` Linus Walleij
2020-02-28 13:36 ` Linus Walleij
2020-03-02 8:47 ` Uwe Kleine-König
2020-03-02 8:47 ` Uwe Kleine-König
2020-03-02 8:39 ` Uwe Kleine-König
2020-03-02 8:39 ` Uwe Kleine-König
2020-03-02 9:36 ` Russell King - ARM Linux admin
2020-03-02 9:36 ` Russell King - ARM Linux admin
2020-03-02 16:34 ` Linus Walleij
2020-03-02 16:34 ` Linus Walleij
2020-03-02 16:44 ` Russell King - ARM Linux admin [this message]
2020-03-02 16:44 ` Russell King - ARM Linux admin
2020-03-02 21:30 ` Uwe Kleine-König
2020-03-02 21:30 ` Uwe Kleine-König
2020-03-03 13:10 ` Linus Walleij
2020-03-03 13:10 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200302164443.GI25745@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=alexandre.belloni@bootlin.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=ludovic.desroches@microchip.com \
--cc=romain.izard.pro@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.