All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Vinod Koul <vinod.koul@intel.com>,
	"andriy.shevchenko@intel.com" <andriy.shevchenko@intel.com>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"zhuzhenhua@allwinnertech.com" <zhuzhenhua@allwinnertech.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"linux-sunxi@googlegroups.com" <linux-sunxi@googlegroups.com>,
	"kevin.z.m.zh@gmail.com" <kevin.z.m.zh@gmail.com>,
	"sunny@allwinnertech.com" <sunny@allwinnertech.com>,
	"shuge@allwinnertech.com" <shuge@allwinnertech.com>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v10 2/2] dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller
Date: Tue, 1 Jul 2014 13:48:52 +0100	[thread overview]
Message-ID: <20140701124852.GB6064@leverpostej> (raw)
In-Reply-To: <20140701072119.GH28647@lukather>

On Tue, Jul 01, 2014 at 08:21:19AM +0100, Maxime Ripard wrote:
> On Mon, Jun 30, 2014 at 04:33:05PM +0100, Mark Rutland wrote:
> > On Mon, Jun 30, 2014 at 04:19:06PM +0100, Maxime Ripard wrote:
> > > On Mon, Jun 30, 2014 at 03:20:54PM +0100, Mark Rutland wrote:
> > > > Hi Maxime,
> > > > 
> > > > On Mon, Jun 30, 2014 at 02:20:54PM +0100, Maxime Ripard wrote:
> > > > > The Allwinner A31 has a 16 channels DMA controller that it shares with the
> > > > > newer A23. Although sharing some similarities with the DMA controller of the
> > > > > older Allwinner SoCs, it's significantly different, I don't expect it to be
> > > > > possible to share the driver for these two.
> > > > >
> > > > > The A31 Controller is able to memory-to-memory or memory-to-device transfers on
> > > > > the 16 channels in parallel.
> > > > >
> > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > > > ---
> > > > >  drivers/dma/Kconfig     |    8 +
> > > > >  drivers/dma/Makefile    |    1 +
> > > > >  drivers/dma/sun6i-dma.c | 1058 +++++++++++++++++++++++++++++++++++++++++++++++
> > > > >  3 files changed, 1067 insertions(+)
> > > > >  create mode 100644 drivers/dma/sun6i-dma.c
> > > > 
> > > > [...]
> > > > 
> > > > > +       sdc->clk = devm_clk_get(&pdev->dev, NULL);
> > > > > +       if (IS_ERR(sdc->clk)) {
> > > > > +               dev_err(&pdev->dev, "No clock specified\n");
> > > > > +               return PTR_ERR(sdc->clk);
> > > > > +       }
> > > > > +
> > > > > +       mux = clk_get(NULL, "ahb1_mux");
> > > > > +       if (IS_ERR(mux)) {
> > > > > +               dev_err(&pdev->dev, "Couldn't get AHB1 Mux\n");
> > > > > +               return PTR_ERR(mux);
> > > > > +       }
> > > > > +
> > > > > +       pll6 = clk_get(NULL, "pll6");
> > > > > +       if (IS_ERR(pll6)) {
> > > > > +               dev_err(&pdev->dev, "Couldn't get PLL6\n");
> > > > > +               clk_put(mux);
> > > > > +               return PTR_ERR(pll6);
> > > > > +       }
> > > > 
> > > > I'm slightly confused. The binding listed a single unnamed clock (the
> > > > AHB clock). What is going on here?
> > > 
> > > The device itself needs only a single clock to work...
> > > 
> > > > 
> > > > > +       ret = clk_set_parent(mux, pll6);
> > > > > +       clk_put(pll6);
> > > > > +       clk_put(mux);
> > > > > +
> > > > > +       if (ret) {
> > > > > +               dev_err(&pdev->dev, "Couldn't reparent AHB1 on PLL6\n");
> > > > > +               return ret;
> > > > > +       }
> > > > 
> > > > Why do we need to reparent the mux?
> > > 
> > > ... but will function only if this clock is derived from PLL6.
> > 
> > Ok, but _why_ is that the case? Could we at least have a comment for
> > that?
> 
> I have no idea, sorry.

Oh no :(

Where did this requirement turn up? Did an issue crop up in testing and
using PLL6 just happened to work, or does some manual somewhere say that
the device must have its clock derived from PLL6 without further
explanation?

Does PLL6 drive some other clock that the DMA clock needs to stay in
sync with, possibly?

> > Where does the driver get the named clocks from if they aren't provided
> > on the device node? Is there a clock-ranges somewhere?
> 
> No, it just looks up the global clock name.

Ok.

> > It feels a little fragile to rely on the organisation of the clock tree
> > and the naming thereof. If the IP block is ever reused on an SoC with a
> > different clock tree layout then we have to handle things differently.
> 
> What do you suggest then?

I will admit that I don't have a better suggestion.

Without knowing which particular constraint on the mux parent clock we
care about it's difficult to suggest anything useful.

Mark.

WARNING: multiple messages have this Message-ID (diff)
From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v10 2/2] dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller
Date: Tue, 1 Jul 2014 13:48:52 +0100	[thread overview]
Message-ID: <20140701124852.GB6064@leverpostej> (raw)
In-Reply-To: <20140701072119.GH28647@lukather>

On Tue, Jul 01, 2014 at 08:21:19AM +0100, Maxime Ripard wrote:
> On Mon, Jun 30, 2014 at 04:33:05PM +0100, Mark Rutland wrote:
> > On Mon, Jun 30, 2014 at 04:19:06PM +0100, Maxime Ripard wrote:
> > > On Mon, Jun 30, 2014 at 03:20:54PM +0100, Mark Rutland wrote:
> > > > Hi Maxime,
> > > > 
> > > > On Mon, Jun 30, 2014 at 02:20:54PM +0100, Maxime Ripard wrote:
> > > > > The Allwinner A31 has a 16 channels DMA controller that it shares with the
> > > > > newer A23. Although sharing some similarities with the DMA controller of the
> > > > > older Allwinner SoCs, it's significantly different, I don't expect it to be
> > > > > possible to share the driver for these two.
> > > > >
> > > > > The A31 Controller is able to memory-to-memory or memory-to-device transfers on
> > > > > the 16 channels in parallel.
> > > > >
> > > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > > > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > > > ---
> > > > >  drivers/dma/Kconfig     |    8 +
> > > > >  drivers/dma/Makefile    |    1 +
> > > > >  drivers/dma/sun6i-dma.c | 1058 +++++++++++++++++++++++++++++++++++++++++++++++
> > > > >  3 files changed, 1067 insertions(+)
> > > > >  create mode 100644 drivers/dma/sun6i-dma.c
> > > > 
> > > > [...]
> > > > 
> > > > > +       sdc->clk = devm_clk_get(&pdev->dev, NULL);
> > > > > +       if (IS_ERR(sdc->clk)) {
> > > > > +               dev_err(&pdev->dev, "No clock specified\n");
> > > > > +               return PTR_ERR(sdc->clk);
> > > > > +       }
> > > > > +
> > > > > +       mux = clk_get(NULL, "ahb1_mux");
> > > > > +       if (IS_ERR(mux)) {
> > > > > +               dev_err(&pdev->dev, "Couldn't get AHB1 Mux\n");
> > > > > +               return PTR_ERR(mux);
> > > > > +       }
> > > > > +
> > > > > +       pll6 = clk_get(NULL, "pll6");
> > > > > +       if (IS_ERR(pll6)) {
> > > > > +               dev_err(&pdev->dev, "Couldn't get PLL6\n");
> > > > > +               clk_put(mux);
> > > > > +               return PTR_ERR(pll6);
> > > > > +       }
> > > > 
> > > > I'm slightly confused. The binding listed a single unnamed clock (the
> > > > AHB clock). What is going on here?
> > > 
> > > The device itself needs only a single clock to work...
> > > 
> > > > 
> > > > > +       ret = clk_set_parent(mux, pll6);
> > > > > +       clk_put(pll6);
> > > > > +       clk_put(mux);
> > > > > +
> > > > > +       if (ret) {
> > > > > +               dev_err(&pdev->dev, "Couldn't reparent AHB1 on PLL6\n");
> > > > > +               return ret;
> > > > > +       }
> > > > 
> > > > Why do we need to reparent the mux?
> > > 
> > > ... but will function only if this clock is derived from PLL6.
> > 
> > Ok, but _why_ is that the case? Could we at least have a comment for
> > that?
> 
> I have no idea, sorry.

Oh no :(

Where did this requirement turn up? Did an issue crop up in testing and
using PLL6 just happened to work, or does some manual somewhere say that
the device must have its clock derived from PLL6 without further
explanation?

Does PLL6 drive some other clock that the DMA clock needs to stay in
sync with, possibly?

> > Where does the driver get the named clocks from if they aren't provided
> > on the device node? Is there a clock-ranges somewhere?
> 
> No, it just looks up the global clock name.

Ok.

> > It feels a little fragile to rely on the organisation of the clock tree
> > and the naming thereof. If the IP block is ever reused on an SoC with a
> > different clock tree layout then we have to handle things differently.
> 
> What do you suggest then?

I will admit that I don't have a better suggestion.

Without knowing which particular constraint on the mux parent clock we
care about it's difficult to suggest anything useful.

Mark.

  reply	other threads:[~2014-07-01 12:49 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-30 13:20 [PATCH v10 0/2] Add support for the Allwinner A31 DMA Controller Maxime Ripard
2014-06-30 13:20 ` Maxime Ripard
2014-06-30 13:20 ` [PATCH v10 1/2] Documentation: dt: Add Allwinner A31 DMA controller bindings Maxime Ripard
2014-06-30 13:20   ` Maxime Ripard
2014-06-30 13:20 ` [PATCH v10 2/2] dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller Maxime Ripard
2014-06-30 13:20   ` Maxime Ripard
2014-06-30 14:20   ` Mark Rutland
2014-06-30 14:20     ` Mark Rutland
2014-06-30 15:19     ` Maxime Ripard
2014-06-30 15:19       ` Maxime Ripard
2014-06-30 15:33       ` Mark Rutland
2014-06-30 15:33         ` Mark Rutland
2014-07-01  7:21         ` Maxime Ripard
2014-07-01  7:21           ` Maxime Ripard
2014-07-01 12:48           ` Mark Rutland [this message]
2014-07-01 12:48             ` Mark Rutland
2014-07-04  7:57             ` Maxime Ripard
2014-07-04  7:57               ` Maxime Ripard
2014-07-06 15:22               ` Arnd Bergmann
2014-07-06 15:22                 ` Arnd Bergmann
2014-07-07 12:41                 ` Maxime Ripard
2014-07-07 12:41                   ` Maxime Ripard
2014-07-27 18:49             ` Mark Brown
2014-07-27 18:49               ` Mark Brown
2014-07-28 15:09               ` Maxime Ripard
2014-07-28 15:09                 ` Maxime Ripard
2014-07-29 12:05                 ` Mark Brown
2014-07-29 12:05                   ` Mark Brown
2014-07-06  3:23   ` [linux-sunxi] " Emilio López
2014-07-06  3:23     ` Emilio López

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=20140701124852.GB6064@leverpostej \
    --to=mark.rutland@arm.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=arnd@arndb.de \
    --cc=dan.j.williams@intel.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=kevin.z.m.zh@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=shuge@allwinnertech.com \
    --cc=sunny@allwinnertech.com \
    --cc=vinod.koul@intel.com \
    --cc=zhuzhenhua@allwinnertech.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.