> 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 > 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. > Similarly if you've got performnace problems going through the libata > core and AHCI driver the right thing to do is to fix the performance > problems in the core (or rewrite bits of the core as needed). > I think the starting point would be to explain what problems you see with > 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. > Otherwise we will end up with one AHCIish driver per vendor and it turns > into a nightmare for maintenance. Regards, Asai Thambi -- 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
