All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Kurtz <djkurtz@chromium.org>
To: Liguo Zhang <liguo.zhang@mediatek.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
	srv_heupstream <srv_heupstream@mediatek.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	Eddie Huang <eddie.huang@mediatek.com>,
	Xudong Chen <xudong.chen@mediatek.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	Linux I2C <linux-i2c@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH v2 2/2] i2c: mediatek: fix i2c multi transfer issue in high speed mode
Date: Sat, 14 Nov 2015 22:38:42 +0800	[thread overview]
Message-ID: <CAGS+omAixwqw2QwR5_4VffHN66aAYNXP1ZJPxsq2WKcgzVxOZw@mail.gmail.com> (raw)
In-Reply-To: <1447047839-5223-3-git-send-email-liguo.zhang@mediatek.com>

On Mon, Nov 9, 2015 at 1:43 PM, Liguo Zhang <liguo.zhang@mediatek.com> wrote:
> For platform with auto restart support, when doing i2c multi transfer
> in high speed, for example, doing write-then-read transfer, the master
> code will occupy the first transfer, and the second transfer will be
> the read transfer, the write transfer will be discarded. So we should
> first send the master code, and then start i2c multi transfer.
>
> Signed-off-by: Liguo Zhang <liguo.zhang@mediatek.com>
> Reviewed-by: Eddie Huang <eddie.huang@mediatek.com>
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 45 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index dc4aac6..249df86 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -53,6 +53,8 @@
>  #define I2C_FS_TIME_INIT_VALUE         0x1303
>  #define I2C_WRRD_TRANAC_VALUE          0x0002
>  #define I2C_RD_TRANAC_VALUE            0x0001
> +#define I2C_TRAN_DEFAULT_VALUE         0x0001
> +#define I2C_TRANAC_DEFAULT_VALUE       0x0001

"TRAN" and "TRANAC" are not good names; this should be "TRANSFER_LEN"
and "TRANSAC", based on the names of the registers to which you write
these constants.

Furthermore, these are not "default" values, they are the transfer
length and number of transactions for sending the "master code", so:

#define I2C_TRANSFER_LEN_MASTER_CODE         0x0001
#define I2C_TRANSAC_LEN_MASTER_CODE       0x0001

Similarly, I think the "TRANAC" in I2C_WRRD_TRANAC_VALUE and
I2C_RD_TRANAC_VALUE should also be TRANSAC.

>
>  #define I2C_DMA_CON_TX                 0x0000
>  #define I2C_DMA_CON_RX                 0x0001
> @@ -365,6 +367,43 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk,
>         return 0;
>  }
>
> +static int mtk_i2c_send_master_code(struct mtk_i2c *i2c)
> +{
> +       int ret = 0;
> +
> +       reinit_completion(&i2c->msg_complete);
> +
> +       writew(I2C_CONTROL_RS | I2C_CONTROL_ACKERR_DET_EN |
> +              I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN,
> +              i2c->base + OFFSET_CONTROL);
> +
> +       /* Clear interrupt status */
> +       writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP | I2C_HS_NACKERR | I2C_ACKERR,
> +              i2c->base + OFFSET_INTR_STAT);
> +
> +       /* Enable interrupt */
> +       writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP, i2c->base +
> +              OFFSET_INTR_MASK);
> +
> +       writew(I2C_TRAN_DEFAULT_VALUE, i2c->base + OFFSET_TRANSFER_LEN);
> +       writew(I2C_TRANAC_DEFAULT_VALUE, i2c->base + OFFSET_TRANSAC_LEN);
> +
> +       writew(I2C_TRANSAC_START | I2C_RS_MUL_CNFG, i2c->base + OFFSET_START);
> +
> +       ret = wait_for_completion_timeout(&i2c->msg_complete,
> +                                         i2c->adap.timeout);

How does the hardware know that this transaction should be a "master code"?
Do you have to tell the hardware what value ('00001XXX') to use as the
master code?
The Master Code must be sent at <= 400 kHz, not the target clock.  How
does the hardware know what rate to use?
When sending the master code, arbitration is supposed to occur, such
that only one winning master can proceed with the following high speed
transaction.
Where do you check that you won this arbitration?
If this is not implemented, adding a "TODO" would be helpful.

> +
> +       completion_done(&i2c->msg_complete);

This completion_done() is only useful if you check the return value.
You should check it too, since we should only check for timeout if the
message hasn't completed.

> +
> +       if (ret == 0) {
> +               dev_dbg(i2c->dev, "send master code timeout.\n");
> +               mtk_i2c_init_hw(i2c);
> +               return -ETIMEDOUT;
> +       }
> +
> +       return 0;
> +}
> +
>  static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>                                int num, int left_num)
>  {
> @@ -539,6 +578,12 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
>                 }
>         }
>
> +       if (i2c->auto_restart && i2c->speed_hz > 400000) {

Don't we need to send the master code for *every* HS transaction, not
just "auto_restart"?

"400000" => You already have a macro for this: MAX_FS_MODE_SPEED

> +               ret = mtk_i2c_send_master_code(i2c);
> +               if (ret)
> +                       return ret;
> +       }
> +
>         while (left_num--) {
>                 if (!msgs->buf) {
>                         dev_dbg(i2c->dev, "data buffer is NULL.\n");
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Kurtz <djkurtz-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
To: Liguo Zhang <liguo.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Cc: Xudong Chen <xudong.chen-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	srv_heupstream
	<srv_heupstream-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
	Sascha Hauer <s.hauer-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	Linux I2C <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Matthias Brugger
	<matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Eddie Huang <eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v2 2/2] i2c: mediatek: fix i2c multi transfer issue in high speed mode
Date: Sat, 14 Nov 2015 22:38:42 +0800	[thread overview]
Message-ID: <CAGS+omAixwqw2QwR5_4VffHN66aAYNXP1ZJPxsq2WKcgzVxOZw@mail.gmail.com> (raw)
In-Reply-To: <1447047839-5223-3-git-send-email-liguo.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>

On Mon, Nov 9, 2015 at 1:43 PM, Liguo Zhang <liguo.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org> wrote:
> For platform with auto restart support, when doing i2c multi transfer
> in high speed, for example, doing write-then-read transfer, the master
> code will occupy the first transfer, and the second transfer will be
> the read transfer, the write transfer will be discarded. So we should
> first send the master code, and then start i2c multi transfer.
>
> Signed-off-by: Liguo Zhang <liguo.zhang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Reviewed-by: Eddie Huang <eddie.huang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 45 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index dc4aac6..249df86 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -53,6 +53,8 @@
>  #define I2C_FS_TIME_INIT_VALUE         0x1303
>  #define I2C_WRRD_TRANAC_VALUE          0x0002
>  #define I2C_RD_TRANAC_VALUE            0x0001
> +#define I2C_TRAN_DEFAULT_VALUE         0x0001
> +#define I2C_TRANAC_DEFAULT_VALUE       0x0001

"TRAN" and "TRANAC" are not good names; this should be "TRANSFER_LEN"
and "TRANSAC", based on the names of the registers to which you write
these constants.

Furthermore, these are not "default" values, they are the transfer
length and number of transactions for sending the "master code", so:

#define I2C_TRANSFER_LEN_MASTER_CODE         0x0001
#define I2C_TRANSAC_LEN_MASTER_CODE       0x0001

Similarly, I think the "TRANAC" in I2C_WRRD_TRANAC_VALUE and
I2C_RD_TRANAC_VALUE should also be TRANSAC.

>
>  #define I2C_DMA_CON_TX                 0x0000
>  #define I2C_DMA_CON_RX                 0x0001
> @@ -365,6 +367,43 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk,
>         return 0;
>  }
>
> +static int mtk_i2c_send_master_code(struct mtk_i2c *i2c)
> +{
> +       int ret = 0;
> +
> +       reinit_completion(&i2c->msg_complete);
> +
> +       writew(I2C_CONTROL_RS | I2C_CONTROL_ACKERR_DET_EN |
> +              I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN,
> +              i2c->base + OFFSET_CONTROL);
> +
> +       /* Clear interrupt status */
> +       writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP | I2C_HS_NACKERR | I2C_ACKERR,
> +              i2c->base + OFFSET_INTR_STAT);
> +
> +       /* Enable interrupt */
> +       writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP, i2c->base +
> +              OFFSET_INTR_MASK);
> +
> +       writew(I2C_TRAN_DEFAULT_VALUE, i2c->base + OFFSET_TRANSFER_LEN);
> +       writew(I2C_TRANAC_DEFAULT_VALUE, i2c->base + OFFSET_TRANSAC_LEN);
> +
> +       writew(I2C_TRANSAC_START | I2C_RS_MUL_CNFG, i2c->base + OFFSET_START);
> +
> +       ret = wait_for_completion_timeout(&i2c->msg_complete,
> +                                         i2c->adap.timeout);

How does the hardware know that this transaction should be a "master code"?
Do you have to tell the hardware what value ('00001XXX') to use as the
master code?
The Master Code must be sent at <= 400 kHz, not the target clock.  How
does the hardware know what rate to use?
When sending the master code, arbitration is supposed to occur, such
that only one winning master can proceed with the following high speed
transaction.
Where do you check that you won this arbitration?
If this is not implemented, adding a "TODO" would be helpful.

> +
> +       completion_done(&i2c->msg_complete);

This completion_done() is only useful if you check the return value.
You should check it too, since we should only check for timeout if the
message hasn't completed.

> +
> +       if (ret == 0) {
> +               dev_dbg(i2c->dev, "send master code timeout.\n");
> +               mtk_i2c_init_hw(i2c);
> +               return -ETIMEDOUT;
> +       }
> +
> +       return 0;
> +}
> +
>  static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>                                int num, int left_num)
>  {
> @@ -539,6 +578,12 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
>                 }
>         }
>
> +       if (i2c->auto_restart && i2c->speed_hz > 400000) {

Don't we need to send the master code for *every* HS transaction, not
just "auto_restart"?

"400000" => You already have a macro for this: MAX_FS_MODE_SPEED

> +               ret = mtk_i2c_send_master_code(i2c);
> +               if (ret)
> +                       return ret;
> +       }
> +
>         while (left_num--) {
>                 if (!msgs->buf) {
>                         dev_dbg(i2c->dev, "data buffer is NULL.\n");
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

WARNING: multiple messages have this Message-ID (diff)
From: djkurtz@chromium.org (Daniel Kurtz)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] i2c: mediatek: fix i2c multi transfer issue in high speed mode
Date: Sat, 14 Nov 2015 22:38:42 +0800	[thread overview]
Message-ID: <CAGS+omAixwqw2QwR5_4VffHN66aAYNXP1ZJPxsq2WKcgzVxOZw@mail.gmail.com> (raw)
In-Reply-To: <1447047839-5223-3-git-send-email-liguo.zhang@mediatek.com>

On Mon, Nov 9, 2015 at 1:43 PM, Liguo Zhang <liguo.zhang@mediatek.com> wrote:
> For platform with auto restart support, when doing i2c multi transfer
> in high speed, for example, doing write-then-read transfer, the master
> code will occupy the first transfer, and the second transfer will be
> the read transfer, the write transfer will be discarded. So we should
> first send the master code, and then start i2c multi transfer.
>
> Signed-off-by: Liguo Zhang <liguo.zhang@mediatek.com>
> Reviewed-by: Eddie Huang <eddie.huang@mediatek.com>
> ---
>  drivers/i2c/busses/i2c-mt65xx.c | 45 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 45 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-mt65xx.c b/drivers/i2c/busses/i2c-mt65xx.c
> index dc4aac6..249df86 100644
> --- a/drivers/i2c/busses/i2c-mt65xx.c
> +++ b/drivers/i2c/busses/i2c-mt65xx.c
> @@ -53,6 +53,8 @@
>  #define I2C_FS_TIME_INIT_VALUE         0x1303
>  #define I2C_WRRD_TRANAC_VALUE          0x0002
>  #define I2C_RD_TRANAC_VALUE            0x0001
> +#define I2C_TRAN_DEFAULT_VALUE         0x0001
> +#define I2C_TRANAC_DEFAULT_VALUE       0x0001

"TRAN" and "TRANAC" are not good names; this should be "TRANSFER_LEN"
and "TRANSAC", based on the names of the registers to which you write
these constants.

Furthermore, these are not "default" values, they are the transfer
length and number of transactions for sending the "master code", so:

#define I2C_TRANSFER_LEN_MASTER_CODE         0x0001
#define I2C_TRANSAC_LEN_MASTER_CODE       0x0001

Similarly, I think the "TRANAC" in I2C_WRRD_TRANAC_VALUE and
I2C_RD_TRANAC_VALUE should also be TRANSAC.

>
>  #define I2C_DMA_CON_TX                 0x0000
>  #define I2C_DMA_CON_RX                 0x0001
> @@ -365,6 +367,43 @@ static int mtk_i2c_set_speed(struct mtk_i2c *i2c, unsigned int parent_clk,
>         return 0;
>  }
>
> +static int mtk_i2c_send_master_code(struct mtk_i2c *i2c)
> +{
> +       int ret = 0;
> +
> +       reinit_completion(&i2c->msg_complete);
> +
> +       writew(I2C_CONTROL_RS | I2C_CONTROL_ACKERR_DET_EN |
> +              I2C_CONTROL_CLK_EXT_EN | I2C_CONTROL_DMA_EN,
> +              i2c->base + OFFSET_CONTROL);
> +
> +       /* Clear interrupt status */
> +       writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP | I2C_HS_NACKERR | I2C_ACKERR,
> +              i2c->base + OFFSET_INTR_STAT);
> +
> +       /* Enable interrupt */
> +       writew(I2C_RS_TRANSFER | I2C_TRANSAC_COMP, i2c->base +
> +              OFFSET_INTR_MASK);
> +
> +       writew(I2C_TRAN_DEFAULT_VALUE, i2c->base + OFFSET_TRANSFER_LEN);
> +       writew(I2C_TRANAC_DEFAULT_VALUE, i2c->base + OFFSET_TRANSAC_LEN);
> +
> +       writew(I2C_TRANSAC_START | I2C_RS_MUL_CNFG, i2c->base + OFFSET_START);
> +
> +       ret = wait_for_completion_timeout(&i2c->msg_complete,
> +                                         i2c->adap.timeout);

How does the hardware know that this transaction should be a "master code"?
Do you have to tell the hardware what value ('00001XXX') to use as the
master code?
The Master Code must be sent at <= 400 kHz, not the target clock.  How
does the hardware know what rate to use?
When sending the master code, arbitration is supposed to occur, such
that only one winning master can proceed with the following high speed
transaction.
Where do you check that you won this arbitration?
If this is not implemented, adding a "TODO" would be helpful.

> +
> +       completion_done(&i2c->msg_complete);

This completion_done() is only useful if you check the return value.
You should check it too, since we should only check for timeout if the
message hasn't completed.

> +
> +       if (ret == 0) {
> +               dev_dbg(i2c->dev, "send master code timeout.\n");
> +               mtk_i2c_init_hw(i2c);
> +               return -ETIMEDOUT;
> +       }
> +
> +       return 0;
> +}
> +
>  static int mtk_i2c_do_transfer(struct mtk_i2c *i2c, struct i2c_msg *msgs,
>                                int num, int left_num)
>  {
> @@ -539,6 +578,12 @@ static int mtk_i2c_transfer(struct i2c_adapter *adap,
>                 }
>         }
>
> +       if (i2c->auto_restart && i2c->speed_hz > 400000) {

Don't we need to send the master code for *every* HS transaction, not
just "auto_restart"?

"400000" => You already have a macro for this: MAX_FS_MODE_SPEED

> +               ret = mtk_i2c_send_master_code(i2c);
> +               if (ret)
> +                       return ret;
> +       }
> +
>         while (left_num--) {
>                 if (!msgs->buf) {
>                         dev_dbg(i2c->dev, "data buffer is NULL.\n");
> --
> 1.8.1.1.dirty
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

  reply	other threads:[~2015-11-14 14:39 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-09  5:43 [PATCH v2 0/2] Mediatek I2C Fixup Liguo Zhang
2015-11-09  5:43 ` Liguo Zhang
2015-11-09  5:43 ` Liguo Zhang
2015-11-09  5:43 ` [PATCH v2 1/2] i2c: mediatek: add i2c first write then read optimization Liguo Zhang
2015-11-09  5:43   ` Liguo Zhang
2015-11-09  5:43   ` Liguo Zhang
2015-11-09 14:25   ` Andy Shevchenko
2015-11-09 14:25     ` Andy Shevchenko
2015-11-10  0:34     ` Daniel Kurtz
2015-11-10  0:34       ` Daniel Kurtz
2015-11-10  0:50     ` Yingjoe Chen
2015-11-10  0:50       ` Yingjoe Chen
2015-11-10  0:50       ` Yingjoe Chen
2015-12-01  0:56   ` Wolfram Sang
2015-12-01  0:56     ` Wolfram Sang
2015-11-09  5:43 ` [PATCH v2 2/2] i2c: mediatek: fix i2c multi transfer issue in high speed mode Liguo Zhang
2015-11-09  5:43   ` Liguo Zhang
2015-11-09  5:43   ` Liguo Zhang
2015-11-14 14:38   ` Daniel Kurtz [this message]
2015-11-14 14:38     ` Daniel Kurtz
2015-11-14 14:38     ` Daniel Kurtz
2015-12-01  0:54     ` Wolfram Sang
2015-12-01  0:54       ` Wolfram Sang
2015-12-01  0:54       ` Wolfram Sang
2015-12-01 11:24     ` Liguo Zhang (张立国)
2015-12-01 11:24       ` Liguo Zhang (张立国)
2015-12-01 11:24       ` Liguo Zhang (张立国)
2015-12-02  2:51     ` liguo zhang
2015-12-02  2:51       ` liguo zhang
2015-12-02  2:51       ` liguo zhang

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=CAGS+omAixwqw2QwR5_4VffHN66aAYNXP1ZJPxsq2WKcgzVxOZw@mail.gmail.com \
    --to=djkurtz@chromium.org \
    --cc=eddie.huang@mediatek.com \
    --cc=liguo.zhang@mediatek.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=srv_heupstream@mediatek.com \
    --cc=wsa@the-dreams.de \
    --cc=xudong.chen@mediatek.com \
    /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: link
Be 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.