From: Richard Zidlicky <rz@linux-m68k.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: John Bradford <john@grabjohn.com>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Linus Torvalds <torvalds@transmeta.com>,
Paul Mackerras <paulus@samba.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] M68k IDE updates
Date: Thu, 24 Apr 2003 15:14:46 +0200 [thread overview]
Message-ID: <20030424131446.GB3073@linux-m68k.org> (raw)
In-Reply-To: <Pine.GSO.4.21.0304241309200.19942-100000@vervain.sonytel.be>
On Thu, Apr 24, 2003 at 01:26:12PM +0200, Geert Uytterhoeven wrote:
>
> After some more thinking, Alan's suggestion (always doing the swapping) isn't
> that bad. Except for the loop layer on old slow machines, which I'd like to
> avoid.
convincing by simplicity, oversimplification also may have drawbacks.
> If we always swap, we only have to un-swap when reading/writing platter data
> from native disks. No more swapping has to be done in ide_fix_driveid(), apart
> from the obvious conversion from little to big endian of the driveid structure
> itself, which we cannot avoid.
yes. Smartdata and everything would be correct, except for the disk
contents.
> Since both Atari and Q40/Q60 use PIO only, this affects ata_{in,out}put_data()
> only. It's quite easy to add a swap flag to ide_drive_t (configurable through
> hdX=swapdata), that is checked in ata_{in,out}put_data(). To improve
> performance, we wouldn't swap twice, but just call the new routines
> hwif->{IN,OUT}S[WL]_NOSWAP.
contradicts previous paragraph? Still wrong smartdata etc unless
you mean to set the flag per request depending on the type of command
- which would be quite easy afaics.
> All of this can be protected by #ifdef CONFIG_IDE_BYTESWAPPED_HWIF. Influence
> on generic code is limited to ata_{in,out}put_data() and the new routines
> hwif->{IN,OUT}S[WL]_NOSWAP.
>
> Is this OK?
so to sum up, your idea is
- cleanup and correct current solution for IDE_BYTESWAPPED_HWIF machines
- make all others use the loop layer
looks fine.
Richard
next prev parent reply other threads:[~2003-04-24 13:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.GSO.4.21.0304221802570.16017-100000@vervain.sonytel.be>
2003-04-23 11:27 ` [PATCH] M68k IDE updates Richard Zidlicky
2003-04-23 11:04 ` Alan Cox
2003-04-23 20:19 ` John Bradford
2003-04-24 9:47 ` Richard Zidlicky
2003-04-24 11:26 ` Geert Uytterhoeven
2003-04-24 13:14 ` Richard Zidlicky [this message]
2003-04-24 14:11 ` Geert Uytterhoeven
2003-04-22 13:55 Mudama, Eric
-- strict thread matches above, loose matches on Subject: below --
2003-04-13 13:06 Geert Uytterhoeven
2003-04-13 14:10 ` Alan Cox
2003-04-13 23:43 ` Paul Mackerras
2003-04-14 8:39 ` Geert Uytterhoeven
2003-04-14 9:19 ` Benjamin Herrenschmidt
2003-04-14 9:24 ` Geert Uytterhoeven
2003-04-14 12:19 ` Alan Cox
2003-04-14 12:21 ` Alan Cox
2003-04-14 13:44 ` Geert Uytterhoeven
2003-04-14 16:03 ` Alan Cox
2003-04-15 4:45 ` Jamie Lokier
2003-04-15 8:11 ` Geert Uytterhoeven
2003-04-15 9:23 ` Jörn Engel
2003-04-15 9:52 ` Geert Uytterhoeven
2003-04-14 12:48 ` Alan Cox
2003-04-14 12:48 ` Alan Cox
2003-04-14 17:44 ` Linus Torvalds
2003-04-14 19:54 ` Geert Uytterhoeven
2003-04-14 22:31 ` Paul Mackerras
2003-04-15 8:14 ` Geert Uytterhoeven
2003-04-21 16:55 ` Geert Uytterhoeven
2003-04-22 14:49 ` Alan Cox
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=20030424131446.GB3073@linux-m68k.org \
--to=rz@linux-m68k.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=geert@linux-m68k.org \
--cc=john@grabjohn.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=torvalds@transmeta.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.