Patch AR6000

[Ivan Petrov]

Dear Werner,

>> 001.diff - Added means build on non GTA02 platform,
>
> Those GPIOs were in fact only experimental and, as it turned out,
> didn't do anything. So the correct way of handling them is to just
> remove them. I'll do that now.

Ok, then patch #1 not actualy, I will correct it, after u add changes to 
GIT.

>> 002.diff - Added SDIO onebit mode support.
>
> Yuck. Why that ? If it's a limitation of the hardware, why not
> make the host controller driver not set MMC_CAP_4_BIT_DATA ? You
> could do this cleanly by adding some flag to the platform data.

The fact is that not hardware limitation, CPU good work with mem card in 
4wire mode,
but after I start test it on AR6K card, sometimes have lost of IRQ. Posible 
it hardware bug, but while not known.
Also, 1 wire mode provided in AR6K, hif2 not support it. Patch make hif2 to 
much compatible with AR6K driver.

>> 003.diff - Changed method of data transfer, now it based on low-level 
>> function.
>
> Hmm, duplicating code from one subsystem in another one is pretty
> evil. How about adding a function that does what you want to the
> mmc subsystem and calling that function ?

'mmc_wait_for_request' & 'mmc_wait_for_cmd' it one legal path to send custom 
constructed packet to hardware. It's special shared for this operations.
One onether path, to much low level, it use host callback for send packets 
(It's also posible use for ASYN send, but complete will call in IRQ asserted 
state, and AR6K driver give BUG report), already tested. I not guilty, what 
my packet constructor similar original :)

> You can then probably also share the body of the function with 
> mmc_io_rw_extended.

It's also posible, but if I will correct keknel code, after 1 week max, we 
will have new SDIO stack like AR6K original.

> Also, how much do you actually gain by doing all this ?
1, It to short path, i.e. fater (first my aim, make as much as posible fast 
TX path).
2. At bottom of fact, data come from AR6K driver fully suitable for packet 
constructor. If we will use SDIO level API, first we make other format, 
after it on SDIO_OPS level our format will returned to similar sentet from 
AR6K level. I think convering/unconvering/converting to bigger evil, than 
dup part of code one subsystem to another.
3. If you will see mmc_io_rw_extended, it will send single packet with size 
smaller or equal 512b it byte mode, though AR6K want to send it as block.

>> comment: with out patch 001 - 002 inconveniently work on my platform,
>> therefore patches not fully separate, it is in series.
>
> That's okay. Interdependencies are only a problem if an early
> patch depends on a later patch, because that means that you can
> no longer bisect.

--
Regards, Ivan.