public inbox for linux-i2c@vger.kernel.org
 help / color / mirror / Atom feed
From: <Ryan.Wanner@microchip.com>
To: <linux-i2c@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-gpio@vger.kernel.org>
Cc: <alexandre.belloni@bootlin.com>,
	<Ludovic.Desroches@microchip.com>, <linus.walleij@linaro.org>,
	<Nicolas.Ferre@microchip.com>, <Claudiu.Beznea@microchip.com>
Subject: I2c GPIO Recovery with pinctrl strict mode
Date: Tue, 7 Feb 2023 17:56:16 +0000	[thread overview]
Message-ID: <b151531d-c9fc-cafa-4e46-e213a9892247@microchip.com> (raw)

Hello,

I came across an issue working on i2c and pinctrl strict mode, with
at91-i2c and at91-pio4 pinctrl driver. I understand that for i2c
recovery the pins under i2c change states into gpio mode for the
recovery then back to their default state when recovery is complete.
With strict mode my goal is to change ownership from the default i2c
into gpio ownership then back to i2c ownership to continue normal
operation.

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?

Thanks,
Ryan

             reply	other threads:[~2023-02-07 17:56 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07 17:56 Ryan.Wanner [this message]
2023-02-09 10:32 ` I2c GPIO Recovery with pinctrl strict mode Linus Walleij
2023-02-09 13:24   ` Michael Walle
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=b151531d-c9fc-cafa-4e46-e213a9892247@microchip.com \
    --to=ryan.wanner@microchip.com \
    --cc=Claudiu.Beznea@microchip.com \
    --cc=Ludovic.Desroches@microchip.com \
    --cc=Nicolas.Ferre@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