[PATCH] ahci_sunxi: Drop AHCI_HFLAG_NO_PMP flag
Hans de Goede
hdegoede at redhat.com
Fri Nov 14 05:24:51 PST 2014
Hi,
On 11/14/2014 01:49 PM, Hans de Goede wrote:
> Hi,
>
> On 11/14/2014 12:56 PM, Hans de Goede wrote:
>> Hi,
>>
>> On Thursday, November 13, 2014 11:29:56 PM UTC+1, Tejun Heo wrote:
>>>
>>> On Thu, Nov 13, 2014 at 11:24:16AM +0100, Hans de Goede wrote:
>>>> This is something which we inherited from the Allwinner android kernel
>>> sources,
>>>> and I've always wanted to test if this is really necessary.
>>>>
>>>> So recently I've bought a sata port multiplexer, and I've given this a
>>> test
>>>> spin on both A10 and A20 devices, and it seems to work fine:
>>>>
>>>> [ 2.154456] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>>>> [ 2.161092] ata1.15: Port Multiplier 1.2, 0x197b:0x0325 r0, 5 ports,
>>> feat 0x5/0xf
>>>> [ 2.175511] ata1.00: hard resetting link
>>>> [ 2.524929] ata1.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
>>>> [ 2.531430] ata1.01: hard resetting link
>>>> [ 2.974465] ata1.01: link resume succeeded after 1 retries
>>>> [ 3.094932] ata1.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>>>> [ 3.101431] ata1.02: hard resetting link
>>>> [ 4.174466] ata1.02: failed to resume link (SControl 0)
>>>> [ 4.180065] ata1.02: SATA link down (SStatus 0 SControl 0)
>>>> (and the same for links 3 and 4)
>>>>
>>>> Once the NO_PMP flag is removed it correctly sees the 2 disks which I've
>>>> attached, and I can mount and use them just fine, so lets drop the flag.
>>>>
>>>> Signed-off-by: Hans de Goede <hdeg... at redhat.com <javascript:>>
>>>
>>> Applied to libata/for-3.18-fixes.
>>>
>>
>> I just found out why Allwinner added that AHCI_HFLAG_NO_PMP flag, after
>> putting the system I used to test the port multiplexer back together this
>> morning, it seems that probing for a port multiplexer being present breaks
>> the no-port-multiplexer (so direct attached disk) case :( I guess I should
>> have tested for that before sending the patch, but the thought of it
>> breaking normal usage did not cross my mind.
>>
>> So self NACK. If it is not too late, can you please drop this from your
>> tree ?
>>
>> Let me know if you want me to send a revert instead.
>>
>> I'll look into fixing this another way, maybe with a quirk + an extra reset
>> after failed pmp testing, and it that does not work a module option.
>
> Ok, so the problem seems to be that the controller fails to do a soft-reset
> when attached directly to a normal device rather then to a pmp.
>
> If I comment out this block of code in libata-core.c:
>
> if (sata_pmp_supported(link->ap) && ata_is_host_link(link)) {
> /* If PMP is supported, we have to do follow-up SRST.
> * Some PMPs don't send D2H Reg FIS after hardreset if
> * the first port is empty. Wait only for
> * ATA_TMOUT_PMP_SRST_WAIT.
> */
> if (check_ready) {
> unsigned long pmp_deadline;
>
> pmp_deadline = ata_deadline(jiffies,
> ATA_TMOUT_PMP_SRST_WAIT);
> if (time_after(pmp_deadline, deadline))
> pmp_deadline = deadline;
> ata_wait_ready(link, pmp_deadline, check_ready);
> }
> rc = -EAGAIN;
> goto out;
> }
>
> Then things work again. This code looks like it is a must have for
> pmp use, so I'll do a follow up patch to my initial patch dropping the
> AHCI_HFLAG_NO_PMP flag, which re-adds it based on a module option
> (defaulting to the non-pmp case).
>
> This way you don't have to do a forced-push to your tree to drop the
> original patch (or revert it).
Just saw your message that you've dropped the troublesome patch, in that
case I'll do a completely new patch, rather then a follow on patch, to
add a module option for this (unless you've a better idea).
Regards,
Hans
More information about the linux-arm-kernel
mailing list