All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yao Yuan <yao.yuan@freescale.com>
To: Marek Vasut <marex@denx.de>
Cc: "wsa@the-dreams.de" <wsa@the-dreams.de>,
	"LW@karo-electronics.de" <LW@karo-electronics.de>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>,
	"fugang.duan@freescale.com" <fugang.duan@freescale.com>,
	"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: RE: [PATCH v7 1/2] i2c: imx: add DMA support for freescale i2c driver
Date: Wed, 17 Sep 2014 14:50:34 +0000	[thread overview]
Message-ID: <1410965416759.91038@freescale.com> (raw)
In-Reply-To: <201409162017.06439.marex@denx.de>

On Wednesday, September 17, 2014 2:17 AM, Marek Vasut wrote:
> On Wednesday, September 10, 2014 at 04:48:01 PM, Yao Yuan wrote:
> > On Friday, September 05, 2014 6:41 PM, Marek Vasut wrote:
> > > On Friday, September 05, 2014 at 12:32:40 PM, Yao Yuan wrote:
> > > [...]
> > >
> > > > > > +static int i2c_imx_dma_write(struct imx_i2c_struct *i2c_imx,
> > > > > > +					struct i2c_msg *msgs)
> > > > > > +{
> > > > > > +	int result;
> > > > > > +	unsigned int temp = 0;
> > > > > > +	unsigned long orig_jiffies = jiffies;
> > > > > > +	struct imx_i2c_dma *dma = i2c_imx->dma;
> > > > > > +	struct device *dev = &i2c_imx->adapter.dev;
> > > > > > +
> > > > > > +	dev_dbg(dev, "<%s> write slave address: addr=0x%x\n",
> > > > > > +		__func__, msgs->addr << 1);
> > > > > > +
> > > > > > +	reinit_completion(&i2c_imx->dma->cmd_complete);
> > > > > > +	dma->chan_using = dma->chan_tx;
> > > > > > +	dma->dma_transfer_dir = DMA_MEM_TO_DEV;
> > > > > > +	dma->dma_data_dir = DMA_TO_DEVICE;
> > > > > > +	dma->dma_len = msgs->len - 1;
> > > > > > +	result = i2c_imx_dma_xfer(i2c_imx, msgs);
> > > > > > +	if (result)
> > > > > > +		return result;
> > > > > > +
> > > > > > +	temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> > > > > > +	temp |= I2CR_DMAEN;
> > > > > > +	imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * Write slave address.
> > > > > > +	 * The first byte muse be transmitted by the CPU.
> > > > > > +	 */
> > > > > > +	imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
> > > > > > +	result = wait_for_completion_interruptible_timeout(
> > > > > > +				&i2c_imx->dma->cmd_complete,
> > > > > > +				msecs_to_jiffies(IMX_I2C_DMA_TIMEOUT));
> > > > > > +	if (result <= 0) {
> > > > > > +		dmaengine_terminate_all(dma->chan_using);
> > > > > > +		if (result)
> > > > > > +			return result;
> > > > > > +		else
> > > > > > +			return -ETIMEDOUT;
> > > > >
> > > > > Shouldn't you force-disable the DMA here somehow (like unsetting
> > > > > I2CR_DMAEN bit), if it failed or timed out?
> > > >
> > > > [Yuan Yao] Yes, I put the code for force-disable DMA in
> > > > i2c_imx_start(). In order to make sure any DMA error will not
> > > > effect the I2C.
> > > > It seems almost the same as put the code here, how about your think?
> > >
> > > Would that mean that the "crashed" DMA would be running until the
> > > next transmission is scheduled ?
> >
> > [Yuan Yao] No, In fact any DMA timeout will result the failure of I2C
> > transmission and then it will turn to report the exception and wait
> > for next transmission.
> 
> Can you tell when the next transmission will happen? What if I issue a
> single transmission and that one fails ? Will the DMA run until who knows
> when ?

[Yuan Yao] 
Sorry for my unclear description. In fact, During the DMA transmission  if
an error happened or time out, DMA will stop at once and be disabled.
I just continue to route the TX and RX request to signal the DMA controller.
Because the DMA is disabled, it will ignore those signals.

In a word, I just want to block the I2C TX, RX and interrupt signal when
DMA mode failed until the next I2C transmission start.

In fact, the bit "I2CR_DMAEN" is a switch which decide whether I2C route
the TX, RX and interrupt signal to DMA controller. 

> > The only thing I worried about is I2C may still receive some feedbacks
> > after DMA timeout. In this case the feedbacks may lead to abnormal
> > state in PIO mode.But it will be ignored in DMA model.
> > That's why I tend to delay force-disable DMA until the next
> > transmission begin. Could you please give me some suggestion?
> 
> No, this design just seems flawed to me. You should stop the DMA
> immediatelly if there is an error to avoid wasting resources and prevent
> possible other adverse effects.
>
[Yuan Yao] 
Yes, I have stopped the DMA immediately. However I keep the I2C DMA
single route.

I don't have the exact evidence to prove that my design is acceptable.
So if you are sure it's flawed, I will change it in the next version(V8).

Best regards,
Yuan Yao

WARNING: multiple messages have this Message-ID (diff)
From: Yao Yuan <yao.yuan@freescale.com>
To: Marek Vasut <marex@denx.de>
Cc: "mark.rutland@arm.com" <mark.rutland@arm.com>,
	"wsa@the-dreams.de" <wsa@the-dreams.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"fugang.duan@freescale.com" <fugang.duan@freescale.com>,
	"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"LW@karo-electronics.de" <LW@karo-electronics.de>
Subject: RE: [PATCH v7 1/2] i2c: imx: add DMA support for freescale i2c driver
Date: Wed, 17 Sep 2014 14:50:34 +0000	[thread overview]
Message-ID: <1410965416759.91038@freescale.com> (raw)
In-Reply-To: <201409162017.06439.marex@denx.de>

On Wednesday, September 17, 2014 2:17 AM, Marek Vasut wrote:
> On Wednesday, September 10, 2014 at 04:48:01 PM, Yao Yuan wrote:
> > On Friday, September 05, 2014 6:41 PM, Marek Vasut wrote:
> > > On Friday, September 05, 2014 at 12:32:40 PM, Yao Yuan wrote:
> > > [...]
> > >
> > > > > > +static int i2c_imx_dma_write(struct imx_i2c_struct *i2c_imx,
> > > > > > +					struct i2c_msg *msgs)
> > > > > > +{
> > > > > > +	int result;
> > > > > > +	unsigned int temp = 0;
> > > > > > +	unsigned long orig_jiffies = jiffies;
> > > > > > +	struct imx_i2c_dma *dma = i2c_imx->dma;
> > > > > > +	struct device *dev = &i2c_imx->adapter.dev;
> > > > > > +
> > > > > > +	dev_dbg(dev, "<%s> write slave address: addr=0x%x\n",
> > > > > > +		__func__, msgs->addr << 1);
> > > > > > +
> > > > > > +	reinit_completion(&i2c_imx->dma->cmd_complete);
> > > > > > +	dma->chan_using = dma->chan_tx;
> > > > > > +	dma->dma_transfer_dir = DMA_MEM_TO_DEV;
> > > > > > +	dma->dma_data_dir = DMA_TO_DEVICE;
> > > > > > +	dma->dma_len = msgs->len - 1;
> > > > > > +	result = i2c_imx_dma_xfer(i2c_imx, msgs);
> > > > > > +	if (result)
> > > > > > +		return result;
> > > > > > +
> > > > > > +	temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> > > > > > +	temp |= I2CR_DMAEN;
> > > > > > +	imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * Write slave address.
> > > > > > +	 * The first byte muse be transmitted by the CPU.
> > > > > > +	 */
> > > > > > +	imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
> > > > > > +	result = wait_for_completion_interruptible_timeout(
> > > > > > +				&i2c_imx->dma->cmd_complete,
> > > > > > +				msecs_to_jiffies(IMX_I2C_DMA_TIMEOUT));
> > > > > > +	if (result <= 0) {
> > > > > > +		dmaengine_terminate_all(dma->chan_using);
> > > > > > +		if (result)
> > > > > > +			return result;
> > > > > > +		else
> > > > > > +			return -ETIMEDOUT;
> > > > >
> > > > > Shouldn't you force-disable the DMA here somehow (like unsetting
> > > > > I2CR_DMAEN bit), if it failed or timed out?
> > > >
> > > > [Yuan Yao] Yes, I put the code for force-disable DMA in
> > > > i2c_imx_start(). In order to make sure any DMA error will not
> > > > effect the I2C.
> > > > It seems almost the same as put the code here, how about your think?
> > >
> > > Would that mean that the "crashed" DMA would be running until the
> > > next transmission is scheduled ?
> >
> > [Yuan Yao] No, In fact any DMA timeout will result the failure of I2C
> > transmission and then it will turn to report the exception and wait
> > for next transmission.
> 
> Can you tell when the next transmission will happen? What if I issue a
> single transmission and that one fails ? Will the DMA run until who knows
> when ?

[Yuan Yao] 
Sorry for my unclear description. In fact, During the DMA transmission  if
an error happened or time out, DMA will stop at once and be disabled.
I just continue to route the TX and RX request to signal the DMA controller.
Because the DMA is disabled, it will ignore those signals.

In a word, I just want to block the I2C TX, RX and interrupt signal when
DMA mode failed until the next I2C transmission start.

In fact, the bit "I2CR_DMAEN" is a switch which decide whether I2C route
the TX, RX and interrupt signal to DMA controller. 

> > The only thing I worried about is I2C may still receive some feedbacks
> > after DMA timeout. In this case the feedbacks may lead to abnormal
> > state in PIO mode.But it will be ignored in DMA model.
> > That's why I tend to delay force-disable DMA until the next
> > transmission begin. Could you please give me some suggestion?
> 
> No, this design just seems flawed to me. You should stop the DMA
> immediatelly if there is an error to avoid wasting resources and prevent
> possible other adverse effects.
>
[Yuan Yao] 
Yes, I have stopped the DMA immediately. However I keep the I2C DMA
single route.

I don't have the exact evidence to prove that my design is acceptable.
So if you are sure it's flawed, I will change it in the next version(V8).

Best regards,
Yuan Yao

WARNING: multiple messages have this Message-ID (diff)
From: yao.yuan@freescale.com (Yao Yuan)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v7 1/2] i2c: imx: add DMA support for freescale i2c driver
Date: Wed, 17 Sep 2014 14:50:34 +0000	[thread overview]
Message-ID: <1410965416759.91038@freescale.com> (raw)
In-Reply-To: <201409162017.06439.marex@denx.de>

On Wednesday, September 17, 2014 2:17 AM, Marek Vasut wrote:
> On Wednesday, September 10, 2014 at 04:48:01 PM, Yao Yuan wrote:
> > On Friday, September 05, 2014 6:41 PM, Marek Vasut wrote:
> > > On Friday, September 05, 2014 at 12:32:40 PM, Yao Yuan wrote:
> > > [...]
> > >
> > > > > > +static int i2c_imx_dma_write(struct imx_i2c_struct *i2c_imx,
> > > > > > +					struct i2c_msg *msgs)
> > > > > > +{
> > > > > > +	int result;
> > > > > > +	unsigned int temp = 0;
> > > > > > +	unsigned long orig_jiffies = jiffies;
> > > > > > +	struct imx_i2c_dma *dma = i2c_imx->dma;
> > > > > > +	struct device *dev = &i2c_imx->adapter.dev;
> > > > > > +
> > > > > > +	dev_dbg(dev, "<%s> write slave address: addr=0x%x\n",
> > > > > > +		__func__, msgs->addr << 1);
> > > > > > +
> > > > > > +	reinit_completion(&i2c_imx->dma->cmd_complete);
> > > > > > +	dma->chan_using = dma->chan_tx;
> > > > > > +	dma->dma_transfer_dir = DMA_MEM_TO_DEV;
> > > > > > +	dma->dma_data_dir = DMA_TO_DEVICE;
> > > > > > +	dma->dma_len = msgs->len - 1;
> > > > > > +	result = i2c_imx_dma_xfer(i2c_imx, msgs);
> > > > > > +	if (result)
> > > > > > +		return result;
> > > > > > +
> > > > > > +	temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> > > > > > +	temp |= I2CR_DMAEN;
> > > > > > +	imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> > > > > > +
> > > > > > +	/*
> > > > > > +	 * Write slave address.
> > > > > > +	 * The first byte muse be transmitted by the CPU.
> > > > > > +	 */
> > > > > > +	imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
> > > > > > +	result = wait_for_completion_interruptible_timeout(
> > > > > > +				&i2c_imx->dma->cmd_complete,
> > > > > > +				msecs_to_jiffies(IMX_I2C_DMA_TIMEOUT));
> > > > > > +	if (result <= 0) {
> > > > > > +		dmaengine_terminate_all(dma->chan_using);
> > > > > > +		if (result)
> > > > > > +			return result;
> > > > > > +		else
> > > > > > +			return -ETIMEDOUT;
> > > > >
> > > > > Shouldn't you force-disable the DMA here somehow (like unsetting
> > > > > I2CR_DMAEN bit), if it failed or timed out?
> > > >
> > > > [Yuan Yao] Yes, I put the code for force-disable DMA in
> > > > i2c_imx_start(). In order to make sure any DMA error will not
> > > > effect the I2C.
> > > > It seems almost the same as put the code here, how about your think?
> > >
> > > Would that mean that the "crashed" DMA would be running until the
> > > next transmission is scheduled ?
> >
> > [Yuan Yao] No, In fact any DMA timeout will result the failure of I2C
> > transmission and then it will turn to report the exception and wait
> > for next transmission.
> 
> Can you tell when the next transmission will happen? What if I issue a
> single transmission and that one fails ? Will the DMA run until who knows
> when ?

[Yuan Yao] 
Sorry for my unclear description. In fact, During the DMA transmission  if
an error happened or time out, DMA will stop at once and be disabled.
I just continue to route the TX and RX request to signal the DMA controller.
Because the DMA is disabled, it will ignore those signals.

In a word, I just want to block the I2C TX, RX and interrupt signal when
DMA mode failed until the next I2C transmission start.

In fact, the bit "I2CR_DMAEN" is a switch which decide whether I2C route
the TX, RX and interrupt signal to DMA controller. 

> > The only thing I worried about is I2C may still receive some feedbacks
> > after DMA timeout. In this case the feedbacks may lead to abnormal
> > state in PIO mode.But it will be ignored in DMA model.
> > That's why I tend to delay force-disable DMA until the next
> > transmission begin. Could you please give me some suggestion?
> 
> No, this design just seems flawed to me. You should stop the DMA
> immediatelly if there is an error to avoid wasting resources and prevent
> possible other adverse effects.
>
[Yuan Yao] 
Yes, I have stopped the DMA immediately. However I keep the I2C DMA
single route.

I don't have the exact evidence to prove that my design is acceptable.
So if you are sure it's flawed, I will change it in the next version(V8).

Best regards,
Yuan Yao

  reply	other threads:[~2014-09-17 15:23 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-13  9:46 [PATCH v7 0/2] i2c: imx: add DMA support for freescale i2c driver Yuan Yao
2014-08-13  9:46 ` Yuan Yao
2014-08-13  9:46 ` Yuan Yao
2014-08-13  9:46 ` [PATCH v7 1/2] " Yuan Yao
2014-08-13  9:46   ` Yuan Yao
2014-08-13  9:46   ` Yuan Yao
2014-09-04  3:38   ` Yao Yuan
2014-09-04  3:38     ` Yao Yuan
2014-09-04  3:38     ` Yao Yuan
2014-09-04 14:38   ` Marek Vasut
2014-09-04 14:38     ` Marek Vasut
2014-09-05 10:32     ` Yao Yuan
2014-09-05 10:32       ` Yao Yuan
2014-09-05 10:32       ` Yao Yuan
2014-09-05 10:40       ` Marek Vasut
2014-09-05 10:40         ` Marek Vasut
2014-09-05 10:40         ` Marek Vasut
2014-09-10 14:48         ` Yao Yuan
2014-09-10 14:48           ` Yao Yuan
2014-09-10 14:48           ` Yao Yuan
2014-09-16 18:17           ` Marek Vasut
2014-09-16 18:17             ` Marek Vasut
2014-09-16 18:17             ` Marek Vasut
2014-09-17 14:50             ` Yao Yuan [this message]
2014-09-17 14:50               ` Yao Yuan
2014-09-17 14:50               ` Yao Yuan
2014-09-17 19:14               ` Marek Vasut
2014-09-17 19:14                 ` Marek Vasut
2014-09-17 19:14                 ` Marek Vasut
2014-09-18 15:46                 ` Yao Yuan
2014-09-18 15:46                   ` Yao Yuan
2014-09-18 15:46                   ` Yao Yuan
2014-09-19 12:15                   ` Marek Vasut
2014-09-19 12:15                     ` Marek Vasut
2014-09-19 12:15                     ` Marek Vasut
2014-08-13  9:46 ` [PATCH v7 2/2] Documentation:add " Yuan Yao
2014-08-13  9:46   ` Yuan Yao
2014-08-13  9:46   ` Yuan Yao
  -- strict thread matches above, loose matches on Subject: below --
2014-08-13  9:37 [PATCH v7 1/2] i2c: imx: add " Yuan Yao
2014-08-13  9:37 ` Yuan Yao
2014-08-13  9:37 ` Yuan Yao

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=1410965416759.91038@freescale.com \
    --to=yao.yuan@freescale.com \
    --cc=LW@karo-electronics.de \
    --cc=fugang.duan@freescale.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marex@denx.de \
    --cc=mark.rutland@arm.com \
    --cc=shawn.guo@linaro.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: 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.