Messages in this thread | | | From | Denis Vlasenko <> | Subject | Re: [PATCH] 2.5.15 IDE 61 | Date | 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/
| |