From: <Codrin.Ciubotariu@microchip.com>
To: peda@axentia.se, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Cc: kamel.bouhara@bootlin.com, wsa@the-dreams.de,
Nicolas.Ferre@microchip.com, alexandre.belloni@bootlin.com,
Ludovic.Desroches@microchip.com, robh@kernel.org
Subject: Re: [PATCH v2 4/6] ARM: at91/dt: sama5d3: add i2c gpio pinctrl
Date: Mon, 6 Jan 2020 16:58:39 +0000 [thread overview]
Message-ID: <91f1362e-590d-4592-bc16-5d2393f73199@microchip.com> (raw)
In-Reply-To: <e22772f8-9e6d-002d-98d7-414136a32439@axentia.se>
On 05.01.2020 00:39, Peter Rosin wrote:
> On 2020-01-03 10:49, Codrin.Ciubotariu@microchip.com wrote:
>> From: Kamel Bouhara <kamel.bouhara@bootlin.com>
>>
>> Add the i2c gpio pinctrls to support the i2c bus recovery
>>
>> Signed-off-by: Kamel Bouhara <kamel.bouhara@bootlin.com>
>> ---
>>
>> Changes in v2:
>> - none;
>>
>> arch/arm/boot/dts/sama5d3.dtsi | 33 ++++++++++++++++++++++++++++++---
>> 1 file changed, 30 insertions(+), 3 deletions(-)
>>
>
> *snip*
>
>> @@ -639,6 +648,12 @@
>> <AT91_PIOA 30 AT91_PERIPH_A AT91_PINCTRL_NONE /* PA30 periph A TWD0 pin, conflicts with URXD1, ISI_VSYNC */
>> AT91_PIOA 31 AT91_PERIPH_A AT91_PINCTRL_NONE>; /* PA31 periph A TWCK0 pin, conflicts with UTXD1, ISI_HSYNC */
>> };
>> +
>> + pinctrl_i2c0_gpio: i2c0-gpio {
>> + atmel,pins =
>> + <AT91_PIOA 30 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP
>> + AT91_PIOA 31 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
>> + };
>
> I'm curious, but why are pull-ups suddenly needed just because the pins are
> used for GPIO recovery? Why are pull-ups not needed when the pins are used
> by the I2C peripheral device(s)?
>
> Given figure 27-2 "I/O Line Control Logic" in my SAMA5D3 datasheet, I see
> no difference as to how and why the pull-ups are applied depending on what
> the current function of the pin is. So, if the I2C bus works w/o pulls, bus
> recovery using GPIO must also work w/o pulls.
>
> I.e. the device tree requires you to have external pull-ups on the I2C bus
> anyway, so why bother with internal pull-ups for the recovery case?
>
> Changing pull-up settings just for recovery feels like something that will
> inevitably create hard to debug surprises at the least opportune time...
>
> Or am I missing something?
>
> (I'm focusing on SAMA5D3 since that is what I happen to work with,
> but the same question appears to apply for SAMA5D2 and SAMA5D4...)
I don't think we need the pull-ups. I will remove them in v3.
Thanks and best regards,
Codrin
next prev parent reply other threads:[~2020-01-06 16:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-03 9:49 [PATCH v2 0/6] i2c bus recovery for Microchip SoCs Codrin.Ciubotariu
2020-01-03 9:49 ` [PATCH v2 1/6] dt-bindings: i2c: at91: document optional bus recovery properties Codrin.Ciubotariu
2020-01-03 22:29 ` Rob Herring
2020-01-06 16:34 ` Codrin.Ciubotariu
2020-01-03 9:49 ` [PATCH v2 2/6] i2c: at91: implement i2c bus recovery Codrin.Ciubotariu
2020-01-09 7:48 ` Ludovic Desroches
[not found] ` <20200109074819.rhlaxg3sgwlng5xm-cg6aFISJjbMT2m6MMfBamRL4W9x8LtSr@public.gmane.org>
2020-01-09 10:54 ` Codrin.Ciubotariu-UWL1GkI3JZL3oGB3hsPCZA
2020-01-03 9:49 ` [PATCH v2 3/6] i2c: at91: Send bus clear command if SCL is down Codrin.Ciubotariu
2020-01-09 7:47 ` Ludovic Desroches
2020-01-09 10:58 ` Codrin.Ciubotariu
2020-01-09 11:05 ` Russell King - ARM Linux admin
[not found] ` <20200109110557.GO25745-QEMnZ+CodIVURfEZ8mYm6t73F7V6hmMc@public.gmane.org>
2020-01-09 13:29 ` Codrin.Ciubotariu-UWL1GkI3JZL3oGB3hsPCZA
2020-01-03 9:49 ` [PATCH v2 5/6] ARM: at91/dt: sama5d4: add i2c gpio pinctrl Codrin.Ciubotariu
2020-01-03 9:49 ` [PATCH v2 4/6] ARM: at91/dt: sama5d3: " Codrin.Ciubotariu
2020-01-04 22:39 ` Peter Rosin
2020-01-06 16:58 ` Codrin.Ciubotariu [this message]
2020-01-03 9:49 ` [PATCH v2 6/6] ARM: at91/dt: sama5d2: " Codrin.Ciubotariu
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=91f1362e-590d-4592-bc16-5d2393f73199@microchip.com \
--to=codrin.ciubotariu@microchip.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=devicetree@vger.kernel.org \
--cc=kamel.bouhara@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=robh@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