From: Silvan Wicki <linux_wi-ADq4ffItWIY@public.gmane.org>
To: Eric Anholt <eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
Cc: wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH v2] i2c: busses: i2c-bcm2835: limits cdiv to allowed values
Date: Tue, 2 Jun 2015 17:45:06 +0200 [thread overview]
Message-ID: <20150602154506.GA2341@jessie.tinag.lan> (raw)
In-Reply-To: <87pp5f5mlw.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
On Mon, Jun 01, 2015 at 11:07:07AM -0700, Eric Anholt wrote:
> Silvan Wicki <linux_wi-ADq4ffItWIY@public.gmane.org> writes:
>
> > Adds: make sure bits 16-31 of DIV register are always 0
> > Adds: assume minimal divider of 2 if divider resulted in 0
> > (bcm2835 sets divider to 32768 if cdiv is set to 0)
> >
> > See page 33/34 of BCM2835-ARM-Peripherals.pdf for the DIV register.
> > https://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
> >
> > Signed-off-by: Silvan Wicki <linux_wi-ADq4ffItWIY@public.gmane.org>
> > ---
> > drivers/i2c/busses/i2c-bcm2835.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
> > index c9336a3..8195b04 100644
> > --- a/drivers/i2c/busses/i2c-bcm2835.c
> > +++ b/drivers/i2c/busses/i2c-bcm2835.c
> > @@ -50,6 +50,9 @@
> > #define BCM2835_I2C_S_CLKT BIT(9)
> > #define BCM2835_I2C_S_LEN BIT(10) /* Fake bit for SW error reporting */
> >
> > +#define BCM2835_I2C_CDIV_MIN 0x0002
> > +#define BCM2835_I2C_CDIV_MAX 0xFFFE
> > +
> > #define BCM2835_I2C_TIMEOUT (msecs_to_jiffies(1000))
> >
> > struct bcm2835_i2c_dev {
> > @@ -252,12 +255,22 @@ static int bcm2835_i2c_probe(struct platform_device *pdev)
> >
> > divider = DIV_ROUND_UP(clk_get_rate(i2c_dev->clk), bus_clk_rate);
> > /*
> > + * Divider results in 0 by extremely high bus_clk_rate values
> > + * such as bus_clk_rate >= 4044967297 and core_clock = 250MHz.
> > + * In such a case assume the minimal possible divider since
> > + * bcm2835 chip sets divisor internally to 32768 if cdiv is 0.
> > + */
> > + if (divider < BCM2835_I2C_CDIV_MIN)
> > + divider = BCM2835_I2C_CDIV_MIN;
> > + /*
> > * Per the datasheet, the register is always interpreted as an even
> > * number, by rounding down. In other words, the LSB is ignored. So,
> > * if the LSB is set, increment the divider to avoid any issue.
> > */
> > if (divider & 1)
> > divider++;
> > + if (divider > BCM2835_I2C_CDIV_MAX)
> > + divider = BCM2835_I2C_CDIV_MAX;
> > bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_DIV, divider);
>
> I'm not clear on the motivation of this patch. If the bus_clk_rate is
> something totally unreasonable (125MHz? 3.8KHz?) it seems like
> something is misconfigured and we should at best just fail the probe.
> Does this fix some particular problem you've run into?
The motivation is to not allow wrong values to be written in CDIV.
No, i was not able to fix my problem. I had to choose another clock rate.
Failing the probe would be an alternative. The problem with failing
is, when do we fail? I did not find values in the datasheet about what
speeds are supported or not.
next prev parent reply other threads:[~2015-06-02 15:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-29 10:26 [PATCH v2] i2c: busses: i2c-bcm2835: limits cdiv to allowed values Silvan Wicki
[not found] ` <1432895204-19924-1-git-send-email-linux_wi-ADq4ffItWIY@public.gmane.org>
2015-06-01 18:07 ` Eric Anholt
[not found] ` <87pp5f5mlw.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
2015-06-02 15:45 ` Silvan Wicki [this message]
2015-06-05 3:10 ` Stephen Warren
[not found] ` <5571131D.7060100-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2015-06-06 17:31 ` Silvan Wicki
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=20150602154506.GA2341@jessie.tinag.lan \
--to=linux_wi-adq4ffitwiy@public.gmane.org \
--cc=eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.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;
as well as URLs for NNTP newsgroup(s).