All of lore.kernel.org
 help / color / mirror / Atom feed
From: ulf.hansson@stericsson.com (Ulf Hansson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmci: sync DATAEND irq with dma transfer done
Date: Fri, 29 Apr 2011 14:44:59 +0200	[thread overview]
Message-ID: <4DBAB2CB.2030700@stericsson.com> (raw)
In-Reply-To: <20110428170342.GA17290@n2100.arm.linux.org.uk>

> 
> That's rather unfortunate, because it means that trying it on ARM
> hardware is going to hang indefinitely waiting for the nonexistent
> DMA stuff to finish.

I see the problem, we need a way of being able to switch between using 
the dma callback and not using it. I think the variant data should be 
used for this, what do you think?

> 
> I remain unconvinced whether this problem applies only to ARMs
> evaluation boards as I believe the whole primecell DMA stuff from
> the outset is fundamentally misdesigned.  I suspect there maybe SoCs
> out there which suffer from the same broken DMA issues which ARMs
> eval boards do.
> 
> Maybe an alternative solution is on data end to set a timer, which
> is cancelled when the DMA engine callback arrives.  If the timer
> expires, it means we have broken DMA and that needs to be shutdown
> for that instance.

This could be a very good alternative for error handling of the DMA job. 
I will try to add some code that handles this.

> 
> However, one thing worries me - what if the DMA callback comes before
> we get the data end interrupt.  Given the weirdnesses of your
> implementation found so far (which are well beyond what's visible
> on ARMs own implementation) I wouldn't put any guarantees on the
> relative ordering of that either.
> 

host->dataend and host->size==0 controls whether the data transfer has 
finished successfully. I believe this should be handled correctly in my 
patch. Maybe it is possible to make some minor restructuring to make it 
more clear what the end condition really is, I can see if I can figure 
something out.


BR
Ulf Hansson

  parent reply	other threads:[~2011-04-29 12:44 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19  9:02 [PATCH] mmci: sync DATAEND irq with dma transfer done Linus Walleij
2011-04-19  9:20 ` Russell King - ARM Linux
2011-04-19 12:00   ` Linus Walleij
2011-04-19 12:03     ` Russell King - ARM Linux
2011-04-20 16:29       ` Linus Walleij
2011-04-20 16:46         ` Vitaly Wool
2011-04-20 17:17           ` Linus Walleij
2011-04-20 17:58             ` Vitaly Wool
2011-04-20 20:11               ` Linus Walleij
2011-04-28 17:03         ` Russell King - ARM Linux
2011-04-28 22:24           ` Martin Furmanski
2011-05-11 20:13             ` Linus Walleij
2011-04-29 12:44           ` Ulf Hansson [this message]
2011-04-29 13:49             ` Russell King - ARM Linux
2011-05-06  8:13               ` Ulf Hansson
2011-05-12  8:36         ` Per Forlin
2011-05-12 13:15           ` Linus Walleij

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=4DBAB2CB.2030700@stericsson.com \
    --to=ulf.hansson@stericsson.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.