All of lore.kernel.org
 help / color / mirror / Atom feed
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 13:25:47 +0530	[thread overview]
Message-ID: <20170721075547.GO3053@localhost> (raw)
In-Reply-To: <1499343941-6375-3-git-send-email-pierre-yves.mordret@st.com>

On Thu, Jul 06, 2017 at 02:25:39PM +0200, Pierre-Yves MORDRET wrote:

> +config STM32_MDMA
> +	bool "STMicroelectronics STM32 master dma support"
> +	depends on ARCH_STM32  || COMPILE_TEST
			    ^^^
why multiple spaces

> +static enum dma_slave_buswidth stm32_mdma_get_max_width(u32 buf_len, u32 tlen)
> +{
> +	enum dma_slave_buswidth max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
> +
> +	while (((buf_len % max_width) || (tlen < max_width)) &&
> +	       (max_width > DMA_SLAVE_BUSWIDTH_1_BYTE))
> +		max_width = max_width >> 1;

ok, this is a bit hard to read...

> +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..

...

> +static int stm32_mdma_setup_xfer(struct stm32_mdma_chan *chan,
> +				 struct stm32_mdma_desc *desc,
> +				 struct scatterlist *sgl, u32 sg_len,
> +				 enum dma_transfer_direction direction)
> +{
> +	struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
> +	struct dma_slave_config *dma_config = &chan->dma_config;
> +	struct scatterlist *sg;
> +	dma_addr_t src_addr, dst_addr;
> +	u32 ccr, ctcr, ctbr;
> +	int i, ret = 0;
> +
> +	for_each_sg(sgl, sg, sg_len, i) {
> +		if (sg_dma_len(sg) > STM32_MDMA_MAX_BLOCK_LEN) {
> +			dev_err(chan2dev(chan), "Invalid block len\n");
> +			return -EINVAL;
> +		}
> +
> +		ret = stm32_mdma_set_xfer_param(chan, direction, &ccr, &ctcr,
> +						&ctbr, sg_dma_len(sg));
> +		if (ret < 0)
> +			return ret;
> +
> +		if (direction == DMA_MEM_TO_DEV) {
> +			src_addr = sg_dma_address(sg);
> +			dst_addr = dma_config->dst_addr;

and this seems correct, but then why are we doing it in
stm32_mdma_set_xfer_param()

> +static struct dma_async_tx_descriptor *stm32_mdma_prep_slave_sg(
> +	struct dma_chan *c, struct scatterlist *sgl,
> +	u32 sg_len, enum dma_transfer_direction direction,
> +	unsigned long flags, void *context)

right justfied these please, it makes a terrible read

> +{
> +	struct stm32_mdma_chan *chan = to_stm32_mdma_chan(c);
> +	struct stm32_mdma_desc *desc;
> +	int ret;
> +
> +	desc = stm32_mdma_alloc_desc(chan, sg_len);
> +	if (!desc)
> +		return NULL;
> +
> +	ret = stm32_mdma_setup_xfer(chan, desc, sgl, sg_len, direction);
> +	if (ret < 0)
> +		goto xfer_setup_err;
> +
> +	desc->cyclic = false;
> +
> +	return vchan_tx_prep(&chan->vchan, &desc->vdesc, flags);
> +
> +xfer_setup_err:
> +	dma_pool_free(chan->desc_pool, &desc->hwdesc, desc->hwdesc_phys);
> +	kfree(desc);
> +	return NULL;
> +}
> +
> +static struct dma_async_tx_descriptor *stm32_mdma_prep_dma_cyclic(
> +	struct dma_chan *c, dma_addr_t buf_addr, size_t buf_len,
> +	size_t period_len, enum dma_transfer_direction direction,
> +	unsigned long flags)

here too and few other places

> +static int stm32_mdma_probe(struct platform_device *pdev)
> +{
> +	struct stm32_mdma_chan *chan;
> +	struct stm32_mdma_device *dmadev;
> +	struct dma_device *dd;
> +	struct device_node *of_node;
> +	struct resource *res;
> +	u32 nr_channels, nr_requests;
> +	int i, count, ret;
> +
> +	of_node = pdev->dev.of_node;
> +	if (!of_node)
> +		return -ENODEV;
> +
> +	ret = of_property_read_u32(of_node, "dma-channels", &nr_channels);
> +	if (ret)
> +		nr_channels = STM32_MDMA_MAX_CHANNELS;
> +
> +	ret = of_property_read_u32(of_node, "dma-requests", &nr_requests);
> +	if (ret)
> +		nr_requests = STM32_MDMA_MAX_REQUESTS;

wouldn't it make sense to print error about these properties not being
present and continuing w/ defaults..?

and can we have device_property_xxx instead of of_ variants?

> +static int __init stm32_mdma_init(void)
> +{
> +	return platform_driver_probe(&stm32_mdma_driver, stm32_mdma_probe);
> +}
> +
> +subsys_initcall(stm32_mdma_init);

Where are the MODULE_xx tags, license is mandatory. You should add author
too.
 

-- 
~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: 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, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/4] dmaengine: Add STM32 MDMA driver
Date: Fri, 21 Jul 2017 13:25:47 +0530	[thread overview]
Message-ID: <20170721075547.GO3053@localhost> (raw)
In-Reply-To: <1499343941-6375-3-git-send-email-pierre-yves.mordret@st.com>

On Thu, Jul 06, 2017 at 02:25:39PM +0200, Pierre-Yves MORDRET wrote:

> +config STM32_MDMA
> +	bool "STMicroelectronics STM32 master dma support"
> +	depends on ARCH_STM32  || COMPILE_TEST
			    ^^^
why multiple spaces

> +static enum dma_slave_buswidth stm32_mdma_get_max_width(u32 buf_len, u32 tlen)
> +{
> +	enum dma_slave_buswidth max_width = DMA_SLAVE_BUSWIDTH_8_BYTES;
> +
> +	while (((buf_len % max_width) || (tlen < max_width)) &&
> +	       (max_width > DMA_SLAVE_BUSWIDTH_1_BYTE))
> +		max_width = max_width >> 1;

ok, this is a bit hard to read...

> +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..

...

> +static int stm32_mdma_setup_xfer(struct stm32_mdma_chan *chan,
> +				 struct stm32_mdma_desc *desc,
> +				 struct scatterlist *sgl, u32 sg_len,
> +				 enum dma_transfer_direction direction)
> +{
> +	struct stm32_mdma_device *dmadev = stm32_mdma_get_dev(chan);
> +	struct dma_slave_config *dma_config = &chan->dma_config;
> +	struct scatterlist *sg;
> +	dma_addr_t src_addr, dst_addr;
> +	u32 ccr, ctcr, ctbr;
> +	int i, ret = 0;
> +
> +	for_each_sg(sgl, sg, sg_len, i) {
> +		if (sg_dma_len(sg) > STM32_MDMA_MAX_BLOCK_LEN) {
> +			dev_err(chan2dev(chan), "Invalid block len\n");
> +			return -EINVAL;
> +		}
> +
> +		ret = stm32_mdma_set_xfer_param(chan, direction, &ccr, &ctcr,
> +						&ctbr, sg_dma_len(sg));
> +		if (ret < 0)
> +			return ret;
> +
> +		if (direction == DMA_MEM_TO_DEV) {
> +			src_addr = sg_dma_address(sg);
> +			dst_addr = dma_config->dst_addr;

and this seems correct, but then why are we doing it in
stm32_mdma_set_xfer_param()

> +static struct dma_async_tx_descriptor *stm32_mdma_prep_slave_sg(
> +	struct dma_chan *c, struct scatterlist *sgl,
> +	u32 sg_len, enum dma_transfer_direction direction,
> +	unsigned long flags, void *context)

right justfied these please, it makes a terrible read

> +{
> +	struct stm32_mdma_chan *chan = to_stm32_mdma_chan(c);
> +	struct stm32_mdma_desc *desc;
> +	int ret;
> +
> +	desc = stm32_mdma_alloc_desc(chan, sg_len);
> +	if (!desc)
> +		return NULL;
> +
> +	ret = stm32_mdma_setup_xfer(chan, desc, sgl, sg_len, direction);
> +	if (ret < 0)
> +		goto xfer_setup_err;
> +
> +	desc->cyclic = false;
> +
> +	return vchan_tx_prep(&chan->vchan, &desc->vdesc, flags);
> +
> +xfer_setup_err:
> +	dma_pool_free(chan->desc_pool, &desc->hwdesc, desc->hwdesc_phys);
> +	kfree(desc);
> +	return NULL;
> +}
> +
> +static struct dma_async_tx_descriptor *stm32_mdma_prep_dma_cyclic(
> +	struct dma_chan *c, dma_addr_t buf_addr, size_t buf_len,
> +	size_t period_len, enum dma_transfer_direction direction,
> +	unsigned long flags)

here too and few other places

> +static int stm32_mdma_probe(struct platform_device *pdev)
> +{
> +	struct stm32_mdma_chan *chan;
> +	struct stm32_mdma_device *dmadev;
> +	struct dma_device *dd;
> +	struct device_node *of_node;
> +	struct resource *res;
> +	u32 nr_channels, nr_requests;
> +	int i, count, ret;
> +
> +	of_node = pdev->dev.of_node;
> +	if (!of_node)
> +		return -ENODEV;
> +
> +	ret = of_property_read_u32(of_node, "dma-channels", &nr_channels);
> +	if (ret)
> +		nr_channels = STM32_MDMA_MAX_CHANNELS;
> +
> +	ret = of_property_read_u32(of_node, "dma-requests", &nr_requests);
> +	if (ret)
> +		nr_requests = STM32_MDMA_MAX_REQUESTS;

wouldn't it make sense to print error about these properties not being
present and continuing w/ defaults..?

and can we have device_property_xxx instead of of_ variants?

> +static int __init stm32_mdma_init(void)
> +{
> +	return platform_driver_probe(&stm32_mdma_driver, stm32_mdma_probe);
> +}
> +
> +subsys_initcall(stm32_mdma_init);

Where are the MODULE_xx tags, license is mandatory. You should add author
too.
 

-- 
~Vinod

  reply	other threads:[~2017-07-21  7:55 UTC|newest]

Thread overview: 42+ 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 [this message]
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 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
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-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=20170721075547.GO3053@localhost \
    --to=vinod.koul@intel.com \
    --cc=linux-arm-kernel@lists.infradead.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.