From: Pierre Yves MORDRET <pierre-yves.mordret@st.com>
To: Wolfram Sang <wsa@the-dreams.de>
Cc: Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@st.com>,
Russell King <linux@armlinux.org.uk>, <linux-i2c@vger.kernel.org>,
<devicetree@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [RESEND PATCH v3 3/5] i2c: i2c-stm32f7: add driver
Date: Thu, 14 Sep 2017 10:11:11 +0200 [thread overview]
Message-ID: <63ecfac9-990b-e6c5-d9bf-7708bacc10d2@st.com> (raw)
In-Reply-To: <20170913212639.2zyvg24364ovwfxh@ninjato>
On 09/13/2017 11:26 PM, Wolfram Sang wrote:
> Hi,
>
> thanks for this driver!
>
>> +/**
>> + * struct stm32f7_i2c_spec - private i2c specification timing
>> + * @rate: I2C bus speed (Hz)
>> + * @rate_min: 80% of I2C bus speed (Hz)
>> + * @rate_max: 120% of I2C bus speed (Hz)
>
> You would generate a clock which is higher than the requested one?
> This is highly unusual. Any special reason?
Well. I allow the clock to be higher than expected.
Looking at I2C spec again it turns out the mode specifies the max: no overshoot
of the clock. I will lock max to 100% then.
Will be fixed
>
>> + * @fall_max: Max fall time of both SDA and SCL signals (ns)
>> + * @rise_max: Max rise time of both SDA and SCL signals (ns)
>> + * @hddat_min: Min data hold time (ns)
>> + * @vddat_max: Max data valid time (ns)
>> + * @sudat_min: Min data setup time (ns)
>> + * @l_min: Min low period of the SCL clock (ns)
>> + * @h_min: Min high period of the SCL clock (ns)
>> + */
>> +static struct stm32f7_i2c_spec i2c_specs[] = {
>> + [STM32_I2C_SPEED_STANDARD] = {
>> + .rate = 100000,
>> + .rate_min = 8000,
>
> This is not 80%. Typo?
Yep. This is a typo
>
>> + .rate_max = 120000,
>> + .fall_max = 300,
>> + .rise_max = 1000,
>> + .hddat_min = 0,
>> + .vddat_max = 3450,
>> + .sudat_min = 250,
>> + .l_min = 4700,
>> + .h_min = 4000,
>> + },
>
> ...
>
>> + /*
>> + * Among Prescaler possibilities discovered above figures out SCL Low
>> + * and High Period. Provided:
>> + * - SCL Low Period has to be higher than Low Period of tehs SCL Clock
>
> tehs?
Oops.
>
>> + * defined by I2C Specification. I2C Clock has to be lower than
>> + * (SCL Low Period - Analog/Digital filters) / 4.
>> + * - SCL High Period has to be lower than High Period of the SCL Clock
>> + * defined by I2C Specification
>> + * - I2C Clock has to be lower than SCL High Period
>> + */
>
> ...
>
>> + /* NACK received */
>> + if (status & STM32F7_I2C_ISR_NACKF) {
>> + dev_dbg(i2c_dev->dev, "<%s>: Receive NACK\n", __func__);
>> + writel_relaxed(STM32F7_I2C_ICR_NACKCF, base + STM32F7_I2C_ICR);
>> + f7_msg->result = -EBADE;
>
> -ENXIO (see Documentation/i2c/fault-codes)
OK
>
> ...
>
>> + timeout = wait_for_completion_timeout(&i2c_dev->complete,
>> + i2c_dev->adap.timeout);
>> + ret = f7_msg->result;
>> +
>> + if (!timeout) {
>> + dev_dbg(i2c_dev->dev, "Access to slave 0x%x timed out\n",
>> + i2c_dev->msg->addr);
>> + ret = -ETIMEDOUT;
>> + }
>
> Could you rename the variable to time_left? It looks strange, basically:
>
> if (!timeout)
> return -ETIMEDOUT
>
okay
> ...
>
>> + adap->retries = 0;
>
> Why no retries when you check for arbitration lost?
>
>> + adap->algo = &stm32f7_i2c_algo;
>> + adap->dev.parent = &pdev->dev;
>> + adap->dev.of_node = pdev->dev.of_node;
>> +
>> + init_completion(&i2c_dev->complete);
>> +
>> + ret = i2c_add_adapter(adap);
>> + if (ret) {
>> + dev_err(&pdev->dev, "Failed to add adapter\n");
>
> Please remove, the core will print info when adding fails.
>
I will
>
> Rest looks good!
Great !
>
> Thanks,
>
> Wolfram
>
Thanks
next prev parent reply other threads:[~2017-09-14 8:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-01 7:34 [RESEND PATCH v3 0/5] Add support for the STM32F7 I2C Pierre-Yves MORDRET
2017-09-01 7:34 ` [RESEND PATCH v3 1/5] dt-bindings: i2c-stm32: Document the STM32F7 I2C bindings Pierre-Yves MORDRET
2017-09-01 7:34 ` [RESEND PATCH v3 2/5] i2c: i2c-stm32f4: use generic definition of speed enum Pierre-Yves MORDRET
2017-09-01 7:34 ` [RESEND PATCH v3 3/5] i2c: i2c-stm32f7: add driver Pierre-Yves MORDRET
2017-09-13 21:26 ` Wolfram Sang
2017-09-14 8:11 ` Pierre Yves MORDRET [this message]
2017-09-01 7:34 ` [RESEND PATCH v3 4/5] ARM: dts: stm32: Add I2C1 support for STM32F746 SoC Pierre-Yves MORDRET
2017-09-01 7:34 ` [RESEND PATCH v3 5/5] ARM: dts: stm32: Add I2C1 support for STM32F746 eval board Pierre-Yves MORDRET
2017-09-11 12:55 ` [RESEND PATCH v3 0/5] Add support for the STM32F7 I2C Benjamin Gaignard
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=63ecfac9-990b-e6c5-d9bf-7708bacc10d2@st.com \
--to=pierre-yves.mordret@st.com \
--cc=alexandre.torgue@st.com \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=robh+dt@kernel.org \
--cc=wsa@the-dreams.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®