[PATCH v3] efifb: avoid reconfiguration of BAR that covers the framebuffer

Sinan Kaya okaya at codeaurora.org
Wed Mar 22 12:57:56 PDT 2017


On 3/22/2017 3:52 PM, Ard Biesheuvel wrote:
> On 22 March 2017 at 19:49, Sinan Kaya <okaya at codeaurora.org> wrote:
>> On 3/22/2017 3:41 PM, Ard Biesheuvel wrote:
>>>> As far as I know, kernel honors resource assignments done by the UEFI BIOS if
>>>> they are correct. Kernel will reassign the resources only if something is wrong.
>>>>
>>> No, the kernel always reassigns all BARs on arm64.
>>
>> I think this is where the problem is.
>>
>> I'm not seeing this happen on QDF2400 which supports ACPI + UEFI BIOS
>> combination only.
>>
>> I see that kernel honored the resources assigned by UEFI BIOS if I compare
>> the BAR addresses.
>>
> 
> Well, if you are using the standard MdeModulePkg PciHostBridgeDxe
> driver in UEFI, the logic is quite similar, and so you usually end up
> with the same resource assignments. But the kernel does recompute them
> from scratch, and ignores the existing configuration that is present
> in the BARs

Yes, standard stuff in UEFI. OK. That may explain what I'm seeing.

> 
>> I see reassignment only when something is horribly broken. Then, there would
>> be a bridge configuration invalid message in the boot log to confirm this.
>>
>>>
>>>> Will this code break other platforms/architectures?
>>>>
>>> Which platforms/architectures are you referring to? EFIFB on a PCI
>>> device is currently broken on arm64.
>>
>> In general or on your particular platform?
>>
>>> On x86, it works, given that BARs
>>> are usually not reassigned, and so the patch should be a no-op in that
>>> case (although I'd argue it is still an improvement to check whether
>>> the device that owns the BAR actually has memory decoding enabled
>>> before we attach the framebuffer driver to it)
>>>
>>
>> I'm fine as long as it doesn't break anything. That's why, I'm asking.
>>
> 
> If you have working EFIFB on your platform, it works by accident. This
> patch is needed to ensure that the BAR associated with the EFI
> framebuffer is left untouched.
> 

I never claimed that. I was just double checking your assumptions.
I really don't like ARM64 specific PCI code in general. PCI doesn't care
about CPU type. I hope to see this patch become part of common code.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.



More information about the linux-arm-kernel mailing list