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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

-- 
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.



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux