PATA drivers in libata?

PATA drivers in libata?

[Jeff Garzik]

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?

Re: PATA drivers in libata?

[Mark Hahn]

> * 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?

Re: PATA drivers in libata?

[Jeff Garzik]

Mark Hahn wrote:
>>* 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

Re: PATA drivers in libata?

[Alan Cox]

On Sul, 2005-02-13 at 18:51, Jeff Garzik wrote:
> 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).

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)

> * 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

> * pci_enable_device() issues?

Nothing really special there, pci_disable_device can be funny thats all.

> * power management differences?

AFAIK only the "I have a cache but no flush command" issue

I'm all for burying the old IDE layer

Re: PATA drivers in libata?

[Jeff Garzik]

Alan Cox wrote:
> On Sul, 2005-02-13 at 18:51, Jeff Garzik wrote:
> 
>>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).
> 
> 
> 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

Re: PATA drivers in libata?

[Doug Maxey]

On Sun, 13 Feb 2005 17:01:51 EST, Jeff Garzik wrote:
>Mark Hahn wrote:
>>>* 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

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

Re: PATA drivers in libata?

[Jeff Garzik]

On Sun, Feb 13, 2005 at 06:19:31PM -0600, Doug Maxey wrote:
> 
> On Sun, 13 Feb 2005 17:01:51 EST, Jeff Garzik wrote:
> >Mark Hahn wrote:
> >>>* 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
> 
> 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

Re: PATA drivers in libata?

[Alan Cox]

On Llu, 2005-02-14 at 00:16, Jeff Garzik wrote:
> 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

Re: PATA drivers in libata?

[Benjamin Herrenschmidt]

On Sun, 2005-02-13 at 13:51 -0500, Jeff Garzik wrote:
> 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?"

Yes.

> * 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?

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.

> * 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.
 

Re: PATA drivers in libata?

[Benjamin Herrenschmidt]

On Mon, 2005-02-14 at 20:42 +0000, Alan Cox wrote:
> On Llu, 2005-02-14 at 00:16, Jeff Garzik wrote:
> > 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.

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.