Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1438636 > unrolled thread

[PATCH] i2c: imx: add retries for i2c-0 on Ventana boards

Back to article view | Back to linux.kernel

Contents

  [PATCH] i2c: imx: add retries for i2c-0 on Ventana boards Tim Harvey <tharvey@gateworks.com> - 2016-07-07 16:00 +0200
    Re: [PATCH] i2c: imx: add retries for i2c-0 on Ventana boards Uwe Kleine-König   <u.kleine-koenig@pengutronix.de> - 2016-07-08 08:30 +0200
      Re: [PATCH] i2c: imx: add retries for i2c-0 on Ventana boards Tim Harvey <tharvey@gateworks.com> - 2016-07-08 21:50 +0200
        Re: [PATCH] i2c: imx: add retries for i2c-0 on Ventana boards Uwe Kleine-König   <u.kleine-koenig@pengutronix.de> - 2016-07-08 23:10 +0200
          Re: [PATCH] i2c: imx: add retries for i2c-0 on Ventana boards Wolfram Sang <wsa@the-dreams.de> - 2016-07-09 04:40 +0200

#1438636 — [PATCH] i2c: imx: add retries for i2c-0 on Ventana boards

Gateworks Ventana IMX6 based boards have a Gateworks System Controller [1]
(gsc) device that can NAK i2c transactions when its busy in an ADC loop. As
this is always on i2c-0 we will add retries for that bus for any Ventana
board.

Signed-off-by: Tim Harvey <tharvey@gateworks.com>
---
 drivers/i2c/busses/i2c-imx.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 1844bc9..aec71c3 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -460,6 +460,8 @@ static int i2c_imx_acked(struct imx_i2c_struct *i2c_imx)
 {
 	if (imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR) & I2SR_RXAK) {
 		dev_dbg(&i2c_imx->adapter.dev, "<%s> No ACK\n", __func__);
+		if (i2c_imx->adapter.retries)
+			return -EAGAIN;
 		return -ENXIO;  /* No ACK */
 	}
 
@@ -1068,6 +1070,16 @@ static int i2c_imx_probe(struct platform_device *pdev)
 	i2c_imx->adapter.dev.of_node	= pdev->dev.of_node;
 	i2c_imx->base			= base;
 
+	/*
+	 * The Gateworks Ventana has an i2c based system controller on i2c-0
+	 * which emulates several standard i2c devices with existing drivers.
+	 * That device can NAK when its in an ADC loop. Add bus retries.
+	 */
+	if (of_machine_is_compatible("gw,ventana") && phy_addr == 0x021a0000) {
+		dev_info(&pdev->dev, "Adding retries for Ventana GSC\n");
+		i2c_imx->adapter.retries = 3;
+	}
+
 	/* Get I2C clock */
 	i2c_imx->clk = devm_clk_get(&pdev->dev, NULL);
 	if (IS_ERR(i2c_imx->clk)) {
-- 
1.9.1

[toc] | [next] | [standalone]

#1439128

Hello Tim,

On Thu, Jul 07, 2016 at 07:03:49AM -0700, Tim Harvey wrote:
> Gateworks Ventana IMX6 based boards have a Gateworks System Controller [1]
> (gsc) device that can NAK i2c transactions when its busy in an ADC loop. As
> this is always on i2c-0 we will add retries for that bus for any Ventana
> board.

The right thing is to fix the drivers IMHO.

> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index 1844bc9..aec71c3 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -460,6 +460,8 @@ static int i2c_imx_acked(struct imx_i2c_struct *i2c_imx)
>  {
>  	if (imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR) & I2SR_RXAK) {
>  		dev_dbg(&i2c_imx->adapter.dev, "<%s> No ACK\n", __func__);
> +		if (i2c_imx->adapter.retries)
> +			return -EAGAIN;

This is wrong, struct i2c_adapter::retries is for restarting a transfer
on arbitration loss.

>  		return -ENXIO;  /* No ACK */
>  	}
>  
> @@ -1068,6 +1070,16 @@ static int i2c_imx_probe(struct platform_device *pdev)
>  	i2c_imx->adapter.dev.of_node	= pdev->dev.of_node;
>  	i2c_imx->base			= base;
>  
> +	/*
> +	 * The Gateworks Ventana has an i2c based system controller on i2c-0
> +	 * which emulates several standard i2c devices with existing drivers.
> +	 * That device can NAK when its in an ADC loop. Add bus retries.
> +	 */
> +	if (of_machine_is_compatible("gw,ventana") && phy_addr == 0x021a0000) {

Please don't. If you want to do handle a device in a special way, invent
a device tree property, add it to your machine description and add
handling here. Using of_machine_is_compatible + base address of the
device to decide about configuration is a no go.

> +		dev_info(&pdev->dev, "Adding retries for Ventana GSC\n");
> +		i2c_imx->adapter.retries = 3;
> +	}
> +

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[toc] | [prev] | [next] | [standalone]

#1439763

On Thu, Jul 7, 2016 at 11:28 PM, Uwe Kleine-König
<u.kleine-koenig@pengutronix.de> wrote:
> Hello Tim,
>
> On Thu, Jul 07, 2016 at 07:03:49AM -0700, Tim Harvey wrote:
>> Gateworks Ventana IMX6 based boards have a Gateworks System Controller [1]
>> (gsc) device that can NAK i2c transactions when its busy in an ADC loop. As
>> this is always on i2c-0 we will add retries for that bus for any Ventana
>> board.
>
> The right thing is to fix the drivers IMHO.
>

Hi Uwe,

Thanks for the feedack!

The issue I have is that the i2c device emulates several other devices
with existing drivers (pca953x, ds1672, at24) and those drivers don't
have any retry mechanism in place for a retry.

Maybe if I converted those drivers to use regmap I could implement a
regmap with retries in the mfd driver for my device?

Regards,

Tim

[toc] | [prev] | [next] | [standalone]

#1439797

Hello Tim, hello Wolfram,

On Fri, Jul 08, 2016 at 12:49:04PM -0700, Tim Harvey wrote:
> On Thu, Jul 7, 2016 at 11:28 PM, Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
> > Hello Tim,
> >
> > On Thu, Jul 07, 2016 at 07:03:49AM -0700, Tim Harvey wrote:
> >> Gateworks Ventana IMX6 based boards have a Gateworks System Controller [1]
> >> (gsc) device that can NAK i2c transactions when its busy in an ADC loop. As
> >> this is always on i2c-0 we will add retries for that bus for any Ventana
> >> board.
> >
> > The right thing is to fix the drivers IMHO.
> >
> The issue I have is that the i2c device emulates several other devices
> with existing drivers (pca953x, ds1672, at24) and those drivers don't
> have any retry mechanism in place for a retry.
> 
> Maybe if I converted those drivers to use regmap I could implement a
> regmap with retries in the mfd driver for my device?

Wolfram: what do you think?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[toc] | [prev] | [next] | [standalone]

#1439874

[Multipart message — attachments visible in raw view] — view raw

> > The issue I have is that the i2c device emulates several other devices
> > with existing drivers (pca953x, ds1672, at24) and those drivers don't
> > have any retry mechanism in place for a retry.
> > 
> > Maybe if I converted those drivers to use regmap I could implement a
> > regmap with retries in the mfd driver for my device?
> 
> Wolfram: what do you think?

What NAK means is device specific IMO, so to do it generally at regmap
level is convenient but wrong. at24 already has retry support because it
may be accessed while in an erase cycle. I don't know the other devices.
You need to discuss with the driver authors/maintainers if a NAK can
generally mean "let's retry" or if you need a seperate i2c_device_id for
your variant which then handles the NAK differently.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web