Re: [PATCH] ide: New libata driver for OCTEON SOC Compact Flash interface.

[Sergei Shtylyov <sshtylyov@ru.mvista.com>]

Hello, I wrote:

>>> diff --git a/drivers/ata/pata_octeon_cf.c 
>>> b/drivers/ata/pata_octeon_cf.c
>>> new file mode 100644
>>> index 0000000..e8712c0
>>> --- /dev/null
>>> +++ b/drivers/ata/pata_octeon_cf.c
>>> @@ -0,0 +1,942 @@
>> [...]
>>> +/**
>>> + * Get the status of the DMA engine. The results of this function
>>> + * must emulate the BMDMA engine expected by libata.
>>> + *
>>> + * @ap:     ATA port to check status on
>>> + *
>>> + * Returns BMDMA status bits
>>> + */
>>> +static uint8_t octeon_cf_bmdma_status(struct ata_port *ap)
>>> +{
>>> +    struct octeon_cf_data *ocd = ap->dev->platform_data;
>>> +    cvmx_mio_boot_dma_intx_t mio_boot_dma_int;
>>> +    cvmx_mio_boot_dma_cfgx_t mio_boot_dma_cfg;
>>> +    uint8_t result = 0;
>>> +
>>> +    mio_boot_dma_int.u64 =
>>> +        cvmx_read_csr(CVMX_MIO_BOOT_DMA_INTX(ocd->dma_engine));
>>> +    if (mio_boot_dma_int.s.done)
>>> +        result |= ATA_DMA_INTR;
>>
>>   But if you're saying that there is only DMA completion inetrrupt, 
>> you *cannot* completely emulate SFF-8038i BMDMA since its interrupt 
>> status is the (delayed) IDE INTRQ status. I suggest that you move 
>> away from the emulation -- Alan has said it's possible.
> As part of our efforts to get the Cavium OCTEON processor support
>
>   My suggestion then is not to emulate the ATA_DMA_INTR bit (always 
> returning it as 0)

   No, this is not an option because you chain to ata_sff_host_intr(). 
However, DMA interrupt status is *not* a substitute for SFF-8038i 
interrupt status (as it gets set on the S/G segment boundaries too), so 
you should employ the pure software emulation for this bit, only 
triggering before the control gets passed to ata_sff_host_intr().

> directly in octeon_cf_interrupt().
>

MBR, Sergei