All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Pierre Ossman <drzeus@drzeus.cx>
Cc: Nicolas Ferre <nicolas.ferre@atmel.com>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	Andrew Victor <linux@maxim.org.za>, Eric BENARD <ebenard@free.fr>,
	ARM Linux Mailing List  <linux-arm-kernel@lists.arm.linux.org.uk>
Subject: Re: [PATCH 4/7] mmc: at91_mci: add multiwrite switch
Date: Mon, 9 Jun 2008 14:08:31 +0100	[thread overview]
Message-ID: <20080609130831.GC30971@flint.arm.linux.org.uk> (raw)
In-Reply-To: <20080609124249.349995df@mjolnir.drzeus.cx>

On Mon, Jun 09, 2008 at 12:42:49PM +0200, Pierre Ossman wrote:
> On Sun, 1 Jun 2008 15:42:52 +0100
> Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> 
> > If Pierre wants to remove the MULTIWRITE flag, I'd like to hear his
> > solution for the pxamci driver, where the only way to ascertain how
> > many bytes were transmitted may be to walk the SG list comparing the
> > DMA pointer with what was in the hardware DMA engine at the time.
> > Maybe.
> 
> You set bytes_xfered to 0. As mentioned in my previous mail, I had a
> chat with Jens about this and upper layers can only expect to get the
> lower bound in how many bytes were written. Other hardware/drivers
> already behaves like this so there is no point in crippling the MMC
> layer in an effort to give nicer guarantees.
> 
> This is why I asked people to audit their drivers to make sure it's
> the lower bound that's returned, but I've not received much in the way
> of replies.

You won't do from me concerning pxamci - I don't look after it anymore
after one of my MMC cards got eaten by the misbehaving bugger.  I don't
think anyone else is looking after it, so that means the driver's
effectively unmaintained.

  reply	other threads:[~2008-06-09 13:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-30 11:49 [PATCH 0/7] mmc: at91_mci: rework to allow better transfer Nicolas Ferre
2008-05-30 12:18 ` [PATCH 5/7] mmc: at91_mci: update bytes_xfered value once xfer done Nicolas Ferre
2008-06-01 14:44   ` Russell King - ARM Linux
2008-05-30 12:26 ` [PATCH 6/7] mmc: at91_mci: add sdio irq management Nicolas Ferre
2008-05-30 12:28 ` [PATCH 7/7] mmc: at91_mci: do not read irq status twice as it will forget some errors Nicolas Ferre
2008-05-30 12:43 ` [PATCH 1/7] mmc: at91_mci: support for block size not modulo 4 Nicolas Ferre
2008-05-30 12:44 ` [PATCH 2/7] mmc: at91_mci: show timeouts Nicolas Ferre
2008-05-30 12:45 ` [PATCH 3/7] mmc: at91_mci: avoid timeouts Nicolas Ferre
2008-05-30 12:45 ` [PATCH 4/7] mmc: at91_mci: add multiwrite switch Nicolas Ferre
     [not found] ` <483FED84.50100@atmel.com>
2008-05-30 12:57   ` [PATCH 1/7] mmc: at91_mci: support for block size not modulo 4 Marc Pignat
     [not found] ` <483FEE58.5000500@atmel.com>
2008-06-01 14:42   ` [PATCH 4/7] mmc: at91_mci: add multiwrite switch Russell King - ARM Linux
2008-06-09 10:42     ` Pierre Ossman
2008-06-09 13:08       ` Russell King - ARM Linux [this message]
2008-06-09 13:42         ` Pierre Ossman
2008-06-09 13:53           ` Russell King - ARM Linux
2008-06-09 13:58             ` Pierre Ossman
2008-06-09 10:46 ` [PATCH 0/7] mmc: at91_mci: rework to allow better transfer Pierre Ossman
2008-06-10  9:54   ` Nicolas Ferre
2008-06-14 16:28     ` Pierre Ossman
2008-06-18 10:04       ` Nicolas Ferre
2008-06-18 10:47         ` Erik Mouw
2008-06-18 11:16           ` Erik Mouw
2008-06-18 11:40             ` Hans J. Koch
2008-06-18 11:47               ` David Woodhouse
2008-06-18 13:35                 ` Erik Mouw
2008-06-18 13:37                   ` David Woodhouse
2008-06-18 15:17                     ` Erik Mouw
2008-06-20 16:30         ` Pierre Ossman
     [not found]           ` <6306c640806201005n17aba42ag6f0bc344256a1ad@mail.gmail.com>
2008-06-20 17:25             ` Pierre Ossman

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=20080609130831.GC30971@flint.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=drzeus@drzeus.cx \
    --cc=ebenard@free.fr \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@maxim.org.za \
    --cc=nicolas.ferre@atmel.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 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.