sata_promise and SATA+PATA controllers in general

sata_promise and SATA+PATA controllers in general

[David Lloyd]

I've got one of those promise controllers with 2 SATA ports and 1 PATA 
port and I've been looking at a couple variations on how the driver has 
been made to work with this setup.

Gentoo has a patch (against 2.6.10) that allows this to work (as far as I 
can tell) by putting an if statement in each operation that is different 
between PATA and SATA, and making the decision at runtime on how to handle 
each port.

This patch does not apply against 2.6.14-rc1 for various reasons.  The 
2.6.14-rc1 driver has separate ata_port_operations structures for PATA and 
SATA; however, since only one can be used at a time, my promise controller 
(PDC20378) as well as any other SATA+PATA controller that follows this 
structure cannot use the PATA port.  I hacked around this by simply using 
the PATA structure exclusively (obviously making my SATA ports useless) to 
allow me to boot, but it got me to thinking.

A while back (almost a year ago, in fact) Jeff Garzik posted a message [1] 
stating that the two things that need to be done to support these types of 
controllers are to add support for multiple ata_port_operations structures 
to both ata_probe_ent and ata_host_set.

I noticed that the sata_promise driver does in fact have separate port_ops 
for pata and sata, but since each controller only supports one of these, 
SATA+PATA controllers are still not fully functional in mainline.

Is this still the right direction to go?

Does this mean have e.g. a pata_port_ops member as well as a sata_port_ops 
member on the ata_probe_ent/ata_host_set, and mark each port as being 
either PATA or SATA with a flag of some sort?  Or, would it be best to 
have a port_ops pointer per port?

[1] http://marc.theaimsgroup.com/?l=linux-ide&m=109606830029825&w=2

- D

Re: sata_promise and SATA+PATA controllers in general

[Jeff Garzik]

David Lloyd wrote:
> Does this mean have e.g. a pata_port_ops member as well as a 
> sata_port_ops member on the ata_probe_ent/ata_host_set, and mark each 
> port as being either PATA or SATA with a flag of some sort?  Or, would 

definitely not.


> it be best to have a port_ops pointer per port?

Each port should be able to export unique behavior.  That implies having 
per-port hooks, since host-global hooks make it impossible for one port 
to have different hooks from another port.

Establishing a global limit of two unique behaviors (sata_port_ops, 
pata_port_ops) is not scalable at all.

Further complicating things, some hooks (such as ->irq_clear) are 
host-wide hooks and not port-specific hooks.

	Jeff

Re: sata_promise and SATA+PATA controllers in general

[David Lloyd]

On Sun, 18 Sep 2005, Jeff Garzik wrote:

> Further complicating things, some hooks (such as ->irq_clear) are 
> host-wide hooks and not port-specific hooks.

Looks like what is needed is a host_ops kind of structure that would 
contain irq_handler, irq_clear (it seems as if irq_clear generally 
operates on a port, however, so that makes it kinda odd), and host_stop, 
maybe others too; then these members would be moved there, and 
ata_probe_ent would get a pointer to this structure, as would 
ata_host_set.

As an aside, is ata_probe_ent supposed to represent the entire controller 
or simply a single port?  It looks like sometimes it does one role, 
sometimes the other.  If the former, then I guess the port_ops pointer 
should become an array of size ATA_MAX_PORTS.

Answers or comments appreciated.

- D