> > 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. > > Given the highly parallel nature of these parts, I wouldn't be surprised > if the ahci queue depth of 31 is one of the main bottlenecks. Can you > think of a way to extend the ahci driver in this manner to accommodate > devices like this one? The queue depth and tag limits come from the SATA standard and also leak fairly comprehensively into the AHCI spec so not unless the hardware has extensions for it and is merely faked SATA (and if you are faking SATA you have to wonder why if your goal is max performance) -- 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
