* [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia
@ 2019-04-25 13:22 Marek Behún
2019-04-29 7:28 ` Stefan Roese
0 siblings, 1 reply; 6+ messages in thread
From: Marek Behún @ 2019-04-25 13:22 UTC (permalink / raw)
To: u-boot
Commit c68c6243 ("i2c: mvtwsi: Make delay times frequency-dependent")
broke the default configuration of the Turris Omnia target.
With i2c frequency at 100kHz the twsi_wait function call to ndelay(tick)
the tick variable is computed to 10340 (nanoseconds). Since ndelay
calls udelay(DIV_ROUND_UP(10340, 1000), the result is udelay(11).
For some reason this sometimes (cca every third boot) breaks the i2c
controller on Turris Omnia completely (even kernel cannot use it, and
soft reset does not help, only complete power off).
Microcontroller watchdog cannot be disabled without i2c and the device
is unusable.
The original commit message mentions erratum FE-8471889. This is weird
since Linux does not enable this erratum workaround for armada-38x. But
the commit message says that it was tested on Armada MV88F6820.
I therefore fix this in this unclean way only for Turris Omnia, because
I do not know if it would not break other devices.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Mario Six <mario.six@gdsys.cc>
Cc: Stefan Roese <sr@denx.de>
---
drivers/i2c/mvtwsi.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index b0f7c3e057..ef269f3b0c 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -176,9 +176,13 @@ enum mvtwsi_ack_flags {
*/
inline uint calc_tick(uint speed)
{
+#ifdef CONFIG_TARGET_TURRIS_OMNIA
+ return 10000;
+#else
/* One tick = the duration of a period at the specified speed in ns (we
* add 100 ns to be on the safe side) */
return (1000000000u / speed) + 100;
+#endif
}
#ifndef CONFIG_DM_I2C
--
2.21.0
^ permalink raw reply related [flat|nested] 6+ messages in thread* [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia
2019-04-25 13:22 [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia Marek Behún
@ 2019-04-29 7:28 ` Stefan Roese
2019-04-30 1:49 ` Marek Behun
0 siblings, 1 reply; 6+ messages in thread
From: Stefan Roese @ 2019-04-29 7:28 UTC (permalink / raw)
To: u-boot
Hi Marek,
(added Heiko to Cc)
On 25.04.19 15:22, Marek Behún wrote:
> Commit c68c6243 ("i2c: mvtwsi: Make delay times frequency-dependent")
> broke the default configuration of the Turris Omnia target.
>
> With i2c frequency at 100kHz the twsi_wait function call to ndelay(tick)
> the tick variable is computed to 10340 (nanoseconds). Since ndelay
> calls udelay(DIV_ROUND_UP(10340, 1000), the result is udelay(11).
>
> For some reason this sometimes (cca every third boot) breaks the i2c
> controller on Turris Omnia completely (even kernel cannot use it, and
> soft reset does not help, only complete power off).
>
> Microcontroller watchdog cannot be disabled without i2c and the device
> is unusable.
>
> The original commit message mentions erratum FE-8471889. This is weird
> since Linux does not enable this erratum workaround for armada-38x. But
> the commit message says that it was tested on Armada MV88F6820.
>
> I therefore fix this in this unclean way only for Turris Omnia, because
> I do not know if it would not break other devices.
>
> Signed-off-by: Marek Behún <marek.behun@nic.cz>
> Cc: Mario Six <mario.six@gdsys.cc>
> Cc: Stefan Roese <sr@denx.de>
> ---
> drivers/i2c/mvtwsi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
> index b0f7c3e057..ef269f3b0c 100644
> --- a/drivers/i2c/mvtwsi.c
> +++ b/drivers/i2c/mvtwsi.c
> @@ -176,9 +176,13 @@ enum mvtwsi_ack_flags {
> */
> inline uint calc_tick(uint speed)
> {
> +#ifdef CONFIG_TARGET_TURRIS_OMNIA
> + return 10000;
> +#else
> /* One tick = the duration of a period at the specified speed in ns (we
> * add 100 ns to be on the safe side) */
> return (1000000000u / speed) + 100;
> +#endif
> }
>
> #ifndef CONFIG_DM_I2C
>
I would really like not to see such board specific code added to this
driver.
Frankly, I fail to understand why used udelay(11) instead of udelay(10)
should result in such a difference on your board. Could you please
investigate a bit more and hopefully come up with a "better" solution
for this issue?
Thanks,
Stefan
^ permalink raw reply [flat|nested] 6+ messages in thread* [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia
2019-04-29 7:28 ` Stefan Roese
@ 2019-04-30 1:49 ` Marek Behun
2019-04-30 4:07 ` Heiko Schocher
0 siblings, 1 reply; 6+ messages in thread
From: Marek Behun @ 2019-04-30 1:49 UTC (permalink / raw)
To: u-boot
> I would really like not to see such board specific code added to this
> driver.
>
> Frankly, I fail to understand why used udelay(11) instead of udelay(10)
> should result in such a difference on your board. Could you please
> investigate a bit more and hopefully come up with a "better" solution
> for this issue?
>
> Thanks,
> Stefan
Hi Stefan, I think I found what was the issue, just sent a patch series
for Omnia, the last patch explains my theory and fixes the issue with
one ndelay(100)
Marek
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia
2019-04-30 1:49 ` Marek Behun
@ 2019-04-30 4:07 ` Heiko Schocher
2019-04-30 7:01 ` Marek Behun
0 siblings, 1 reply; 6+ messages in thread
From: Heiko Schocher @ 2019-04-30 4:07 UTC (permalink / raw)
To: u-boot
Hello Marek,
Am 30.04.2019 um 03:49 schrieb Marek Behun:
>> I would really like not to see such board specific code added to this
>> driver.
>>
>> Frankly, I fail to understand why used udelay(11) instead of udelay(10)
>> should result in such a difference on your board. Could you please
>> investigate a bit more and hopefully come up with a "better" solution
>> for this issue?
>>
>> Thanks,
>> Stefan
>
> Hi Stefan, I think I found what was the issue, just sent a patch series
> for Omnia, the last patch explains my theory and fixes the issue with
> one ndelay(100)
You mean tha patch series
"[U-Boot] [PATCH u-boot-marvell v2 00/15] Fixes for Turris Omnia"
So we can ignore this patch?
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia
2019-04-30 4:07 ` Heiko Schocher
@ 2019-04-30 7:01 ` Marek Behun
2019-04-30 7:22 ` Heiko Schocher
0 siblings, 1 reply; 6+ messages in thread
From: Marek Behun @ 2019-04-30 7:01 UTC (permalink / raw)
To: u-boot
> You mean tha patch series
>
> "[U-Boot] [PATCH u-boot-marvell v2 00/15] Fixes for Turris Omnia"
>
> So we can ignore this patch?
>
> bye,
> Heiko
Yes :)
^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia
2019-04-30 7:01 ` Marek Behun
@ 2019-04-30 7:22 ` Heiko Schocher
0 siblings, 0 replies; 6+ messages in thread
From: Heiko Schocher @ 2019-04-30 7:22 UTC (permalink / raw)
To: u-boot
Hello Marek,
Am 30.04.2019 um 09:01 schrieb Marek Behun:
>> You mean tha patch series
>>
>> "[U-Boot] [PATCH u-boot-marvell v2 00/15] Fixes for Turris Omnia"
>>
>> So we can ignore this patch?
>>
>> bye,
>> Heiko
>
> Yes :)
Ok, fine. I set Patchwork state for this patch to superseded
http://patchwork.ozlabs.org/patch/1090791/
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-04-30 7:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-04-25 13:22 [U-Boot] [PATCH] i2c: mvtwsi: Fix delay time for Turris Omnia Marek Behún
2019-04-29 7:28 ` Stefan Roese
2019-04-30 1:49 ` Marek Behun
2019-04-30 4:07 ` Heiko Schocher
2019-04-30 7:01 ` Marek Behun
2019-04-30 7:22 ` Heiko Schocher
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.