On Mon, 2 May 2011 06:40:31 -0600
"Asai Thambi Samymuthu Pattrayasamy (asamymuthupa) [CONTRACTOR]"
[off-list ref] wrote:

quoted

The kernel starting point would be that we have an AHCI driver. If you
need workarounds for hardware errata then they can go into it and that

is

quoted

fine. We support NCQ so we can use the queue depths. If there are
extensions then the AHCI driver can be enhanced.

We understand that AHCI driver can be patched for hardware errata and
other customizations, but main concern is performance.

Yes I understand that - but our main concern is maintainability, which
means one driver per AHCI flash vendor is a mess that isn't practicable
to deal with.

Documenting the errata would be a help anyway so we can get them into the
mainline AHCI driver, irrespective of what drivers we end up with
ultimately.

quoted

I think the starting point would be to explain what problems you see

with

quoted

the existing driver, and where the profiling tools say the bottlenecks
are when you try and get full speed under libata + libata ahci driver.

The performance difference is not just because of libata + libata ahci
driver. Our driver gets the request before elevator comes into picture.
So, the stack starting from elevator,scsi upper, scsi mid, libata and
libata ahci driver attributes to the performance difference. 

Elevator for flash devices should automatically be null and most of the
SCSI layer isn't actually used so it would be interesting to know for
example what shows up in comparative profiles so that it can be optimised
or dropped out.

Alan