From: Richard Zidlicky <rz@linux-m68k.org>
To: Bartlomiej Zolnierkiewicz <B.Zolnierkiewicz@elka.pw.edu.pl>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
Jeff Garzik <jgarzik@pobox.com>, Jens Axboe <axboe@suse.de>,
Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: Worrisome IDE PIO transfers...
Date: Mon, 1 Mar 2004 11:43:21 +0100 [thread overview]
Message-ID: <20040301104321.GB1773@linux-m68k.org> (raw)
In-Reply-To: <200402292136.33589.bzolnier@elka.pw.edu.pl>
On Sun, Feb 29, 2004 at 09:36:33PM +0100, Bartlomiej Zolnierkiewicz wrote:
> On Sunday 29 of February 2004 20:23, Richard Zidlicky wrote:
> > On Sun, Feb 29, 2004 at 09:52:08AM +0100, Geert Uytterhoeven wrote:
> > > On Sun, 29 Feb 2004, Bartlomiej Zolnierkiewicz wrote:
> > > > On Sunday 29 of February 2004 01:58, Jeff Garzik wrote:
> > > > > > I like Alan's idea to use loopback instead of "bswap".
> > > > >
> > > > > Neat but no more zerocopy that way. I much prefer a
> > > > > swap-as-you-go...
> > > >
> > > > Okay, better solution:
> > > >
> > > > - on Atari/Q40:
> > > > if drive->bswap use insw/outsw instead of swapping variants
> > >
> > > Yep, that sounds the most logical. Richard?
> >
> > looks good.
> >
> > However it appears to fix only part of the problem - we need some
> > logic to ensure only disk data is swapped.
> > Bswapping WIN_DOWNLOAD_MICROCODE data would not be very
> > clever I guess.
>
> Actually drive->bswap should die as I overlooked the fact that we are
> _not_ swapping disk data (byteswapped data is used for FS) on Atari/Q40.
correct, on those machines the IDE bus is wired "reversed" and we take
the data without any correction, except for IDENTIFY and atapi requests.
That means that quite a few ioctls (SMART etc) are most likely broken
right now.
> Therefore the real solution is to use device-mapper instead of drive->bswap
> and on Atari/Q40 use standard insw/outs only if blk_fs_request(drive->rq),
> for everything else insw_swapw/outsw_swapw should be used.
>
> Does it make any sense? :)
that would be the perfect solution. Note that atapi transfers are
already correct the way they are - nothing to fix here.
Richard
next prev parent reply other threads:[~2004-03-01 11:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-28 23:24 Worrisome IDE PIO transfers Jeff Garzik
2004-02-29 0:21 ` Bartlomiej Zolnierkiewicz
2004-02-29 0:58 ` Jeff Garzik
2004-02-29 3:05 ` Bartlomiej Zolnierkiewicz
2004-02-29 8:52 ` Geert Uytterhoeven
2004-02-29 19:23 ` Richard Zidlicky
2004-02-29 20:36 ` Bartlomiej Zolnierkiewicz
2004-03-01 10:43 ` Richard Zidlicky [this message]
2004-02-29 1:50 ` Matt Mackall
2004-02-29 2:41 ` Jeff Garzik
2004-02-29 3:08 ` Bartlomiej Zolnierkiewicz
2004-02-29 9:32 ` Aubin LaBrosse
2004-03-01 0:47 ` Bartlomiej Zolnierkiewicz
2004-03-01 13:23 ` Christophe Saout
2004-03-01 16:45 ` Bartlomiej Zolnierkiewicz
2004-02-29 8:50 ` Geert Uytterhoeven
2004-02-29 14:55 ` Bartlomiej Zolnierkiewicz
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=20040301104321.GB1773@linux-m68k.org \
--to=rz@linux-m68k.org \
--cc=B.Zolnierkiewicz@elka.pw.edu.pl \
--cc=axboe@suse.de \
--cc=geert@linux-m68k.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.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.