[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CADRPPNQW92jqwNgmxVK69Sqp13utoy=owSKMAxkC7tgRgjygGw@mail.gmail.com>
Date: Mon, 12 Sep 2016 13:29:47 -0500
From: Leo Li <pku.leo@...il.com>
To: Gao Pan <pandy.gao@....com>, Ying Zhang <ying.zhang22455@....com>
Cc: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>,
"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
Wolfram Sang <wsa@...-dreams.de>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, linux-gpio@...r.kernel.org,
Li Yang <leoyang.li@....com>, Stefan Agner <stefan@...er.ch>,
lkml <linux-kernel@...r.kernel.org>,
Tracy Smith <tlsmith3777@...il.com>
Subject: Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional
On Mon, Sep 12, 2016 at 11:35 AM, Leo Li <pku.leo@...il.com> wrote:
> On Wed, Sep 7, 2016 at 5:07 AM, Tracy Smith <tlsmith3777@...il.com> wrote:
>> Hello, bus recovery is needed generally speaking because of potential
>> protocol errors that might cause a failure condition hanging the bus.
>>
>> It happens frequently during bring-up of new I2C devices because firmware in
>> I2C controllers fail to handle properly protocol errors.
>>
>> Can NXP add bus recovery for the LS1021A and LS1043A in a separate patch--
>> unless there is no HW bus recovery mechanism?
>>
>> The concern is while fixing I.MX, NXP will fail to fix the driver bus
>> recovery for the LS1021A and LS1043A and the bus will hang.
>>
>> If bus recovery is supported on the LS1021A and the LS1043A, a patch should
>> be provided or added in this patch instead of simply disabling bus recovery.
>> Request NXP to consider the patch if there is HW support for bus recovery.
>
> FYI. http://patchwork.ozlabs.org/patch/573879/
Hi Gao Pan,
Do you think the operations in the proposed patch is also usable on
the I.MX SoC for bus recovery? If so, would it be better to align the
bus recovery implementation for both I.MX and QorIQ to use the same
logic inside the IP?
Regards,
Leo
Powered by blists - more mailing lists