All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sshtylyov@ru.mvista.com>
To: Hugh Dickins <hugh@veritas.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
	Jeff Garzik <jgarzik@redhat.com>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Andrew Morton <akpm@linux-foundation.org>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	Mikael Pettersson <mikpe@it.uu.se>,
	linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: 2.6.29-rc libata sff 32bit PIO regression
Date: Mon, 02 Feb 2009 14:48:57 +0300	[thread overview]
Message-ID: <4986DDA9.6010903@ru.mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0902012050190.16351@blonde.anvils>



Hugh Dickins wrote:
> On Mon, 26 Jan 2009, Alan Cox wrote:
>   
>>> [PATCH] libata sff: 32bit PIO use 16bit on slop
>>>
>>> 871af1210f13966ab911ed2166e4ab2ce775b99d libata: Add 32bit PIO support
>>> causes errors on a four-year-old ata_piix Dell Precision 670.  Using
>>> 16bit PIO instead of 32bit PIO on the odd 1, 2 or 3 chars fixes that.
>>>
>>> Signed-off-by: Hugh Dickins <hugh@veritas.com>
>>>       
>> For the 3 bytes of slop it should use a single iowrite32 but otherwise
>> that seems ok. We do need to handle the FIFO setup on the AMD differently
>> if we do this ...
>>     
>
> Sorry, I believe you were waiting on me for this, to accompany your
> AMD and VLB patches.  I'm afraid I don't have any such AMD devices
> to test this along with yours, and the only non-0 slop that I've seen
> in testing has been 2 (about 25% of ops, so I removed the "unlikely").
> But this patch works as well for me as the patch I posted before
> (though much more verbose: please simplify if you see a better way).
>
>
> [PATCH] libata sff: 32bit PIO use 16bit on slop
>
> 871af1210f13966ab911ed2166e4ab2ce775b99d libata: Add 32bit PIO support
> causes errors on a four-year-old ata_piix Dell Precision 670.  Using
> 16bit PIO instead of 32bit PIO on the odd 1 or 2 chars fixes that,
> but Alan Cox indicates that we should still use 32bit for 3 chars.
>
> Signed-off-by: Hugh Dickins <hugh@veritas.com>
> ---
>
>  drivers/ata/libata-sff.c |   33 ++++++++++++++++++++++++---------
>  1 file changed, 24 insertions(+), 9 deletions(-)
>
> --- 2.6.29-rc3/drivers/ata/libata-sff.c	2009-01-29 12:33:28.000000000 +0000
> +++ linux/drivers/ata/libata-sff.c	2009-02-01 20:21:13.000000000 +0000
> @@ -773,18 +773,33 @@ unsigned int ata_sff_data_xfer32(struct
>  	else
>  		iowrite32_rep(data_addr, buf, words);
>  
> -	if (unlikely(slop)) {
> -		__le32 pad;
> -		if (rw == READ) {
> -			pad = cpu_to_le32(ioread32(ap->ioaddr.data_addr));
> -			memcpy(buf + buflen - slop, &pad, slop);
> +	if (slop) {
> +		unsigned char *trailing_buf = buf + buflen - slop;
>   
> +   
>   
> +		if (slop <= 2) {
> +			__le16 slop_word;
> +			if (rw == READ) {
> +				slop_word = cpu_to_le16(ioread16(data_addr));
> +				memcpy(trailing_buf, &slop_word, slop);
> +			} else {
> +				slop_word = 0;
> +				memcpy(&slop_word, trailing_buf, slop);
> +				iowrite16(le16_to_cpu(slop_word), data_addr);
> +			}
>  		} else {
> -			memcpy(&pad, buf + buflen - slop, slop);
> -			iowrite32(le32_to_cpu(pad), ap->ioaddr.data_addr);
> +			__le32 slop_word;
> +			if (rw == READ) {
> +				slop_word = cpu_to_le32(ioread32(data_addr));
> +				memcpy(trailing_buf, &slop_word, slop);
> +			} else {
> +				slop_word = 0;
> +				memcpy(&slop_word, trailing_buf, slop);
> +				iowrite32(le32_to_cpu(slop_word), data_addr);
> +			}
>   

   How about the following?

		unsigned char *tail = buf + buflen - slop;
		unsigned char pad[4];

		if (rw == READ) {
			if (slop <= 2)
				ioread16_rep(data_addr, pad, 1);
			else
				ioread32_rep(data_addr, pad, 1);
			memcpy(tail, pad, slop);
 		} else {
			memcpy(pad, tail, slop);
			memset(pad + slop, 0, 4 - slop);
			if (slop <= 2)
				iowrite16_rep(data_addr, pad, 1);
			else
				iowrite32_rep(data_addr, pad, 1);
		}

>  	}
> -	return words << 2;
> +
> +	return buflen + (buflen & 1);
>   

    return (buflen + 1) & ~1;

   Well, I guess I could just have posted my own patch... :-)

MBR, Sergei



  reply	other threads:[~2009-02-02 11:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-21 13:34 2.6.29-rc libata sff 32bit PIO regression Hugh Dickins
2009-01-21 20:11 ` Mikael Pettersson
2009-01-21 21:47   ` Alan Cox
2009-01-21 22:51     ` Sergei Shtylyov
2009-01-21 22:58       ` Alan Cox
2009-01-21 23:34         ` Sergei Shtylyov
2009-01-21 23:37           ` Sergei Shtylyov
2009-01-22  0:20             ` Sergei Shtylyov
2009-01-25 15:22             ` Alan Cox
2009-01-25 15:22               ` Alan Cox
2009-01-26 19:11 ` Alan Cox
2009-01-31 15:11   ` Sergei Shtylyov
2009-01-31 16:06     ` Alan Cox
2009-01-31 16:57       ` Sergei Shtylyov
2009-02-01 21:13   ` Hugh Dickins
2009-02-02 11:48     ` Sergei Shtylyov [this message]
2009-02-02 12:12       ` Hugh Dickins
2009-02-02 14:17         ` Sergei Shtylyov
2009-02-03  3:59   ` Jeff Garzik
2009-02-04 11:10   ` Sergei Shtylyov
2009-01-26 19:12 ` Alan Cox
2009-02-03  4:00   ` Jeff Garzik

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=4986DDA9.6010903@ru.mvista.com \
    --to=sshtylyov@ru.mvista.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=akpm@linux-foundation.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=hugh@veritas.com \
    --cc=jgarzik@redhat.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    --cc=rjw@sisk.pl \
    /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.