Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1481535 > unrolled thread
| Started by | Leo Li <pku.leo@gmail.com> |
|---|---|
| First post | 2016-09-12 18:40 +0200 |
| Last post | 2016-09-12 20:30 +0200 |
| Articles | 2 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional Leo Li <pku.leo@gmail.com> - 2016-09-12 18:40 +0200
Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional Leo Li <pku.leo@gmail.com> - 2016-09-12 20:30 +0200
| From | Leo Li <pku.leo@gmail.com> |
|---|---|
| Date | 2016-09-12 18:40 +0200 |
| Subject | Re: [PATCH v5] i2c: imx: make bus recovery through pinctrl optional |
| Message-ID | <sgCr0-5K3-21@gated-at.bofh.it> |
On Wed, Sep 7, 2016 at 5:07 AM, Tracy Smith <tlsmith3777@gmail.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/ This seem to be the patch you are asking for. I have asked the original developer to update the patch according to Wolfram's comment and work together with the current pinctrl/gpio based recovery. In the meanwhile you can make use of the patch for now for LS1021A and LS1043A if necessary. Regards, Leo
[toc] | [next] | [standalone]
| From | Leo Li <pku.leo@gmail.com> |
|---|---|
| Date | 2016-09-12 20:30 +0200 |
| Message-ID | <sgE9r-6Zj-1@gated-at.bofh.it> |
| In reply to | #1481535 |
On Mon, Sep 12, 2016 at 11:35 AM, Leo Li <pku.leo@gmail.com> wrote: > On Wed, Sep 7, 2016 at 5:07 AM, Tracy Smith <tlsmith3777@gmail.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
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web