linux-ide.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marek Vasut <marek.vasut@gmail.com>
To: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Jeff Garzik <jeff@garzik.org>,
	linux-ide@vger.kernel.org, eric.y.miao@gmail.com,
	haojian.zhuang@gmail.com, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] PXA DMA-capable PATA driver
Date: Sun, 16 May 2010 03:00:01 +0200	[thread overview]
Message-ID: <201005160300.02076.marek.vasut@gmail.com> (raw)
In-Reply-To: <877hn4ao32.fsf@free.fr>

Dne So 15. května 2010 22:48:17 Robert Jarzmik napsal(a):
> Marek Vasut <marek.vasut@gmail.com> writes:
> > Dne So 15. května 2010 00:03:45 Jeff Garzik napsal(a):
> >> On 05/09/2010 11:02 PM, Marek Vasut wrote:
> >> > This patch adds a driver for a harddrive attached to PXA address and
> >> > data bus. Unlike pata_platform, this driver allows usage of PXA DMA
> >> > controller, making the transmission speed 3x higher.
> 
> ...
> zip
> ...
> 
> >> > +static void pxa_bmdma_setup(struct ata_queued_cmd *qc)
> >> > +{
> >> > +	struct pata_pxa_data *pd = qc->ap->private_data;
> >> > +	int si = 0;
> >> > +	struct scatterlist *sg;
> >> > +
> >> > +	pd->dma_desc_id = 0;
> >> > +
> >> > +	DCSR(pd->dma_channel) = 0;
> >> > +	DALGN&= ~(1<<  pd->dma_dreq);
> >> > +
> >> > +	for_each_sg(qc->sg, sg, qc->n_elem, si)
> >> > +		pxa_load_dmac(sg, qc);
> >> > +
> >> > +	pd->dma_desc[pd->dma_desc_id - 1].ddadr = DDADR_STOP;
> >> > +
> >> > +	/* Fire IRQ only at the end of last block */
> >> > +	pd->dma_desc[pd->dma_desc_id - 1].dcmd |= DCMD_ENDIRQEN;
> >> > +
> >> > +	DDADR(pd->dma_channel) = pd->dma_desc_addr;
> >> > +	DRCMR(pd->dma_dreq) = DRCMR_MAPVLD | pd->dma_channel;
> >> > +	qc->ap->ops->sff_exec_command(qc->ap,&qc->tf);
> >> > +}
> 
> I don't know the ATA infrastructure well here, but I wonder how cache
> consistency is handled here. Normally, once the sg is ready, you have to
> call dma_map_sg() to map the scatter/gather _and_ to flush any stale cache
> entry the CPU(s) might have over the memory used for the transfer.
> 
> Once the transfer is over, you have to call dma_unmap_sg() to give back the
> memory (ie. ensure cache consistency once the peripheral has finished
> pushing data to the memory).

This should be taken care of by the libata code, shouldn't it ?
> 
> I didn't see that is this piece of code. Did I miss something ?
> 
> > BUG() doesn't happen here so the user won't come into any contact with it
> > unless he sets the drive on fire or something. And in case user comes in
> > contact with it, this is all I need to know to help him. Or maybe
> > dev_err() would be good here ?
> > 
> >> > + * Read DMA status. The bmdma_stop() will take care of properly
> >> > finishing the + * DMA transfer so we always have DMA-complete
> >> > interrupt here.
> >> > + */
> >> > +static unsigned char pxa_bmdma_status(struct ata_port *ap)
> >> > +{
> >> > +	return ATA_DMA_INTR;
> >> > +}
> >> 
> >> are you able to detect bus error?
> > 
> > Sadly, no. Nor can I detect any other condition.
> 
> Wouldn't the DCSR_BUSERR bit of DCSR report a bus error ?

I have doubts, check the PXA270 TRM for example for description of that bit.
> 
> +/*
> + * DMA interrupt handler.
> + */
> +static void pxa_ata_dma_irq(int dma, void *port)
> +{
> +	uint32_t dcsr;
> +	struct ata_port *ap = port;
> +	struct pata_pxa_data *pd = ap->private_data;
> +
> +	dcsr = DCSR(dma);
> +	DCSR(dma) = dcsr;
> +	if (dcsr & DCSR_STOPSTATE)
> +		complete(&pd->dma_done);
> +}
> 
> Cheers.
> 
> --
> Robert

  reply	other threads:[~2010-05-16  1:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10  3:02 [PATCH] PXA DMA-capable PATA driver Marek Vasut
2010-05-14 13:51 ` Marek Vasut
2010-05-14 17:42   ` Jeff Garzik
2010-05-14 22:03 ` Jeff Garzik
2010-05-14 22:23   ` Marek Vasut
2010-05-15 20:48     ` Robert Jarzmik
2010-05-16  1:00       ` Marek Vasut [this message]
2010-05-17 15:35         ` Robert Jarzmik
2010-05-17 22:53   ` Marek Vasut
2010-05-20  8:48     ` Tejun Heo
2010-05-20 10:28       ` Marek Vasut

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=201005160300.02076.marek.vasut@gmail.com \
    --to=marek.vasut@gmail.com \
    --cc=eric.y.miao@gmail.com \
    --cc=haojian.zhuang@gmail.com \
    --cc=jeff@garzik.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=robert.jarzmik@free.fr \
    /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).