Re: [PATCH] clean up some more tmscsim scan logic

[Christoph Hellwig <hch@lst.de>]

On Tue, Aug 17, 2004 at 10:17:14PM +0200, Guennadi Liakhovetski wrote:
> Currently SCSI drivers (tmscsim included) implement multiplecommand 
> queues. Which, in part, makes sense, but the generic code changed, and not 
> all drivers nave been converted to fully use it promptly. So, as a 
> maximum, I saw (maybe you could add a couple:-)):
> 
> 1) Queue in the block-layer
> 2) Incoming queue in a scsi LLD (recently removed in tmscsim)
> 3) Issue queue in LLD (Waiting in tmscsim)
> 4) Submitted tagged command queue or untagged 1 current command in LLD 
> with a timer (Going in tmscsim)
> 5) tcq in SCSI mid-layer / block.
> 
> So, I can't figure out, nor find a sample implementation or a document 
> about which queues should really be implemented in LLDs and how they 
> should inter-operate with the mid- / block-layer. Say, a document, 
> describing the (SCSI-)command flow would be very useful, like

None should be in the LLDD.  I have an experimental patch that doesn't
remove the per-device queue yet but only does the easier part of
returning MLQUEUE_DEVICE_BUSY in ->queuecommand but doesn't do the
requeueing from the isr yet.  I'll send it out ASAP.

> n)   scsi.c: LLD->queuecommand()
> n+1) LLD:    send out on the bus, insert on tcq / return
>      SCSI_MLQUEUE_DEVICE_BUSY
> n+2) LLD:    on command-completion, if successful, report (scsi_done()),
>      if not - auto request sense, put the request-sense command on
>      internal "going" queue
> ...
> 
> Where n+2 is, actually, the second question - I've seen a comment 
> somewhere, that LLDs should (not?) auto request-sense, rather than failing 
> and letting the mid-layer issue one...

No, mid-layer auto request sense is deprecated and isn't that reliable.
See the comment ontop of scsi_eh_get_sense() in scsi_error.c

> Is there a "perfect" LLD, I could look at for an example? I looked at 
> 53c700.c, as it was until recently the only one using tcq, but it also has 
> a few of those internal queues...

that driver queues commands in HBA memory, not in the driver.  It's one
of the NCR scripts family HBAs where the firmware is written specificly
to match the driver and they cooperate closely.  (better ask James on
the details..)