[PATCH 0/3]ACPI support for SATA/PATA

[PATCH 0/3]ACPI support for SATA/PATA

[zhao, forrest]

Hello, all

In ACPI spec 3.0, section 9.9 defines 4 objects for PATA/SATA:

_GTM and _STM are PATA-only objects, which are used to get/set PATA
timing information(i.e. PIO and DMA speed);
_SDD is SATA-only object, which is used to inform the platform of the
type of device attached to a port;
_GTF is for both PATA and SATA, which is used to return ATA task file
needed to re-init the drive

In this patch set, 
ata_acpi_get_timing() is for getting PATA timing information;
ata_acpi_push_timing() is for setting PATA timing information;
ata_acpi_push_id() is for operating on _SDD;
ata_acpi_exec_tfs() is for getting ATA task file from _GTF and executing
them for a given drive

NOTE: ata_acpi_get_timing() and ata_acpi_push_timing() are channel
(port)-level operations, which have more suitable invocation place in
Tejun's upcoming PM patch. So I would not bother to reference(invoke)
them in this version of patches and will send out updated patches after
Tejun's PM patch is merged into #upstream.

Randy,
I'll add your sign-off line after you review the patch.

Thanks,
Forrest

Re: [PATCH 0/3]ACPI support for SATA/PATA

[Jeff Garzik]

zhao, forrest wrote:
> Hello, all
> 
> In ACPI spec 3.0, section 9.9 defines 4 objects for PATA/SATA:
> 
> _GTM and _STM are PATA-only objects, which are used to get/set PATA
> timing information(i.e. PIO and DMA speed);
> _SDD is SATA-only object, which is used to inform the platform of the
> type of device attached to a port;
> _GTF is for both PATA and SATA, which is used to return ATA task file
> needed to re-init the drive
> 
> In this patch set, 
> ata_acpi_get_timing() is for getting PATA timing information;
> ata_acpi_push_timing() is for setting PATA timing information;
> ata_acpi_push_id() is for operating on _SDD;
> ata_acpi_exec_tfs() is for getting ATA task file from _GTF and executing
> them for a given drive
> 
> NOTE: ata_acpi_get_timing() and ata_acpi_push_timing() are channel
> (port)-level operations, which have more suitable invocation place in
> Tejun's upcoming PM patch. So I would not bother to reference(invoke)
> them in this version of patches and will send out updated patches after
> Tejun's PM patch is merged into #upstream.

This is a great starting point for rejuvinating the SATA ACPI support, 
thanks!

I would request that you create two patches for this support:

Patch #1:  Adds everything needed to make SATA ACPI work...  Makefile, 
noacpi flag, core code, etc.

Patch #2:  Dependent on patch #1.  Adds everything needed to make PATA 
ACPI work.

And overall, I want to reinforce a principle used for Linux patches: 
applying 1-N patches for any given patchset should always produce a 
compileable (and _hopefully_ working) piece of code.  Patches are 
separated into _logical_ changes, much like the steps in a calculus proof.

Regards,

	Jeff