Re: 2.6.32: Promise UDMA33 card refuses to work in UDMA mode

[Jeff Garzik <jeff@garzik.org>]

On 01/04/2010 01:06 PM, Russell King wrote:
> On Mon, Jan 04, 2010 at 01:03:36PM -0500, Jeff Garzik wrote:
>> On 01/04/2010 12:30 PM, Russell King wrote:
>>> On Mon, Jan 04, 2010 at 12:27:54PM -0500, Jeff Garzik wrote:
>>>> On 01/04/2010 12:02 PM, Alan Cox wrote:
>>>>>> (1b)  The solution for MMIO controllers is a bit more complex:  replace
>>>>>> the dummy AltStatus register read with something else.
>>>>>
>>>>> If we had any SFF PATA controllers using MMIO. I can't find any. SATA is
>>>>> different anyway. In fact we probably want to avoid such delays on a pure
>>>>> SATA controller.
>>>>
>>>> Early SATA controllers are just PATA controllers in disguise.  All SFF
>>>> controllers want that 400ns delay.  The 400ns delay should -not- be
>>>> avoided.
>>>
>>> Note that ICH5 SATA is SFF, which only offers non-MMIO addressing; the
>>> change I made is running there just fine:
>>
>> Yes, your change should be fine for all non-MMIO SFF controllers, SATA
>> or PATA.
>>
>> The AltStatus read is simply a dummy read, for MMIO controllers, to
>> ensure the previously-written taskfile registers make it to the
>> controller before the ndelay() begins execution.
>
> Can we solve the problem by doing a read of the BMDMA status register?
>
> As it is, the command register and alt status registers are in different
> BARs on the controller, so reading from BAR 4 instead of 1/3 should have
> the same effect?

Correct -- it does not matter which controller register is read, to 
ensure the MMIO flush.

Standard MMIO flush / PCI posting rules, nothing unique to PATA at all 
really.  You can see examples of MMIO flushes all over the tree, such as 
the cpw8_f() and cpw32_f() macros in drivers/net/8139cp.c.

	Jeff