From: Neil Conway <nconway.list@ukaea.org.uk>
To: vda@port.imtp.ilyichevsk.odessa.ua
Cc: Martin Dalecki <dalecki@evision-ventures.com>,
Anton Altaparmakov <aia21@cantab.net>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
Russell King <rmk@arm.linux.org.uk>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5.15 IDE 61
Date: Wed, 15 May 2002 12:55:37 +0100 [thread overview]
Message-ID: <3CE24CB9.8DFC5821@ukaea.org.uk> (raw)
In-Reply-To: <E177dYp-00083c-00@the-village.bc.nu> <5.1.0.14.2.20020514202811.01fcc1d0@pop.cus.cam.ac.uk> <3CE22B2B.5080506@evision-ventures.com> <200205151138.g4FBcGY13110@Port.imtp.ilyichevsk.odessa.ua>
Denis Vlasenko wrote:
>
> On 15 May 2002 07:32, Martin Dalecki wrote:
> > >> Yes thinking about it longer and longer I tend to the same conclusion,
> > >> that we just shouldn't have per device queue but per channel queues
> > >> instead.
>
> IMHO logically request queue is a separate entity for each disk.
> IDE can have 2 devices on one cable (or more: think about
> buggy cmd640 like chipset as a weird IDE with four disks
> on a channel since we can talk to one disk only at a time).
Actually, since Martin pointed out the hardsect stuff, I'm inclined to
think per-device queues but with a per-channel busy flag are the best
idea. Or perhaps I should call it a per-channel "Don't touch the cable"
flag. See below.
> It is a _spin_ lock.
> Does this mean you will spin on it while IDE request for other disk
> is processed?
No. An SMP machine will spin on it only while the queue-handling code
is active. During the pause while the disk fetches the sectors from the
media, no problem.
> Somebody enlighten me: can IDE mix reqests and completion like this:
I'll try (!) Treat my words with caution ;-)
> host ----read reqest---> master
> host ----read reqest---> slave (is this possible?)
No, in general. Not unless you're using tagged command queueing. This
is because the master won't have performed a bus-release on any normal
R/W command. Once you are using TCQ it's OK though (tricky but OK).
You can (and must) safely "touch the cable" in between TCQ commands in
the right circumstances. You are therefore touching the cable while the
hwgroup is busy, hence my suggestion that the flag we use to prevent
touching the cable during DMA should be named something other than busy.
Neil
next prev parent reply other threads:[~2002-05-15 11:57 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-14 9:49 [PATCH] 2.5.15 IDE 61 Neil Conway
2002-05-14 8:52 ` Martin Dalecki
2002-05-14 10:12 ` Neil Conway
2002-05-14 9:30 ` Martin Dalecki
2002-05-14 11:10 ` Neil Conway
2002-05-14 10:21 ` Martin Dalecki
2002-05-14 11:38 ` Russell King
2002-05-14 10:49 ` Martin Dalecki
2002-05-14 12:10 ` Alan Cox
2002-05-14 11:11 ` Martin Dalecki
2002-05-14 12:47 ` Alan Cox
2002-05-14 12:30 ` Martin Dalecki
2002-05-15 14:43 ` Pavel Machek
2002-05-14 12:00 ` Russell King
2002-05-14 11:03 ` Martin Dalecki
2002-05-14 13:03 ` Neil Conway
2002-05-14 13:27 ` Andre Hedrick
2002-05-14 14:45 ` Alan Cox
2002-05-14 14:30 ` Martin Dalecki
2002-05-14 16:20 ` Neil Conway
2002-05-14 16:32 ` Jens Axboe
2002-05-14 16:47 ` Neil Conway
2002-05-14 16:51 ` Jens Axboe
2002-05-15 11:37 ` Neil Conway
2002-05-14 22:51 ` Mike Fedyk
2002-05-14 16:26 ` Jens Axboe
2002-05-14 19:34 ` Anton Altaparmakov
2002-05-15 6:16 ` Jens Axboe
2002-05-15 8:32 ` Anton Altaparmakov
2002-05-15 9:42 ` Martin Dalecki
2002-05-15 9:32 ` Martin Dalecki
2002-05-15 11:44 ` Neil Conway
2002-05-15 11:02 ` Martin Dalecki
2002-05-15 13:10 ` Alan Cox
2002-05-15 13:34 ` Neil Conway
2002-05-15 13:04 ` Martin Dalecki
2002-05-15 14:08 ` benh
2002-05-15 16:40 ` Denis Vlasenko
2002-05-15 11:55 ` Neil Conway [this message]
2002-05-17 7:07 ` Mike Fedyk
2002-05-17 11:06 ` Neil Conway
2002-05-17 10:12 ` Martin Dalecki
2002-05-14 16:03 ` Neil Conway
2002-05-14 16:46 ` Alan Cox
2002-05-14 12:52 ` Daniela Engert
-- strict thread matches above, loose matches on Subject: below --
2002-05-06 3:53 Linux-2.5.14 Linus Torvalds
2002-05-13 9:48 ` [PATCH] 2.5.15 IDE 61 Martin Dalecki
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=3CE24CB9.8DFC5821@ukaea.org.uk \
--to=nconway.list@ukaea.org.uk \
--cc=aia21@cantab.net \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dalecki@evision-ventures.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk@arm.linux.org.uk \
--cc=vda@port.imtp.ilyichevsk.odessa.ua \
/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