Re: [RFC][PATCH] at91_ide driver

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

Hello.

Stanislaw Gruszka wrote:

>>>>>>Well, we could add #ifdef with diffrent implementation of 
>>>>>>init_smc_mode(), set_8bit_mode(), etc... 

>>>>>  No, #ifdef'ery is certainly not an option.

>>>>Why?

>>>   It's totally ugly and unacceptable way of doing things. It seems also 
>>>totally wrong to add support for totally incompatible SMC to this driver 
>>>(especially with #ifdef's). Another driver should be written if CF 
>>>support is required.

>>>>Other option is create some header files and implement and exporting 
>>>>these
>>>>functions from processor specific code. This add files dependencies 
>>>>and spread
>>>>things across sources, FWIW.

>>>   I don't think it's feasible as that SMC is just too different.

>>    Besides, AT91RM9200 code turned out to already be registering a platform 
>>device called at91_cf -- driver for which I have located in drivers/pcmcia/, 
>>so apparently they're not interested in True IDE mode support (and have 
>>overgeneralized the name as well :-).

> There can be AT91RM9200 boards where is only IDE hardware instead
> "full" Compact Flash support.

> Atmel publish application note with description how connect HDD to AT91RM9200.
> Connection is very similar as for SAM9, the major difference is using GPIO to control 
> CF ~CSx signals. Here is document:

    Horror... Frankly speaking, I don't see why they had to use GPIO and not 
the same decoding scheme as on AT91SAM9xxx.

> http://www.atmel.com/dyn/resources/prod_documents/doc6023.pdf

> Currently people at at91.com forum did board with HDD. As driver
> they use pata_platform with some hacks, which look very similar
> as things in this driver, except they use polling and not need irq quirk:

> http://www.at91.com/samphpbb/viewtopic.php?f=9&t=4528&p=15739

    It's not clear why they define IRQ resource not having IRQ.

> Stanislaw Gruszka

MBR, Sergei