[PATCH] Revert "arm64: Make default dma_ops to be noncoherent"

[Dann Frazier]

On Mon, Dec 1, 2014 at 6:17 PM, Ming Lei <ming.lei at canonical.com> wrote:
> On Tue, Dec 2, 2014 at 4:00 AM, Dann Frazier <dann.frazier at canonical.com> wrote:
>> On Thu, Nov 27, 2014 at 8:43 PM, Ming Lei <ming.lei at canonical.com> wrote:
>>> This reverts commit c7a4a7658d689f664050c45493d79adf053f226e.
>>>
>>> Conflicts:
>>>         arch/arm64/mm/dma-mapping.c
>>>
>>> On ARM64, Utopic kernel ships APM's PCI host controller driver
>>> which isn't upstreamed yet, and APM's ARM64 Soc is a coherent
>>> platform. On the other side, ARM64 maintainer[1] said the
>>> commit c7a4a7658 can be reverted safely if booting with ACPI
>>> which can be supported by APM's own kernel release too.
>>>
>>> So please revert the commit c7a4a7658 to avoid breaking
>>> PCI function on APM ARM64.
>>
>> Thanks Ming.
>
> You are welcome, :-)
>
> BTW, this patch is only for utopic.
>
>>
>> One question I have (that I also mentioned in the bug), is what will
>> prevent us from having to carry this forward indefinitely?
>> The m400 cartridge does not provide ACPI tables (afaik), so we need a
>
> Actually the community thought ACPI should be used on server only,
> and in case of server, the fact is that devices have cache-coherent DMA
> all the time.  Since APM ARM64 is a DMA coherent SoC, it is correct to
> apply the revert patch on utopic.

I think that's a reasonable argument, given that X-Gene (TMK) is the
only hardware supported by utopic's arm64 generic kernel.

Acked-by: dann frazier <dann.frazier at canonical.com>

>> device-tree based boot to continue to work. Reverting this for utopic
>> might be the right stop-gap, but what's plan for vivid and beyond?
>
> For DT based booting, my patch in the link should be correct, and
> redhat shipped the similar patch in their internal tree too.  But the kernel
> community thought handling the dma coherency(include irq, iommu, dma
> offset, dma mask, ..) should be moved to drivers/pci of kernel first, instead
> of arch/arm64.  That need cooperation between the two communities,
> and I am not sure if the sort of stuff can be merged soon.

It seems odd to me that upstream favors a known-broken state for the
only commercially available arm64 server, but at least you've
confirmed they are aware of the issue.

 -dann

> Thanks,
> Ming Lei
>
>>
>>  -dann
>>
>>> BugLink: https://bugs.launchpad.net/bugs/1386490
>>>
>>> [1] http://marc.info/?l=linux-arm-kernel&m=141708838404470&w=2
>>>
>>> Cc: Dann Frazier <dann.frazier at canonical.com>
>>> Signed-off-by: Ming Lei <ming.lei at canonical.com>
>>> ---
>>>  arch/arm64/mm/dma-mapping.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>>> index 4164c5a..acc807a 100644
>>> --- a/arch/arm64/mm/dma-mapping.c
>>> +++ b/arch/arm64/mm/dma-mapping.c
>>> @@ -342,7 +342,7 @@ static int __init swiotlb_late_init(void)
>>>         bus_register_notifier(&platform_bus_type, &platform_bus_nb);
>>>         bus_register_notifier(&amba_bustype, &amba_bus_nb);
>>>
>>> -       dma_ops = &noncoherent_swiotlb_dma_ops;
>>> +       dma_ops = &coherent_swiotlb_dma_ops;
>>>
>>>         return swiotlb_late_init_with_default_size(swiotlb_size);
>>>  }
>>> --
>>> 1.9.1
>>>
>>>
>>> --
>>> kernel-team mailing list
>>> kernel-team at lists.ubuntu.com
>>> https://lists.ubuntu.com/mailman/listinfo/kernel-team