diff mbox

[v2,5/5] i2c: davinci: use ICPFUNC to toggle I2C as gpio for bus recovery

Message ID 1417010393-30598-6-git-send-email-grygorii.strashko@ti.com
State Superseded
Headers show

Commit Message

Grygorii Strashko Nov. 26, 2014, 1:59 p.m. UTC 
Having a board where the I2C bus locks up occasionally made it clear
that the bus recovery in the i2c-davinci driver will only work on
some boards, because on regular boards, this will only toggle GPIO
lines that aren't muxed to the actual pins.

The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
built-in capability to bit-bang its lines by using the ICPFUNC registers
of the i2c controller.
Implement the suggested procedure by toggling SCL and checking SDA using
the ICPFUNC registers of the I2C controller when present. Allow platforms
to indicate the presence of the ICPFUNC registers with a has_pfunc platform
data flag and add optional DT property "ti,has-pfunc" to indicate
the same in DT.

CC: Sekhar Nori <nsekhar@ti.com>
CC: Kevin Hilman <khilman@deeprootsystems.com>
CC: Santosh Shilimkar <ssantosh@kernel.org>
CC: Murali Karicheri <m-karicheri2@ti.com>
CC: <devicetree@vger.kernel.org>
Signed-off-by: Ben Gardiner <bengardiner@nanometrics.ca>
Signed-off-by: Mike Looijmans <milo-software@users.sourceforge.net>
[grygorii.strashko@ti.com: combined patches from Ben Gardiner and
Mike Looijmans and reimplemented ICPFUNC bus recovery using I2C
bus recovery infrastructure]
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
 .../devicetree/bindings/i2c/i2c-davinci.txt        |   3 +
 drivers/i2c/busses/i2c-davinci.c                   | 102 ++++++++++++++++++++-
 include/linux/platform_data/i2c-davinci.h          |   1 +
 3 files changed, 105 insertions(+), 1 deletion(-)

Comments

Uwe Kleine-König Nov. 26, 2014, 4:04 p.m. UTC | #1 
Hello,

On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote:
> Having a board where the I2C bus locks up occasionally made it clear
> that the bus recovery in the i2c-davinci driver will only work on
> some boards, because on regular boards, this will only toggle GPIO
> lines that aren't muxed to the actual pins.
> 
> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
> built-in capability to bit-bang its lines by using the ICPFUNC registers
> of the i2c controller.
> Implement the suggested procedure by toggling SCL and checking SDA using
> the ICPFUNC registers of the I2C controller when present. Allow platforms
> to indicate the presence of the ICPFUNC registers with a has_pfunc platform
> data flag and add optional DT property "ti,has-pfunc" to indicate
> the same in DT.
On what does it depend if this pfunc stuff works or not? Only the SoC,
or also on some board specific properties? Given the former using the
compatible string to detect its availability would be better. (In this
case also sorry, didn't consider this case when requesting the property
in the last round.)

The patch looks ok.

Best regards
Uwe
Grygorii Strashko Nov. 26, 2014, 5:05 p.m. UTC | #2 
On 11/26/2014 06:04 PM, Uwe Kleine-König wrote:
> On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote:
>> Having a board where the I2C bus locks up occasionally made it clear
>> that the bus recovery in the i2c-davinci driver will only work on
>> some boards, because on regular boards, this will only toggle GPIO
>> lines that aren't muxed to the actual pins.
>>
>> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
>> built-in capability to bit-bang its lines by using the ICPFUNC registers
>> of the i2c controller.
>> Implement the suggested procedure by toggling SCL and checking SDA using
>> the ICPFUNC registers of the I2C controller when present. Allow platforms
>> to indicate the presence of the ICPFUNC registers with a has_pfunc platform
>> data flag and add optional DT property "ti,has-pfunc" to indicate
>> the same in DT.
> On what does it depend if this pfunc stuff works or not? Only the SoC,
> or also on some board specific properties?

SoC / set of SoCs. Also, similar feature is supported by OMAP and AM335x/AM437x SoCs
using I2C_SYSTEST register.

> Given the former using the
> compatible string to detect its availability would be better. (In this
> case also sorry, didn't consider this case when requesting the property
> in the last round.)
> 
> The patch looks ok.

regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Jan Lübbe July 7, 2015, 1:37 p.m. UTC | #3 
On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote:
> On 11/26/2014 06:04 PM, Uwe Kleine-König wrote:
> > On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote:
> >> Having a board where the I2C bus locks up occasionally made it clear
> >> that the bus recovery in the i2c-davinci driver will only work on
> >> some boards, because on regular boards, this will only toggle GPIO
> >> lines that aren't muxed to the actual pins.
> >>
> >> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
> >> built-in capability to bit-bang its lines by using the ICPFUNC registers
> >> of the i2c controller.
> >> Implement the suggested procedure by toggling SCL and checking SDA using
> >> the ICPFUNC registers of the I2C controller when present. Allow platforms
> >> to indicate the presence of the ICPFUNC registers with a has_pfunc platform
> >> data flag and add optional DT property "ti,has-pfunc" to indicate
> >> the same in DT.
> > On what does it depend if this pfunc stuff works or not? Only the SoC,
> > or also on some board specific properties?
> 
> SoC / set of SoCs. Also, similar feature is supported by OMAP and AM335x/AM437x SoCs
> using I2C_SYSTEST register.
> 
> > Given the former using the
> > compatible string to detect its availability would be better. (In this
> > case also sorry, didn't consider this case when requesting the property
> > in the last round.)

I only stumbled across this after it was merged, with the additional
ti,has-pfunc property instead of using the compatible string (which
would be better for a soc-dependent feature). Can we still fix this?

Regards,
Jan
Wolfram Sang July 7, 2015, 1:43 p.m. UTC | #4 
> I only stumbled across this after it was merged, with the additional
> ti,has-pfunc property instead of using the compatible string (which
> would be better for a soc-dependent feature). Can we still fix this?

Makes sense to me.
Uwe Kleine-König July 7, 2015, 1:48 p.m. UTC | #5 
Hello,

On Tue, Jul 07, 2015 at 03:37:49PM +0200, Jan Lübbe wrote:
> On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote:
> > On 11/26/2014 06:04 PM, Uwe Kleine-König wrote:
> > > On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote:
> > >> Having a board where the I2C bus locks up occasionally made it clear
> > >> that the bus recovery in the i2c-davinci driver will only work on
> > >> some boards, because on regular boards, this will only toggle GPIO
> > >> lines that aren't muxed to the actual pins.
> > >>
> > >> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
> > >> built-in capability to bit-bang its lines by using the ICPFUNC registers
> > >> of the i2c controller.
> > >> Implement the suggested procedure by toggling SCL and checking SDA using
> > >> the ICPFUNC registers of the I2C controller when present. Allow platforms
> > >> to indicate the presence of the ICPFUNC registers with a has_pfunc platform
> > >> data flag and add optional DT property "ti,has-pfunc" to indicate
> > >> the same in DT.
> > > On what does it depend if this pfunc stuff works or not? Only the SoC,
> > > or also on some board specific properties?
> > 
> > SoC / set of SoCs. Also, similar feature is supported by OMAP and AM335x/AM437x SoCs
> > using I2C_SYSTEST register.
> > 
> > > Given the former using the
> > > compatible string to detect its availability would be better. (In this
> > > case also sorry, didn't consider this case when requesting the property
> > > in the last round.)
> 
> I only stumbled across this after it was merged, with the additional
I also wonder how it came to the Reviewed-by tag for me. The last thing
that I said about the patch was "On what does it depend if this pfunc
stuff works or not? Only the SoC, or also on some board specific
properties?" (see above) and "the patch looks ok". IMHO this hardly
justifies to add the Reviewed-by tag for the next round. :-(

Best regards
Uwe
Wolfram Sang July 7, 2015, 2:13 p.m. UTC | #6 
On Tue, Jul 07, 2015 at 03:48:52PM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Tue, Jul 07, 2015 at 03:37:49PM +0200, Jan Lübbe wrote:
> > On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote:
> > > On 11/26/2014 06:04 PM, Uwe Kleine-König wrote:
> > > > On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote:
> > > >> Having a board where the I2C bus locks up occasionally made it clear
> > > >> that the bus recovery in the i2c-davinci driver will only work on
> > > >> some boards, because on regular boards, this will only toggle GPIO
> > > >> lines that aren't muxed to the actual pins.
> > > >>
> > > >> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
> > > >> built-in capability to bit-bang its lines by using the ICPFUNC registers
> > > >> of the i2c controller.
> > > >> Implement the suggested procedure by toggling SCL and checking SDA using
> > > >> the ICPFUNC registers of the I2C controller when present. Allow platforms
> > > >> to indicate the presence of the ICPFUNC registers with a has_pfunc platform
> > > >> data flag and add optional DT property "ti,has-pfunc" to indicate
> > > >> the same in DT.
> > > > On what does it depend if this pfunc stuff works or not? Only the SoC,
> > > > or also on some board specific properties?
> > > 
> > > SoC / set of SoCs. Also, similar feature is supported by OMAP and AM335x/AM437x SoCs
> > > using I2C_SYSTEST register.
> > > 
> > > > Given the former using the
> > > > compatible string to detect its availability would be better. (In this
> > > > case also sorry, didn't consider this case when requesting the property
> > > > in the last round.)
> > 
> > I only stumbled across this after it was merged, with the additional
> I also wonder how it came to the Reviewed-by tag for me. The last thing
> that I said about the patch was "On what does it depend if this pfunc
> stuff works or not? Only the SoC, or also on some board specific
> properties?" (see above) and "the patch looks ok". IMHO this hardly
> justifies to add the Reviewed-by tag for the next round. :-(

That needs to be discussed with Grygorii. I can't verify the correctness
of tags for every patch, although I do try to keep an eye on it...
Grygorii Strashko July 7, 2015, 2:53 p.m. UTC | #7 
On 07/07/2015 05:13 PM, Wolfram Sang wrote:
> On Tue, Jul 07, 2015 at 03:48:52PM +0200, Uwe Kleine-König wrote:

>> On Tue, Jul 07, 2015 at 03:37:49PM +0200, Jan Lübbe wrote:
>>> On Mi, 2014-11-26 at 19:05 +0200, Grygorii Strashko wrote:
>>>> On 11/26/2014 06:04 PM, Uwe Kleine-König wrote:
>>>>> On Wed, Nov 26, 2014 at 03:59:53PM +0200, Grygorii Strashko wrote:
>>>>>> Having a board where the I2C bus locks up occasionally made it clear
>>>>>> that the bus recovery in the i2c-davinci driver will only work on
>>>>>> some boards, because on regular boards, this will only toggle GPIO
>>>>>> lines that aren't muxed to the actual pins.
>>>>>>
>>>>>> The I2C controller on SoCs like da850 (and da830), Keystone 2 has the
>>>>>> built-in capability to bit-bang its lines by using the ICPFUNC registers
>>>>>> of the i2c controller.
>>>>>> Implement the suggested procedure by toggling SCL and checking SDA using
>>>>>> the ICPFUNC registers of the I2C controller when present. Allow platforms
>>>>>> to indicate the presence of the ICPFUNC registers with a has_pfunc platform
>>>>>> data flag and add optional DT property "ti,has-pfunc" to indicate
>>>>>> the same in DT.
>>>>> On what does it depend if this pfunc stuff works or not? Only the SoC,
>>>>> or also on some board specific properties?
>>>>
>>>> SoC / set of SoCs. Also, similar feature is supported by OMAP and AM335x/AM437x SoCs
>>>> using I2C_SYSTEST register.
>>>>
>>>>> Given the former using the
>>>>> compatible string to detect its availability would be better. (In this
>>>>> case also sorry, didn't consider this case when requesting the property
>>>>> in the last round.)
>>>
>>> I only stumbled across this after it was merged, with the additional
>> I also wonder how it came to the Reviewed-by tag for me. The last thing
>> that I said about the patch was "On what does it depend if this pfunc
>> stuff works or not? Only the SoC, or also on some board specific
>> properties?" (see above) and "the patch looks ok". IMHO this hardly
>> justifies to add the Reviewed-by tag for the next round. :-(
> 
> That needs to be discussed with Grygorii. I can't verify the correctness
> of tags for every patch, although I do try to keep an eye on it...
> 

Regarding "the patch looks ok" - sincerely sorry!
This is not the first time I've treated "looks good.." as Reviewed-by and I got no complaints before :(
Will take it into account.


Regarding technical comments:
OK. Seems I missed smth. or understood wrongly.
So, I'll say what's people usually saying here - Sorry for that :(
But, to be honest I don't feel guilty, because:
- v4 of these patches was merged finally
- that v4 missed >2 kernel releases
- you were added in "TO:" for all versions of these patches.
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
index 2dc935b..a4e1cbc 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt
@@ -10,6 +10,9 @@  Required properties:
 Recommended properties :
 - interrupts : standard interrupt property.
 - clock-frequency : desired I2C bus clock frequency in Hz.
+- ti,has-pfunc: boolean; if defined, it indicates that SoC supports PFUNC
+	registers. PFUNC registers allow to switch I2C pins to function as
+	GPIOs, so they can by toggled manually.
 
 Example (enbw_cmc board):
 	i2c@1c22000 {
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index b8605b4..f7dae10f 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -64,6 +64,12 @@ 
 #define DAVINCI_I2C_IVR_REG	0x28
 #define DAVINCI_I2C_EMDR_REG	0x2c
 #define DAVINCI_I2C_PSC_REG	0x30
+#define DAVINCI_I2C_FUNC_REG	0x48
+#define DAVINCI_I2C_DIR_REG	0x4c
+#define DAVINCI_I2C_DIN_REG	0x50
+#define DAVINCI_I2C_DOUT_REG	0x54
+#define DAVINCI_I2C_DSET_REG	0x58
+#define DAVINCI_I2C_DCLR_REG	0x5c
 
 #define DAVINCI_I2C_IVR_AAS	0x07
 #define DAVINCI_I2C_IVR_SCD	0x06
@@ -97,6 +103,29 @@ 
 #define DAVINCI_I2C_IMR_NACK	BIT(1)
 #define DAVINCI_I2C_IMR_AL	BIT(0)
 
+/* set SDA and SCL as GPIO */
+#define DAVINCI_I2C_FUNC_PFUNC0	BIT(0)
+
+/* set SCL as output when used as GPIO*/
+#define DAVINCI_I2C_DIR_PDIR0	BIT(0)
+/* set SDA as output when used as GPIO*/
+#define DAVINCI_I2C_DIR_PDIR1	BIT(1)
+
+/* read SCL GPIO level */
+#define DAVINCI_I2C_DIN_PDIN0 BIT(0)
+/* read SDA GPIO level */
+#define DAVINCI_I2C_DIN_PDIN1 BIT(1)
+
+/*set the SCL GPIO high */
+#define DAVINCI_I2C_DSET_PDSET0	BIT(0)
+/*set the SDA GPIO high */
+#define DAVINCI_I2C_DSET_PDSET1	BIT(1)
+
+/* set the SCL GPIO low */
+#define DAVINCI_I2C_DCLR_PDCLR0	BIT(0)
+/* set the SDA GPIO low */
+#define DAVINCI_I2C_DCLR_PDCLR1	BIT(1)
+
 struct davinci_i2c_dev {
 	struct device           *dev;
 	void __iomem		*base;
@@ -257,6 +286,71 @@  static struct i2c_bus_recovery_info davinci_i2c_gpio_recovery_info = {
 	.unprepare_recovery = davinci_i2c_unprepare_recovery,
 };
 
+static void davinci_i2c_set_scl(struct i2c_adapter *adap, int val)
+{
+	struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+
+	if (val)
+		davinci_i2c_write_reg(dev, DAVINCI_I2C_DSET_REG,
+				      DAVINCI_I2C_DSET_PDSET0);
+	else
+		davinci_i2c_write_reg(dev, DAVINCI_I2C_DCLR_REG,
+				      DAVINCI_I2C_DCLR_PDCLR0);
+}
+
+static int davinci_i2c_get_scl(struct i2c_adapter *adap)
+{
+	struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+	int val;
+
+	/* read the state of SCL */
+	val = davinci_i2c_read_reg(dev, DAVINCI_I2C_DIN_REG);
+	return val & DAVINCI_I2C_DIN_PDIN0;
+}
+
+static int davinci_i2c_get_sda(struct i2c_adapter *adap)
+{
+	struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+	int val;
+
+	/* read the state of SDA */
+	val = davinci_i2c_read_reg(dev, DAVINCI_I2C_DIN_REG);
+	return val & DAVINCI_I2C_DIN_PDIN1;
+}
+
+static void davinci_i2c_scl_prepare_recovery(struct i2c_adapter *adap)
+{
+	struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+
+	davinci_i2c_prepare_recovery(adap);
+
+	/* SCL output, SDA input */
+	davinci_i2c_write_reg(dev, DAVINCI_I2C_DIR_REG, DAVINCI_I2C_DIR_PDIR0);
+
+	/* change to GPIO mode */
+	davinci_i2c_write_reg(dev, DAVINCI_I2C_FUNC_REG,
+			      DAVINCI_I2C_FUNC_PFUNC0);
+}
+
+static void davinci_i2c_scl_unprepare_recovery(struct i2c_adapter *adap)
+{
+	struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
+
+	/* change back to I2C mode */
+	davinci_i2c_write_reg(dev, DAVINCI_I2C_FUNC_REG, 0);
+
+	davinci_i2c_unprepare_recovery(adap);
+}
+
+static struct i2c_bus_recovery_info davinci_i2c_scl_recovery_info = {
+	.recover_bus = i2c_generic_scl_recovery,
+	.set_scl = davinci_i2c_set_scl,
+	.get_scl = davinci_i2c_get_scl,
+	.get_sda = davinci_i2c_get_sda,
+	.prepare_recovery = davinci_i2c_scl_prepare_recovery,
+	.unprepare_recovery = davinci_i2c_scl_unprepare_recovery,
+};
+
 /*
  * Waiting for bus not busy
  */
@@ -669,6 +763,10 @@  static int davinci_i2c_probe(struct platform_device *pdev)
 		if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
 			&prop))
 			dev->pdata->bus_freq = prop / 1000;
+
+		dev->pdata->has_pfunc =
+			of_property_read_bool(pdev->dev.of_node,
+					      "ti,has-pfunc");
 	} else if (!dev->pdata) {
 		dev->pdata = &davinci_i2c_platform_data_default;
 	}
@@ -710,7 +808,9 @@  static int davinci_i2c_probe(struct platform_device *pdev)
 	adap->timeout = DAVINCI_I2C_TIMEOUT;
 	adap->dev.of_node = pdev->dev.of_node;
 
-	if (dev->pdata->scl_pin) {
+	if (dev->pdata->has_pfunc)
+		adap->bus_recovery_info = &davinci_i2c_scl_recovery_info;
+	else if (dev->pdata->scl_pin) {
 		adap->bus_recovery_info = &davinci_i2c_gpio_recovery_info;
 		adap->bus_recovery_info->scl_gpio = dev->pdata->scl_pin;
 		adap->bus_recovery_info->sda_gpio = dev->pdata->sda_pin;
diff --git a/include/linux/platform_data/i2c-davinci.h b/include/linux/platform_data/i2c-davinci.h
index 2312d19..89fd347 100644
--- a/include/linux/platform_data/i2c-davinci.h
+++ b/include/linux/platform_data/i2c-davinci.h
@@ -18,6 +18,7 @@  struct davinci_i2c_platform_data {
 	unsigned int	bus_delay;	/* post-transaction delay (usec) */
 	unsigned int    sda_pin;        /* GPIO pin ID to use for SDA */
 	unsigned int    scl_pin;        /* GPIO pin ID to use for SCL */
+	bool		has_pfunc;	/*chip has a ICPFUNC register */
 };
 
 /* for board setup code */