All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Vinod Koul <vinod.koul@intel.com>, Dan Williams <djbw@fb.com>,
	linux-arm-kernel@lists.infradead.org,
	devicetree-discuss@lists.ozlabs.org,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Olof Johansson <olof@lixom.net>,
	linux-kernel@vger.kernel.org,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Vinod Koul <vinod.koul@linux.intel.com>
Subject: Re: [PATCH 2/4] dmaengine: dw_dmac: move to generic DMA binding
Date: Sat, 16 Feb 2013 13:13:01 +0200	[thread overview]
Message-ID: <CAHp75VfyO5wep-shvZ_mkwLmL2_Fa2jgq63AvE2t8=TPLZn6yg@mail.gmail.com> (raw)
In-Reply-To: <1360952512-971558-3-git-send-email-arnd@arndb.de>

On Fri, Feb 15, 2013 at 8:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The original device tree binding for this driver, from Viresh Kumar
> unfortunately conflicted with the generic DMA binding, and did not allow
> to completely seperate slave device configuration from the controller.
>
> This is an attempt to replace it with an implementation of the generic
> binding, but it is currently completely untested, because I do not have
> any hardware with this particular controller.
>
> The patch applies on top of linux-next, which contains both the base
> support for the generic DMA binding, as well as the earlier attempt from
> Viresh. Both of these are currently not merged upstream however.
>
> There are a couple of TODO items that are left remaining and are open
> for ideas from other people.

> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c

> @@ -168,7 +169,13 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
>         if (dwc->initialized == true)
>                 return;
>
> -       if (dws) {
> +       if (dws && dws->cfg_hi == 0xffffffff && dws->cfg_lo == 0xffffffff) {
> +               /* autoconfigure based on request line from DT */
> +               if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> +                       cfghi = DWC_CFGH_DST_PER(dwc->req);
> +               else if (dwc->dma_sconfig.direction == DMA_DEV_TO_MEM)
> +                       cfghi = DWC_CFGH_SRC_PER(dwc->req);

Please, use dwc->direction instead of field in the slave_config. If I
remember correctly it's marked like obsoleted/deprecated.

> @@ -1179,49 +1186,61 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
>         dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
>  }
>
> -bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
> +struct dw_dma_filter_args {
> +       struct dw_dma *dw;
> +       u32 req;

Why this is u32 and not unsigned int?

> +       u32 src;
> +       u32 dst;

And this could be also just unsigned int.

> +static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
>  {

> +       dws->cfg_hi     = 0xffffffff;
> +       dws->cfg_lo     = 0xffffffff;

Agree with Russell about ~0.

> +static struct dma_chan *dw_dma_xlate(struct of_phandle_args *dma_spec,
> +                                        struct of_dma *ofdma)
> +{
> +       struct dw_dma *dw = ofdma->of_dma_data;
> +       struct dw_dma_filter_args fargs = {
> +               .dw = dw,
> +       };
> +       dma_cap_mask_t cap;
> +
> +       if (dma_spec->args_count != 3)
> +               return NULL;
> +
> +       fargs.req = be32_to_cpup(dma_spec->args+0);
> +       fargs.src = be32_to_cpup(dma_spec->args+1);
> +       fargs.dst = be32_to_cpup(dma_spec->args+2);

You could cast them to usual C types like unsigned int. I see u32 in
rare cases in the driver like for reading/writting from/to hw and when
API contains it. Here I doubt we have to leave them as u32.

> +
> +       if (WARN_ON(fargs.req >= 16 || fargs.src >= 2 || fargs.dst >= 2))
> +               return NULL;

16 here is a magic number for me. I would like to see something like
#define DW_MAX_REQUEST_LINES 16 in the dw_dmac_regs.h.

Besides of that, what 2 does come from?

> @@ -1765,6 +1751,10 @@ static int dw_probe(struct platform_device *pdev)
>
>         dma_async_device_register(&dw->dma);
>
> +       err = of_dma_controller_register(pdev->dev.of_node, dw_dma_xlate, dw);
> +       if (err)
> +               dev_err(&pdev->dev, "could not register of_dma_controller\n");

It's not an error, dev_dbg. Consider case when !CONFIG_OF.

> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -213,6 +213,10 @@ struct dw_dma_chan {
>         /* configuration passed via DMA_SLAVE_CONFIG */
>         struct dma_slave_config dma_sconfig;
>
> +       /* slave configuration from DT */
> +       unsigned int            req;

Could you use here full name like "request_line"? And I think the
better place for it in subsection "hardware configuration" (consider
non-DT cases of use).

>         /* backlink to dw_dma */
>         struct dw_dma           *dw;
>  };

We should not have this in linux-next. Are you sure you rebased it on
top of recent one?

-- 
With Best Regards,
Andy Shevchenko

WARNING: multiple messages have this Message-ID (diff)
From: Andy Shevchenko <andy.shevchenko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Vinod Koul <vinod.koul-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Viresh Kumar
	<viresh.kumar-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Dan Williams <djbw-b10kYP2dOMg@public.gmane.org>,
	Andy Shevchenko
	<andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 2/4] dmaengine: dw_dmac: move to generic DMA binding
Date: Sat, 16 Feb 2013 13:13:01 +0200	[thread overview]
Message-ID: <CAHp75VfyO5wep-shvZ_mkwLmL2_Fa2jgq63AvE2t8=TPLZn6yg@mail.gmail.com> (raw)
In-Reply-To: <1360952512-971558-3-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>

On Fri, Feb 15, 2013 at 8:21 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> The original device tree binding for this driver, from Viresh Kumar
> unfortunately conflicted with the generic DMA binding, and did not allow
> to completely seperate slave device configuration from the controller.
>
> This is an attempt to replace it with an implementation of the generic
> binding, but it is currently completely untested, because I do not have
> any hardware with this particular controller.
>
> The patch applies on top of linux-next, which contains both the base
> support for the generic DMA binding, as well as the earlier attempt from
> Viresh. Both of these are currently not merged upstream however.
>
> There are a couple of TODO items that are left remaining and are open
> for ideas from other people.

> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c

> @@ -168,7 +169,13 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
>         if (dwc->initialized == true)
>                 return;
>
> -       if (dws) {
> +       if (dws && dws->cfg_hi == 0xffffffff && dws->cfg_lo == 0xffffffff) {
> +               /* autoconfigure based on request line from DT */
> +               if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> +                       cfghi = DWC_CFGH_DST_PER(dwc->req);
> +               else if (dwc->dma_sconfig.direction == DMA_DEV_TO_MEM)
> +                       cfghi = DWC_CFGH_SRC_PER(dwc->req);

Please, use dwc->direction instead of field in the slave_config. If I
remember correctly it's marked like obsoleted/deprecated.

> @@ -1179,49 +1186,61 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
>         dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
>  }
>
> -bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
> +struct dw_dma_filter_args {
> +       struct dw_dma *dw;
> +       u32 req;

Why this is u32 and not unsigned int?

> +       u32 src;
> +       u32 dst;

And this could be also just unsigned int.

> +static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
>  {

> +       dws->cfg_hi     = 0xffffffff;
> +       dws->cfg_lo     = 0xffffffff;

Agree with Russell about ~0.

> +static struct dma_chan *dw_dma_xlate(struct of_phandle_args *dma_spec,
> +                                        struct of_dma *ofdma)
> +{
> +       struct dw_dma *dw = ofdma->of_dma_data;
> +       struct dw_dma_filter_args fargs = {
> +               .dw = dw,
> +       };
> +       dma_cap_mask_t cap;
> +
> +       if (dma_spec->args_count != 3)
> +               return NULL;
> +
> +       fargs.req = be32_to_cpup(dma_spec->args+0);
> +       fargs.src = be32_to_cpup(dma_spec->args+1);
> +       fargs.dst = be32_to_cpup(dma_spec->args+2);

You could cast them to usual C types like unsigned int. I see u32 in
rare cases in the driver like for reading/writting from/to hw and when
API contains it. Here I doubt we have to leave them as u32.

> +
> +       if (WARN_ON(fargs.req >= 16 || fargs.src >= 2 || fargs.dst >= 2))
> +               return NULL;

16 here is a magic number for me. I would like to see something like
#define DW_MAX_REQUEST_LINES 16 in the dw_dmac_regs.h.

Besides of that, what 2 does come from?

> @@ -1765,6 +1751,10 @@ static int dw_probe(struct platform_device *pdev)
>
>         dma_async_device_register(&dw->dma);
>
> +       err = of_dma_controller_register(pdev->dev.of_node, dw_dma_xlate, dw);
> +       if (err)
> +               dev_err(&pdev->dev, "could not register of_dma_controller\n");

It's not an error, dev_dbg. Consider case when !CONFIG_OF.

> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -213,6 +213,10 @@ struct dw_dma_chan {
>         /* configuration passed via DMA_SLAVE_CONFIG */
>         struct dma_slave_config dma_sconfig;
>
> +       /* slave configuration from DT */
> +       unsigned int            req;

Could you use here full name like "request_line"? And I think the
better place for it in subsection "hardware configuration" (consider
non-DT cases of use).

>         /* backlink to dw_dma */
>         struct dw_dma           *dw;
>  };

We should not have this in linux-next. Are you sure you rebased it on
top of recent one?

-- 
With Best Regards,
Andy Shevchenko

WARNING: multiple messages have this Message-ID (diff)
From: andy.shevchenko@gmail.com (Andy Shevchenko)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/4] dmaengine: dw_dmac: move to generic DMA binding
Date: Sat, 16 Feb 2013 13:13:01 +0200	[thread overview]
Message-ID: <CAHp75VfyO5wep-shvZ_mkwLmL2_Fa2jgq63AvE2t8=TPLZn6yg@mail.gmail.com> (raw)
In-Reply-To: <1360952512-971558-3-git-send-email-arnd@arndb.de>

On Fri, Feb 15, 2013 at 8:21 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> The original device tree binding for this driver, from Viresh Kumar
> unfortunately conflicted with the generic DMA binding, and did not allow
> to completely seperate slave device configuration from the controller.
>
> This is an attempt to replace it with an implementation of the generic
> binding, but it is currently completely untested, because I do not have
> any hardware with this particular controller.
>
> The patch applies on top of linux-next, which contains both the base
> support for the generic DMA binding, as well as the earlier attempt from
> Viresh. Both of these are currently not merged upstream however.
>
> There are a couple of TODO items that are left remaining and are open
> for ideas from other people.

> --- a/drivers/dma/dw_dmac.c
> +++ b/drivers/dma/dw_dmac.c

> @@ -168,7 +169,13 @@ static void dwc_initialize(struct dw_dma_chan *dwc)
>         if (dwc->initialized == true)
>                 return;
>
> -       if (dws) {
> +       if (dws && dws->cfg_hi == 0xffffffff && dws->cfg_lo == 0xffffffff) {
> +               /* autoconfigure based on request line from DT */
> +               if (dwc->dma_sconfig.direction == DMA_MEM_TO_DEV)
> +                       cfghi = DWC_CFGH_DST_PER(dwc->req);
> +               else if (dwc->dma_sconfig.direction == DMA_DEV_TO_MEM)
> +                       cfghi = DWC_CFGH_SRC_PER(dwc->req);

Please, use dwc->direction instead of field in the slave_config. If I
remember correctly it's marked like obsoleted/deprecated.

> @@ -1179,49 +1186,61 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
>         dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
>  }
>
> -bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
> +struct dw_dma_filter_args {
> +       struct dw_dma *dw;
> +       u32 req;

Why this is u32 and not unsigned int?

> +       u32 src;
> +       u32 dst;

And this could be also just unsigned int.

> +static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
>  {

> +       dws->cfg_hi     = 0xffffffff;
> +       dws->cfg_lo     = 0xffffffff;

Agree with Russell about ~0.

> +static struct dma_chan *dw_dma_xlate(struct of_phandle_args *dma_spec,
> +                                        struct of_dma *ofdma)
> +{
> +       struct dw_dma *dw = ofdma->of_dma_data;
> +       struct dw_dma_filter_args fargs = {
> +               .dw = dw,
> +       };
> +       dma_cap_mask_t cap;
> +
> +       if (dma_spec->args_count != 3)
> +               return NULL;
> +
> +       fargs.req = be32_to_cpup(dma_spec->args+0);
> +       fargs.src = be32_to_cpup(dma_spec->args+1);
> +       fargs.dst = be32_to_cpup(dma_spec->args+2);

You could cast them to usual C types like unsigned int. I see u32 in
rare cases in the driver like for reading/writting from/to hw and when
API contains it. Here I doubt we have to leave them as u32.

> +
> +       if (WARN_ON(fargs.req >= 16 || fargs.src >= 2 || fargs.dst >= 2))
> +               return NULL;

16 here is a magic number for me. I would like to see something like
#define DW_MAX_REQUEST_LINES 16 in the dw_dmac_regs.h.

Besides of that, what 2 does come from?

> @@ -1765,6 +1751,10 @@ static int dw_probe(struct platform_device *pdev)
>
>         dma_async_device_register(&dw->dma);
>
> +       err = of_dma_controller_register(pdev->dev.of_node, dw_dma_xlate, dw);
> +       if (err)
> +               dev_err(&pdev->dev, "could not register of_dma_controller\n");

It's not an error, dev_dbg. Consider case when !CONFIG_OF.

> --- a/drivers/dma/dw_dmac_regs.h
> +++ b/drivers/dma/dw_dmac_regs.h
> @@ -213,6 +213,10 @@ struct dw_dma_chan {
>         /* configuration passed via DMA_SLAVE_CONFIG */
>         struct dma_slave_config dma_sconfig;
>
> +       /* slave configuration from DT */
> +       unsigned int            req;

Could you use here full name like "request_line"? And I think the
better place for it in subsection "hardware configuration" (consider
non-DT cases of use).

>         /* backlink to dw_dma */
>         struct dw_dma           *dw;
>  };

We should not have this in linux-next. Are you sure you rebased it on
top of recent one?

-- 
With Best Regards,
Andy Shevchenko

  parent reply	other threads:[~2013-02-16 11:13 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-15 18:21 [PATCH 0/4] dw_dmac: introduce generic DMA binding for DT Arnd Bergmann
2013-02-15 18:21 ` Arnd Bergmann
2013-02-15 18:21 ` [PATCH 1/4] Revert "ARM: SPEAr13xx: Pass DW DMAC platform data from DT" Arnd Bergmann
2013-02-15 18:21   ` Arnd Bergmann
2013-02-15 18:21 ` [PATCH 2/4] dmaengine: dw_dmac: move to generic DMA binding Arnd Bergmann
2013-02-15 18:21   ` Arnd Bergmann
2013-02-15 18:21   ` Arnd Bergmann
2013-02-16  3:26   ` Viresh Kumar
2013-02-16  3:26     ` Viresh Kumar
2013-02-16 10:07     ` Arnd Bergmann
2013-02-16 10:07       ` Arnd Bergmann
2013-02-16 10:07       ` Arnd Bergmann
2013-02-16 10:51       ` Russell King - ARM Linux
2013-02-16 10:51         ` Russell King - ARM Linux
2013-02-16 10:51         ` Russell King - ARM Linux
2013-02-16 13:43         ` Arnd Bergmann
2013-02-16 13:43           ` Arnd Bergmann
2013-02-16 11:13   ` Andy Shevchenko [this message]
2013-02-16 11:13     ` Andy Shevchenko
2013-02-16 11:13     ` Andy Shevchenko
2013-02-16 14:00     ` Arnd Bergmann
2013-02-16 14:00       ` Arnd Bergmann
2013-02-16 14:00       ` Arnd Bergmann
2013-02-16 14:53       ` Andy Shevchenko
2013-02-16 14:53         ` Andy Shevchenko
2013-02-16 22:21         ` [PATCHv3 " Arnd Bergmann
2013-02-16 22:21           ` Arnd Bergmann
2013-02-16 22:21           ` Arnd Bergmann
2013-02-16 22:54           ` Andy Shevchenko
2013-02-16 22:54             ` Andy Shevchenko
2013-02-16 23:24             ` [PATCHv4 " Arnd Bergmann
2013-02-16 23:24               ` Arnd Bergmann
2013-02-16 23:24               ` Arnd Bergmann
2013-02-16 23:28             ` [PATCHv3 " Arnd Bergmann
2013-02-16 23:28               ` Arnd Bergmann
2013-02-16 22:23         ` [BONUS PATCH] dmaengine: dw_dmac: simplify master selection Arnd Bergmann
2013-02-16 22:23           ` Arnd Bergmann
2013-02-15 18:21 ` [PATCH 3/4] spi: pl022: use generic DMA slave configuration if possible Arnd Bergmann
2013-02-15 18:21   ` Arnd Bergmann
2013-02-15 18:21 ` [PATCH 4/4] serial: pl011: " Arnd Bergmann
2013-02-15 18:21   ` Arnd Bergmann
2013-02-16  3:26 ` [PATCH 0/4] dw_dmac: introduce generic DMA binding for DT Viresh Kumar
2013-02-16  3:26   ` Viresh Kumar
2013-02-16  3:26   ` Viresh Kumar
2013-02-20  8:03 ` Vinod Koul
2013-02-20  8:03   ` Vinod Koul
2013-02-20  9:50   ` Arnd Bergmann
2013-02-20  9:50     ` Arnd Bergmann
2013-02-20  9:50     ` Arnd Bergmann
2013-02-20  9:58     ` Vinod Koul
2013-02-20  9:58       ` Vinod Koul
2013-02-20 11:10       ` Arnd Bergmann
2013-02-20 11:10         ` Arnd Bergmann

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='CAHp75VfyO5wep-shvZ_mkwLmL2_Fa2jgq63AvE2t8=TPLZn6yg@mail.gmail.com' \
    --to=andy.shevchenko@gmail.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=djbw@fb.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=vinod.koul@intel.com \
    --cc=vinod.koul@linux.intel.com \
    --cc=viresh.kumar@linaro.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.