registration has failed / was skipped to ensure that there is a
backlight device available before the drm_device gets registered with
userspace.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/nouveau
necessary to monitor for a
native (BACKLIGHT_RAW) device showing up later and to then unregister
the acpi_video backlight device(s).
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 2 --
drivers/acpi/video_detect.c | 36
2 files changed, 38
de Goede
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 85fbf59e0f58..500659c51e8d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b
driver or when it is
disabled.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 45 ---
include/acpi/video.h | 2 ++
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi
Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.
Signed-off-by: Hans de Goede
---
drivers/acpi
devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c| 7
device is available.
Relying on the cached native_available value not only is simpler, it will
also work correctly in cases where then native backlight registration was
skipped because of the acpi_video_get_backlight_type() return value.
Signed-off-by: Hans de Goede
---
drivers/acpi/video_detect.c
devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/radeon/atombios_encoders.c | 7
devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu
acpi_video_get_backlight_type() behave as if a native backlight has
already been registered.
Note that all current callers are updated to pass false for the new
parameter, so this change in itself causes no functional changes.
Signed-off-by: Hans de Goede
---
drivers/acpi/acpi_video.c | 2
devices for a single display really is
undesirable, don't register the GPU's native backlight device when
another backlight device should be used.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers
systems / touches multiple
kms drivers my plan is to provide an immutable branch based on say
5.19-rc1 and then have that get merged into all the relevant trees.
Please review.
Regards,
Hans
Hans de Goede (14):
ACPI: video: Add a native function parameter to
acpi_video_get_backlight_type()
Hi All,
I just noticed the below lockdep possible deadlock report with a 5.18-rc6
kernel on a Dell Latitude E6430 laptop with the following nvidia GPU:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108GLM [NVS
5200M] [10de:0dfc] (rev a1)
01:00.1 Audio device [0403]: NVIDIA
Hi,
On 5/16/22 13:25, Heikki Krogerus wrote:
> +Hans
>
> Hans, do you have any comments?
Thanks for the ping, this looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
>
> On Mon, May 02, 2022 at 09:53:13AM -0700, Bjorn Andersson wrote:
>> In
Hi,
On 5/13/22 15:25, Zack Rusin wrote:
>
>
>> On May 13, 2022, at 3:43 AM, Thorsten Leemhuis > <mailto:regressi...@leemhuis.info>> wrote:
>>
>> CCing airlied
>>
>> On 09.05.22 14:02, Javier Martinez Canillas wrote:
>>> On 5/9/22 1
enabled at (119684): []
__irq_exit_rcu+0xca/0x100
[3.868501] softirqs last disabled at (119679): []
__irq_exit_rcu+0xca/0x100
[3.868504] ---[ end trace ]---
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | 4 ++--
1 file changed, 2 insertio
Hi,
On 5/9/22 13:52, Javier Martinez Canillas wrote:
> Hello Hans,
>
> On 5/9/22 13:04, Hans de Goede wrote:
>> vmw_fb_kms_framebuffer() declares a drm_mode_fb_cmd2 struct on the stack
>> without zero-ing it and then continues with initializing only some fie
ion and thus also fbcon to not work.
Initialize the struct with all zeros to fix this.
Fixes: dabdcdc9822a ("drm/vmwgfx: Switch to mode_cmd2")
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=2072556
Signed-off-by: Hans de Goede
---
While working on this I noticed that at least th
Hi Zack,
On 4/11/22 16:24, Zack Rusin wrote:
> On Mon, 2022-04-11 at 10:52 +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Fedora has received a bug report here:
>>
>> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_b
Hi All,
When running a 5.18-rc4 (and -rc5) kernel on a Chuwi Hi 8, which is
a Bay Trail based tablet with 2G RAM and a 1200x1920 DSI panel.
I noticed that gnome-shell was misrendering. Many UI elements were
missing (they were all black) and at the gdm login screen (which is
a special gnome-shell
gt;>>>> On Mon, Apr 11, 2022 at 6:18 AM Hans de Goede wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On 4/8/22 17:11, Alex Deucher wrote:
>>>>>>> On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede
>>
Hi All,
As discussed in the "[RFC] drm/kms: control display brightness through
drm_connector properties" thread, step 1 of the plan is to stop
registering multiple /sys/class/backlight devs for a single display.
On x86 there can be multiple firmware + direct-hw-access methods
for controlling the
Hi,
On 4/13/22 10:32, Daniel Vetter wrote:
> On Fri, Apr 08, 2022 at 12:26:24PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 4/8/22 12:16, Simon Ser wrote:
>>> Would it be an option to only support the KMS prop for Good devices,
>>> and continue using th
Hi Pekka,
On 4/11/22 13:34, Pekka Paalanen wrote:
> On Mon, 11 Apr 2022 12:18:30 +0200
> Hans de Goede wrote:
>
>> Hi,
>>
>> On 4/8/22 17:11, Alex Deucher wrote:
>>> On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede wrote:
>>>>
>
> ...
>
Hi Simon,
On 4/8/22 10:22, Simon Ser wrote:
> Hi Hans,
>
> Thanks for your details replies!
>
> On Thursday, April 7th, 2022 at 19:43, Hans de Goede
> wrote:
>
>>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede
>>> wrote:
>>&
Hi,
On 4/7/22 20:58, Carsten Haitzler wrote:
> On Thu, 7 Apr 2022 17:38:59 +0200 Hans de Goede said:
>
> Below you covered our usual /sys/class/backlight device friends... what about
> DDC monitor controls? These function similarly but just remotely control a
> screen via I2C
Hi,
On 4/8/22 17:11, Alex Deucher wrote:
> On Fri, Apr 8, 2022 at 10:56 AM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 4/8/22 16:08, Alex Deucher wrote:
>>> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter wrote:
>>>>
>>>> On Thu, Apr 07, 202
Hi All,
Fedora has received a bug report here:
https://bugzilla.redhat.com/show_bug.cgi?id=2072556
That Fedora rawhide VMs no longer boot under the VirtualBox hypervisor
after the VM has been updated to a 5.18-rc# kernel.
Switching the emulated GPU from vmwaregfx to VirtualBoxSVGA fixes
this,
Hi Simon,
On 4/8/22 10:22, Simon Ser wrote:
> Hi Hans,
>
> Thanks for your details replies!
>
> On Thursday, April 7th, 2022 at 19:43, Hans de Goede
> wrote:
>
>>> On Thursday, April 7th, 2022 at 17:38, Hans de Goede
>>> wrote:
>>&
Hi,
On 4/8/22 16:08, Alex Deucher wrote:
> On Fri, Apr 8, 2022 at 4:07 AM Daniel Vetter wrote:
>>
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
>>>>
>>>> Hi Simon,
>&g
Hi,
On 4/8/22 12:16, Simon Ser wrote:
> Would it be an option to only support the KMS prop for Good devices,
> and continue using the suboptimal existing sysfs API for Bad devices?
>
> (I'm just throwing ideas around to see what sticks, feel free to ignore.)
Currently suid-root or pkexec
Hi,
On 4/8/22 11:58, Hans de Goede wrote:
> Hi Daniel,
>
> On 4/8/22 10:07, Daniel Vetter wrote:
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
>>>>
>>>> Hi Simon,
>&g
Hi,
On 4/8/22 11:58, Hans de Goede wrote:
> Hi Daniel,
>
> On 4/8/22 10:07, Daniel Vetter wrote:
>> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
>>>>
>>>> Hi Simon,
>&g
Hi Daniel,
On 4/8/22 10:07, Daniel Vetter wrote:
> On Thu, Apr 07, 2022 at 05:05:52PM -0400, Alex Deucher wrote:
>> On Thu, Apr 7, 2022 at 1:43 PM Hans de Goede wrote:
>>>
>>> Hi Simon,
>>>
>>> On 4/7/22 18:51, Simon Ser wrote:
>>>> Very n
Hi Simon,
On 4/7/22 18:51, Simon Ser wrote:
> Very nice plan! Big +1 for the overall approach.
Thanks.
> On Thursday, April 7th, 2022 at 17:38, Hans de Goede
> wrote:
>
>> The drm_connector brightness properties
>> ===
>>
&g
As discussed already several times in the past:
https://www.x.org/wiki/Events/XDC2014/XDC2014GoedeBacklight/
https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad-d37d844b0...@linux.intel.com/
The current userspace API for brightness control offered by
/sys/class/backlight devices has various
Hi Yusuf,
On 4/4/22 01:08, Yusuf Khan wrote:
> This patch adds the DDCCI driver by Christoph Grenz into the kernel.
> The original gitlab page is loacted at https://gitlab.com/ddcci-driv
> er-linux/ddcci-driver-linux/-/tree/master.
>
> DDC/CI is a control protocol for monitor settings supported
to
display properly.
Cc: Javier Martinez Canillas
Signed-off-by: Hans de Goede
Reviewed-by: Javier Martinez Canillas
Acked-by: Thomas Zimmermann
Link:
https://patchwork.freedesktop.org/patch/msgid/20220221220045.11958-1-hdego...@redhat.com
---
drivers/gpu/drm/tiny/simpledrm.c | 3 +++
1 file
/show_bug.cgi?id=2071134
Hans de Goede (1):
drm/simpledrm: Add "panel orientation" property on non-upright mounted
LCD panels
drivers/gpu/drm/tiny/simpledrm.c | 3 +++
1 file changed, 3 insertions(+)
--
2.35.1
unted on a laptop form factor, sideways.
>>
>> Signed-off-by: Anisse Astier
>> Reviewed-by: Hans de Goede
>> Signed-off-by: Jani Nikula
>> Link:
>> https://patchwork.freedesktop.org/patch/msgid/2021122900.53128-3-ani...@astier.eu
>> Signed-off-by: Sas
Hi,
On 3/20/22 21:11, Rajat Jain wrote:
> () Hello Hans, Sean,
>
>
>
> On Fri, Mar 11, 2022 at 4:12 AM Hans de Goede wrote:
>>
>> Hi All,
>>
>> On 3/9/22 18:53, Rajat Jain wrote:
>>> On Wed, Mar 9, 2022 at 7:06 AM Sean Paul wrote:
>
the lookup tables in drivers/gpu/drm/drm_privacy_screen_x86.c
and adjusting the i915 driver to match.
Using the con_id parameter paves the way for potentially having another
display (attached to a different connector) which also has a builtin
privacy-screen.
This was tested by Hans de Goede on
Hi Daniel,
On 3/17/22 19:36, Daniel Dadap wrote:
>
> On 3/17/22 11:42, Hans de Goede wrote:
>> Hi Daniel,
>>
>> On 3/17/22 14:28, Daniel Dadap wrote:
>>>> On Mar 17, 2022, at 07:17, Hans de Goede wrote:
>>>>
>>>> Hi,
>>>>
Hi Daniel,
On 3/17/22 14:28, Daniel Dadap wrote:
>
>> On Mar 17, 2022, at 07:17, Hans de Goede wrote:
>>
>> Hi,
>>
>>> On 3/16/22 21:33, Daniel Dadap wrote:
>>> Some notebook systems with EC-driven backlight control appear to have a
>>>
-1, but there isn't a way to make it clear in the i915 and
> now amdgpu code.
>
> Thanks,
>
> Rajat
>
>
>> + if (!IS_ERR(privacy_screen)) {
>> +
>> drm_connector_attach_privacy_screen_provider(>base,
>> +
/patch/477640/ #v1
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 9 +
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c| 3 +++
> .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 16
Hi,
On 3/8/22 23:07, Harry Wentland wrote:
>
>
> On 2022-03-08 17:02, Hans de Goede wrote:
>> Hi,
>>
>> On 3/8/22 21:56, Sean Paul wrote:
>>> From: Sean Paul
>>>
>>> This patch adds the necessary hooks to make amdgpu aware of priva
Hi,
On 3/8/22 21:56, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds the necessary hooks to make amdgpu aware of privacy
> screens. On devices with privacy screen drivers (such as thinkpad-acpi),
> the amdgpu driver will defer probe until it's ready and then sync the sw
> and hw state on
Hi,
On 3/2/22 02:34, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 2 Feb 2022 09:38:37 +0100 Hans de Goede wrote:
>>
>> On 2/2/22 05:03, Stephen Rothwell wrote:
>>>
>>> On Wed, 2 Feb 2022 15:02:01 +1100 Stephen Rothwell
>>> wrote:
>>
(1) to reg (22)
Besides these errors this also causes the screen turning on to be delayed
by 2 seconds. At a DMI based quirk to ignore VBT DSI MIPI I2C writes on
the Microsoft Surface 3.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 18 ++
1 file
2014.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi.h | 3 +++
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 10 --
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi.h
b/drivers/gpu/drm/i915/display
Add some debug logging to mipi_exec_i2c, to make debugging various
issues seen with it easier.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gpu/drm
iewed-by: Javier Martinez Canillas
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 37 ++
1 file changed, 37 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 831ca6401c51..0ddc0c8cd4f7 100
nez Canillas
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 40 ++
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index 06ef822c27bd..831ca6401c51 100644
--- a/
Hi,
On 2/22/22 20:14, Thomas Zimmermann wrote:
> Hi
>
> Am 21.02.22 um 23:00 schrieb Hans de Goede:
>> Some devices use e.g. a portrait panel in a standard laptop casing made
>> for landscape panels. efifb calls drm_get_panel_orientation_quirk() and
>> sets fb_inf
quot; 1050 models as well as the 8" 830 models use the same
mainboard and thus the same DMI strings. The 10" 1050 uses a 1920x1200
landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen,
so the quirk handling uses the display resolution to detect the model.
Sig
which uses the EFI FB which does have this bug
has the last line all black causing the bug to not be visible.
This commit introduces a generic DMI based mechanism for doing modeline
fixups, in case we need similar fixups on other models in the future.
Signed-off-by: Hans de Goede
---
drivers
renders on its side. Call the
drm_connector_set_panel_orientation_with_quirk() helper to add
a "panel orientation" property on devices listed in the quirk table,
to make the fbcon (and aware userspace apps) rotate the image to
display properly.
Cc: Javier Martinez Canillas
Signed-off-b
Hi,
On 2/18/22 12:39, Simon Ser wrote:
> On Friday, February 18th, 2022 at 11:38, Hans de Goede
> wrote:
>
>> What I'm reading in the above is that it is being considered to allow
>> changing the panel-orientation value after the connector has been made
>> avai
Hi,
Sorry for jumping in in the middle of the thread I did
not notice this thread before.
On 2/16/22 13:00, Emil Velikov wrote:
> On Tue, 15 Feb 2022 at 16:37, Simon Ser wrote:
>>
>> On Tuesday, February 15th, 2022 at 15:38, Emil Velikov
>> wrote:
>>
>>> On Tue, 15 Feb 2022 at 13:55, Simon
The Lenovo Yoga Tablet 2 830F / 830L use a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm
Hi,
On 2/11/22 10:00, Yehezkel Bernat wrote:
> On Fri, Feb 11, 2022 at 12:43 AM Mario Limonciello
> wrote:
>>
>> Currently `pci_is_thunderbolt_attached` is used to indicate a device
>> is connected externally.
>>
>> The PCI core now marks such devices as removable and downstream drivers
>> can
Limonciello
Thanks, this looks good to me. I assume that this whole series
will be merged in one go through another tree (e.g. the PCI tree),
so here is my ack for merging this patch through another tree:
Acked-by: Hans de Goede
Regards,
Hans
> ---
> drivers/platform/x86/apple-gmux.c
Hi,
On 2/7/22 14:05, Simon Ser wrote:
> Reviewed-by: Simon Ser
Thank I've pushed this one to drm-misc-fixes now; and the other one you reviewed
to drm-misc-next.
Regards,
Hans
Fix the following warning from "make htmldocs":
drivers/gpu/drm/drm_privacy_screen.c:270:
WARNING: Inline emphasis start-string without end-string.
Fixes: 8a12b170558a ("drm/privacy-screen: Add notifier support (v2)")
Reported-by: Stephen Rothwell
Signed-off-by: Hans d
Hi,
Thank you for the review.
On 2/7/22 12:43, Simon Ser wrote:
> On Wednesday, January 26th, 2022 at 16:11, Hans de Goede
> wrote:
>
>> - * A pointer to the drm_privacy_screen's struct is passed as the void *data
>> + * A pointer to the drm_privacy_screen's struct
Hi Simon,
On 2/7/22 12:37, Simon Ser wrote:
> Reviewed-by: Simon Ser
Thank you, I also have this very similar patch pennding (also a simple htmldocs
warning fix).
Any chance you can also review this one? :
https://patchwork.freedesktop.org/patch/470957/
Regards,
Hans
Rajat Jain
Reported-by: Stephen Rothwell
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/drm_privacy_screen.c
b/drivers/gpu/drm/drm_privacy_screen.c
index 03b149cc455b..45c080134488 100644
--- a/drivers/gpu/drm/
Hi,
On 2/2/22 05:03, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 2 Feb 2022 15:02:01 +1100 Stephen Rothwell
> wrote:
>>
>> After merging the drm tree, today's linux-next build (htmldocs) produced
>> this warning:
>>
>> drivers/gpu/drm/drm_privacy_screen.c:X: warning: Function parameter or
Hi,
On 1/27/22 14:33, Rafael J. Wysocki wrote:
> On Thu, Jan 27, 2022 at 2:05 PM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 1/26/22 18:11, Rafael J. Wysocki wrote:
>>> On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede wrote:
>>>>
>>>
Hi,
On 1/26/22 18:11, Rafael J. Wysocki wrote:
> On Wed, Jan 26, 2022 at 5:41 PM Hans de Goede wrote:
>>
>> Hi,
>>
>> On 1/26/22 16:54, Rafael J. Wysocki wrote:
>>> On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote:
>>>>
>>>> Hi A
Hi,
On 1/26/22 16:54, Rafael J. Wysocki wrote:
> On Wed, Jan 26, 2022 at 2:47 PM Hans de Goede wrote:
>>
>> Hi All,
>>
>> On 1/23/22 10:10, Tong Zhang wrote:
>>> when acpi=off is provided in bootarg, kernel crash with
>>>
>>> [1
Fix the following warning from "make htmldocs":
drivers/gpu/drm/drm_privacy_screen.c:270:
WARNING: Inline emphasis start-string without end-string.
Fixes: 8a12b170558a ("drm/privacy-screen: Add notifier support (v2)")
Reported-by: Stephen Rothwell
Signed-off-by: Hans de Goe
Hi,
On 1/26/22 14:47, Hans de Goede wrote:
> Hi All,
>
> On 1/23/22 10:10, Tong Zhang wrote:
>> when acpi=off is provided in bootarg, kernel crash with
>>
>> [1.252739] BUG: kernel NULL pointer dereference, address:
>> 0018
>> [
Hi All,
On 1/23/22 10:10, Tong Zhang wrote:
> when acpi=off is provided in bootarg, kernel crash with
>
> [1.252739] BUG: kernel NULL pointer dereference, address: 0018
> [1.258308] Call Trace:
> [1.258490] ? acpi_walk_namespace+0x147/0x147
> [1.258770]
https://lore.kernel.org/dri-devel/20220117180359.18114-1-z...@kde.org/
>
> v2:
> * fix possible NULL deref in simpledrm (Jocelyn)
> * various style fixes (Javier)
The entire series looks good to me:
Reviewed-by: Hans de Goede
for the series.
Regards,
Hans
>
Hi Stepen,
On 1/20/22 04:18, Stephen Rothwell wrote:
> Hi all,
>
> On Fri, 15 Oct 2021 20:54:22 +1100 Stephen Rothwell
> wrote:
>>
>> After merging the drm-misc tree, today's linux-next build (htmldocs)
>> produced this warning:
>>
>> Documentation/gpu/drm-kms-helpers:451:
>>
Hi Daniel,
On 1/20/22 12:15, Daniel Palmer wrote:
> Hi Daniel,
>
> On Thu, 20 Jan 2022 at 01:30, Daniel Vetter wrote:
>>> I got the feeling that maybe I should just provide an interface to the
>>> blitter from userspace and userspace should be doing the rotation. I'd
>>> like to do it in the
when needed.
>
> This also touches the IBM Thinkpad platform driver, the only user of
> privacy screen today, to pass NULL for now to the updated API.
>
> Signed-off-by: Rajat Jain
> Reviewed-by: Hans de Goede
I've pushed this series to drm-misc-next now.
Regards,
Hans
> ---
>
sdegoede.livejournal.com/25948.html
>>
>> Signed-off-by: Rajat Jain
>> Reviewed-by: Hans de Goede
>
> Hi Hans,
>
> Since this change depends on the privacy screen changes staged for v5.17,
> I'm OK as platform/chrome maintainer to have this go through the drm tree.
&g
ACPI, then the i915 probe
> shall return EPROBE_DEFER until a platform driver actually registers the
> privacy-screen: https://hansdegoede.livejournal.com/25948.html
>
> Signed-off-by: Rajat Jain
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Re
Hi,
On 12/20/21 23:28, Rajat Jain wrote:
> Add a static entry in the x86 table, to detect and wait for
> privacy-screen on some ChromeOS platforms.
>
> Please note that this means that if CONFIG_CHROMEOS_PRIVACY_SCREEN is
> enabled, and if "GOOG0010" device is found in ACPI, then the i915 probe
when needed.
>
> This also touches the IBM Thinkpad platform driver, the only user of
> privacy screen today, to pass NULL for now to the updated API.
>
> Signed-off-by: Rajat Jain
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
> ---
> v3: Initial versio
which uses the EFI FB which does have this bug
has the last line all black causing the bug to not be visible.
This commit introduces a generic DMI based mechanism for doing modeline
fixups, in case we need similar fixups on other models in the future.
Signed-off-by: Hans de Goede
---
drivers
Hi,
On 11/21/21 12:00, Hans de Goede wrote:
> After the recent refactoring of the backlight code the contents of
> intel_panel_actually_set_backlight() is exactly the same (minus a
> small wording difference in the drm_dbg_kms() as the contents if the
> more
Hi,
On 12/11/21 15:49, Miaoqian Lin wrote:
> The devm_gen_pool_create() function does not return NULL. It
> returns error pointers.
>
> Signed-off-by: Miaoqian Lin
This is already fixed in linux-next, see:
up for Linus to
> decide)? Does everything start to work normally shortly after the kernel
> mounted the rootfs and finally can load the missing module?
Yes everything will work normally once the rootfs gets mounted and the
missing module gets loaded.
Regards,
Hans
> On 05.10.21 22:
Hi all,
On 12/7/21 13:26, Heikki Krogerus wrote:
> +Hans and Imre
>
> On Mon, Dec 06, 2021 at 02:31:40PM -0800, Bjorn Andersson wrote:
>> On Thu 07 Oct 03:17 PDT 2021, Heikki Krogerus wrote:
>>> On Wed, Oct 06, 2021 at 01:26:35PM -0700, Prashant Malani wrote:
(CC+ Heikki)
>> [..]
On
The intel_gmbus_set_speed() function is not used anywhere, remove it.
Note drivers/gpu/drm/gma500 has its own copy called
gma_intel_gmbus_set_speed() which is used, the intel_gmbus_set_speed()
version in the i915 code is not used at all
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915
-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_backlight.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 03cd730c926a..2758a2f6c093 100644
--- a/drivers/gpu/drm/i915/display
intel_panel_actually_set_backlight() function.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_backlight.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
Hi,
On 11/7/21 12:27, Yauhen Kharuzhy wrote:
> On Sun, Nov 07, 2021 at 11:12:56AM +0100, Sam Ravnborg wrote:
>> Hi Yauhen,
>> On Sun, Nov 07, 2021 at 12:59:11AM +0300, Yauhen Kharuzhy wrote:
>>> On Sat, Nov 06, 2021 at 02:02:27PM +0100, Hans de Goede wrote:
>>>&
Hi,
On 10/25/21 10:17, Jani Nikula wrote:
> On Sun, 24 Oct 2021, Hans de Goede wrote:
>> In intel_dsi_get_config() double the pclk returned by foo_dsi_get_pclk()
>> for dual-link panels. This fixes the following WARN triggering:
>>
>> i915 :00:02.0: [drm] *ERROR
Hi,
On 11/18/21 12:12, Dan Carpenter wrote:
> The devm_gen_pool_create() function never returns NULL, it returns
> error pointers.
>
> Fixes: 4cc9b565454b ("drm/vboxvideo: Use devm_gen_pool_create")
> Signed-off-by: Dan Carpenter
Thanks, patch looks good to me:
Revie
Hi Rajat,
On 11/17/21 15:28, Rajat Jain wrote:
> +Heikki Krogerus
>
> Hello Hans, Heikki,
>
> I have a question below, which isn't really a problem, but more of an
> attempt to understand the current code and its limitations.
>
> On Tue, Oct 5, 2021 at 1:23
Hi Rajat,
On 11/17/21 15:13, Rajat Jain wrote:
> Hello Hans,
>
> On Tue, Oct 5, 2021 at 1:23 PM Hans de Goede wrote:
>>
>> Add X86 specific arch init code, which fills the privacy-screen lookup
>> table by checking for various vendor specific ACPI interfaces for
; Changes in v2:
>> - Call drm_connector_update_privacy_screen() from
>> intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
>> for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
>> - Move the probe-deferral check to the intel_modeset_pro
The Lenovo Yoga Book X91F/L uses a panel which has been mounted
90 degrees rotated. Add a quirk for this.
Cc: Yauhen Kharuzhy
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm
Hi,
On 11/4/21 00:16, Rajat Jain wrote:
> Hello Hans,
>
> Thanks a lot for working on this diligently and getting almost all of
> it finally merged!
>
> On Wed, Oct 13, 2021 at 2:59 PM Ville Syrjälä
> wrote:
>>
>> On Tue, Oct 05, 2021 at 10:23:22PM +0200, Han
401 - 500 of 1992 matches
Mail list logo
