Re: [PATCHSET #upstream] libata: separate out SFF and BMDMA

[Sergei Shtylyov <sshtylyov@mvista.com>]

Hello.

Tejun Heo wrote:

> This is the first take of separate-out-SFF-and-BMDMA patchset.
>
> Historically, ATA meant SFF (or TASKFILE interface) plus BMDMA and
> that holds true for many modern SATA controllers.  This was reflected
> in libata implementation and libata core layer and SFF/BMDMA support
> used to be all tangled in one piece.
>
> For SFF/BMDMA drivers, this assumption is fine but for drivers which
> have native interfaces (e.g. ahci, sata_sil24), this meant that those
> drivers had to emulate SFF/BMDMA to ceratin not-so-well defined level
> libata core layer expects.  A lot of this vague dependency on
> SFF/BMDMA was removed during recent SFF/BMDMA separation but there
> still are SFF/BMDMA specific assumptions in libata core layer.
>
> Another issue which surpassed with the addition of all the legacy,
> platform and somewhat peculiar PATA drivers is that now there are
> enough drivers which use SFF interface but use its own DMA interface
> or don't support DMA at all.  This, in similar fashion, led those
> drivers to fake certain level of BMDMA functionality to please the
> libata SFF/BMDMA layer.  This led to the following interesting
> solutions in low level drivers.
>
> 1. For BMDMA drivers which don't use traditional BMDMA register,
>    ata_bmdma_mode_filter() incorrectly inhibits DMA modes.  Those
>    drivers either have to inherit from ata_sff_port_ops or clear
>    ->mode_filter explicitly.
>
> 2. non-BMDMA drivers call into BMDMA PRD table allocation.  It doesn't
>    actually allocate PRD table if bmdma_addr is not initialized but is
>    still confusing.
>
> 3. For BMDMA drivers which don't use traditional BMDMA register, some
>    methods might not be invoked as expected (e.g. bmdma_stop from
>    ata_sff_post_internal_cmd()).
>
> 4. SFF drivers w/ custom DMA interface implement noop BMDMA ops
>    worrying libata core might call into one of them.
>
> This patchset further separates SFF/BMDMA support from the rest of the
> libata and separate out BMDMA from SFF.  This patchset contains the
> following 22 patches.
>
>  0001-pata_sch-use-ata_pci_sff_init_one.patch
>  0002-sata_inic162x-inic162x-is-not-dependent-on-CONFIG_A.patch
>  0003-sata_mv-remove-unnecessary-initialization.patch
>  0004-libata-sff-clear-IRQ-from-ata_sff_error_handler-o.patch
>  0005-libata-sff-kill-unused-prototype-and-make-ata_dev_s.patch
>  0006-libata-kill-ATA_FLAG_DISABLED.patch
>  0007-sata_inic162x-kill-PORT_PRD_ADDR-initialization.patch
>  0008-libata-sff-reorder-SFF-BMDMA-functions.patch
>  0009-pata_cmd640-bf54x-icside-fix-inheritance.patch
>  0010-libata-sff-clean-up-BMDMA-initialization.patch
>  0011-libata-sff-introduce-ata_sff_init-exit-and-ata_sf.patch
>  0012-libata-sff-ap-last_-ctl-are-SFF-specific.patch
>  0013-libata-sff-port_task-is-SFF-specific.patch
>  0014-libata-sff-separate-out-BMDMA-EHs.patch
>  0015-libata-sff-ata_sff_-dumb_-qc_prep-are-BMDMA-specifi.patch
>  0016-libata-sff-prd-is-BMDMA-specific.patch
>  0017-libata-sff-separate-out-BMDMA-qc_issue.patch
>  0018-libata-sff-ata_sff_irq_clear-is-BMDMA-specific.patch
>  0019-libata-sff-separate-out-BMDMA-irq-handler.patch
>  0020-libata-sff-separate-out-BMDMA-init.patch
>  0021-sata_qstor-kill-dummy-BMDMA-ops.patch
>  0022-libata-sff-make-BMDMA-optional.patch
>
> 0001-0010 make things aligned for the future changes.
>
>  0004 changes the default SFF error handler behavior such that
>  unnecessary register accesses are removed.  I'm fairly sure this
>  change is safe (tested on various SFF/BMDMA controllers) but we'll
>  need to look out for problem reports.
>
>  0006 kills ATA_FLAG_DISABLED (finally).  This patch touches SCSI SAS
>  drivers.
>
>  0010 cleans up BMDMA initialization and bmdma_addr condition checks.
>
> 0011-0013 further separate out SFF assumptions from libata core layer.
>
> 0014-0021 separate out BMDMA from SFF.
>
> 0022 makes BMDMA optional and reorganizes Kconfig options according to
> the groups of drivers they belong to.
>
> This patchset is on top of
>
>   linus#master (2515ddc6db8eb49a79f0fe5e67ff09ac7c81eab4)
> + [1] libata-sff-fix-ata_sff_post_internal_cmd
> + [2] libata-initialize-port_task-when-!CONFIG_ATA_SFF
> + [3] libata-eh-fix-slave-link-EH-action-mask-handling
> + [4] libata-transfer-EHI-control-flags-to-slave-ehc_i
>
> and makes the followings changes.

   Tejun, what was the fate of this patchset? Looks like it ended up 
ignored...

MBR, Sergei