.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3474
Cc: sta...@vger.kernel.org # 5.11-
Signed-off-by: Aaron Ma
---
drivers/gpu/drm/drm_dp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..7b91d8a76cd6 100644
-
Hi Greg:
Could this patch get a chance to be applied on stable kernel?
It only for 5.11- kernel, not for Linus' tree.
Thanks,
Aaron
On 5/20/21 12:27 AM, Lyude Paul wrote:
Seems reasonable to me:
Reviewed-by: Lyude Paul
On Wed, 2021-05-19 at 17:53 +0800, Aaron Ma wrote:
Another Samsung
.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3474
Cc: sta...@vger.kernel.org # 5.11-
Signed-off-by: Aaron Ma
---
drivers/gpu/drm/drm_dp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 5bd0934004e3..7b91d8a76cd6 100644
-
BOE 2270 panel failed to control backlight brightness.
Add it in edid quirks to force using DPCD backlight control.
Then the brightness can be controlled.
Signed-off-by: Aaron Ma
---
drivers/gpu/drm/drm_dp_helper.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm
BOE panel with ID 2270 claims both PWM_PIN_CAP and AUX_SET_CAP backlight
control bits, but default chip backlight failed to control brightness.
Check AUX_SET_CAP and proceed to check quirks or VBT backlight type.
DPCD can control the brightness of this pannel.
Signed-off-by: Aaron Ma
RENOIR loads dmub fw not dmcu, check dmcu only will prevent loading iram,
it breaks backlight control.
Bug: https://bugzilla.kernel.org/show_bug.cgi?id=208277
Signed-off-by: Aaron Ma
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On ARCTURUS and RENOIR, powerplay is not supported yet.
When plug in or unplug power jack, ACPI event will issue.
Then kernel NULL pointer BUG will be triggered.
Check for NULL pointers before calling.
Signed-off-by: Aaron Ma
---
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 3 ++-
1 file changed, 2
On 5/10/19 11:46 PM, Michel Dänzer wrote:
>> Given that the bug is a bit a mess I think we need to add a bit more
>> context here in the commit message. My understanding:
>>
>> Goal of the revert commit was to make the integrated boot device the
>> primary one, if we can't detect which one is the
Hi David:
get_maintainer.pl still got your old e-mail.
Add airl...@redhat.com.
Loop Sean too.
Please review and apply these 2 patches.
Thanks,
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Hi David:
Could you review and apply these 2 patches?
Regards,
Aaron
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
If failed to find the deivice owning the boot framebuffer,
try to use the first VGA device instead of the last one.
Usually the 1st device is integrated GPU who owns the boot framebuffer.
Signed-off-by: Aaron Ma
---
drivers/gpu/vga/vgaarb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
EFI GOP uses 64-bit frame buffer address when some BIOS
disabled CSM support. vgaarb only stores lfb_base,
this will lead boot framebuffer to wrong device.
Add ext_lfb_base support to use 64-bit fb address.
Signed-off-by: Aaron Ma
---
drivers/gpu/vga/vgaarb.c | 19 +--
1 file
12 matches
Mail list logo
