Re: [PATCH] 2.5.15 IDE 61

Denis Vlasenko (vda@port.imtp.ilyichevsk.odessa.ua)
Wed, 15 May 2002 14:40:51 -0200


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).

This fact is a hardware limitation which can be hidden,
IDE code should arbitrare access to IDE channel.
But why mix up queues?

> >> The only problem here is the fact that some device properties
> >> are attached to the queue right now. Like for example sector size and
> >> friends.

This is naturally happening with one queue per disk.

> > Hi Martin,
> > instead of having per channel queue, you could have per device queue,
> > but use the same lock for both, i.e. don't make the lock part of "struct
> > queue" (or whatever it is called) but instead make the address of the
> > lock be attached to "struct queue".

> In 63 we have:
> blk_init_queue(q, do_ide_request, drive->channel->lock);
> struct ata_channel {
> struct device dev; /* device handle */
> int unit; /* channel number */
>
> /* This lock is used to serialize requests on the same device queue or
> * between differen queues sharing the same irq line.
> */
> spinlock_t *lock;
>
> + The whole glory of lock sharing for IRQ sharing and serialization.

It is a _spin_ lock.
Does this mean you will spin on it while IDE request for other disk
is processed?

Somebody enlighten me: can IDE mix reqests and completion like this:

host ----read reqest---> master
host ----read reqest---> slave (is this possible?)
host <---interrupt------ master
host ----okay,send it--> master
host <---data----------- master
host <---data----------- master (do slave has to wait until end here?)
host <---data----------- master
host <---that's all----- master
host <---interrupt------ slave
(can host issue another read for master here?)
host ----okay,send it--> slave
host <---data----------- slave

Please comment what is allowed and what is not.
I suspect we are in IDE chipset bugs land here.

Does current IDE code (as Martin sees it) utilize this fully but
does not push IDE over limit?

Hm, seems like IDE code needs to remember set of ATA capabilities
(i.e. what should be serialized and what can be safely intermixed
in time) for each controller in order to run full speed on good chips
yet don't croak on buggy ones.

--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/