mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
To: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Cc: linux-kernel@vger.kernel.org, maciej.sosnowski@intel.com,
	dan.j.williams@intel.com
Subject: Re: dw_dmac driver questions
Date: Mon, 5 Jan 2009 15:30:24 +0100	[thread overview]
Message-ID: <20090105153024.179c9f29@hskinnemoen-d830> (raw)
In-Reply-To: <20081229.233932.25909762.anemo@mba.ocn.ne.jp>

Atsushi Nemoto wrote:
> Hi.  I'm writing a new DMA driver, using dw_dmac driver in kernel
> 2.6.28 as a reference implementation.
> 
> I can see an outline of the dw_dmac driver and framework (well,
> hopefully), but have some questions in details.
> 
> 
> 1. map/unmap DMA buffers for slave transfer
> 
> For slave-DMA, it seems dmac driver is responsible for mapping DMA
> buffers, and client is responsible for unmapping them.  Is it right?

No, it's the other way around, unless DMA_COMPL_SKIP_*_UNMAP is set.
But I think the dw_dmac driver wrongly maps the buffers before queuing
them.

> Now dwc_descriptor_complete() unmaps DMA buffer unless
> DMA_COMPL_SKIP_XXX_UNMAP set.  These unmapping should be done only for
> non-slave transfers?  I.e. I suppose "if (!dwc->dws)" is required
> around dma_unmap_page() pair.

Yes, perhaps. Or we could just forcibly set those flags in
prep_slave_sg().

> I also wonder why dwc_prep_slave_sg() calculates total_len. The
> total_len is stored in first descriptor of the chain and it is only
> referenced for unmapping DMA buffers.  But the scatterlist may contain
> uncontinuous buffers, so they can not be unmaped at a time.

Yes, it is indeed a bit pointless to keep the total length around for
scatterlists.

> 2.  dwc_is_tx_complete() and dwc->lock
> 
> The function dwc_is_tx_complete() calls dwc_scan_descriptors() without
> dwc->lock (and disabling bh).  Is it safe?  All other callers of
> dwc_scan_descriptors() take dwc->lock and disable bh.

No, that does indeed look unsafe. We should probably take dwc->lock and
disable bh around the call to dwc_scan_descriptors().

> 3.  dwc->queue list management
> 
> The function dwc_tx_submit() add the descriptor to dwc->queue list if
> active list was not empty.  But it does not manage lli.llp list.  And
> all descriptors in the queue list will be moved to active list at a
> time.  So it seems non-first descriptors in queue list will never
> processed by the hardware.
> 
> The dwc_tx_submit() should rewrite lli.llp of the last descriptor in
> queue list (it it had children, the last children of it) by txd.phys
> of newly queued descriptor.  Or, only first elements of queue list
> should be moved to active list at a time.
> 
> Is my analysis correct?

Yes, I think you're right. lli.llp of the last queued entry should be
updated when adding new entries to the queue.

> 
> BTW, I found some redundant code in the driver.
> 
> * memset(dw, 0, sizeof *dw) seems redundant while dw is allocated
>   kzalloc().

Indeed.

> * platform_get_drvdata(pdev) is called twice in dw_shutdown,
>   dw_suspend_late.
> 
> Both of them harmless.

Right.

> 4. This is a comment on head of dwc_handle_error().
> 
> 	/*
> 	 * The descriptor currently at the head of the active list is
> 	 * borked. Since we don't have any way to report errors, we'll
> 	 * just have to scream loudly and try to carry on.
> 	 */
> 
> But, the bad descriptor can be at any place of the active list, no ?
> For example, if the active list contained two descriptor and latter
> was broken and tasklet was delayed by some reason, the head of the
> list should be good.

Since dwc_scan_descriptors() was just called, all descriptors that were
completed successfully have been removed from the active list. So the
first entry must be the broken one.

Haavard

  parent reply	other threads:[~2009-01-05 14:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-29 14:39 Atsushi Nemoto
2009-01-05 14:02 ` Atsushi Nemoto
2009-01-09 14:06   ` Atsushi Nemoto
2009-01-05 14:30 ` Haavard Skinnemoen [this message]
2009-01-05 15:35   ` Atsushi Nemoto
2009-01-05 15:48     ` Haavard Skinnemoen
2009-01-06  1:33       ` Atsushi Nemoto
2009-01-06 10:14         ` Haavard Skinnemoen
2009-01-06 14:31           ` Atsushi Nemoto

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=20090105153024.179c9f29@hskinnemoen-d830 \
    --to=haavard.skinnemoen@atmel.com \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=dan.j.williams@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maciej.sosnowski@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

all inboxes | Powered by JetHome®