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

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

Hello.

Chad Reese wrote:

> +    /*
> +     * Don't stop the DMA if the device deasserts DMARQ. Many compact
> +     * flashes deassert DMARQ for a short time between sectors. 
> Instead of

   It's perfectly legal to do for any IDE device -- even not on the 
sector boundaries.

> +     * stoppng and restarting the DMA, we'll let the hardware do it. 
> If the

   stopping

> +     * DMA is really stopped early due to an error condition, a later
> +     * timeout will force us to stop.

   Sigh... So any command error will result in a timeout. I wonder what 
hardware genius decided that CF doesn't need an IRQ...

>>    Also, this fragment of octeon_cf_bmdma_status() looks doubtful to me:
>>     
>>> +    else if (mio_boot_dma_cfg.s.size != 0xfffff)
>>> +        result |= ATA_DMA_ERR; 
>>>       
>>    I suppose this only makes sense when DMA interrupt is active. What 
>> does this bitfield mean?
>>     
>
> When you start the Octeon DMA engine, you program
> mio_boot_dma_cfg.s.size with the number of 16bit words to transfer. As
> the DMA runs, the hardware decrements this field. At the end it ends up
> decrementing past 0 to -1. The above check is simply checking if the DMA
>   

   What warrants that 0xfffff doesn't mean 2 MB transfer?

> completed. Since this specific interrupt can only be generated by the
> DMA engine, it must have been caused by an error condition if the size
> is not -1.
>   

   Note that In the real SFF-8038i BMDMA, error bit doesn't cause an 
interrupt...

> Chad
>   

MBR, Sergei