Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 7HhQMYrOoqZvi6ER8Jyhp+oEDQmDX+/2/CxaYnvKjdBAPyx5YQDZy3kbiQ6J3WQkNuI6HwaIca
 HxEgIJe0CNMu1VDdfJCUQf2Aefp9I4+mSLL96Wx0f+eQUnewyNCT4hm5bt21Yo4FoDnbj0h915
 Gk236FJpr9tdd/JNHAkFE1AXBNf33IKz64/baTQsAhILZqC/9LOi4V2W42m/J6CWyFnHMe67qj
 7v8PAiIGupivTMTRPMxp+85XlfXMLltDUmQXonjZeHkHhmpurmUfLoXEq5/z3lP/3dsuYARx8l
 z4w=
From:   <Codrin.Ciubotariu@microchip.com>
To:     <wsa@kernel.org>
CC:     <linux-i2c@vger.kernel.org>, <devicetree@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>, <robh+dt@kernel.org>,
        <Ludovic.Desroches@microchip.com>, <Nicolas.Ferre@microchip.com>,
        <alexandre.belloni@bootlin.com>, <linux@armlinux.org.uk>,
        <kamel.bouhara@bootlin.com>
Subject: Re: Re: Re: [RFC PATCH 4/4] i2c: at91: Move to generic GPIO bus
 recovery
Thread-Topic: Re: Re: [RFC PATCH 4/4] i2c: at91: Move to generic GPIO bus
 recovery
Thread-Index: AQHWRkUH28LN6vyz50q8ydS45lftAKklUoAAgAF6cgCAI4blAIAOUeWA
Date:   Fri, 4 Sep 2020 08:55:30 +0000
Message-ID: <15466c95-f1ea-63a4-1429-24d9b7567c1c@microchip.com>
References: <20200619141904.910889-1-codrin.ciubotariu@microchip.com>
 <20200619141904.910889-5-codrin.ciubotariu@microchip.com>
 <20200802170820.GC10193@kunai>
 <65890aab-1d19-7e7e-abff-3c6ee05c8ade@microchip.com>
 <20200826061444.GB1081@ninjato>
In-Reply-To: <20200826061444.GB1081@ninjato>
Accept-Language: en-US
Content-Language: en-US
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <F03D349C753B32459467A66588A5B40D@namprd11.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 28e66f7c-3827-41e6-6e1c-08d850b04712
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2020 08:55:30.8592
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 3f4057f3-b418-4d4e-ba84-d55b4e897d88
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LM00InGX560ruvvsdhtkuJ7WhcbmOHyZrmC3m16cj/t/Sk3h8RvuGDq6ZPCoYRopqXxBWa+14y+G7EUBD0aDUZpAnMkNTBbOepaXzz8SR3Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB0070
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 26.08.2020 09:14, Wolfram Sang wrote:
>=20
>> Thanks, this would be great! I tested this on a sam9x60, with the HW
>> feature for the 9 pulses disabled, with a picky audio codec as I2C devic=
e.
>> Please let me know of the result.
>=20
> I can't make use of the feature on the platform I had in mind, sadly. It
> doesn't really support switching from/to GPIO pinctrl states. If that
> ever changes, I will add bus recovery for that controller, but I think
> this is low priority.

The pinmux driver needs to have strict set to false, otherwise the=20
switching is not available, not at this time at least. Perhaps there is=20
room for improvement here, because the I2C bus is not using the pins=20
while we are doing GPIO recovery.

>=20
> On the good side, there are patches which make i2c-mv64xxx another user
> of your new mechanism, so everything is well, I think.
>=20

I saw them, I will try to take a look.
I am not sure I'll have time the next week to work on what you asked me=20
regarding sh_mobile and PXA, but I will look into it the week after that.
Sorry about my delayed reply, I was on vacation.

Best regards,
Codrin