PATA drivers in libata?
I wanted to open a discussion on libata and PATA.
libata-dev now has two drivers that support PATA, pata_pdc2027x and ata_piix, and the core is getting close (DMA blacklist in, C/H/S support close).
What are the opinions on issues relating to making PATA libata support available in the upstream kernel? Here's my random list.
* I think CONFIG_IDE should continue to be the default answer for "what driver do I use for PATA?"
* Should there be a config option similar to CONFIG_BLK_DEV_IDE_SATA, called CONFIG_SCSI_ATA_PATA? A runtime 'pata' module option? Should we include 'DANGER DANGER conflicts with CONFIG_IDE' in the Kconfig description?
* With ATA passthru (in libata-dev currently), libata supports SMART and the HDIO_CMD/HDIO_TASK generalized ioctls. Should I care about supporting other ioctls?
* pci_enable_device() issues?
* power management differences?
Quoted 3 lines
* With ATA passthru (in libata-dev currently), libata supports SMART and the HDIO_CMD/HDIO_TASK generalized ioctls. Should I care about supporting other ioctls?
is there some other mechanism to en/disable write caching?
Quoted 4 lines · Mark Hahn
Quoted 1 line
* With ATA passthru (in libata-dev currently), libata supports SMART and the HDIO_CMD/HDIO_TASK generalized ioctls. Should I care about supporting other ioctls?
is there some other mechanism to en/disable write caching?
Besides the SG_IO | HDIO_DRIVE_CMD | HDIO_DRIVE_TASK | HDIO_DRIVE_TASKFILE ioctls? Nope.
Jeff
Quoted 6 lines · Jeff Garzik
Quoted 5 lines · Mark Hahn
Quoted 3 lines
* With ATA passthru (in libata-dev currently), libata supports SMART and the HDIO_CMD/HDIO_TASK generalized ioctls. Should I care about supporting other ioctls?
Quoted 6 lines
Quoted 1 line
is there some other mechanism to en/disable write caching?
Besides the
SG_IO|HDIO_DRIVE_CMD|HDIO_DRIVE_TASK|HDIO_DRIVE_TASKFILEioctls? Nope.Jeff
One thing that I would hope for is the ability to recognize that a drive may prefer the use of write cache be set by the drive, defaulting to off, and not have to come back later and turn it off. Certain drives destined to be used in server class machines will be coming that way.
++doug
Quoted 13 lines · Doug Maxey
Quoted 11 lines · Jeff Garzik
Quoted 6 lines · Mark Hahn
Quoted 3 lines
* With ATA passthru (in libata-dev currently), libata supports SMART and the HDIO_CMD/HDIO_TASK generalized ioctls. Should I care about supporting other ioctls?
is there some other mechanism to en/disable write caching?
Besides the
SG_IO|HDIO_DRIVE_CMD|HDIO_DRIVE_TASK|HDIO_DRIVE_TASKFILEioctls? Nope.
Quoted 6 lines
Quoted 1 line
Jeff
One thing that I would hope for is the ability to recognize that a drive may prefer the use of write cache be set by the drive, defaulting to off, and not have to come back later and turn it off. Certain drives destined to be used in server class machines will be coming that way.
Chuckle. I saw you had this discussion with Bart also.
Although libata doesn't touch the write-cache setting right now, I reserve the right to do so in the future.
Therefore, situations where the write cache is to be disabled should modify their initscripts, just like you would if you wish to tune your drive at boot using hdparm(1) or blktool(1).
Jeff
Quoted 3 lines · Jeff Garzik
libata-dev now has two drivers that support PATA,
pata_pdc2027xandata_piix, and the core is getting close (DMA blacklist in, C/H/S support close).
Do you have DMA change down sorted - CRC error, drop speed and/or switch to PIO then later flip back. Thats one real horror to get right and one thats badly screwy in the current IDE code (-ac IDE can hang the box for ages, base will sometimes crash)
Quoted 3 lines
* With ATA passthru (in libata-dev currently), libata supports SMART and the HDIO_CMD/HDIO_TASK generalized ioctls. Should I care about supporting other ioctls?
I'd rather the libata driver just had the sane ioctls
Quoted 1 line
*
pci_enable_device()issues?
Nothing really special there, pci_disable_device can be funny thats all.
Quoted 1 line
* power management differences?
AFAIK only the "I have a cache but no flush command" issue
I'm all for burying the old IDE layer
Quoted 9 lines · Alan Cox
Quoted 1 line · Jeff Garzik
libata-dev now has two drivers that support PATA,
pata_pdc2027xandata_piix, and the core is getting close (DMA blacklist in, C/H/S support close).Do you have DMA change down sorted - CRC error, drop speed and/or switch to PIO then later flip back. Thats one real horror to get right and one thats badly screwy in the current IDE code (-ac IDE can hang the box for ages, base will sometimes crash)
Error handling is -very- stupid simple right now: if we get an error, report that error in the struct request [based on your ATA -> SCSI sense conversion] back to upper layer.
It needs to be fleshed out into separate host bus / ATA bus / device errors, and handled accordingly.
Jeff
Quoted 6 lines · Jeff Garzik
Error handling is -very- stupid simple right now: if we get an error, report that error in the struct request [based on your ATA -> SCSI sense conversion] back to upper layer.
It needs to be fleshed out into separate host bus / ATA bus / device errors, and handled accordingly.
Thats a barrier to real PATA IDE I guess then. We see a lot of cable errors and speed change downs and not all are caused by misdetecting 80wire cables.
The current IDE layer does speed changes synchronously outside the state machine which makes a nasty mess when your error handling interrupt state wants to speed change.
Alan
Quoted 8 lines · Alan Cox
Quoted 6 lines · Jeff Garzik
Error handling is -very- stupid simple right now: if we get an error, report that error in the struct request [based on your ATA -> SCSI sense conversion] back to upper layer.
It needs to be fleshed out into separate host bus / ATA bus / device errors, and handled accordingly.
Quoted 7 lines
Thats a barrier to real PATA IDE I guess then. We see a lot of cable errors and speed change downs and not all are caused by misdetecting 80wire cables.
The current IDE layer does speed changes synchronously outside the state machine which makes a nasty mess when your error handling interrupt state wants to speed change.
It's not _too_ bad ... you can just put the current request "on hold" (and block the queue) until the thread finishes with the speed change, but I tend to think nowadays that the state machine approach might be better in the long run (even if a bit more complex to implement in the first place).
Ben.
Quoted 11 lines · Jeff Garzik
I wanted to open a discussion on libata and PATA.
libata-dev now has two drivers that support PATA,
pata_pdc2027xandata_piix, and the core is getting close (DMA blacklist in, C/H/S support close).What are the opinions on issues relating to making PATA libata support available in the upstream kernel? Here's my random list.
* I think
CONFIG_IDEshould continue to be the default answer for "what driver do I use for PATA?"
Yes.
Quoted 4 lines
* Should there be a config option similar to
CONFIG_BLK_DEV_IDE_SATA, calledCONFIG_SCSI_ATA_PATA? A runtime 'pata' module option? Should we include 'DANGER DANGER conflicts withCONFIG_IDE' in theKconfigdescription?
Eventually... I'm thinking I may port the "macio" IDE to libata one day, but for now, I still need both drivers/ide for it and libata for SATA.
Quoted 7 lines
* With ATA passthru (in libata-dev currently), libata supports SMART and the HDIO_CMD/HDIO_TASK generalized ioctls. Should I care about supporting other ioctls?
*
pci_enable_device()issues?* power management differences?
Well, libata doesn't have power management proper at all for now. In fact, I need to do something at the generic SCSI level similar to what I did for drivers/ide, that is turning the PM callbacks into requests down the queues etc... but I don't have any SCSI or libata HW that can power manage at the moment, so I didn't quite bother yet.
(Though if I ported "macio" IDE ... )
Ultimately, it will have to be done for things like USB & firewire too anyway. So maybe I should start working on this soonish. I talked a bit with jejb at OLS a year or 2 ago about the way to do it, it shouldn't be that much different than what I do in drivers/ide, but then, I know pretty much nothing about the linux scsi layer...
Ben.