On 2/9/23 03:32, Linus Walleij wrote: > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe > > On Tue, Feb 7, 2023 at 6:56 PM <Ryan.Wanner@xxxxxxxxxxxxx> wrote: > >> 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. > > 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. > I am trying to enable .strict in the Atmel pinctrl driver, and that is what is causing my issues. I have tried a similar approach to the imx driver but it seems I cannot transfer ownership cleanly. Best, Ryan
