Re: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)

[Jeff Garzik <jeff@garzik.org>]

Tejun Heo wrote:
> Jeff Garzik wrote:
>> Polling ALREADY makes the job of fixing SAS/SATA exception handling
>> difficult.  Expanding polling to something SAS/SATA controllers treat as
>> fundamentally irq-driven and integrated with the rest of the command
>> flow is moving in the wrong direction.
>>
>> To re-re-re-summarize, polling in PMP is fundamentally broken for an
>> ENTIRE CLASS OF HARDWARE that we actively support today.  And
>> jgarzik/misc-2.6.git#sas is adding two more controllers to that list.
> 
> As an interim solution, it doesn't make anything worse tho.  Those
> drivers don't support PMP anyway.  After rc1 merge, polling PMP access
> can be replaced with new qc_issue (probably ata_exec_internal) based code.
> 
> The question here is whether it's worth to include PMP support with
> polling PMP register access as an interim solution for 2.6.24.  I think
> it will be beneficial for both user convenience and testing as long as
> the said change is made soon after -rc1.

Polling PMP 2.6.24 is completely unacceptable.  It screws the 2.6.24 SAS 
driver releases out of PMP.

I pulled your last PMP patchset, and will now endeavor to fix the API 
prior to 2.6.24 merge window opening.

Linux high level message-submit / message-complete APIs should never 
_require_ polling, even if its 100% polling under the hood.  There are 
far too many cases in the field where you don't have direct access to 
hardware registers to poll.  Or such polling would interfere with the 
operation of other ports.  Or any of a myriad of other reasons.

	Jeff