[RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node

[Steven Price]

On 06/11/2020 16:17, Shameerali Kolothum Thodi wrote:
> 
> 
>> -----Original Message-----
>> From: Steven Price [mailto:steven.price at arm.com]
>> Sent: 06 November 2020 15:22
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>;
>> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org;
>> iommu at lists.linux-foundation.org; devel at acpica.org
>> Cc: lorenzo.pieralisi at arm.com; joro at 8bytes.org; Jonathan Cameron
>> <jonathan.cameron at huawei.com>; Linuxarm <linuxarm at huawei.com>;
>> Guohanjun (Hanjun Guo) <guohanjun at huawei.com>; Sami Mujawar
>> <Sami.Mujawar at arm.com>; robin.murphy at arm.com; wanghuiqiang
>> <wanghuiqiang at huawei.com>
>> Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
>>
>> On 28/10/2020 18:24, Shameerali Kolothum Thodi wrote:
>>> Hi Steve,
>>>
>>>> -----Original Message-----
>>>> From: Steven Price [mailto:steven.price at arm.com]
>>>> Sent: 28 October 2020 16:44
>>>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi at huawei.com>;
>>>> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org;
>>>> iommu at lists.linux-foundation.org; devel at acpica.org
>>>> Cc: lorenzo.pieralisi at arm.com; joro at 8bytes.org; Jonathan Cameron
>>>> <jonathan.cameron at huawei.com>; Linuxarm <linuxarm at huawei.com>;
>>>> Guohanjun (Hanjun Guo) <guohanjun at huawei.com>;
>> robin.murphy at arm.com;
>>>> wanghuiqiang <wanghuiqiang at huawei.com>; Sami Mujawar
>>>> <Sami.Mujawar at arm.com>
>>>> Subject: Re: [RFC PATCH 0/4] ACPI/IORT: Support for IORT RMR node
>>>>
>>>> On 27/10/2020 11:26, Shameer Kolothum wrote:
>>>>> The series adds support to IORT RMR nodes specified in IORT
>>>>> Revision E -ARM DEN 0049E[0]. RMR nodes are used to describe memory
>>>>> ranges that are used by endpoints and require a unity mapping
>>>>> in SMMU.
>>>>
>>>> Hi Shameer,
>>>>
>>>> I've also been taking a look at RMR, and Sami is helping me get set up
>>>> so that I can do some testing. We're hoping to be able to test an EFI
>>>> framebuffer or splash screen - which has the added complication of the
>>>> unity mapping becoming redundant if a native display driver takes over
>>>> the display controller.
>>>>
>>>> I've looked through your series and the code looks correct to me.
>>>
>>> Thanks for taking a look and the details.
>>>
>>>> Hopefully I'll be able to give it some testing soon.
>>>
>>> Cool. Please update once you get a chance run the tests.
>>
>> Hi Shameer,
> 
> Hi Steve,
> 
>> Just to update on this, for the EFI framebuffer use case I hit exactly
>> the issue that Robin has mentioned in another thread - the RMR is
>> effectively ignored because the display controller isn't being handled
>> by Linux (so there's no device to link it to).
> 
> Thanks for the update. Here, by "ignored "you meant get_resv_regions()
> is not called or not?

get_resv_regions() isn't called.

>   The splash screen might
>> similarly flicker as the SMMU reset will initially block the traffic
>> before the RMR region is enabled.
> 
> Does that mean you somehow managed to make the unity
> mapping but there was flicker during the SMMU reset to
> unity mapping setup period. Sorry I am trying to understand
> the exact behavior observed in this case.

I haven't yet got this completely working (on the board which I'm 
testing the display controller doesn't have any existing ACPI bindings). 
However from what I understand the SMMU reset would block all memory 
access for the display controller before the RMR region would be setup. 
I'm going to try to get the display controller working with ACPI so I 
can test this properly.

Steve