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
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
