All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vinod Koul <vinod.koul@intel.com>
To: Pierre Yves MORDRET <pierre-yves.mordret@st.com>
Cc: Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	Russell King <linux@armlinux.org.uk>,
	Dan Williams <dan.j.williams@intel.com>,
	"M'boumba Cedric Madianga" <cedric.madianga@gmail.com>,
	Fabrice GASNIER <fabrice.gasnier@st.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Fabien DESSENNE <fabien.dessenne@st.com>,
	Amelie DELAUNAY <amelie.delaunay@st.com>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver
Date: Fri, 21 Jul 2017 22:47:35 +0530	[thread overview]
Message-ID: <20170721171735.GS3053@localhost> (raw)
In-Reply-To: <3c04c9bf-572d-98a6-ff62-83498bbc7fdf@st.com>

On Fri, Jul 21, 2017 at 10:32:49AM +0000, Pierre Yves MORDRET wrote:
> >>>> +static int stm32_mdma_set_xfer_param(struct stm32_mdma_chan *chan,
> >>>> +				     enum dma_transfer_direction direction,
> >>>> +				     u32 *mdma_ccr, u32 *mdma_ctcr,
> >>>> +				     u32 *mdma_ctbr, u32 buf_len)
> >>>> +{
> >>>> +	struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
> >>>> +	struct stm32_mdma_chan_config *chan_config = &chan->chan_config;
> >>>> +	enum dma_slave_buswidth src_addr_width, dst_addr_width;
> >>>> +	phys_addr_t src_addr, dst_addr;
> >>>> +	int src_bus_width, dst_bus_width;
> >>>> +	u32 src_maxburst, dst_maxburst, src_best_burst, dst_best_burst;
> >>>> +	u32 ccr, ctcr, ctbr, tlen;
> >>>> +
> >>>> +	src_addr_width = chan->dma_config.src_addr_width;
> >>>> +	dst_addr_width = chan->dma_config.dst_addr_width;
> >>>> +	src_maxburst = chan->dma_config.src_maxburst;
> >>>> +	dst_maxburst = chan->dma_config.dst_maxburst;
> >>>> +	src_addr = chan->dma_config.src_addr;
> >>>> +	dst_addr = chan->dma_config.dst_addr;
> >>>
> >>> this doesn't seem right to me, only the periphral address would come from
> >>> slave_config, the memory address is passed as an arg to transfer..
> >>>
> >>> ...
> >>>
> >>
> >> Correct. But these locals are managed in the case statement below. if direction
> >> is Mem2Dev only dst_addr(Peripheral) is considered. In the other way around with
> >> Dev2Mem direction only src_addr(Peripheral) is considered.
> >> However to disambiguate I can move src_addr & dst_addr affectation in the
> >> corresponding case statement if you'd like.
> > 
> > But below you are over writing both, so in effect this is wasted cycles..
> > anyway latter one is more clear, so lets remove from here.
> > 
> 
> Sorry I don't follow ... or miss something
> For instance if direction is Mem2Dev ..._xfer_param is going to configure 
> Destination Bus width and Addr given by slave_config. ..._setup_xfer in its turn 
> will configure source given as parameter.
> Don't the see the over-writing

ah re-looking at it, yes you are right.

The above two assignments threw me off, I should have read it properly.

But I think calculating for src and dstn always might not be optimal as you
would use one only, so should these be moved to respective case where they
are used...

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: Pierre Yves MORDRET <pierre-yves.mordret@st.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Amelie DELAUNAY <amelie.delaunay@st.com>,
	Alexandre TORGUE <alexandre.torgue@st.com>,
	Russell King <linux@armlinux.org.uk>,
	Fabien DESSENNE <fabien.dessenne@st.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dmaengine@vger.kernel.org" <dmaengine@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	M'boumba Cedric Madianga <cedric.madianga@gmail.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Fabrice GASNIER <fabrice.gasnier@st.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver
Date: Fri, 21 Jul 2017 22:47:35 +0530	[thread overview]
Message-ID: <20170721171735.GS3053@localhost> (raw)
In-Reply-To: <3c04c9bf-572d-98a6-ff62-83498bbc7fdf@st.com>

On Fri, Jul 21, 2017 at 10:32:49AM +0000, Pierre Yves MORDRET wrote:
> >>>> +static int stm32_mdma_set_xfer_param(struct stm32_mdma_chan *chan,
> >>>> +				     enum dma_transfer_direction direction,
> >>>> +				     u32 *mdma_ccr, u32 *mdma_ctcr,
> >>>> +				     u32 *mdma_ctbr, u32 buf_len)
> >>>> +{
> >>>> +	struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
> >>>> +	struct stm32_mdma_chan_config *chan_config = &chan->chan_config;
> >>>> +	enum dma_slave_buswidth src_addr_width, dst_addr_width;
> >>>> +	phys_addr_t src_addr, dst_addr;
> >>>> +	int src_bus_width, dst_bus_width;
> >>>> +	u32 src_maxburst, dst_maxburst, src_best_burst, dst_best_burst;
> >>>> +	u32 ccr, ctcr, ctbr, tlen;
> >>>> +
> >>>> +	src_addr_width = chan->dma_config.src_addr_width;
> >>>> +	dst_addr_width = chan->dma_config.dst_addr_width;
> >>>> +	src_maxburst = chan->dma_config.src_maxburst;
> >>>> +	dst_maxburst = chan->dma_config.dst_maxburst;
> >>>> +	src_addr = chan->dma_config.src_addr;
> >>>> +	dst_addr = chan->dma_config.dst_addr;
> >>>
> >>> this doesn't seem right to me, only the periphral address would come from
> >>> slave_config, the memory address is passed as an arg to transfer..
> >>>
> >>> ...
> >>>
> >>
> >> Correct. But these locals are managed in the case statement below. if direction
> >> is Mem2Dev only dst_addr(Peripheral) is considered. In the other way around with
> >> Dev2Mem direction only src_addr(Peripheral) is considered.
> >> However to disambiguate I can move src_addr & dst_addr affectation in the
> >> corresponding case statement if you'd like.
> > 
> > But below you are over writing both, so in effect this is wasted cycles..
> > anyway latter one is more clear, so lets remove from here.
> > 
> 
> Sorry I don't follow ... or miss something
> For instance if direction is Mem2Dev ..._xfer_param is going to configure 
> Destination Bus width and Addr given by slave_config. ..._setup_xfer in its turn 
> will configure source given as parameter.
> Don't the see the over-writing

ah re-looking at it, yes you are right.

The above two assignments threw me off, I should have read it properly.

But I think calculating for src and dstn always might not be optimal as you
would use one only, so should these be moved to respective case where they
are used...

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: vinod.koul@intel.com (Vinod Koul)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver
Date: Fri, 21 Jul 2017 22:47:35 +0530	[thread overview]
Message-ID: <20170721171735.GS3053@localhost> (raw)
In-Reply-To: <3c04c9bf-572d-98a6-ff62-83498bbc7fdf@st.com>

On Fri, Jul 21, 2017 at 10:32:49AM +0000, Pierre Yves MORDRET wrote:
> >>>> +static int stm32_mdma_set_xfer_param(struct stm32_mdma_chan *chan,
> >>>> +				     enum dma_transfer_direction direction,
> >>>> +				     u32 *mdma_ccr, u32 *mdma_ctcr,
> >>>> +				     u32 *mdma_ctbr, u32 buf_len)
> >>>> +{
> >>>> +	struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
> >>>> +	struct stm32_mdma_chan_config *chan_config = &chan->chan_config;
> >>>> +	enum dma_slave_buswidth src_addr_width, dst_addr_width;
> >>>> +	phys_addr_t src_addr, dst_addr;
> >>>> +	int src_bus_width, dst_bus_width;
> >>>> +	u32 src_maxburst, dst_maxburst, src_best_burst, dst_best_burst;
> >>>> +	u32 ccr, ctcr, ctbr, tlen;
> >>>> +
> >>>> +	src_addr_width = chan->dma_config.src_addr_width;
> >>>> +	dst_addr_width = chan->dma_config.dst_addr_width;
> >>>> +	src_maxburst = chan->dma_config.src_maxburst;
> >>>> +	dst_maxburst = chan->dma_config.dst_maxburst;
> >>>> +	src_addr = chan->dma_config.src_addr;
> >>>> +	dst_addr = chan->dma_config.dst_addr;
> >>>
> >>> this doesn't seem right to me, only the periphral address would come from
> >>> slave_config, the memory address is passed as an arg to transfer..
> >>>
> >>> ...
> >>>
> >>
> >> Correct. But these locals are managed in the case statement below. if direction
> >> is Mem2Dev only dst_addr(Peripheral) is considered. In the other way around with
> >> Dev2Mem direction only src_addr(Peripheral) is considered.
> >> However to disambiguate I can move src_addr & dst_addr affectation in the
> >> corresponding case statement if you'd like.
> > 
> > But below you are over writing both, so in effect this is wasted cycles..
> > anyway latter one is more clear, so lets remove from here.
> > 
> 
> Sorry I don't follow ... or miss something
> For instance if direction is Mem2Dev ..._xfer_param is going to configure 
> Destination Bus width and Addr given by slave_config. ..._setup_xfer in its turn 
> will configure source given as parameter.
> Don't the see the over-writing

ah re-looking at it, yes you are right.

The above two assignments threw me off, I should have read it properly.

But I think calculating for src and dstn always might not be optimal as you
would use one only, so should these be moved to respective case where they
are used...

-- 
~Vinod

  reply	other threads:[~2017-07-21 17:15 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-06 12:25 [PATCH v2 0/4] Add STM32 MDMA driver Pierre-Yves MORDRET
2017-07-06 12:25 ` Pierre-Yves MORDRET
2017-07-06 12:25 ` Pierre-Yves MORDRET
2017-07-06 12:25 ` [PATCH v2 1/4] dt-bindings: Document the STM32 MDMA bindings Pierre-Yves MORDRET
2017-07-06 12:25   ` Pierre-Yves MORDRET
2017-07-06 12:25   ` Pierre-Yves MORDRET
2017-07-10 13:20   ` Rob Herring
2017-07-10 13:20     ` Rob Herring
2017-07-10 13:20     ` Rob Herring
2017-07-06 12:25 ` [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver Pierre-Yves MORDRET
2017-07-06 12:25   ` Pierre-Yves MORDRET
2017-07-06 12:25   ` Pierre-Yves MORDRET
2017-07-21  7:55   ` Vinod Koul
2017-07-21  7:55     ` Vinod Koul
2017-07-21  9:30     ` Pierre Yves MORDRET
2017-07-21  9:30       ` Pierre Yves MORDRET
2017-07-21  9:30       ` Pierre Yves MORDRET
2017-07-21  9:54       ` Vinod Koul
2017-07-21  9:54         ` Vinod Koul
2017-07-21  9:54         ` Vinod Koul
2017-07-21 10:32         ` Pierre Yves MORDRET
2017-07-21 10:32           ` Pierre Yves MORDRET
2017-07-21 10:32           ` Pierre Yves MORDRET
2017-07-21 17:17           ` Vinod Koul [this message]
2017-07-21 17:17             ` Vinod Koul
2017-07-21 17:17             ` Vinod Koul
2017-07-24  9:34             ` Pierre Yves MORDRET
2017-07-24  9:34               ` Pierre Yves MORDRET
2017-07-24  9:34               ` Pierre Yves MORDRET
2017-07-26  5:00               ` Vinod Koul
2017-07-26  5:00                 ` Vinod Koul
2017-07-26  5:00                 ` Vinod Koul
2017-07-06 12:25 ` [PATCH v2 3/4] ARM: dts: stm32: Add MDMA support for STM32H743 SoC Pierre-Yves MORDRET
2017-07-06 12:25   ` Pierre-Yves MORDRET
2017-07-06 12:25   ` Pierre-Yves MORDRET
2017-07-06 12:25 ` [PATCH v2 4/4] ARM: configs: stm32: Add MDMA support in STM32 defconfig Pierre-Yves MORDRET
2017-07-06 12:25   ` Pierre-Yves MORDRET
2017-07-06 12:25   ` Pierre-Yves MORDRET
2017-07-20  9:37 ` [PATCH v2 0/4] Add STM32 MDMA driver Pierre Yves MORDRET
2017-07-20  9:37   ` Pierre Yves MORDRET
2017-07-20  9:37   ` Pierre Yves MORDRET
2017-07-21  6:36   ` Vinod Koul
2017-07-21  6:36     ` Vinod Koul
2017-07-21  6:36     ` Vinod Koul

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=20170721171735.GS3053@localhost \
    --to=vinod.koul@intel.com \
    --cc=alexandre.torgue@st.com \
    --cc=amelie.delaunay@st.com \
    --cc=cedric.madianga@gmail.com \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dmaengine@vger.kernel.org \
    --cc=fabien.dessenne@st.com \
    --cc=fabrice.gasnier@st.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=pierre-yves.mordret@st.com \
    --cc=robh+dt@kernel.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.