From: Marek Vasut <marex@denx.de>
To: Yao Yuan <yao.yuan@freescale.com>
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 21:14:36 +0200 [thread overview]
Message-ID: <201409172114.36617.marex@denx.de> (raw)
In-Reply-To: <1410965416759.91038@freescale.com>
On Wednesday, September 17, 2014 at 04:50:34 PM, Yao Yuan wrote:
[...]
> > > > 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.
So the I2C block is in error state until you clean it up upon next transmission?
> 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).
I'm just trying to understand it.
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Yao Yuan <yao.yuan-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: "wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org"
<wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
"LW-AvR2QvxeiV7DiMYJYoSAnRvVK+yQ3ZXh@public.gmane.org"
<LW-AvR2QvxeiV7DiMYJYoSAnRvVK+yQ3ZXh@public.gmane.org>,
"mark.rutland-5wv7dgnIgG8@public.gmane.org"
<mark.rutland-5wv7dgnIgG8@public.gmane.org>,
"fugang.duan-KZfg59tc24xl57MIdRCFDg@public.gmane.org"
<fugang.duan-KZfg59tc24xl57MIdRCFDg@public.gmane.org>,
"shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org"
<shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v7 1/2] i2c: imx: add DMA support for freescale i2c driver
Date: Wed, 17 Sep 2014 21:14:36 +0200 [thread overview]
Message-ID: <201409172114.36617.marex@denx.de> (raw)
In-Reply-To: <1410965416759.91038-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
On Wednesday, September 17, 2014 at 04:50:34 PM, Yao Yuan wrote:
[...]
> > > > 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.
So the I2C block is in error state until you clean it up upon next transmission?
> 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).
I'm just trying to understand it.
Best regards,
Marek Vasut
WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
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 21:14:36 +0200 [thread overview]
Message-ID: <201409172114.36617.marex@denx.de> (raw)
In-Reply-To: <1410965416759.91038@freescale.com>
On Wednesday, September 17, 2014 at 04:50:34 PM, Yao Yuan wrote:
[...]
> > > > 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.
So the I2C block is in error state until you clean it up upon next transmission?
> 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).
I'm just trying to understand it.
Best regards,
Marek Vasut
next prev parent reply other threads:[~2014-09-17 19:14 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
2014-09-17 14:50 ` Yao Yuan
2014-09-17 14:50 ` Yao Yuan
2014-09-17 19:14 ` Marek Vasut [this message]
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=201409172114.36617.marex@denx.de \
--to=marex@denx.de \
--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=mark.rutland@arm.com \
--cc=shawn.guo@linaro.org \
--cc=wsa@the-dreams.de \
--cc=yao.yuan@freescale.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.