|To:||David Daney <firstname.lastname@example.org>|
|Subject:||Re: [PATCH 1/2] libata: Add two more columns to the ata_timing table.|
|From:||Sergei Shtylyov <email@example.com>|
|Date:||Tue, 09 Dec 2008 02:19:03 +0300|
|References:||<4939B402.firstname.lastname@example.org> <email@example.com> <493ADE48.firstname.lastname@example.org> <493D65C8.email@example.com> <493D6C0F.firstname.lastname@example.org> <493D6DA1.email@example.com> <493D873C.firstname.lastname@example.org>|
|User-agent:||Thunderbird 22.214.171.124 (Windows/20081105)|
Hello. David Daney wrote:
OK, t6z is yet longer than t9 but putting it into the table seems pointless anyway as it's fixed at 30 ns, at least for the standard 5 PIO modes (and for other two modes 30 ns would be good anyway). Though frankly speaking I don't quite understand your care for this timing, if the ATA standard permits -CE deasserted and data bus being driven to overlap.It doesn't matter what the ATA standard permits in this case. We need to assure that the OCTEON Boot Bus standard is respected. There are several timing parameters that we have to set based on the documented properties of the device. Ideally if we try to run bus cycles for non-ATA/CF devices that share the signal lines of the Boot Bus, they should not interfere with the CF interface.
Well, your driver is free to handle it on its own, and even respect a lesser minimum for PIO5/6. It just doesn't seem practical to add this to the table. In fact, about all PATA hardware on market only permits to control the active/recovery and the address setup times -- that's why the table looks like it looks now.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||Re: [PATCH 1/2] libata: Add two more columns to the ata_timing table., David Daney|
|Next by Date:||[PATCH 3/3] libata: New driver for OCTEON SOC Compact Flash interface (v3)., David Daney|
|Previous by Thread:||Re: [PATCH 1/2] libata: Add two more columns to the ata_timing table., David Daney|
|Next by Thread:||[PATCH 2/2] libata: New driver for OCTEON SOC Compact Flash interface (v3)., David Daney|
|Indexes:||[Date] [Thread] [Top] [All Lists]|