[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <15466c95-f1ea-63a4-1429-24d9b7567c1c@microchip.com>
Date: Fri, 4 Sep 2020 08:55:30 +0000
From: <Codrin.Ciubotariu@...rochip.com>
To: <wsa@...nel.org>
CC: <linux-i2c@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <robh+dt@...nel.org>,
<Ludovic.Desroches@...rochip.com>, <Nicolas.Ferre@...rochip.com>,
<alexandre.belloni@...tlin.com>, <linux@...linux.org.uk>,
<kamel.bouhara@...tlin.com>
Subject: Re: Re: Re: [RFC PATCH 4/4] i2c: at91: Move to generic GPIO bus
recovery
On 26.08.2020 09:14, Wolfram Sang wrote:
>
>> 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 device.
>> Please let me know of the result.
>
> 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
switching is not available, not at this time at least. Perhaps there is
room for improvement here, because the I2C bus is not using the pins
while we are doing GPIO recovery.
>
> On the good side, there are patches which make i2c-mv64xxx another user
> of your new mechanism, so everything is well, I think.
>
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
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
Powered by blists - more mailing lists