Re: [RFC][PATCH] at91_ide driver

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

Hello.

Stanislaw Gruszka wrote:

>>>You really don't want to put special board specific code in generic
>>>locations. In the libata case you don't need to and I think in the ide
>>>case you can avoid it too by wrapping the IRQ handler.

>>   Unfortunately, it seems you can't wrap ide_intr(), at least with the 
>>current code.

> Perhaps only EXPORT_SYMBOL is missed.

    No, init_irq() always calls request_irq() with ide_intr as argument.

>>>Libata also supports polled mode.

>>   Yeah. Stanslaw, I'd (have to) advise going the libata way in this 
>>case -- in case you want to avoid the additional trouble of porting this 
>>broken-minded IRQ implementation to the IDE core... 

> I think, I will try to add AT91 stuff for pata_at91 to have this hardware
> support in mineline. I will also finish at91_ide for my company usage with
> older kernel.

    Well, it can also be accepted into the IDE subsystem (minus the IRQ hack) 
-- it would fit the embedded use case better due to a lower memory  footprint 
(and not having to emulate SCSI). Libata has been known to lose to IDE core in 
the PIO transfer speeds (very significantly) though I'm not sure of the 
current state of affairs...

>>   Stanislaw's patch is adding the DIOx- to address hold time (t9) to 
>>the existing ones. While there's has been already a patch by David Daney 
>>adding this timing to libata (however, the author have ditched this idea 
>>finally), the table in ide-timings.c still misses it, as well as the PIO 
>>mode 6 timings...

> I use t9 for calculating memory controller settings, but maybe it is unneeded,
> pata_at91 don't use this value.

    You mean pata_at32? It might have been that this detail was missed...

> Cheers
> Stanislaw Gruszka

WBR, Sergei