From: Michael Walle <michael@walle.cc>
To: linus.walleij@linaro.org
Cc: Claudiu.Beznea@microchip.com, Ludovic.Desroches@microchip.com,
Nicolas.Ferre@microchip.com, Ryan.Wanner@microchip.com,
alexandre.belloni@bootlin.com, linux-gpio@vger.kernel.org,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
Michael Walle <michael@walle.cc>
Subject: Re: I2c GPIO Recovery with pinctrl strict mode
Date: Thu, 9 Feb 2023 14:24:22 +0100 [thread overview]
Message-ID: <20230209132422.179674-1-michael@walle.cc> (raw)
In-Reply-To: <CACRpkdbK8A9X4nCZEc53-wXU0Vgkc53j_r5rLQiSeoNbmvm8sg@mail.gmail.com>
>> My main issue is the process of freeing ownership of a pin(s) having
>> another driver, in this case gpio, to take ownership then free that
>> ownership back to the default state, in this case it would be back to
>> i2c.
>>
>> I have tried calling pinmux_disable_setting() and then claiming the
>> gpios then enabling them for recovery then disabling them again. This
>> causes lots of warnings and some cases the full ownership is not
>> transferred.
>>
>> It seems that what I am attempting to achieve is not doable currently.
>> Is this the case or am I missing some extra things needing to prepare
>> for this action?
>
> There are several other i2c bus drivers doing this already, for example
> drivers/i2c/busses/i2c-imx.c
>
> The idea is to have some different pinctrl states and move between
> them explicitly in the driver to move pins from i2c mode to GPIO
> mode and back.
>
> The imx driver depend on the ability of the i.MX pin controller to use
> the pins as a certain function and GPIO at the same time.
But that's because this is a limitation of the imx i2c controller.
Usually, if i2c controllers don't have a hardware bus recovery (which
is broken in most designs..) they usually have an override bit to
bit bang SDA and SCL manually. Do the microchip cores have such bits?
Fun fact: also the layerscape SoCs use the imx i2c cores. It's just that
layerscape SoCs doesn't support dynamic pinmuxing...
-michael
> This is due to the imx pin controller not setting the .strict attribute
> on the struct pinmux_ops so that pins can be used in parallel for
> i2c and GPIO and gpiod_get() will not fail. But the Atmel driver does
> not set this so you should be fine I think.
next prev parent reply other threads:[~2023-02-09 13:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-07 17:56 I2c GPIO Recovery with pinctrl strict mode Ryan.Wanner
2023-02-09 10:32 ` Linus Walleij
2023-02-09 13:24 ` Michael Walle [this message]
2023-02-10 15:21 ` Ryan.Wanner
2023-02-13 9:29 ` Linus Walleij
2023-02-17 17:36 ` Ryan.Wanner
2023-02-18 23:29 ` Linus Walleij
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=20230209132422.179674-1-michael@walle.cc \
--to=michael@walle.cc \
--cc=Claudiu.Beznea@microchip.com \
--cc=Ludovic.Desroches@microchip.com \
--cc=Nicolas.Ferre@microchip.com \
--cc=Ryan.Wanner@microchip.com \
--cc=alexandre.belloni@bootlin.com \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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