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

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

Hello, I just wrote:

>> +     * 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

   I'm not sure which error condition is meant here: ERR=1 in the status 
register, some internal DMA error, both?

>> +     * 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...

   All this makes me think that since the DMA error condition cannot be 
reliably detected, you'd better not try to emulate the BMDMA error bit 
as well...

>>>> +    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
>>   
>    Also, this fragment of octeon_cf_bmdma_status() looks doubtful to me:
>
>   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...

   So, Octeon DMA can actually generate an error interrupt?

MBR, Sergei