From: Linus Walleij <linus.walleij@linaro.org>
To: David Laight <David.Laight@aculab.com>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
Ludovic Desroches <ludovic.desroches@microchip.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
"Claudiu.Beznea@microchip.com" <Claudiu.Beznea@microchip.com>,
"linux-gpio@vger.kernel.org" <linux-gpio@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] pinctrl: at91-pio4: implement .get_multiple and .set_multiple
Date: Thu, 3 Oct 2019 10:08:51 +0200 [thread overview]
Message-ID: <CACRpkdZeBTWZ3NYR-aoTL0whXZLZxCJ+rB_jzCChgA5iKVOk=A@mail.gmail.com> (raw)
In-Reply-To: <b010053340ef48dfa244ff48c8decd38@AcuMS.aculab.com>
On Fri, Sep 6, 2019 at 11:46 AM David Laight <David.Laight@aculab.com> wrote:
> > On 06/09/2019 09:05:36+0000, David Laight wrote:
> > It does improve gpio switching synchronisation when they are in the same
> > bank as it will remove the 250ns delay. Of course, if you need this
> > delay between clk and data, then the consumer driver should ensure the
> > delay is present.
>
> With multiple requests the output pin changes will always be in the
> same order and will be separated by (say) 250ns.
> This is a guaranteed synchronisation.
Do you mean that hardware will guarantee this synchronization?
Linux device driver code cannot rely on that. We will simply
grab two individual GPIO lines (not get_multiple()) then issue
set() on the clock, ndelay(250) and then set() data.
It doesn't matter much because bitbanging is always extremely
slow anyways so one will get lots of delay, which is why
e.g. spi-gpio doesn't insert any delay IIRC.
The point is that the lines need be grabbed individually so
the delay between can be controlled.
> IIRC both SMBus and I2C now quote 0ns setup time.
> Changing both clock and data with the same IOW isn't enough to
> guarantee this.
> (In practise the I2C setup time required by a device is probably
> slightly negative (In order to support 0ns inputs) so a very small
> -ve setup will (mostly) work.)
If you are referring to drivers/i2c/busses/i2c-gpio.c it does seem
to do proper delays using bit_data->udelay from the bitbang
library.
Yours,
Linus Walleij
prev parent reply other threads:[~2019-10-03 8:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-05 14:48 [PATCH v2] pinctrl: at91-pio4: implement .get_multiple and .set_multiple Alexandre Belloni
2019-09-06 9:05 ` David Laight
2019-09-06 9:12 ` Alexandre Belloni
2019-09-06 9:46 ` David Laight
2019-09-06 10:42 ` Alexandre Belloni
2019-10-03 8:08 ` Linus Walleij [this message]
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='CACRpkdZeBTWZ3NYR-aoTL0whXZLZxCJ+rB_jzCChgA5iKVOk=A@mail.gmail.com' \
--to=linus.walleij@linaro.org \
--cc=Claudiu.Beznea@microchip.com \
--cc=David.Laight@aculab.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.desroches@microchip.com \
--cc=nicolas.ferre@microchip.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).