From: Marek Vasut <marex-ynQEQJNshbs@public.gmane.org>
To: Yao Yuan <yao.yuan-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
Cc: "linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
"wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org"
<wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
"mark.rutland-5wv7dgnIgG8@public.gmane.org"
<mark.rutland-5wv7dgnIgG8@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-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH 1/3] i2c: add DMA support for freescale i2c driver
Date: Fri, 28 Feb 2014 10:04:10 +0100 [thread overview]
Message-ID: <201402281004.10238.marex@denx.de> (raw)
In-Reply-To: <3f58a8abdda74100b4f7b14d0c31c90e-AZ66ij2kwaZYLYlmg7qx2OO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
On Friday, February 28, 2014 at 06:19:18 AM, Yao Yuan wrote:
[...]
> > > @@ -213,6 +238,7 @@ static struct imx_i2c_hwdata vf610_i2c_hwdata = {
> > >
> > > .ndivs = ARRAY_SIZE(vf610_i2c_clk_div),
> > > .i2sr_clr_opcode = I2SR_CLR_OPCODE_W1C,
> > > .i2cr_ien_opcode = I2CR_IEN_OPCODE_0,
> > >
> > > + .has_dma_support = true,
> >
> > So why exactly don't we have a DT prop for determining whether the
> > controller has DMA support ?
> >
> > What about the other controllers, do they not support DMA for some
> > specific reason? Please elaborate on that, thank you !
>
> Sorry for my fault. I will modify it.
I would prefer if you could explain why other controllers do have DMA disabled
even if the hardware does support the DMA operation.
> > [...]
> >
> > > +static void i2c_imx_dma_tx_callback(void *arg)
> >
> > [...]
> >
> > > +static int i2c_imx_dma_tx(struct imx_i2c_struct *i2c_imx, struct
> > > +i2c_msg
> > > *msgs) +{
> >
> > [...]
> >
> > > +static void i2c_imx_dma_rx_callback(void *arg)
> >
> > [...]
> >
> > > +static int i2c_imx_dma_rx(struct imx_i2c_struct *i2c_imx, struct
> > > +i2c_msg
> > > *msgs) +{
> >
> > [...]
> >
> > Looks like there's quite a bit of code duplication in the four functions
> > above, can you not unify them ?
>
> Yes, There's looks like quite a bit of code duplication in the four
> functions above. I also hate quite a bit of code duplication.
> But there are many differences in fact.
> If unify them we should add many conditional statements and auxiliary
> variable. I think it's superfluous and will damage the readability.
> So, I am very confused. And if you think unify them will be better I will
> modify it. Thanks for your suggestion and looking forward to hearing from
> you.
I'd say try it, the RX and TX callback look almost the same. So does the
i2c_imx_dma_rx() and i2c_imx_dma_tx() .
> > Also, can the DMA not do full-duplex operation ? What I see here is just
> > half- duplex operations , one for RX and the other one for TX .
>
> Yes, here have two dma channels, one for RX and the other one for TX.
> When we request the channel we should determine it for TX or RX.
Sorry, I don't quite understand this. If you have two DMA channels, can you not
use them both to do full-duplex SPI transfer ?
> > > +static void i2c_imx_dma_free(struct imx_i2c_struct *i2c_imx) {
> > > + struct imx_i2c_dma *dma = i2c_imx->dma;
> > > + struct dma_chan *dma_chan;
> > > +
> > > + dma_chan = dma->chan_tx;
> > > + dma->chan_tx = NULL;
> > > + dma->buf_tx = 0;
> > > + dma->len_tx = 0;
> > > + dma_release_channel(dma_chan);
> > > +
> > > + dma_chan = dma->chan_rx;
> > > + dma->chan_tx = NULL;
> > > + dma->buf_rx = 0;
> > > + dma->len_rx = 0;
> > > + dma_release_channel(dma_chan);
> >
> > You must make _DEAD_ _SURE_ this function is not ever called while the
> > DMA is still active. In your case, I have a feeling that's not handled.
>
> I think this function will not called while the DMA is still
> active because of the Linux synchronization mechanism - completion.
> I used it in the dma function.
This doesn't check whether the completion is actually finished anywhere. I don't
quite understand how this is safe .
[...]
> > > +static int i2c_imx_dma_read(struct imx_i2c_struct *i2c_imx,
> > > + struct i2c_msg *msgs)
> > > +{
> >
> > Looks like almost an duplication as well...
>
> Considering the symmetric with them i2c_imx_dma_write.
> i2c_imx_dma_write and i2c_imx_pio_write have many differences. So I
> separate them. But i2c_imx_dma_read and i2c_imx_pio_read is the same at
> first part. I may should unify them. But it's will not symmetric with them
> i2c_imx_dma_write if unified them. So I don't know which will be better?
> Looking forward to hearing from you.
The dma_read() looks almost like dma_write(), so I'd also try merging them
together.
> > Besides, full-duplex DMA operation is missing, please explain why.
> >
> > THanks!
WARNING: multiple messages have this Message-ID (diff)
From: marex@denx.de (Marek Vasut)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/3] i2c: add DMA support for freescale i2c driver
Date: Fri, 28 Feb 2014 10:04:10 +0100 [thread overview]
Message-ID: <201402281004.10238.marex@denx.de> (raw)
In-Reply-To: <3f58a8abdda74100b4f7b14d0c31c90e@BL2PR03MB338.namprd03.prod.outlook.com>
On Friday, February 28, 2014 at 06:19:18 AM, Yao Yuan wrote:
[...]
> > > @@ -213,6 +238,7 @@ static struct imx_i2c_hwdata vf610_i2c_hwdata = {
> > >
> > > .ndivs = ARRAY_SIZE(vf610_i2c_clk_div),
> > > .i2sr_clr_opcode = I2SR_CLR_OPCODE_W1C,
> > > .i2cr_ien_opcode = I2CR_IEN_OPCODE_0,
> > >
> > > + .has_dma_support = true,
> >
> > So why exactly don't we have a DT prop for determining whether the
> > controller has DMA support ?
> >
> > What about the other controllers, do they not support DMA for some
> > specific reason? Please elaborate on that, thank you !
>
> Sorry for my fault. I will modify it.
I would prefer if you could explain why other controllers do have DMA disabled
even if the hardware does support the DMA operation.
> > [...]
> >
> > > +static void i2c_imx_dma_tx_callback(void *arg)
> >
> > [...]
> >
> > > +static int i2c_imx_dma_tx(struct imx_i2c_struct *i2c_imx, struct
> > > +i2c_msg
> > > *msgs) +{
> >
> > [...]
> >
> > > +static void i2c_imx_dma_rx_callback(void *arg)
> >
> > [...]
> >
> > > +static int i2c_imx_dma_rx(struct imx_i2c_struct *i2c_imx, struct
> > > +i2c_msg
> > > *msgs) +{
> >
> > [...]
> >
> > Looks like there's quite a bit of code duplication in the four functions
> > above, can you not unify them ?
>
> Yes, There's looks like quite a bit of code duplication in the four
> functions above. I also hate quite a bit of code duplication.
> But there are many differences in fact.
> If unify them we should add many conditional statements and auxiliary
> variable. I think it's superfluous and will damage the readability.
> So, I am very confused. And if you think unify them will be better I will
> modify it. Thanks for your suggestion and looking forward to hearing from
> you.
I'd say try it, the RX and TX callback look almost the same. So does the
i2c_imx_dma_rx() and i2c_imx_dma_tx() .
> > Also, can the DMA not do full-duplex operation ? What I see here is just
> > half- duplex operations , one for RX and the other one for TX .
>
> Yes, here have two dma channels, one for RX and the other one for TX.
> When we request the channel we should determine it for TX or RX.
Sorry, I don't quite understand this. If you have two DMA channels, can you not
use them both to do full-duplex SPI transfer ?
> > > +static void i2c_imx_dma_free(struct imx_i2c_struct *i2c_imx) {
> > > + struct imx_i2c_dma *dma = i2c_imx->dma;
> > > + struct dma_chan *dma_chan;
> > > +
> > > + dma_chan = dma->chan_tx;
> > > + dma->chan_tx = NULL;
> > > + dma->buf_tx = 0;
> > > + dma->len_tx = 0;
> > > + dma_release_channel(dma_chan);
> > > +
> > > + dma_chan = dma->chan_rx;
> > > + dma->chan_tx = NULL;
> > > + dma->buf_rx = 0;
> > > + dma->len_rx = 0;
> > > + dma_release_channel(dma_chan);
> >
> > You must make _DEAD_ _SURE_ this function is not ever called while the
> > DMA is still active. In your case, I have a feeling that's not handled.
>
> I think this function will not called while the DMA is still
> active because of the Linux synchronization mechanism - completion.
> I used it in the dma function.
This doesn't check whether the completion is actually finished anywhere. I don't
quite understand how this is safe .
[...]
> > > +static int i2c_imx_dma_read(struct imx_i2c_struct *i2c_imx,
> > > + struct i2c_msg *msgs)
> > > +{
> >
> > Looks like almost an duplication as well...
>
> Considering the symmetric with them i2c_imx_dma_write.
> i2c_imx_dma_write and i2c_imx_pio_write have many differences. So I
> separate them. But i2c_imx_dma_read and i2c_imx_pio_read is the same at
> first part. I may should unify them. But it's will not symmetric with them
> i2c_imx_dma_write if unified them. So I don't know which will be better?
> Looking forward to hearing from you.
The dma_read() looks almost like dma_write(), so I'd also try merging them
together.
> > Besides, full-duplex DMA operation is missing, please explain why.
> >
> > THanks!
WARNING: multiple messages have this Message-ID (diff)
From: Marek Vasut <marex@denx.de>
To: Yao Yuan <yao.yuan@freescale.com>
Cc: "linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"wsa@the-dreams.de" <wsa@the-dreams.de>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"shawn.guo@linaro.org" <shawn.guo@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>
Subject: Re: [PATCH 1/3] i2c: add DMA support for freescale i2c driver
Date: Fri, 28 Feb 2014 10:04:10 +0100 [thread overview]
Message-ID: <201402281004.10238.marex@denx.de> (raw)
In-Reply-To: <3f58a8abdda74100b4f7b14d0c31c90e@BL2PR03MB338.namprd03.prod.outlook.com>
On Friday, February 28, 2014 at 06:19:18 AM, Yao Yuan wrote:
[...]
> > > @@ -213,6 +238,7 @@ static struct imx_i2c_hwdata vf610_i2c_hwdata = {
> > >
> > > .ndivs = ARRAY_SIZE(vf610_i2c_clk_div),
> > > .i2sr_clr_opcode = I2SR_CLR_OPCODE_W1C,
> > > .i2cr_ien_opcode = I2CR_IEN_OPCODE_0,
> > >
> > > + .has_dma_support = true,
> >
> > So why exactly don't we have a DT prop for determining whether the
> > controller has DMA support ?
> >
> > What about the other controllers, do they not support DMA for some
> > specific reason? Please elaborate on that, thank you !
>
> Sorry for my fault. I will modify it.
I would prefer if you could explain why other controllers do have DMA disabled
even if the hardware does support the DMA operation.
> > [...]
> >
> > > +static void i2c_imx_dma_tx_callback(void *arg)
> >
> > [...]
> >
> > > +static int i2c_imx_dma_tx(struct imx_i2c_struct *i2c_imx, struct
> > > +i2c_msg
> > > *msgs) +{
> >
> > [...]
> >
> > > +static void i2c_imx_dma_rx_callback(void *arg)
> >
> > [...]
> >
> > > +static int i2c_imx_dma_rx(struct imx_i2c_struct *i2c_imx, struct
> > > +i2c_msg
> > > *msgs) +{
> >
> > [...]
> >
> > Looks like there's quite a bit of code duplication in the four functions
> > above, can you not unify them ?
>
> Yes, There's looks like quite a bit of code duplication in the four
> functions above. I also hate quite a bit of code duplication.
> But there are many differences in fact.
> If unify them we should add many conditional statements and auxiliary
> variable. I think it's superfluous and will damage the readability.
> So, I am very confused. And if you think unify them will be better I will
> modify it. Thanks for your suggestion and looking forward to hearing from
> you.
I'd say try it, the RX and TX callback look almost the same. So does the
i2c_imx_dma_rx() and i2c_imx_dma_tx() .
> > Also, can the DMA not do full-duplex operation ? What I see here is just
> > half- duplex operations , one for RX and the other one for TX .
>
> Yes, here have two dma channels, one for RX and the other one for TX.
> When we request the channel we should determine it for TX or RX.
Sorry, I don't quite understand this. If you have two DMA channels, can you not
use them both to do full-duplex SPI transfer ?
> > > +static void i2c_imx_dma_free(struct imx_i2c_struct *i2c_imx) {
> > > + struct imx_i2c_dma *dma = i2c_imx->dma;
> > > + struct dma_chan *dma_chan;
> > > +
> > > + dma_chan = dma->chan_tx;
> > > + dma->chan_tx = NULL;
> > > + dma->buf_tx = 0;
> > > + dma->len_tx = 0;
> > > + dma_release_channel(dma_chan);
> > > +
> > > + dma_chan = dma->chan_rx;
> > > + dma->chan_tx = NULL;
> > > + dma->buf_rx = 0;
> > > + dma->len_rx = 0;
> > > + dma_release_channel(dma_chan);
> >
> > You must make _DEAD_ _SURE_ this function is not ever called while the
> > DMA is still active. In your case, I have a feeling that's not handled.
>
> I think this function will not called while the DMA is still
> active because of the Linux synchronization mechanism - completion.
> I used it in the dma function.
This doesn't check whether the completion is actually finished anywhere. I don't
quite understand how this is safe .
[...]
> > > +static int i2c_imx_dma_read(struct imx_i2c_struct *i2c_imx,
> > > + struct i2c_msg *msgs)
> > > +{
> >
> > Looks like almost an duplication as well...
>
> Considering the symmetric with them i2c_imx_dma_write.
> i2c_imx_dma_write and i2c_imx_pio_write have many differences. So I
> separate them. But i2c_imx_dma_read and i2c_imx_pio_read is the same at
> first part. I may should unify them. But it's will not symmetric with them
> i2c_imx_dma_write if unified them. So I don't know which will be better?
> Looking forward to hearing from you.
The dma_read() looks almost like dma_write(), so I'd also try merging them
together.
> > Besides, full-duplex DMA operation is missing, please explain why.
> >
> > THanks!
next prev parent reply other threads:[~2014-02-28 9:04 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-27 6:05 [PATCH 0/3] i2c: add DMA support for freescale i2c driver Yuan Yao
2014-02-27 6:05 ` Yuan Yao
2014-02-27 6:05 ` Yuan Yao
[not found] ` <1393481115-22136-1-git-send-email-yao.yuan-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2014-02-27 6:05 ` [PATCH 1/3] " Yuan Yao
2014-02-27 6:05 ` Yuan Yao
2014-02-27 6:05 ` Yuan Yao
[not found] ` <1393481115-22136-2-git-send-email-yao.yuan-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
2014-02-27 12:55 ` Shawn Guo
2014-02-27 12:55 ` Shawn Guo
2014-02-27 12:55 ` Shawn Guo
2014-02-27 13:21 ` Shawn Guo
2014-02-27 13:21 ` Shawn Guo
2014-02-27 13:21 ` Shawn Guo
2014-02-27 20:39 ` Marek Vasut
2014-02-27 20:39 ` Marek Vasut
2014-02-27 20:39 ` Marek Vasut
2014-02-28 2:13 ` Shawn Guo
2014-02-28 2:13 ` Shawn Guo
2014-02-28 2:13 ` Shawn Guo
[not found] ` <20140228021300.GJ13537-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2014-02-28 2:23 ` Shawn Guo
2014-02-28 2:23 ` Shawn Guo
2014-02-28 2:23 ` Shawn Guo
2014-02-28 8:57 ` Marek Vasut
2014-02-28 8:57 ` Marek Vasut
2014-02-28 5:19 ` Yao Yuan
2014-02-28 5:19 ` Yao Yuan
2014-02-28 5:19 ` Yao Yuan
[not found] ` <3f58a8abdda74100b4f7b14d0c31c90e-AZ66ij2kwaZYLYlmg7qx2OO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-02-28 9:04 ` Marek Vasut [this message]
2014-02-28 9:04 ` Marek Vasut
2014-02-28 9:04 ` Marek Vasut
[not found] ` <201402281004.10238.marex-ynQEQJNshbs@public.gmane.org>
2014-02-28 10:59 ` Lothar Waßmann
2014-02-28 10:59 ` Lothar Waßmann
2014-02-28 10:59 ` Lothar Waßmann
[not found] ` <20140228115925.5fe07693-VjFSrY7JcPWvSplVBqRQBQ@public.gmane.org>
2014-02-28 12:00 ` Marek Vasut
2014-02-28 12:00 ` Marek Vasut
2014-02-28 12:00 ` Marek Vasut
2014-02-28 11:36 ` Yao Yuan
2014-02-28 11:36 ` Yao Yuan
2014-02-28 11:36 ` Yao Yuan
2014-02-28 12:03 ` Marek Vasut
2014-02-28 12:03 ` Marek Vasut
2014-03-03 10:23 ` Yao Yuan
2014-03-03 10:23 ` Yao Yuan
2014-03-03 10:23 ` Yao Yuan
[not found] ` <3bbad0af0bc74f04bc386b141dadedb3-AZ66ij2kwaZYLYlmg7qx2OO6mTEJWrR4XA4E9RH9d+qIuWR1G4zioA@public.gmane.org>
2014-03-03 11:14 ` Marek Vasut
2014-03-03 11:14 ` Marek Vasut
2014-03-03 11:14 ` Marek Vasut
2014-02-27 6:05 ` [PATCH 3/3] Documentation:add " Yuan Yao
2014-02-27 6:05 ` Yuan Yao
2014-02-27 6:05 ` 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=201402281004.10238.marex@denx.de \
--to=marex-ynqeqjnshbs@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org \
--cc=yao.yuan-KZfg59tc24xl57MIdRCFDg@public.gmane.org \
/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.