All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"Heiko Stübner" <heiko@sntech.de>,
	"Padmavathi Venna" <padma.v@samsung.com>,
	"Takashi Iwai" <tiwai@suse.de>,
	"Alessandro Rubini" <rubini@gnudd.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Giancarlo Asnaghi" <giancarlo.asnaghi@st.com>,
	"Kukjin Kim" <kgene.kim@samsung.com>,
	"Russell King - ARM Linux" <linux@arm.linux.org.uk>,
	"Vinod Koul" <vinod.koul@intel.com>,
	"Thomas Abraham" <thomas.abraham@linaro.org>,
	"Grant Likely" <grant.likely@linaro.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	"Sylwester Nawrocki" <sylvester.nawrocki@gmail.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Sangbeom Kim" <sbkim73@samsung.com>,
	"Liam Girdwood" <lgirdwood@gmail.com>,
	linux-spi@vger.kernel.org, "Mark Brown" <broonie@kernel.org>
Subject: Re: [RFC PATCH v2 03/12] dmaengine: PL08x: Rework LLI handling to be less fragile
Date: Thu, 27 Jun 2013 00:04:23 +0200	[thread overview]
Message-ID: <2212577.G2ANCYONVo@flatron> (raw)
In-Reply-To: <CACRpkdYm7gFVLzRpQ2J97M+-zQAug_ftJhyi_kniTgCk=GT_bQ@mail.gmail.com>

On Tuesday 25 of June 2013 00:23:09 Linus Walleij wrote:
> On Sat, Jun 22, 2013 at 10:42 PM, Tomasz Figa <tomasz.figa@gmail.com> 
wrote:
> > +enum {
> > +       PL080_LLI_SRC,
> > +       PL080_LLI_DST,
> > +       PL080_LLI_LLI,
> > +       PL080_LLI_CCTL,
> > +
> > +       PL080_LLI_WORDS
> > +};
> 
> I usually don't like it when enums are not given names, and are
> implicitly cast to integers.
> 
> I think it'd be better to just use #define for these so we know what
> is going on.

OK. I didn't have any preference for one or the other way and I randomly 
chose to use enum, but since you seem to have one (and hard to disagree 
with), I will change this patch to use #define.

> > @@ -181,7 +177,7 @@ struct pl08x_txd {
> > 
> >         struct virt_dma_desc vd;
> >         struct list_head dsg_list;
> >         dma_addr_t llis_bus;
> > 
> > -       struct pl08x_lli *llis_va;
> > +       u32 *llis_va;
> 
> It's nice that you use the u32 * here for proper indexing into an
> array.
> 
> > -/* Size (bytes) of each LLI buffer allocated for one transfer */
> > -# define PL08X_LLI_TSFR_SIZE   0x2000
> > -
> > -/* Maximum times we call dma_pool_alloc on this pool without freeing
> > */ -#define MAX_NUM_TSFR_LLIS      (PL08X_LLI_TSFR_SIZE/sizeof(struct
> > pl08x_lli)) +/*
> > + * Number of LLIs in each LLI buffer allocated for one transfer
> > + * (maximum times we call dma_pool_alloc on this pool without
> > freeing)
> > + */
> > +#define MAX_NUM_TSFR_LLIS      512
> 
> And I like this nice side effect that we allocate a number of LLIs
> rather than a fixed-size buffer.

As we're at it, is there any reason to choose this particular number of 
LLis? I have calculated it from the buffer size defined originally, but I 
wonder if 512 LLIs for single transfer isn't too much?

> > +static void pl08x_write_lli(struct pl08x_driver_data *pl08x,
> > +               struct pl08x_phy_chan *phychan, const u32 *lli, u32
> > ccfg) +{
> > +       dev_vdbg(&pl08x->adev->dev,
> > +               "WRITE channel %d: csrc=0x%08x, cdst=0x%08x, "
> > +               "clli=0x%08x, cctl=0x%08x, ccfg=0x%08x\n",
> > +               phychan->id, lli[PL080_LLI_SRC], lli[PL080_LLI_DST],
> > +               lli[PL080_LLI_LLI], lli[PL080_LLI_CCTL], ccfg);
> > +
> > +       writel(lli[PL080_LLI_SRC], phychan->base + PL080_CH_SRC_ADDR);
> > +       writel(lli[PL080_LLI_DST], phychan->base + PL080_CH_DST_ADDR);
> > +       writel(lli[PL080_LLI_LLI], phychan->base + PL080_CH_LLI);
> > +       writel(lli[PL080_LLI_CCTL], phychan->base + PL080_CH_CONTROL);
> > +
> > +       writel(ccfg, phychan->reg_config);
> 
> Take this opportunity to replace the first four writel() with
> writel_relaxed(), keep the last one to make sure all hit the hardware.

OK.

> Apart from that this looks nice!

Thanks.

Best regards,
Tomasz

WARNING: multiple messages have this Message-ID (diff)
From: tomasz.figa@gmail.com (Tomasz Figa)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2 03/12] dmaengine: PL08x: Rework LLI handling to be less fragile
Date: Thu, 27 Jun 2013 00:04:23 +0200	[thread overview]
Message-ID: <2212577.G2ANCYONVo@flatron> (raw)
In-Reply-To: <CACRpkdYm7gFVLzRpQ2J97M+-zQAug_ftJhyi_kniTgCk=GT_bQ@mail.gmail.com>

On Tuesday 25 of June 2013 00:23:09 Linus Walleij wrote:
> On Sat, Jun 22, 2013 at 10:42 PM, Tomasz Figa <tomasz.figa@gmail.com> 
wrote:
> > +enum {
> > +       PL080_LLI_SRC,
> > +       PL080_LLI_DST,
> > +       PL080_LLI_LLI,
> > +       PL080_LLI_CCTL,
> > +
> > +       PL080_LLI_WORDS
> > +};
> 
> I usually don't like it when enums are not given names, and are
> implicitly cast to integers.
> 
> I think it'd be better to just use #define for these so we know what
> is going on.

OK. I didn't have any preference for one or the other way and I randomly 
chose to use enum, but since you seem to have one (and hard to disagree 
with), I will change this patch to use #define.

> > @@ -181,7 +177,7 @@ struct pl08x_txd {
> > 
> >         struct virt_dma_desc vd;
> >         struct list_head dsg_list;
> >         dma_addr_t llis_bus;
> > 
> > -       struct pl08x_lli *llis_va;
> > +       u32 *llis_va;
> 
> It's nice that you use the u32 * here for proper indexing into an
> array.
> 
> > -/* Size (bytes) of each LLI buffer allocated for one transfer */
> > -# define PL08X_LLI_TSFR_SIZE   0x2000
> > -
> > -/* Maximum times we call dma_pool_alloc on this pool without freeing
> > */ -#define MAX_NUM_TSFR_LLIS      (PL08X_LLI_TSFR_SIZE/sizeof(struct
> > pl08x_lli)) +/*
> > + * Number of LLIs in each LLI buffer allocated for one transfer
> > + * (maximum times we call dma_pool_alloc on this pool without
> > freeing)
> > + */
> > +#define MAX_NUM_TSFR_LLIS      512
> 
> And I like this nice side effect that we allocate a number of LLIs
> rather than a fixed-size buffer.

As we're at it, is there any reason to choose this particular number of 
LLis? I have calculated it from the buffer size defined originally, but I 
wonder if 512 LLIs for single transfer isn't too much?

> > +static void pl08x_write_lli(struct pl08x_driver_data *pl08x,
> > +               struct pl08x_phy_chan *phychan, const u32 *lli, u32
> > ccfg) +{
> > +       dev_vdbg(&pl08x->adev->dev,
> > +               "WRITE channel %d: csrc=0x%08x, cdst=0x%08x, "
> > +               "clli=0x%08x, cctl=0x%08x, ccfg=0x%08x\n",
> > +               phychan->id, lli[PL080_LLI_SRC], lli[PL080_LLI_DST],
> > +               lli[PL080_LLI_LLI], lli[PL080_LLI_CCTL], ccfg);
> > +
> > +       writel(lli[PL080_LLI_SRC], phychan->base + PL080_CH_SRC_ADDR);
> > +       writel(lli[PL080_LLI_DST], phychan->base + PL080_CH_DST_ADDR);
> > +       writel(lli[PL080_LLI_LLI], phychan->base + PL080_CH_LLI);
> > +       writel(lli[PL080_LLI_CCTL], phychan->base + PL080_CH_CONTROL);
> > +
> > +       writel(ccfg, phychan->reg_config);
> 
> Take this opportunity to replace the first four writel() with
> writel_relaxed(), keep the last one to make sure all hit the hardware.

OK.

> Apart from that this looks nice!

Thanks.

Best regards,
Tomasz

  reply	other threads:[~2013-06-26 22:04 UTC|newest]

Thread overview: 87+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-22 20:42 [RFC PATCH v2 00/12] ARM: s3c64xx: Let amba-pl08x driver handle DMA Tomasz Figa
2013-06-22 20:42 ` Tomasz Figa
2013-06-22 20:42 ` Tomasz Figa
2013-06-22 20:42 ` [RFC PATCH v2 01/12] dmaengine: PL08x: Refactor pl08x_getbytes_chan() to lower indentation Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:09   ` Linus Walleij
2013-06-24 22:09     ` Linus Walleij
2013-06-25 15:16   ` Vinod Koul
2013-06-25 15:16     ` Vinod Koul
2013-06-25 15:16     ` Vinod Koul
2013-06-25 18:30     ` Russell King - ARM Linux
2013-06-25 18:30       ` Russell King - ARM Linux
2013-06-25 18:30       ` Russell King - ARM Linux
2013-06-22 20:42 ` [RFC PATCH v2 02/12] dmaengine: PL08x: Add support for different offset of CONFIG register Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:11   ` Linus Walleij
2013-06-24 22:11     ` Linus Walleij
2013-06-25 15:34   ` Vinod Koul
2013-06-25 15:34     ` Vinod Koul
2013-06-25 15:34     ` Vinod Koul
2013-06-22 20:42 ` [RFC PATCH v2 03/12] dmaengine: PL08x: Rework LLI handling to be less fragile Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:23   ` Linus Walleij
2013-06-24 22:23     ` Linus Walleij
2013-06-26 22:04     ` Tomasz Figa [this message]
2013-06-26 22:04       ` Tomasz Figa
2013-06-27  9:31       ` Linus Walleij
2013-06-27  9:31         ` Linus Walleij
2013-06-22 20:42 ` [RFC PATCH v2 04/12] dmaengine: PL08x: Add support for PL080S variant Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:26   ` Linus Walleij
2013-06-24 22:26     ` Linus Walleij
2013-06-22 20:42 ` [RFC PATCH v2 05/12] dmaengine: PL08x: Add support for different maximum transfer size Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:27   ` Linus Walleij
2013-06-24 22:27     ` Linus Walleij
2013-06-25 16:10   ` Vinod Koul
2013-06-25 16:10     ` Vinod Koul
2013-06-25 16:10     ` Vinod Koul
2013-06-22 20:42 ` [RFC PATCH v2 06/12] dmaengine: PL08x: Fix reading the byte count in cctl Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:28   ` Linus Walleij
2013-06-24 22:28     ` Linus Walleij
2013-06-22 20:42 ` [RFC PATCH v2 07/12] dmaengine: PL08x: Add cyclic transfer support Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:33   ` Linus Walleij
2013-06-24 22:33     ` Linus Walleij
2013-06-22 20:42 ` [RFC PATCH v2 08/12] ASoC: Samsung: Do not queue cyclic buffers multiple times Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:35   ` Linus Walleij
2013-06-24 22:35     ` Linus Walleij
2013-06-22 20:42 ` [RFC PATCH v2 09/12] clk: samsung: s3c64xx: Add aliases for DMA clocks Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-24 22:38   ` Linus Walleij
2013-06-24 22:38     ` Linus Walleij
2013-06-25  5:30     ` Tomasz Figa
2013-06-25  5:30       ` Tomasz Figa
2013-06-22 20:42 ` [RFC PATCH v2 10/12] spi: s3c64xx: Do not require legacy DMA API in case of S3C64XX Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42 ` [RFC PATCH v2 11/12] ASoC: Samsung: " Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42 ` [RFC PATCH v2 12/12] ARM: s3c64xx: Add support for DMA using generic amba-pl08x driver Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-22 20:42   ` Tomasz Figa
2013-06-25 10:28 ` [RFC PATCH v2 00/12] ARM: s3c64xx: Let amba-pl08x driver handle DMA Mark Brown
2013-06-25 10:28   ` Mark Brown
2013-06-25 10:28   ` Mark Brown
2013-06-25 11:22   ` Tomasz Figa
2013-06-25 11:22     ` Tomasz Figa
2013-06-25 11:22     ` Tomasz Figa
2013-06-25 15:38     ` Mark Brown
2013-06-25 15:38       ` Mark Brown
2013-06-25 15:38       ` Mark Brown
2013-06-25 15:44       ` Tomasz Figa
2013-06-25 15:44         ` Tomasz Figa
2013-06-25 15:44         ` Tomasz Figa

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=2212577.G2ANCYONVo@flatron \
    --to=tomasz.figa@gmail.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=arnd@arndb.de \
    --cc=broonie@kernel.org \
    --cc=giancarlo.asnaghi@st.com \
    --cc=grant.likely@linaro.org \
    --cc=heiko@sntech.de \
    --cc=kgene.kim@samsung.com \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=padma.v@samsung.com \
    --cc=rubini@gnudd.com \
    --cc=sbkim73@samsung.com \
    --cc=sylvester.nawrocki@gmail.com \
    --cc=thomas.abraham@linaro.org \
    --cc=tiwai@suse.de \
    --cc=vinod.koul@intel.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.