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 3/5] dmaengine: pxa: add pxa dmaengine driver
Date: Sat, 9 May 2015 17:29:11 +0530	[thread overview]
Message-ID: <20150509115911.GL3521@localhost> (raw)
In-Reply-To: <873837uubu.fsf@belgarion.home>

On Fri, May 08, 2015 at 02:28:37PM +0200, Robert Jarzmik wrote:
> Vinod Koul <vinod.koul@intel.com> writes:
> 
> 
> >> +#define DRCMR_MAPVLD	BIT(7)	/* Map Valid (read / write) */
> >> +#define DRCMR_CHLNUM	0x1f	/* mask for Channel Number (read / write) */
> >> +
> >> +#define DDADR_DESCADDR	0xfffffff0	/* Address of next descriptor (mask) */
> >> +#define DDADR_STOP	BIT(0)	/* Stop (read / write) */
> >> +
> >> +#define DCMD_INCSRCADDR	BIT(31)	/* Source Address Increment Setting. */
> >> +#define DCMD_INCTRGADDR	BIT(30)	/* Target Address Increment Setting. */
> >> +#define DCMD_FLOWSRC	BIT(29)	/* Flow Control by the source. */
> >> +#define DCMD_FLOWTRG	BIT(28)	/* Flow Control by the target. */
> >> +#define DCMD_STARTIRQEN	BIT(22)	/* Start Interrupt Enable */
> >> +#define DCMD_ENDIRQEN	BIT(21)	/* End Interrupt Enable */
> >> +#define DCMD_ENDIAN	BIT(18)	/* Device Endian-ness. */
> >> +#define DCMD_BURST8	(1 << 16)	/* 8 byte burst */
> >> +#define DCMD_BURST16	(2 << 16)	/* 16 byte burst */
> >> +#define DCMD_BURST32	(3 << 16)	/* 32 byte burst */
> >> +#define DCMD_WIDTH1	(1 << 14)	/* 1 byte width */
> >> +#define DCMD_WIDTH2	(2 << 14)	/* 2 byte width (HalfWord) */
> >> +#define DCMD_WIDTH4	(3 << 14)	/* 4 byte width (Word) */
> >> +#define DCMD_LENGTH	0x01fff		/* length mask (max = 8K - 1) */
> > Please namespace these ...
> Sorry I don't get this comment, would you care to explain me please ?
Right now you are using very genric names which can conflict with others, so
makese sense to add PXA_DCMD_LENGTH with me lesser prone to conflicts rather
than DCMD_LENGTH

> 
> >> +#define _phy_readl_relaxed(phy, _reg)					\
> >> +	readl_relaxed((phy)->base + _reg((phy)->idx))
> >> +#define phy_readl_relaxed(phy, _reg)					\
> >> +	({								\
> >> +		u32 _v;							\
> >> +		_v = readl_relaxed((phy)->base + _reg((phy)->idx));	\
> >> +		chan_vdbg(phy->vchan, "readl(%s): 0x%08x\n", #_reg,	\
> >> +			  _v);						\
> >> +		_v;							\
> >> +	})
> >> +#define phy_writel(phy, val, _reg)					\
> >> +	do {								\
> >> +		writel((val), (phy)->base + _reg((phy)->idx));		\
> >> +		chan_vdbg((phy)->vchan, "writel(0x%08x, %s)\n",		\
> >> +			  (u32)(val), #_reg);				\
> >> +	} while (0)
> >> +#define phy_writel_relaxed(phy, val, _reg)				\
> >> +	do {								\
> >> +		writel_relaxed((val), (phy)->base + _reg((phy)->idx));	\
> >> +		chan_vdbg((phy)->vchan, "writel(0x%08x, %s)\n",		\
> >> +			  (u32)(val), #_reg);				\
> >> +	} while (0)
> >> +
> >> +/*
> > ??
> > Does this code compile?
> Oh yes, it compiles and works with both debug on and debug off. This is actually
> the most handy debug trace of this driver. I've been using that kind of
> accessors for years in my drivers, and this is truly something I need to
> maintain the driver, especially when a nasty corner case happens on a hardware I
> don't own.
You have start of comment on that line, no ending, so how does it compile!

> >> +	spin_lock_irqsave(&pdev->phy_lock, flags);
> >> +	for (prio = pchan->prio; prio >= PXAD_PRIO_HIGHEST; prio--) {
> >> +		for (i = 0; i < pdev->nr_chans; i++) {
> >> +			if (prio != (i & 0xf) >> 2)
> >> +				continue;
> >> +			phy = &pdev->phys[i];
> >> +			if (!phy->vchan) {
> >> +				phy->vchan = pchan;
> >> +				found = phy;
> >> +				goto out_unlock;
> > what does phy have to do with priorty here?
> Each phy has a priority, it's part of the hardware.  IOW each phy has a "granted
> bandwidth". This guarantee is based on the number of request on the system bus
> the DMA IP can place.
> 
> In PXA2xx/PXA3xx, the DMA IP can have 8 simulaneous request. The highest
> priority phys always get 4 slots, the high 2 slots, etc ...
> 
> So a priority is an intrinsic property of a phy.
Yes that part is ok, but why are you looking up priorty while searching for
a phy, searching thru number of channels should suffice?

> >> +static struct pxad_desc_sw *
> >> +pxad_alloc_desc(struct pxad_chan *chan, unsigned int nb_hw_desc)
> >> +{
> >> +	struct pxad_desc_sw *sw_desc;
> >> +	dma_addr_t dma;
> >> +	int i;
> >> +
> >> +	sw_desc = kzalloc(sizeof(*sw_desc) +
> >> +			  nb_hw_desc * sizeof(struct pxad_desc_hw *),
> >> +			  GFP_ATOMIC);
> >> +	if (!sw_desc) {
> >> +		chan_err(chan, "Couldn't allocate a sw_desc\n");
> > this is not required, memory allocator will spew this as well. I think
> > checkpatch should have warned you..
> Checkpatch did not, but I agree, will remove this print alltogether. For v3.
surprised it does actually, see,
# check for unnecessary "Out of Memory" messages

> 
> >> +static enum dma_status pxad_tx_status(struct dma_chan *dchan,
> >> +				      dma_cookie_t cookie,
> >> +				      struct dma_tx_state *txstate)
> >> +{
> >> +	struct pxad_chan *chan = to_pxad_chan(dchan);
> >> +	enum dma_status ret;
> >> +
> >> +	ret = dma_cookie_status(dchan, cookie, txstate);
> > pls check if txstate is valid
> My understanding is that's already the job of dma_cookie_status() and
> dma_set_residue().
Yes it is, but is txstate is NULL then no need to calculate residue so bail
out here

-- 
~Vinod

WARNING: multiple messages have this Message-ID (diff)
From: Vinod Koul <vinod.koul@intel.com>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Jonathan Corbet <corbet@lwn.net>, Daniel Mack <daniel@zonque.org>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	dmaengine@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Arnd Bergmann <arnd@arndb.de>
Subject: Re: [PATCH v2 3/5] dmaengine: pxa: add pxa dmaengine driver
Date: Sat, 9 May 2015 17:29:11 +0530	[thread overview]
Message-ID: <20150509115911.GL3521@localhost> (raw)
In-Reply-To: <873837uubu.fsf@belgarion.home>

On Fri, May 08, 2015 at 02:28:37PM +0200, Robert Jarzmik wrote:
> Vinod Koul <vinod.koul@intel.com> writes:
> 
> 
> >> +#define DRCMR_MAPVLD	BIT(7)	/* Map Valid (read / write) */
> >> +#define DRCMR_CHLNUM	0x1f	/* mask for Channel Number (read / write) */
> >> +
> >> +#define DDADR_DESCADDR	0xfffffff0	/* Address of next descriptor (mask) */
> >> +#define DDADR_STOP	BIT(0)	/* Stop (read / write) */
> >> +
> >> +#define DCMD_INCSRCADDR	BIT(31)	/* Source Address Increment Setting. */
> >> +#define DCMD_INCTRGADDR	BIT(30)	/* Target Address Increment Setting. */
> >> +#define DCMD_FLOWSRC	BIT(29)	/* Flow Control by the source. */
> >> +#define DCMD_FLOWTRG	BIT(28)	/* Flow Control by the target. */
> >> +#define DCMD_STARTIRQEN	BIT(22)	/* Start Interrupt Enable */
> >> +#define DCMD_ENDIRQEN	BIT(21)	/* End Interrupt Enable */
> >> +#define DCMD_ENDIAN	BIT(18)	/* Device Endian-ness. */
> >> +#define DCMD_BURST8	(1 << 16)	/* 8 byte burst */
> >> +#define DCMD_BURST16	(2 << 16)	/* 16 byte burst */
> >> +#define DCMD_BURST32	(3 << 16)	/* 32 byte burst */
> >> +#define DCMD_WIDTH1	(1 << 14)	/* 1 byte width */
> >> +#define DCMD_WIDTH2	(2 << 14)	/* 2 byte width (HalfWord) */
> >> +#define DCMD_WIDTH4	(3 << 14)	/* 4 byte width (Word) */
> >> +#define DCMD_LENGTH	0x01fff		/* length mask (max = 8K - 1) */
> > Please namespace these ...
> Sorry I don't get this comment, would you care to explain me please ?
Right now you are using very genric names which can conflict with others, so
makese sense to add PXA_DCMD_LENGTH with me lesser prone to conflicts rather
than DCMD_LENGTH

> 
> >> +#define _phy_readl_relaxed(phy, _reg)					\
> >> +	readl_relaxed((phy)->base + _reg((phy)->idx))
> >> +#define phy_readl_relaxed(phy, _reg)					\
> >> +	({								\
> >> +		u32 _v;							\
> >> +		_v = readl_relaxed((phy)->base + _reg((phy)->idx));	\
> >> +		chan_vdbg(phy->vchan, "readl(%s): 0x%08x\n", #_reg,	\
> >> +			  _v);						\
> >> +		_v;							\
> >> +	})
> >> +#define phy_writel(phy, val, _reg)					\
> >> +	do {								\
> >> +		writel((val), (phy)->base + _reg((phy)->idx));		\
> >> +		chan_vdbg((phy)->vchan, "writel(0x%08x, %s)\n",		\
> >> +			  (u32)(val), #_reg);				\
> >> +	} while (0)
> >> +#define phy_writel_relaxed(phy, val, _reg)				\
> >> +	do {								\
> >> +		writel_relaxed((val), (phy)->base + _reg((phy)->idx));	\
> >> +		chan_vdbg((phy)->vchan, "writel(0x%08x, %s)\n",		\
> >> +			  (u32)(val), #_reg);				\
> >> +	} while (0)
> >> +
> >> +/*
> > ??
> > Does this code compile?
> Oh yes, it compiles and works with both debug on and debug off. This is actually
> the most handy debug trace of this driver. I've been using that kind of
> accessors for years in my drivers, and this is truly something I need to
> maintain the driver, especially when a nasty corner case happens on a hardware I
> don't own.
You have start of comment on that line, no ending, so how does it compile!

> >> +	spin_lock_irqsave(&pdev->phy_lock, flags);
> >> +	for (prio = pchan->prio; prio >= PXAD_PRIO_HIGHEST; prio--) {
> >> +		for (i = 0; i < pdev->nr_chans; i++) {
> >> +			if (prio != (i & 0xf) >> 2)
> >> +				continue;
> >> +			phy = &pdev->phys[i];
> >> +			if (!phy->vchan) {
> >> +				phy->vchan = pchan;
> >> +				found = phy;
> >> +				goto out_unlock;
> > what does phy have to do with priorty here?
> Each phy has a priority, it's part of the hardware.  IOW each phy has a "granted
> bandwidth". This guarantee is based on the number of request on the system bus
> the DMA IP can place.
> 
> In PXA2xx/PXA3xx, the DMA IP can have 8 simulaneous request. The highest
> priority phys always get 4 slots, the high 2 slots, etc ...
> 
> So a priority is an intrinsic property of a phy.
Yes that part is ok, but why are you looking up priorty while searching for
a phy, searching thru number of channels should suffice?

> >> +static struct pxad_desc_sw *
> >> +pxad_alloc_desc(struct pxad_chan *chan, unsigned int nb_hw_desc)
> >> +{
> >> +	struct pxad_desc_sw *sw_desc;
> >> +	dma_addr_t dma;
> >> +	int i;
> >> +
> >> +	sw_desc = kzalloc(sizeof(*sw_desc) +
> >> +			  nb_hw_desc * sizeof(struct pxad_desc_hw *),
> >> +			  GFP_ATOMIC);
> >> +	if (!sw_desc) {
> >> +		chan_err(chan, "Couldn't allocate a sw_desc\n");
> > this is not required, memory allocator will spew this as well. I think
> > checkpatch should have warned you..
> Checkpatch did not, but I agree, will remove this print alltogether. For v3.
surprised it does actually, see,
# check for unnecessary "Out of Memory" messages

> 
> >> +static enum dma_status pxad_tx_status(struct dma_chan *dchan,
> >> +				      dma_cookie_t cookie,
> >> +				      struct dma_tx_state *txstate)
> >> +{
> >> +	struct pxad_chan *chan = to_pxad_chan(dchan);
> >> +	enum dma_status ret;
> >> +
> >> +	ret = dma_cookie_status(dchan, cookie, txstate);
> > pls check if txstate is valid
> My understanding is that's already the job of dma_cookie_status() and
> dma_set_residue().
Yes it is, but is txstate is NULL then no need to calculate residue so bail
out here

-- 
~Vinod


  reply	other threads:[~2015-05-09 11:59 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-11 19:40 [PATCH v2 0/5] Driver for pxa architectures Robert Jarzmik
2015-04-11 19:40 ` Robert Jarzmik
2015-04-11 19:40 ` [PATCH v2 1/5] Documentation: dmaengine: pxa-dma design Robert Jarzmik
2015-04-11 19:40   ` Robert Jarzmik
2015-05-08  4:36   ` Vinod Koul
2015-05-08  4:36     ` Vinod Koul
2015-05-08 12:52     ` Robert Jarzmik
2015-05-08 12:52       ` Robert Jarzmik
2015-05-12 10:12       ` Vinod Koul
2015-05-12 10:12         ` Vinod Koul
2015-05-12 19:13         ` Robert Jarzmik
2015-05-12 19:13           ` Robert Jarzmik
2015-04-11 19:40 ` [PATCH v2 2/5] MAINTAINERS: add pxa dma driver to pxa architecture Robert Jarzmik
2015-04-11 19:40   ` Robert Jarzmik
2015-04-11 19:40 ` [PATCH v2 3/5] dmaengine: pxa: add pxa dmaengine driver Robert Jarzmik
2015-04-11 19:40   ` Robert Jarzmik
2015-05-08  6:34   ` Vinod Koul
2015-05-08  6:34     ` Vinod Koul
2015-05-08 12:28     ` Robert Jarzmik
2015-05-08 12:28       ` Robert Jarzmik
2015-05-09 11:59       ` Vinod Koul [this message]
2015-05-09 11:59         ` Vinod Koul
2015-05-09 17:00         ` Robert Jarzmik
2015-05-09 17:00           ` Robert Jarzmik
2015-04-11 19:40 ` [PATCH v2 4/5] dmaengine: pxa_dma: add debug information Robert Jarzmik
2015-04-11 19:40   ` Robert Jarzmik
2015-04-11 19:40 ` [PATCH v2 5/5] dmaengine: pxa_dma: add support for legacy transition Robert Jarzmik
2015-04-11 19:40   ` Robert Jarzmik
2015-04-19 20:01 ` [PATCH v2 0/5] Driver for pxa architectures Robert Jarzmik
2015-04-19 20:01   ` Robert Jarzmik
2015-04-26 19:59   ` Robert Jarzmik
2015-04-26 19:59     ` Robert Jarzmik
2015-05-01 20:13     ` Robert Jarzmik
2015-05-01 20:13       ` Robert Jarzmik
2015-05-03 15:23       ` Vinod Koul
2015-05-03 15:23         ` Vinod Koul
2015-05-03 18:47         ` Robert Jarzmik
2015-05-03 18:47           ` Robert Jarzmik

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=20150509115911.GL3521@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.