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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox