Re: libata PATA support - work items?

Re: libata PATA support - work items?

[Jeff Garzik]

Eric Mudama wrote:
> On Thu, 30 Dec 2004 18:42:33 +0800, Albert Lee <albertcc@tw.ibm.com> wrote:
> 
>>    2. C/H/S addressing; libata currently hardcoded to use LBA
> 
> 
> 
> Are there really people who want to run a newer 2.4 or a 2.6 kernel,
> who have disks that do not support LBA mode?  CHS will never address
> more than 32GB of the drive (unless you use vendor unique
> implementations) and heck, most companies don't even build drives that
> small anymore...  CHS is very messy, LBA is so much simpler.   Can we
> just stick with that?


Well.......  :)

Originally when I started libata, I targetted it at modern PCI IDE BMDMA 
(i.e. Intel ICH4-like) controllers, with an eye towards FIS-based 
controllers such as Intel AHCI or SiI 3124.

As a result, I intentionally hardcoded several things such as LBA 
support, when writing libata.

Over time, I have consistently seen these "hardcode it" decisions 
reversed, and the hardcoding removed, mainly to add support for 
controllers that are an existing PATA chip (with no SATA modifications) 
glued next to a PATA->SATA transparent bridge.  These controllers 
essentially require PATA support.  Also, in the community, Bart, Alan 
Cox, and others (hi Albert) have been interested in supporting some PATA 
controllers with libata.

So while my original intention with libata was "Bart does the IDE driver 
for PATA, and I do the IDE driver for SATA", and make a clean break, it 
seems that libata is moving more and more towards eventually having full 
PATA support for many controllers, with all that entails.

So, that said, I think it is important for libata to fully support PATA, 
if it is to support it at all.  That means handling the errata that Alan 
always bugs me about, and that means handling C/H/S support as well.

	Jeff

Re: libata PATA support - work items?

[Alan Cox]

On Maw, 2005-01-04 at 23:41, Jeff Garzik wrote:
> So, that said, I think it is important for libata to fully support PATA, 
> if it is to support it at all.  That means handling the errata that Alan 
> always bugs me about, and that means handling C/H/S support as well.

I think so. If it supports all the features of the old IDE layer we get
to have a party when we eliminate the need for drivers/ide once and for
all.

That means
- Hotplug (controller and disk)
- CHS
- "Not quite generic" IDE DMA (eg CS5520)
- VDMA (eg CS5520)
- IORDY timers (not handled well in drivers/ide but needed)
- Funky Maxtor "LBA48.. maybe" oddments
- Missing slave detection
- Controller errata hooks (modes, drives, timings, "dont touch during an
I/O" etc)
- Drive nIEN bugs
- No nIEN cases
- Drives that don't do some DMA/modes right
- Crazy shit "Don't DMA from the page below 640K" (not handled by
drivers/ide but an AMD errata
	fixed by using a PS/2 mouse)
- Serialize (RZ1000, CMD640, some 469, etc)
- Bandwidth arbiter (not in drivers/ide but needed)
- Non PCI shared IRQ mess 8(

Hopefully most of this can be buried away in a pata-errata.c 8)

Re: libata PATA support - work items?

[Jeff Garzik]

Alan Cox wrote:
> That means
> - Hotplug (controller and disk)

mostly either there, or easy to add

> - CHS

nod


> - "Not quite generic" IDE DMA (eg CS5520)
> - VDMA (eg CS5520)

existing hooks can handle these


> - IORDY timers (not handled well in drivers/ide but needed)

I think I know what this is.


> - Funky Maxtor "LBA48.. maybe" oddments

details?


> - Missing slave detection

Not missing, master/slave has been working for ages.  Needed for 
combined mode, where a SATA device can appear as a slave.


> - Controller errata hooks (modes, drives, timings, "dont touch during an
> I/O" etc)

Controller hooks for most situations already exist, for the most part. 
Device hooks are what is lacking.


> - Drive nIEN bugs

ditto above ("device hooks are lacking")


> - No nIEN cases

already handled in at least one case (AHCI)


> - Drives that don't do some DMA/modes right

easily doable with existing hooks


> - Crazy shit "Don't DMA from the page below 640K" (not handled by
> drivers/ide but an AMD errata
> 	fixed by using a PS/2 mouse)

heh, interesting


> - Serialize (RZ1000, CMD640, some 469, etc)

non-trivial but doable (and planned-for)


> - Bandwidth arbiter (not in drivers/ide but needed)

interesting


> - Non PCI shared IRQ mess 8(

details?

Thanks,

	Jeff

Re: libata PATA support - work items?

[Alan Cox]

On Mer, 2005-01-05 at 02:42, Jeff Garzik wrote:
> > - IORDY timers (not handled well in drivers/ide but needed)
> I think I know what this is.

The SII has support for this in the h/w btw (see the docs). Otherwise
IDE as a protocol can get stuck if the drive enters rotating doorstop
mode at the wrong moment.

> > - Funky Maxtor "LBA48.. maybe" oddments
> details?

There are a couple of "yes we do LBA48" "no we don't do this command in
LBA48" cases with maxtors (Cache flush is one, the stroke stuff triggers
another)

> > - Missing slave detection
> 
> Not missing, master/slave has been working for ages.  Needed for 
> combined mode, where a SATA device can appear as a slave.

No no - some devices have a master and a slave on them when you detect
but only one disk attached because they forgot to bother decoding it in
the adapter (eg some pcmcia with microdrives). This causes bad shit
especially with hal style automounting.

> > - Bandwidth arbiter (not in drivers/ide but needed)
> interesting

Its effectively serialize I think that is needed but with >1 at a time.

> > - Non PCI shared IRQ mess 8(
> details?

ISA IRQ lines - two controllers, one IRQ but edge triggered and not
sharable directly. The core old IDE code actually supports all of this
and people have run stuff like 6 ISA IDE controllers in a PC.[1]

Alan
[1] Seek medical advice before trying this at home

Re: libata PATA support - work items?

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

> - Crazy shit "Don't DMA from the page below 640K" (not handled by
> drivers/ide but an AMD errata
> 	fixed by using a PS/2 mouse)

This is already fixed in setup.c by reserving a page.  Since early
CPU detect went in it should actually work now too.

-Andi

Re: libata PATA support - work items?

[Bartlomiej Zolnierkiewicz]

On Wed, 05 Jan 2005 00:50:05 +0000, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Maw, 2005-01-04 at 23:41, Jeff Garzik wrote:
> > So, that said, I think it is important for libata to fully support PATA,
> > if it is to support it at all.  That means handling the errata that Alan
> > always bugs me about, and that means handling C/H/S support as well.
> 
> I think so. If it supports all the features of the old IDE layer we get
> to have a party when we eliminate the need for drivers/ide once and for
> all.
> 
> That means
> - Hotplug (controller and disk)
> - CHS
> - "Not quite generic" IDE DMA (eg CS5520)
> - VDMA (eg CS5520)
> - IORDY timers (not handled well in drivers/ide but needed)
> - Funky Maxtor "LBA48.. maybe" oddments
> - Missing slave detection
> - Controller errata hooks (modes, drives, timings, "dont touch during an
> I/O" etc)
> - Drive nIEN bugs
> - No nIEN cases
> - Drives that don't do some DMA/modes right
> - Crazy shit "Don't DMA from the page below 640K" (not handled by
> drivers/ide but an AMD errata
>         fixed by using a PS/2 mouse)
> - Serialize (RZ1000, CMD640, some 469, etc)
> - Bandwidth arbiter (not in drivers/ide but needed)
> - Non PCI shared IRQ mess 8(
> 
> Hopefully most of this can be buried away in a pata-errata.c 8)

:-)

few more:
- Power Management for devices
- 32 bit I/O support
- Multiple Mode PIO support
- Host Protected Area support
  (can be done from user-space but "coldplug" is needed)
- ide-{cd,disk,floppy,tape}.c specific quirks