From: khali@linux-fr.org (Jean Delvare)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/4 v2] i2c/gpio: add DT support
Date: Mon, 20 Feb 2012 14:35:57 +0100 [thread overview]
Message-ID: <20120220143557.02787bad@endymion.delvare> (raw)
In-Reply-To: <20120220125054.GF22562@n2100.arm.linux.org.uk>
On Mon, 20 Feb 2012 12:50:54 +0000, Russell King - ARM Linux wrote:
> What is linux specific is specifying the _delay_ rather than specifying
> the bus frequency. So as soon as you're trying to justify not adding
> the units because they may be linux specific, you've already lost that
> argument by using a delay rather than a bus frequency. You can't have
> it both ways.
While I am not much into DT and did not follow this thread too
carefully... I seem to understand that the dispute is mainly on
frequency vs. udelay specification for the bus speed, Jean-Christophe
arguing that hardware-specific delays are added when changing e.g. a
GPIO pin output value and thus the frequency can't be guaranteed. Do I
get this right?
If so I would suggest that you specify neither the frequency nor
udelay, but the _maximum_ frequency. Where maximum frequency = 10^6 /
(2 * udelay) Hz. Would this make everybody happy?
Note that I2C allows clock stretching by the slaves so even without the
extra delay incurred by hardware state switching, the bus operating
frequency is already a maximum rather than a guaranteed valued.
--
Jean Delvare
next prev parent reply other threads:[~2012-02-20 13:35 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-09 2:25 [PATCH 1/4 v2] i2c/gpio: add DT support Jean-Christophe PLAGNIOL-VILLARD
2012-02-09 2:25 ` [PATCH 2/4 v2] ARM: at91: sam9g20 add i2c " Jean-Christophe PLAGNIOL-VILLARD
2012-02-09 2:25 ` [PATCH 3/4] ARM: at91: usb_a9g20 add DT i2c support Jean-Christophe PLAGNIOL-VILLARD
2012-02-09 2:25 ` [PATCH 4/4 v2] ARM: at91: sam9g45 add i2c DT support Jean-Christophe PLAGNIOL-VILLARD
2012-02-13 17:17 ` [PATCH 1/4 v2] i2c/gpio: add " Karol Lewandowski
2012-02-20 9:58 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 10:08 ` Russell King - ARM Linux
2012-02-20 10:22 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 12:50 ` Russell King - ARM Linux
2012-02-20 13:35 ` Jean Delvare [this message]
2012-02-20 13:51 ` Russell King - ARM Linux
2012-02-20 14:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 15:03 ` Russell King - ARM Linux
2012-02-20 13:37 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 13:46 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 13:58 ` Russell King - ARM Linux
2012-02-20 14:46 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 15:00 ` Russell King - ARM Linux
2012-02-20 15:08 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 15:27 ` Russell King - ARM Linux
2012-02-20 15:30 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 15:46 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-20 16:08 ` Russell King - ARM Linux
2012-02-20 16:09 ` Jean-Christophe PLAGNIOL-VILLARD
2012-02-13 23:09 ` Ben Dooks
2012-02-14 4:06 ` Jean-Christophe PLAGNIOL-VILLARD
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=20120220143557.02787bad@endymion.delvare \
--to=khali@linux-fr.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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