From: Andy Shevchenko <andriy.shevchenko@linux.intel.com> To: Tim Sander <tim@krieglstein.org>, Phil Reid <preid@electromag.com.au> Cc: wsa@the-dreams.de, khilman@kernel.org, nsekhar@ti.com, jarkko.nikula@linux.intel.com, linux-i2c@vger.kernel.org, mika.westerberg@linux.intel.com, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v5 4/7] i2c: designware: add i2c gpio recovery option Date: Wed, 08 Nov 2017 11:29:14 +0200 [thread overview] Message-ID: <1510133354.25007.97.camel@linux.intel.com> (raw) In-Reply-To: <2970055.FM06l9ul3d@dabox> On Wed, 2017-11-08 at 09:29 +0100, Tim Sander wrote: > > > How do we switch pinctrl back to the native function? Is it > > > guaranteed > > > by pinctrl framework and all underneath drivers? > > That is a good question. I don't have an understanding of how the > > pinctrl > > framework works with respect to requesting gpios. > > My device (Intel / Altera Cyclone V SOC) doesn't have a pinctrl for > > the i2c > > / gpio mux as yet. > > According to the documentation from Intel/Altera it is not allowed to > change > the pinmux while running. The driver is used on many platforms and requesting GPIO function while running _is_ a pinmux change. > My guess is that they are using a shift chain, so > the output values of all pins in the chain are not stable. I think > they have > been lazy and just used the io config for fpgas with an jtag > controller and > connected the shift chain for pinconfig to this controller. So > unfortunatly it > is not possible to switch single pins on the run without interfering > with > other pins. ...for this certain SoC. > > It's all setup by the bootloader and they don't expect > > you to change it. I'm using two separate GPIO's "wired" to the i2c > > bus via > > the SOC FPGA for the recovery. Tim was doing the same. > > Yes, i think thats the only way. But it is annoying that the i2c > controllers > of 201x have no way to recover from such bus errors >:-(. Yep, it's pity, and we need to cope somehow with it. So, my understanding of the current case is that either this change goes in only for certain SoC(s), or waiting until there is a guarantee from pinctrl subsystem to return function to native back when recovery finished. My personal vote is for latter. -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy
WARNING: multiple messages have this Message-ID (diff)
From: andriy.shevchenko@linux.intel.com (Andy Shevchenko) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH v5 4/7] i2c: designware: add i2c gpio recovery option Date: Wed, 08 Nov 2017 11:29:14 +0200 [thread overview] Message-ID: <1510133354.25007.97.camel@linux.intel.com> (raw) In-Reply-To: <2970055.FM06l9ul3d@dabox> On Wed, 2017-11-08 at 09:29 +0100, Tim Sander wrote: > > > How do we switch pinctrl back to the native function? Is it > > > guaranteed > > > by pinctrl framework and all underneath drivers? > > That is a good question. I don't have an understanding of how the > > pinctrl > > framework works with respect to requesting gpios. > > My device (Intel / Altera Cyclone V SOC) doesn't have a pinctrl for > > the i2c > > / gpio mux as yet. > > According to the documentation from Intel/Altera it is not allowed to > change > the pinmux while running. The driver is used on many platforms and requesting GPIO function while running _is_ a pinmux change. > My guess is that they are using a shift chain, so > the output values of all pins in the chain are not stable. I think > they have > been lazy and just used the io config for fpgas with an jtag > controller and > connected the shift chain for pinconfig to this controller. So > unfortunatly it > is not possible to switch single pins on the run without interfering > with > other pins. ...for this certain SoC. > > It's all setup by the bootloader and they don't expect > > you to change it. I'm using two separate GPIO's "wired" to the i2c > > bus via > > the SOC FPGA for the recovery. Tim was doing the same. > > Yes, i think thats the only way. But it is annoying that the i2c > controllers > of 201x have no way to recover from such bus errors >:-(. Yep, it's pity, and we need to cope somehow with it. So, my understanding of the current case is that either this change goes in only for certain SoC(s), or waiting until there is a guarantee from pinctrl subsystem to return function to native back when recovery finished. My personal vote is for latter. -- Andy Shevchenko <andriy.shevchenko@linux.intel.com> Intel Finland Oy
next prev parent reply other threads:[~2017-11-08 9:29 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-11-02 2:40 [PATCH v5 0/7] i2c: designware: add i2c gpio recovery option Phil Reid 2017-11-02 2:40 ` Phil Reid 2017-11-02 2:40 ` [PATCH v5 1/7] i2c: Switch to using gpiod interface for gpio bus recovery Phil Reid 2017-11-02 2:40 ` Phil Reid 2017-11-02 2:40 ` [PATCH v5 2/7] i2c: designware: move i2c_dw_plat_prepare_clk to common Phil Reid 2017-11-02 2:40 ` Phil Reid 2017-11-02 2:40 ` [PATCH v5 3/7] i2c: designware: rename i2c_dw_plat_prepare_clk to i2c_dw_prepare_clk Phil Reid 2017-11-02 2:40 ` Phil Reid 2017-11-02 2:40 ` [PATCH v5 4/7] i2c: designware: add i2c gpio recovery option Phil Reid 2017-11-02 2:40 ` Phil Reid 2017-11-06 16:09 ` Andy Shevchenko 2017-11-06 16:09 ` Andy Shevchenko 2017-11-07 1:02 ` Phil Reid 2017-11-07 1:02 ` Phil Reid 2017-11-08 8:29 ` Tim Sander 2017-11-08 8:29 ` Tim Sander 2017-11-08 9:29 ` Andy Shevchenko [this message] 2017-11-08 9:29 ` Andy Shevchenko 2017-11-10 6:55 ` Phil Reid 2017-11-10 6:55 ` Phil Reid 2017-11-10 16:12 ` Andy Shevchenko 2017-11-10 16:12 ` Andy Shevchenko 2017-11-02 2:40 ` [PATCH v5 5/7] i2c: imx: switch to using gpiod for bus recovery gpios Phil Reid 2017-11-02 2:40 ` Phil Reid 2017-11-02 2:40 ` [PATCH v5 6/7] i2c: davinci: " Phil Reid 2017-11-02 2:40 ` Phil Reid 2017-11-02 15:15 ` Sekhar Nori 2017-11-02 15:15 ` Sekhar Nori 2017-11-02 2:40 ` [PATCH v5 7/7] i2c: remove legacy integer scl/sda gpio for recovery Phil Reid 2017-11-02 2:40 ` Phil Reid 2017-11-02 15:23 ` Jarkko Nikula 2017-11-02 15:23 ` Jarkko Nikula 2017-11-27 17:51 ` [PATCH v5 0/7] i2c: designware: add i2c gpio recovery option Wolfram Sang 2017-11-27 17:51 ` Wolfram Sang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1510133354.25007.97.camel@linux.intel.com \ --to=andriy.shevchenko@linux.intel.com \ --cc=jarkko.nikula@linux.intel.com \ --cc=khilman@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-i2c@vger.kernel.org \ --cc=mika.westerberg@linux.intel.com \ --cc=nsekhar@ti.com \ --cc=preid@electromag.com.au \ --cc=tim@krieglstein.org \ --cc=wsa@the-dreams.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.