linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
To: Vinod Koul <vinod.koul@intel.com>
Cc: <dan.j.williams@intel.com>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <alex@alex-smith.me.uk>
Subject: Re: [PATCH_V3 2/3] dma: jz4780: add driver for the Ingenic JZ4780 DMA controller
Date: Tue, 17 Mar 2015 18:07:36 +0000	[thread overview]
Message-ID: <55086D68.1000303@imgtec.com> (raw)
In-Reply-To: <20150316104646.GM32683@intel.com>

Hi,

Thanks for the review.

On 16/03/15 10:46, Vinod Koul wrote:
> On Thu, Feb 26, 2015 at 12:43:33PM +0000, Zubair Lutfullah Kakakhel wrote:
>> +/* Per-channel registers. */
>> +#define JZ_DMA_REG_DSA(n)	(0x00 + (n) * 0x20)
>> +#define JZ_DMA_REG_DTA(n)	(0x04 + (n) * 0x20)
>> +#define JZ_DMA_REG_DTC(n)	(0x08 + (n) * 0x20)
>> +#define JZ_DMA_REG_DRT(n)	(0x0c + (n) * 0x20)
>> +#define JZ_DMA_REG_DCS(n)	(0x10 + (n) * 0x20)
>> +#define JZ_DMA_REG_DCM(n)	(0x14 + (n) * 0x20)
>> +#define JZ_DMA_REG_DDA(n)	(0x18 + (n) * 0x20)
>> +#define JZ_DMA_REG_DSD(n)	(0x1c + (n) * 0x20)
> shouldn't this be a macro rather than copy paste n * 0x20
> 

Done

>> +
>> +#define JZ_DMA_DMAC_DMAE	BIT(0)
>> +#define JZ_DMA_DMAC_AR		BIT(2)
>> +#define JZ_DMA_DMAC_HLT		BIT(3)
>> +#define JZ_DMA_DMAC_FMSC	BIT(31)
>> +
>> +#define JZ_DMA_DRT_AUTO		0x8
> not consistent in BIT?

Its actually 0x01000. instead of just bit.

>> +static struct jz4780_dma_desc *jz4780_dma_desc_alloc(
>> +	struct jz4780_dma_chan *jzchan, unsigned int count,
>> +	enum dma_transaction_type type)
>> +{
>> +	struct jz4780_dma_desc *desc;
>> +
>> +	if (count > JZ_DMA_MAX_DESC)
>> +		return NULL;
>> +
>> +	desc = kzalloc(sizeof(*desc), GFP_ATOMIC);
> GFP_NOWAIT pls
> 
>> +	if (!desc)
>> +		return NULL;
>> +
>> +	desc->desc = dma_pool_alloc(jzchan->desc_pool, GFP_ATOMIC,
> ditto
> 

Done

>> +static uint32_t jz4780_dma_width(enum dma_slave_buswidth width)
>> +{
>> +	switch (width) {
>> +	case DMA_SLAVE_BUSWIDTH_1_BYTE:
>> +		return JZ_DMA_WIDTH_8_BIT;
>> +	case DMA_SLAVE_BUSWIDTH_2_BYTES:
>> +		return JZ_DMA_WIDTH_16_BIT;
> these are same as dmaengine defines so should this be:
> 

These are. The DMA_SLAVE_BUSWIDTH_4_BYTES isn't.

> 	case DMA_SLAVE_BUSWIDTH_1_BYTE:
> 	case DMA_SLAVE_BUSWIDTH_2_BYTES:
> 		return width;
>> +	default:
>> +		return JZ_DMA_WIDTH_32_BIT;
>> +	}
>> +}
>> +
>> +static uint32_t jz4780_dma_transfer_size(unsigned long val, int *ord)
>> +{
>> +	*ord = ffs(val) - 1;
>> +
>> +	/* 8 byte transfer sizes unsupported so fall back on 4. */
> okay falling back is not a good idea, same applies for default in
> jz4780_dma_width(). The slave dma parameters are match with devices, so
> programming something which you dont support, falling back or using defaults
> is not a good idea
> 

How bad of an idea is it and what is a better way?
I see similar stuff in imx-dma and dma-jz4740.

And my jz4740-mmc driver (I add jz4780 support and use it to test this dma driver mainly)
falls back on defaults after it requests a larger transfer size.

>> +	default:
>> +		WARN_ON(1);
>> +		return -1; /* Can never happen. See previous comment */
> -1?? what happened to kernel error codes?
> 

Oops.

>> +	}
>> +}
>> +
>> +static void jz4780_dma_setup_hwdesc(struct jz4780_dma_chan *jzchan,
>> +	struct jz4780_dma_hwdesc *desc, dma_addr_t addr, size_t len)
>> +{
>> +	struct dma_slave_config *config = &jzchan->config;
>> +	uint32_t width, maxburst, tsz;
>> +	int ord;
>> +
>> +	if (config->direction == DMA_MEM_TO_DEV) {
> this is a wrong idea, use the direction from the prep_ call
> 
Done

>> +static enum dma_status jz4780_dma_tx_status(struct dma_chan *chan,
>> +	dma_cookie_t cookie, struct dma_tx_state *txstate)
>> +{
>> +	struct jz4780_dma_chan *jzchan = to_jz4780_dma_chan(chan);
>> +	struct virt_dma_desc *vdesc;
>> +	enum dma_status status;
>> +	unsigned long flags;
>> +
>> +	status = dma_cookie_status(chan, cookie, txstate);
>> +	if (status == DMA_COMPLETE)
> or if the txstate is NULL
> 

Done

> 
> 

Thanks
ZubairLK

  reply	other threads:[~2015-03-17 18:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-26 12:43 [PATCH_V3 0/3] dma: dt: Add DMA driver for jz4780 Zubair Lutfullah Kakakhel
2015-02-26 12:43 ` [PATCH_V3 1/3] dt-bindings: dma: Add binding for jz4780-dma Zubair Lutfullah Kakakhel
2015-02-26 20:04   ` Alex Smith
2015-02-27  9:20     ` Zubair Lutfullah Kakakhel
2015-02-28  9:58       ` Alex Smith
2015-02-26 12:43 ` [PATCH_V3 2/3] dma: jz4780: add driver for the Ingenic JZ4780 DMA controller Zubair Lutfullah Kakakhel
2015-03-16 10:46   ` Vinod Koul
2015-03-17 18:07     ` Zubair Lutfullah Kakakhel [this message]
2015-03-18 11:19       ` Vinod Koul
2015-02-26 12:43 ` [PATCH_V3 3/3] MAINTAINERS: Add Ingenic JZ4780 DMA driver maintainer entry Zubair Lutfullah Kakakhel

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=55086D68.1000303@imgtec.com \
    --to=zubair.kakakhel@imgtec.com \
    --cc=alex@alex-smith.me.uk \
    --cc=dan.j.williams@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).