I updated the info at http://linux-ata.org/ to match the current code in
linux-2.6.git.
Hardware and driver status:
http://linux-ata.org/driver-status.html
notably, the driver matrix:
http://linux-ata.org/driver-status.html#matrix
Software status:
http://linux-ata.org/software-status.html
Concise feature (i.e. buzzword) list:
http://linux-ata.org/features.html
Let me know if something is missing or in error.
Jeff
Am Freitag 29 September 2006 11:35 schrieb Jeff Garzik:
> I updated the info at http://linux-ata.org/ to match the current code in
> linux-2.6.git.
>
> Hardware and driver status:
> http://linux-ata.org/driver-status.html
> notably, the driver matrix:
> http://linux-ata.org/driver-status.html#matrix
Does any ETA exists for NV NON-AHCI NCQ support? The proabably not so small
userbase would be happy if work on it would be done...
Cheers,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
Prakash Punnoor wrote:
> Am Freitag 29 September 2006 11:35 schrieb Jeff Garzik:
>> I updated the info at http://linux-ata.org/ to match the current code in
>> linux-2.6.git.
>>
>> Hardware and driver status:
>> http://linux-ata.org/driver-status.html
>> notably, the driver matrix:
>> http://linux-ata.org/driver-status.html#matrix
>
> Does any ETA exists for NV NON-AHCI NCQ support? The proabably not so small
> userbase would be happy if work on it would be done...
No ETA at all. It is admittedly low priority, and unfortunately the
only people with hardware documentation are myself and NVIDIA.
There is a non-working patch, if someone wants to debug it, though:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/archive/2.6.17-nv-adma.patch.bz2
Jeff
Am Freitag 29 September 2006 11:53 schrieb Jeff Garzik:
> Prakash Punnoor wrote:
> > Am Freitag 29 September 2006 11:35 schrieb Jeff Garzik:
> >> I updated the info at http://linux-ata.org/ to match the current code in
> >> linux-2.6.git.
> >>
> >> Hardware and driver status:
> >> http://linux-ata.org/driver-status.html
> >> notably, the driver matrix:
> >> http://linux-ata.org/driver-status.html#matrix
> >
> > Does any ETA exists for NV NON-AHCI NCQ support? The proabably not so
> > small userbase would be happy if work on it would be done...
>
> No ETA at all. It is admittedly low priority, and unfortunately the
> only people with hardware documentation are myself and NVIDIA.
>
> There is a non-working patch, if someone wants to debug it, though:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/archive/2.6.17
>-nv-adma.patch.bz2
Well, how would one debug it w/o hw docs? Or is it possible to compare the
patch with a working driver for another chipset?
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
Prakash Punnoor wrote:
> Well, how would one debug it w/o hw docs? Or is it possible to compare the
> patch with a working driver for another chipset?
Well, it is based off of the standard ADMA[1] specification, albeit with
modifications. There is pdc_adma.c, which is also based off ADMA. And
the author (from NVIDIA) claims that the driver worked at one time, so
maybe it is simply bit rot that broke the driver.
If I knew the answer, it would be fixed, so the best answer
unfortunately is "who knows".
I wish I had the time. But I also wish I had a team of programmers
working on libata, too ;-)
Jeff
Jeff> I updated the info at http://linux-ata.org/ to match the current
Jeff> code in linux-2.6.git.
Thanks!
Jeff> Let me know if something is missing or in error.
It would be nice to have more details about PATA support. I'm hoping
to test my HPT302 rev1 card with 2.6.18-mm2 tonight if all goes
well...
John
Ar Gwe, 2006-09-29 am 13:51 -0400, ysgrifennodd John Stoffel:
> Jeff> I updated the info at http://linux-ata.org/ to match the current
> Jeff> code in linux-2.6.git.
>
> Thanks!
>
> Jeff> Let me know if something is missing or in error.
>
> It would be nice to have more details about PATA support. I'm hoping
> to test my HPT302 rev1 card with 2.6.18-mm2 tonight if all goes
> well...
I've sent Jeff so material to do that. The HPT302 is a "needs lots of
testing" case still, as is pretty much all HPT later than the 366.
>>>>> "Alan" == Alan Cox <[email protected]> writes:
Alan> Ar Gwe, 2006-09-29 am 13:51 -0400, ysgrifennodd John Stoffel:
Jeff> I updated the info at http://linux-ata.org/ to match the current
Jeff> code in linux-2.6.git.
>>
>> Thanks!
>>
Jeff> Let me know if something is missing or in error.
>>
>> It would be nice to have more details about PATA support. I'm hoping
>> to test my HPT302 rev1 card with 2.6.18-mm2 tonight if all goes
>> well...
Alan> I've sent Jeff so material to do that. The HPT302 is a "needs
Alan> lots of testing" case still, as is pretty much all HPT later
Alan> than the 366.
I'm happy to test that code as well, if you care to bounce me a patch
vs. 2.6.18-mm2, or any reasonably recent kernel. My latest tests have
basically just bombed big time, with lots of errors.
John
Jeff Garzik wrote:
> Prakash Punnoor wrote:
>> Well, how would one debug it w/o hw docs? Or is it possible to compare
>> the patch with a working driver for another chipset?
>
> Well, it is based off of the standard ADMA[1] specification, albeit with
> modifications. There is pdc_adma.c, which is also based off ADMA. And
> the author (from NVIDIA) claims that the driver worked at one time, so
> maybe it is simply bit rot that broke the driver.
>
> If I knew the answer, it would be fixed, so the best answer
> unfortunately is "who knows".
>
> I wish I had the time. But I also wish I had a team of programmers
> working on libata, too ;-)
Do you know exactly what is allegedly broken in that version? I see that
there are some functions which are just "TODO"..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
> Jeff Garzik wrote:
>> Prakash Punnoor wrote:
>>> Well, how would one debug it w/o hw docs? Or is it possible to
>>> compare the patch with a working driver for another chipset?
>>
>> Well, it is based off of the standard ADMA[1] specification, albeit
>> with modifications. There is pdc_adma.c, which is also based off
>> ADMA. And the author (from NVIDIA) claims that the driver worked at
>> one time, so maybe it is simply bit rot that broke the driver.
>>
>> If I knew the answer, it would be fixed, so the best answer
>> unfortunately is "who knows".
>>
>> I wish I had the time. But I also wish I had a team of programmers
>> working on libata, too ;-)
>
> Do you know exactly what is allegedly broken in that version? I see that
> there are some functions which are just "TODO"..
I just know it was a working driver at one time.
Jeff
Am Freitag 29 September 2006 12:03 schrieb Jeff Garzik:
> Prakash Punnoor wrote:
> > Well, how would one debug it w/o hw docs? Or is it possible to compare
> > the patch with a working driver for another chipset?
>
> Well, it is based off of the standard ADMA[1] specification, albeit with
> modifications. There is pdc_adma.c, which is also based off ADMA. And
> the author (from NVIDIA) claims that the driver worked at one time, so
> maybe it is simply bit rot that broke the driver.
Well, I tried to hack the patch into 2.6.18 driver, but wasn't very
successful. It migt be also due to the case that I have a MCP51 chipset and
if I read the patch correctly it isn't designed to activate ADMA on MCP51.
Do you know whether MCP51 knows ADMA? If not, how is NCQ to be activated on
MCP51? According to nvidia.com and windows user reports MCP51 does know NCQ.
Cheers,
--
(?= =?)
//\ Prakash Punnoor /\\
V_/ \_V
Prakash Punnoor wrote:
> Am Freitag 29 September 2006 12:03 schrieb Jeff Garzik:
>> Prakash Punnoor wrote:
>>> Well, how would one debug it w/o hw docs? Or is it possible to compare
>>> the patch with a working driver for another chipset?
>> Well, it is based off of the standard ADMA[1] specification, albeit with
>> modifications. There is pdc_adma.c, which is also based off ADMA. And
>> the author (from NVIDIA) claims that the driver worked at one time, so
>> maybe it is simply bit rot that broke the driver.
>
> Well, I tried to hack the patch into 2.6.18 driver, but wasn't very
> successful. It migt be also due to the case that I have a MCP51 chipset and
> if I read the patch correctly it isn't designed to activate ADMA on MCP51.
> Do you know whether MCP51 knows ADMA? If not, how is NCQ to be activated on
> MCP51? According to nvidia.com and windows user reports MCP51 does know NCQ.
The same Windows driver supports all of:
CK804SSS="NVIDIA nForce4 Serial ATA Controller"
MCP51S="NVIDIA nForce 430/410 Serial ATA Controller"
MCP55S="NVIDIA nForce 590/570/550 Serial ATA Controller"
From looking at the patch it seems to only use the ADMA code for CK804
only. Probably the others use the same programming interface (though who
knows if they implemented a totally different one in the same Windows
driver). I guess you could try hacking it to use ADMA on that controller
and see what happens..
I have an nForce4 board and it would be nice if we could have working
NCQ, though I haven't really played with libata before. I may experiment
with it a bit, though - Jeff, what kernel was this patch against? It
obviously won't apply to current -mm, that nv_host_desc structure it is
patching is gone for one thing..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Jeff Garzik wrote:
> Robert Hancock wrote:
>> Jeff Garzik wrote:
>>> Prakash Punnoor wrote:
>>>> Well, how would one debug it w/o hw docs? Or is it possible to
>>>> compare the patch with a working driver for another chipset?
>>>
>>> Well, it is based off of the standard ADMA[1] specification, albeit
>>> with modifications. There is pdc_adma.c, which is also based off
>>> ADMA. And the author (from NVIDIA) claims that the driver worked at
>>> one time, so maybe it is simply bit rot that broke the driver.
>>>
>>> If I knew the answer, it would be fixed, so the best answer
>>> unfortunately is "who knows".
>>>
>>> I wish I had the time. But I also wish I had a team of programmers
>>> working on libata, too ;-)
>>
>> Do you know exactly what is allegedly broken in that version? I see
>> that there are some functions which are just "TODO"..
>
> I just know it was a working driver at one time.
I had a look at the ADMA patch. It looks like it is vaguely based off
the ADMA spec, though with some significant changes (i.e. 64-bit
addresses instead of 32-bit, some things are missing or at least not
defined in the constants provided in the patch).
I think the code will more or less work in ADMA mode with NCQ disabled
(i.e. how it is in the patch currently, with #define NV_ADMA_NCQ
commented out). However, with NCQ on there would be a few problems:
-When the driver gets a command which is not DMA-mapped (i.e. PIO
commands), it switches the controller from ADMA mode into port-register
mode and then issues the command in the existing fashion. This isn't
going to work very well if there are already NCQ command(s) in progress,
which I assume is a possibility. Either the driver needs to stall the
PIO command until all the NCQ commands are done and prevent any other
NCQ commands starting while the PIO is in progress (is this viable?), or
it needs to push the PIO command through the ADMA pipeline. The ADMA
standard provides a means for executing PIO commands through the
pipeline using PIO-over-DMA, but there's not enough info to say whether
the NVIDIA controller implements that the same way or at all. Jeff, you
may be able to help with this if you have access to the docs.
-Inside the interrupt handler the driver uses ata_qc_from_tag(ap,
ap->active_tag) to find the qc which was just completed. This won't work
in NCQ as active_tag is not used and multiple commands may be in
progress. It should be checking the CPB flags on all the active CPBs to
see which one(s) have completed (or maybe the hardware has a register
that indicates which CPBs have been completed already, the patch doesn't
provide a hint of how that would work however).
So it looks like it needs some work before NCQ will work properly.
However, there would be some gains to getting ADMA working even without
NCQ, both in terms of reduced CPU overhead. Also, ADMA supports full
64-bit DMA as opposed to the 32-bit DMA capability of the standard
interface, which would reduce IOMMU load on systems with RAM above 4GB.
(Note that this is broken in the patch currently, the sg addresses get
dumped into a u32 and truncated before they are written to the
controller, and it also doesn't set a 64-bit DMA mask in ADMA mode..)
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
[cc'ing linux-ide]
Robert Hancock wrote:
> Jeff Garzik wrote:
>> Robert Hancock wrote:
>>> Jeff Garzik wrote:
>>>> Prakash Punnoor wrote:
>>>>> Well, how would one debug it w/o hw docs? Or is it possible to
>>>>> compare the patch with a working driver for another chipset?
>>>>
>>>> Well, it is based off of the standard ADMA[1] specification, albeit
>>>> with modifications. There is pdc_adma.c, which is also based off
>>>> ADMA. And the author (from NVIDIA) claims that the driver worked at
>>>> one time, so maybe it is simply bit rot that broke the driver.
>>>>
>>>> If I knew the answer, it would be fixed, so the best answer
>>>> unfortunately is "who knows".
>>>>
>>>> I wish I had the time. But I also wish I had a team of programmers
>>>> working on libata, too ;-)
>>>
>>> Do you know exactly what is allegedly broken in that version? I see
>>> that there are some functions which are just "TODO"..
>>
>> I just know it was a working driver at one time.
>
> I had a look at the ADMA patch. It looks like it is vaguely based off
> the ADMA spec, though with some significant changes (i.e. 64-bit
> addresses instead of 32-bit, some things are missing or at least not
> defined in the constants provided in the patch).
>
> I think the code will more or less work in ADMA mode with NCQ disabled
> (i.e. how it is in the patch currently, with #define NV_ADMA_NCQ
> commented out). However, with NCQ on there would be a few problems:
>
> -When the driver gets a command which is not DMA-mapped (i.e. PIO
> commands), it switches the controller from ADMA mode into port-register
> mode and then issues the command in the existing fashion. This isn't
> going to work very well if there are already NCQ command(s) in progress,
> which I assume is a possibility. Either the driver needs to stall the
> PIO command until all the NCQ commands are done and prevent any other
> NCQ commands starting while the PIO is in progress (is this viable?), or
> it needs to push the PIO command through the ADMA pipeline.
Actually, libata core layer already does it. It never mixes NCQ and
non-NCQ commands. sata_nv can safely assume that those two sets of
commands are always issued disjointly. The relevant function is
libata-scsi.c::ata_scmd_need_defer().
> The ADMA
> standard provides a means for executing PIO commands through the
> pipeline using PIO-over-DMA, but there's not enough info to say whether
> the NVIDIA controller implements that the same way or at all. Jeff, you
> may be able to help with this if you have access to the docs.
It would be nice to have that but I'm doubtful it would worth the
effort. I would just leave it as it is as long as it works.
> -Inside the interrupt handler the driver uses ata_qc_from_tag(ap,
> ap->active_tag) to find the qc which was just completed. This won't work
> in NCQ as active_tag is not used and multiple commands may be in
> progress. It should be checking the CPB flags on all the active CPBs to
> see which one(s) have completed (or maybe the hardware has a register
> that indicates which CPBs have been completed already, the patch doesn't
> provide a hint of how that would work however).
>
> So it looks like it needs some work before NCQ will work properly.
> However, there would be some gains to getting ADMA working even without
> NCQ, both in terms of reduced CPU overhead. Also, ADMA supports full
> 64-bit DMA as opposed to the 32-bit DMA capability of the standard
> interface, which would reduce IOMMU load on systems with RAM above 4GB.
> (Note that this is broken in the patch currently, the sg addresses get
> dumped into a u32 and truncated before they are written to the
> controller, and it also doesn't set a 64-bit DMA mask in ADMA mode..)
Not only that, hopefully, it will show better EH behavior. sata_nv's TF
register mode sometimes hangs holding PCI bus (as in IORDY lockup).
This happens a lot if you pull a disk out while it's actively processing
a command but doesn't seem to be restricted to that. Also, it has been
suggested that sata_nv's TF register mode might involve some nasty SMM
code. I don't recall whether it was verified tho.
Anyways, it would be very nice to have working nv_adma. I have a CK804
nv but it's my primary work machine and I'm too lazy to develop on it,
but I would be more than happy to test or answer questions.
Thanks.
--
tejun
Hi Jeff,
On 9/29/06, Jeff Garzik <[email protected]> wrote:
> Software status:
> http://linux-ata.org/software-status.html
It says:
"Over and above the power management specified in the ATA/ATAPI
specification, one can aggressively control the power consumption of
SATA hosts, the SATA bus, and the SATA device. [...]
There is little demand at the present time for aggressive, automatic
power management under Linux."
What about laptops on batteries? Pavel reports a 1W power draw by his
ThinkPad's ICH7M SATA controller [1]. It would be neat to eliminate
this when the disk is not in use (and powering up the silicon can't
take much longer than spinning up a chunk glass to 7200RPM).
Shem
[1] http://atrey.karlin.mff.cuni.cz/~pavel/swsusp/8hours.pdf
slide 11