gt; Cc: Arnd Bergmann
> Cc: linux-a...@vger.kernel.org
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
> ---
> arch/sparc/video/Makefile| 2 +-
> arch/spa
Hi,
On 5/16/24 5:11 PM, Thomas Zimmermann wrote:
> Hi
>
> Am 16.05.24 um 17:03 schrieb Hans de Goede:
>> Hi,
>>
>> On 5/16/24 3:04 PM, Rafael J. Wysocki wrote:
>>> CC Hans who has been doing the majority of the ACPI video work.
>>>
>>
Hi,
On 5/16/24 3:04 PM, Rafael J. Wysocki wrote:
> CC Hans who has been doing the majority of the ACPI video work.
>
> On Thu, May 16, 2024 at 2:43 PM Thomas Zimmermann wrote:
>>
>> Commit 2fd001cd3600 ("arch: Rename fbdev header and source files")
>> renames the video source files under arch/
Hi Dmitry,
On 5/7/24 3:32 PM, Dmitry Baryshkov wrote:
> On Mon, May 06, 2024 at 01:49:17PM +0200, Hans de Goede wrote:
>> Hi dma-buf maintainers, et.al.,
>>
>> Various people have been working on making complex/MIPI cameras work OOTB
>> with mainline Linux kernels
Hi Sima,
On 5/6/24 3:38 PM, Daniel Vetter wrote:
> On Mon, May 06, 2024 at 02:05:12PM +0200, Maxime Ripard wrote:
>> Hi,
>>
>> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
>>> Hi dma-buf maintainers, et.al.,
>>>
>>> Various people
Hi Maxime,
On 5/6/24 2:05 PM, Maxime Ripard wrote:
> Hi,
>
> On Mon, May 06, 2024 at 01:49:17PM GMT, Hans de Goede wrote:
>> Hi dma-buf maintainers, et.al.,
>>
>> Various people have been working on making complex/MIPI cameras work OOTB
>> with mainline Linux ke
Hi dma-buf maintainers, et.al.,
Various people have been working on making complex/MIPI cameras work OOTB
with mainline Linux kernels and an opensource userspace stack.
The generic solution adds a software ISP (for Debayering and 3A) to
libcamera. Libcamera's API guarantees that buffers handed
Hi,
On 4/10/24 3:02 PM, Thomas Zimmermann wrote:
> Implement fbdev emulation with fbdev-shmem. Avoids the overhead of
> fbdev-generic's additional shadow buffering. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Hans de Goede
Thanks, patch looks good t
deo]
Note as mentioned in the added comment it seems the original length
calculation for the allocated and send hgsmi buffer is 4 bytes too large.
Changing this is not the goal of this patch, so this behavior is kept.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/vboxvideo/hgsmi_base.c | 10
Hi,
On 4/2/24 3:50 PM, Philipp Stanner wrote:
> On Thu, 2024-03-28 at 12:55 -0500, Bjorn Helgaas wrote:
>> On Fri, Mar 01, 2024 at 12:29:58PM +0100, Philipp Stanner wrote:
>>> When the PCI devres API was introduced to this driver, it was
>>> wrongly
>>> assumed that initializing the device with
Hi,
On 3/26/24 4:39 PM, Benjamin Tissoires wrote:
> On Mar 26 2024, Werner Sembach wrote:
>> Hi all,
>>
>> Am 25.03.24 um 19:30 schrieb Hans de Goede:
>>
>> [snip]
>>>>> If the kernel already handles the custom protocol into generic HID, the
Hi Werner,
On 3/25/24 5:48 PM, Werner Sembach wrote:
> Hi Benjamin,
>
> Am 25.03.24 um 16:56 schrieb Benjamin Tissoires:
>> On Mar 25 2024, Hans de Goede wrote:
>>> +Cc: Bentiss, Jiri
>>>
>>> Hi Werner,
>>>
>>> On 3/20/24 12:16 PM, Wer
+Cc: Bentiss, Jiri
Hi Werner,
On 3/20/24 12:16 PM, Werner Sembach wrote:
> Hi Hans and the others,
>
> Am 22.02.24 um 14:14 schrieb Werner Sembach:
>> Hi,
>>
>> Thanks everyone for the exhaustive feedback. And at least this thread is a
>> good comprehesive reference for the future ^^.
>>
>> To
Hi Werner,
On 3/19/24 4:18 PM, Werner Sembach wrote:
> Hi Hans,
>
> Am 18.03.24 um 12:11 schrieb Hans de Goede:
>> Hi Werner,
>>
>> Sorry for the late reply.
> np
>>
>> On 2/22/24 2:14 PM, Werner Sembach wrote:
>>> Hi,
>>>
>>>
Hi Werner,
Sorry for the late reply.
On 2/22/24 2:14 PM, Werner Sembach wrote:
> Hi,
>
> Thanks everyone for the exhaustive feedback. And at least this thread is a
> good comprehesive reference for the future ^^.
>
> To recap the hopefully final UAPI for complex RGB lighting devices:
>
> -
; Fixes: 8558de401b5f ("drm/vboxvideo: use managed pci functions")
> Signed-off-by: Philipp Stanner
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Since this depends on the pcim_iomap_range() function which is new
in this series and since the vboxvideo code does
Hi Daniel,
On 2/28/24 03:00, Daniel van Vugt wrote:
> On 27/2/24 21:47, Hans de Goede wrote:
> I think some boot failures also take you to the grub menu automatically next
> time?
In Fedora all boot failures will unhide the grub menu on
the next boot. This unfortunately relies on d
Hi,
On 2/27/24 02:06, Daniel van Vugt wrote:
> On 27/2/24 02:23, Hans de Goede wrote:
>> Hi All,
>>
>> On 2/2/24 09:53, Daniel van Vugt wrote:
>>> Until now, deferred console takeover only meant defer until there is
>>> output. But that risks stepping
Hi All,
On 2/2/24 09:53, Daniel van Vugt wrote:
> Until now, deferred console takeover only meant defer until there is
> output. But that risks stepping on the toes of userspace splash screens,
> as console messages may appear before the splash screen. So check for the
> "splash" parameter (as
Hi,
On 2/22/24 17:44, Matthew Auld wrote:
> On 22/02/2024 14:58, Marek Behún wrote:
>> A few drivers are doing resource-managed mutex initialization by
>> implementing ad-hoc one-liner mutex dropping functions and using them
>> with devm_add_action_or_reset(). Help drivers avoid these repeated
>>
Hi,
On 2/22/24 12:38, Gregor Riepl wrote:
>> This certainly is the most KISS approach. This proposal
>> in essence is just an arbitrary command multiplexer /
>> demultiplexer and ioctls already are exactly that.
>>
>> With the added advantage of being able to directly use
>> pass the
Hi,
On 2/21/24 23:17, Pavel Machek wrote:
> Hi!
>
>> so after more feedback from the OpenRGB maintainers I came up with an even
>> more generic proposal:
>> https://gitlab.com/CalcProgrammer1/OpenRGB/-/issues/3916#note_1753072869
>
>>> evaluate-set-command ioctl taking:
>>> {
>>> enum
Hi,
On 1/30/24 20:08, Werner Sembach wrote:
> Hi,
>
> Am 30.01.24 um 19:35 schrieb Hans de Goede:
>> Hi,
>>
>> On 1/30/24 19:09, Werner Sembach wrote:
>>> Hi Hans,
>>>
>>> resend because Thunderbird htmlified the mail :/
>>
sages in HTML format"
I think that should do the trick.
> Am 30.01.24 um 18:10 schrieb Hans de Goede:
>> Hi Werner,
>>
>> On 1/30/24 12:12, Werner Sembach wrote:
>>> Hi Hans,
>>>
>>> Am 29.01.24 um 14:24 schrieb Hans de Goede:
>
>>
Hi Werner,
On 1/30/24 12:12, Werner Sembach wrote:
> Hi Hans,
>
> Am 29.01.24 um 14:24 schrieb Hans de Goede:
>> That sounds workable OTOH combined with your remarks about also supporting
>> lightbars. I'm starting to think that we need to just punt this to userspac
Hi Werner,
On 1/19/24 17:04, Werner Sembach wrote:
> Am 19.01.24 um 09:44 schrieb Hans de Goede:
>> So my proposal would be an ioctl interface (ioctl only no r/w)
>> using /dev/rgbkbd0 /dev/rgbkdb1, etc. registered as a misc chardev.
>>
>> For per key controllable
Hi,
On 1/19/24 21:15, Pavel Machek wrote:
> Hi!
>
2. Implement per-key keyboards as auxdisplay
- Pro:
- Already has a concept for led positions
- Is conceptually closer to "multiple leds forming a singular
entity"
- Con:
Hi Philipp,
On 1/23/24 10:43, Philipp Stanner wrote:
> When the PCI devres API was introduced to this driver, it was wrongly
> assumed that initializing the device with pcim_enable_device() instead
> of pci_enable_device() will make all PCI functions managed.
>
> This is wrong and was caused by
Hi,
On 1/18/24 18:45, Pavel Machek wrote:
> Hi!
>
>> We have an upcoming device that has a per-key keyboard backlight, but does
>> the control completely via a wmi/acpi interface. So no usable hidraw here
>> for a potential userspace driver implementation ...
>>
>> So a quick summary for the
Hi All,
On 11/27/23 11:59, Werner Sembach wrote:
> I also stumbled across a new Problem:
>
> We have an upcoming device that has a per-key keyboard backlight, but does
> the control completely via a wmi/acpi interface. So no usable hidraw here for
> a potential userspace driver
Hi Werner,
Once again, sorry for the very slow response here.
On 11/27/23 11:59, Werner Sembach wrote:
> Hi Hans,
>
> Am 22.11.23 um 19:34 schrieb Hans de Goede:
>> Hi Werner,
> [snip]
>>>>> Another idea I want to throw in the mix:
>>>>&g
Hi,
On 12/12/23 20:57, Brian Masney wrote:
> When the power domains cannot be parsed, the message is incorrectly
> logged as an info message. Let's change this to an error since an error
> is returned.
>
> Fixes: 92a511a568e4 ("fbdev/simplefb: Add support for generic power-domains")
>
soc_gpio_set_value() already uses devm_gpiod_get(), lets be consistent
and use devm_gpiod_get() for all GPIOs.
This allows removing the intel_dsi_vbt_gpio_cleanup() function,
which only function was to put the GPIO-descriptors.
Signed-off-by: Hans de Goede
---
Note this applies on top of Andy's
Hi Werner,
On 11/21/23 14:29, Werner Sembach wrote:
>
> Am 21.11.23 um 13:20 schrieb Hans de Goede:
>> Hi Werner,
>>
>> On 11/21/23 12:33, Werner Sembach wrote:
>>> Hi,
>>>
>>> Am 20.11.23 um 21:52 schrieb Pavel Machek:
>>>> Hi!
>
Hi,
On 11/22/23 01:54, Richard Acayan wrote:
> When the power domains are missing, the call to of_count_phandle_with_args
> fails with -ENOENT. The power domains are not required and there are
> some device trees that do not specify them. Suppress this error to fix
> devices without power domains
Hi,
On 11/22/23 01:01, Richard Acayan wrote:
> On Tue, Nov 21, 2023 at 10:01:18AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/21/23 02:17, Richard Acayan wrote:
>>> Hello,
>>>
>>> On Wed, Nov 01, 2023 at 06:20:17PM +0100, Thierry Reding wrote:
Hi Werner,
On 11/21/23 12:33, Werner Sembach wrote:
> Hi,
>
> Am 20.11.23 um 21:52 schrieb Pavel Machek:
>> Hi!
>>
> So... a bit of rationale. The keyboard does not really fit into the
> LED subsystem; LEDs are expected to be independent ("hdd led") and not
> a matrix of them.
Hi,
On 11/21/23 02:17, Richard Acayan wrote:
> Hello,
>
> On Wed, Nov 01, 2023 at 06:20:17PM +0100, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> The simple-framebuffer device tree bindings document the power-domains
>> property, so make sure that simplefb supports it. This ensures that
ies is:
Tested-by: Hans de Goede
And the code of the entire series also looks good to me:
Reviewed-by: Hans de Goede
for the series.
Regards,
Hans
> In v4:
> - fixed compile time errors in patch 14 (Hans, LKP)
> - fixed cover letter Subject
> - added patch 15 (as sugg
Hi Brenton,
On 11/15/23 16:52, Brenton Simpson wrote:
> Yes, thanks!
>
> That's the email attached to my public git work, so it should be the
> one here as well.
Ok, I've pushed this to drm-misc-fixes now, thank you for the patch.
> Sorry for the hassle. Very new to sending PRs over email,
Hi,
On 11/15/23 16:48, Brenton Simpson wrote:
> Resending from the email address linked to my GitHub account.
Ok, this doesn't really help. I'll just fix-up the author
field of the original patch.
Do understand correctly that both the author and the Signed-off-by
should be set to:
Brenton
Hi,
On 11/10/23 17:58, Owen T. Heisler wrote:
> Hi everyone,
>
> On 11/10/23 06:52, Kai-Heng Feng wrote:
>> On Fri, Nov 10, 2023 at 2:19 PM Hans de Goede wrote:
>>> On 11/10/23 07:09, Kai-Heng Feng wrote:
>>>> On Fri, Nov 10, 2023 at 5:55 AM Owen T. Heisl
you build a v6.6 kernel with these 2 patches added
on top please and see if that fixes things ?
Kai-Heng can you test that the issue on the HP ZBook Fury 16 G10
is still resolved after applying these patches ?
Regards,
Hans
From 68a819101c580bb89f34a31196ace81244ca8eb5 Mon Sep 17 00:00:00 2001
`is_tunneled`.
>
> Signed-off-by: Mario Limonciello
Here is my ack for the trivial drivers/platform/x86/apple-gmux.c change:
Acked-by: Hans de Goede
Bjorn, feel free to route this through the PCI tree.
Regards,
Hans
> ---
> drivers/pci/pci.c | 2 +
Hi,
On 11/2/23 16:12, Andy Shevchenko wrote:
> It's a dirty hack in the driver that pokes GPIO registers behind
> the driver's back. Moreoever it might be problematic as simultaneous
> I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
> cherryview: prevent concurrent access to GPIO
Hi,
On 11/2/23 15:19, Andy Shevchenko wrote:
> On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote:
>> On 11/1/23 10:32, Andy Shevchenko wrote:
>>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>>>> On 10/31/23 17:07, Hans de Goede wrote:
Hi,
On 11/1/23 18:54, Hans de Goede wrote:
> Hi,
>
> On 11/1/23 18:20, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> Hi,
>>
>> This contains two patches that bring simplefb up to feature parity with
>> simpledrm. The patches add support for
n v2:
> - remove unnecessary call to simplefb_detach_genpds() since that's
> already done automatically by devres
> - fix crash if power-domains property is missing in DT
Thanks, the new version looks good to me:
Reviewed-by: Hans de Goede
for the series.
Helge, will you pick
Hi,
On 11/1/23 17:50, Thierry Reding wrote:
> On Thu, Oct 26, 2023 at 02:50:27PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> Thank you for your patches.
>>
>> On 10/11/23 16:38, Thierry Reding wrote:
>>> From: Thierry Reding
>>>
>>> Th
Hi,
On 11/1/23 11:20, Hans de Goede wrote:
> Hi,
>
> On 11/1/23 10:32, Andy Shevchenko wrote:
>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>>> On 10/31/23 17:07, Hans de Goede wrote:
>>>> On 10/24/23 18:11, Andy Shevchenko wrote:
>
Hi,
On 11/1/23 11:34, Ville Syrjälä wrote:
> On Wed, Nov 01, 2023 at 11:20:23AM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 11/1/23 10:32, Andy Shevchenko wrote:
>>> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>>>> On 10/31/23 17:07, Ha
Hi,
On 11/1/23 10:32, Andy Shevchenko wrote:
> On Tue, Oct 31, 2023 at 10:15:52PM +0100, Hans de Goede wrote:
>> On 10/31/23 17:07, Hans de Goede wrote:
>>> On 10/24/23 18:11, Andy Shevchenko wrote:
>>>> On Tue, Oct 24, 2023 at 06:57:38P
Hi,
On 10/31/23 17:07, Hans de Goede wrote:
> Hi Andy,
>
> On 10/24/23 18:11, Andy Shevchenko wrote:
>> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
>>> It's a dirty hack in the driver that pokes GPIO registers behind
>>> the driver's back.
Hi Andy,
On 10/24/23 18:11, Andy Shevchenko wrote:
> On Tue, Oct 24, 2023 at 06:57:38PM +0300, Andy Shevchenko wrote:
>> It's a dirty hack in the driver that pokes GPIO registers behind
>> the driver's back. Moreoever it might be problematic as simultaneous
>> I/O may hang the system, see the
Hi,
Thank you for your patches.
On 10/11/23 16:38, Thierry Reding wrote:
> From: Thierry Reding
>
> The simple-framebuffer device tree bindings document the power-domains
> property, so make sure that simplefb supports it. This ensures that the
> power domains remain enabled as long as
display hardware. Implement support
> for this in the simplefb driver.
>
> Signed-off-by: Thierry Reding
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
Regards,
Hans
> ---
> drivers/video/fbdev/simplefb.c | 35 +-
> 1 file changed, 30 in
Hi Sean,
On 10/22/23 12:46, Sean Young wrote:
> Hi Hans,
>
> On Sat, Oct 21, 2023 at 11:08:22AM +0200, Hans de Goede wrote:
>> On 10/19/23 12:51, Uwe Kleine-König wrote:
>>> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote:
>>>> On 10/17/23
Hi Uwe,
On 10/19/23 12:51, Uwe Kleine-König wrote:
> On Wed, Oct 18, 2023 at 03:57:48PM +0200, Hans de Goede wrote:
>> Hi Sean,
>>
>> On 10/17/23 11:17, Sean Young wrote:
>>> Some drivers require sleeping, for example if the pwm device is connected
>>> o
Hi,
I was not following this at first, so my apologies for
jumping in in the middle of the thread:
> +static int amd_pmf_gpu_get_cur_state(struct thermal_cooling_device
> *cooling_dev,
> + unsigned long *state)
> +{
> + struct backlight_device *bd;
Hi Sean,
On 10/17/23 11:17, Sean Young wrote:
> Some drivers require sleeping, for example if the pwm device is connected
> over i2c. The pwm-ir-tx requires precise timing, and sleeping causes havoc
> with the generated IR signal when sleeping occurs.
>
> This patch makes it possible to use pwm
Hi Andy,
On 10/18/23 07:10, Andy Shevchenko wrote:
> DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> talking to GPIO IP behind the actual driver's back. An attempt to fix
> that is here.
>
> If I understood correctly, my approach should work in the similar way as
> the
Hi,
On 10/11/23 15:05, Jani Nikula wrote:
> On Sun, 08 Oct 2023, Hans de Goede wrote:
>> Hi All,
>>
>> Ping what is the status of this now? This v3 addresses all review
>> remarks from previous versions (specifically the request to file
>> + link gitlab issue
,
Hans
On 9/20/23 21:56, Hans de Goede wrote:
> Hi All,
>
> Some vlv/chv tablets ship with Android as factory OS. The factory OS
> BSP style kernel on these tablets does not use the normal x86 hw
> autodetection instead it hardcodes a whole bunch of things including
> using pan
Kai Uwe Broulik
> ---
> Changes since v1:
> * Got two more BIOS dates reported
Thanks, patch still looks good to me:
Reviewed-by: Hans de Goede
drm-misc maintainers, I'm currently traveling can
one of you push this to drm-misc-fixes please?
Regards,
Hans
>
> drivers/gpu/drm/drm_p
roulik
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
drm-misc maintainers, I'm currently traveling can
one of you push this to drm-misc-fixes please?
Regards,
Hans
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 16
> 1 file changed, 16 inser
HI,
On 9/26/23 15:17, Christian König wrote:
> Am 26.09.23 um 14:56 schrieb Hans de Goede:
>> Hi,
>>
>> On 9/26/23 13:24, Shyam Sundar S K wrote:
>>> Hi Hans,
>>>
>>> On 9/26/2023 4:05 PM, Hans de Goede wrote:
>>>> Hi,
>>>&g
Hi,
On 9/26/23 13:24, Shyam Sundar S K wrote:
> Hi Hans,
>
> On 9/26/2023 4:05 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 9/22/23 19:50, Shyam Sundar S K wrote:
>>> For the Smart PC Solution to fully work, it has to enact to the actions
>>> comi
Hi,
On 9/22/23 19:50, Shyam Sundar S K wrote:
> For the Smart PC Solution to fully work, it has to enact to the actions
> coming from TA. Add the initial code path for set interface to AMDGPU.
>
> Co-developed-by: Mario Limonciello
> Signed-off-by: Mario Limonciello
> Signed-off-by: Shyam
Add some debug logging to mipi_exec_i2c, to make debugging various
issues seen with it easier.
Changes in v2:
- Drop unnecessary __func__ drm_dbg_kms() argument
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
, VBT info
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9379
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 52 ++
1 file changed, 52 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/dri
() to pick the wrong bus.
2. There is no backlight off sequence, causing the backlight to stay on.
Add a DMI quirk fixing both issues.
v2:
- Add Closes tag to gitlab issue with drm.debug=0xe, VBT info
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9380
Signed-off-by: Hans de Goede
tag to gitlab issue with drm.debug=0xe, VBT info
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9381
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 44 ++
1 file changed, 44 insertions(+)
diff --git a/
affected models. Add Closes: tags with links to gitlab issues
Regards,
Hans
Hans de Goede (4):
drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on
Asus TF103C (v3)
drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on
Lenovo Yoga Tablet 2 series (v3)
drm
Hi Ville,
On 9/18/23 10:00, Ville Syrjälä wrote:
> On Sat, Sep 16, 2023 at 02:54:51PM +0200, Hans de Goede wrote:
>> Hi All,
>>
>> Some vlv/chv tablets ship with Android as factory OS. The factory OS
>> BSP style kernel on these tablets does not use the normal x86
Hi,
On 9/19/23 19:46, Julius Zint wrote:
>
>
> On Wed, 6 Sep 2023, Hans de Goede wrote:
>
>> Hi Julius,
>>
>> On 9/4/23 21:02, Julius Zint wrote:
>>>
>>>
>>> On Mon, 4 Sep 2023, Thomas Weißschuh wrote:
>>>
>>>&
Add some debug logging to mipi_exec_i2c, to make debugging various
issues seen with it easier.
Changes in v2:
- Drop unnecessary __func__ drm_dbg_kms() argument
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 +++
1 file
050 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.
Changes in v2:
- Also override i2c_bus_num to fix mipi_exec_i2c() timeouts
Reviewed-by: Javier Martinez Canillas
Signed-off-by: Ha
() to pick the wrong bus.
2. There is no backlight off sequence, causing the backlight to stay on.
Add a DMI quirk fixing both issues.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 32 ++
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm
. This should
avoid any chances of causing regressions on devices where the quirks
do not apply.
- New quirk for backlight control issues on Lenovo Yoga Tab 3
- Address Jani Nikula's remark about __func__ being redundant when using
drm_dbg_kms()
Regards,
Hans
Hans de Goede (4):
drm/i915
nez Canillas
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/vlv_dsi.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/vlv_dsi.c
b/drivers/gpu/drm/i915/display/vlv_dsi.c
index a96e7d028c5c..51c4b1491fa2 100644
--- a/
Hi Julius,
On 9/4/23 21:02, Julius Zint wrote:
>
>
> On Mon, 4 Sep 2023, Thomas Weißschuh wrote:
>
>> +Cc Hans who ins involved with the backlight subsystem
>>
>> Hi Julius,
>>
>> today I stumbled upon a mail from Hans [0], which explains that the
>> backlight subsystem is not actually a good
ed, also remove msecs_to_jiffies() for the IDLE_TIMEOUT
> macro to make it consistent here and so change IDLE_TIMEOUT to
> msecs_to_jiffies(IDLE_TIMEOUT) where it is used.
>
> Fixes: e4f86e437164 ("drm: Add Grain Media GM12U320 driver v2")
> Signed-off-by: Jinjie Ruan
&
Hi Jinjie,
On 9/3/23 10:55, Jinjie Ruan wrote:
> The timeout arg of usb_bulk_msg() is ms already and it has convert it
> to jiffies by msecs_to_jiffies() in usb_start_wait_urb(). So fix the usage
> by remove the redundant msecs_to_jiffies() in the macros.
>
> Fixes: 77b8cabf3d52 ("drm/gm12u320:
to be an Air Pro, and on Air Plus.
>
> Signed-off-by: Maya Matuszczyk
Thanks, patch looks good to me:
Reviewed-by: Hans de Goede
I have just pushed this to drm-misc-fixes, so it should get
send to Linus with the next drm-fixes pull-req.
Regards,
Hans
> ---
> drivers/gp
drm-misc-fixes now.
I'll also submit a downstream Fedora kernel pull-req with this
to get this resolved in the Fedora kernels .
Regards,
Hans
>
> On Sun, 2023-03-26 at 22:54 +0200, Hans de Goede wrote:
>> The nouveau code used to call drm_fb_helper_initial_config() from
>
://gitlab.freedesktop.org/drm/nouveau/-/issues/202
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 4040
Hi,
On 3/13/23 16:39, Javier Martinez Canillas wrote:
> Hans de Goede writes:
>
> Hello Hans,
>
>> Like the Windows Lenovo Yoga Book X91F/L the Android Lenovo Yoga Book
>> X90F/L has a portrait 1200x1920 screen used in landscape mode,
>> add a quirk for this.
>
Hi Takashi,
On 3/17/23 11:04, Takashi Iwai wrote:
> Hi,
>
> we've received a regression report on openSUSE Bugzilla about the
> missing backlight control of nouveau device:
> https://bugzilla.opensuse.org/show_bug.cgi?id=1209296
>
> On 6.1, with acpi_video=native option, the system provided
>
Hi,
On 3/16/23 15:57, Rodrigo Siqueira Jordao wrote:
>
>
> On 3/12/23 13:17, Hans de Goede wrote:
>> Hi All,
>>
>> Here is version 3 of my patch series to pass the proper parent device
>> to backlight_device_register().
>>
>> Changes in v3:
>>
)
Immutable branch between pdx86 and backlight due for the v6.4 merge window
Dan Carpenter (1):
platform/x86: apple-gmux: return -EFAULT if copy fails
Hans de Goede (2
Another Lenovo convertable which reports a landscape resolution of
1920x1200 with a pitch of (1920 * 4) bytes, while the actual framebuffer
has a resolution of 1200x1920 with a pitch of (1200 * 4) bytes.
Signed-off-by: Hans de Goede
---
drivers/firmware/efi/sysfb_efi.c | 8
1 file
orm_device) into its own function and call that at
the place of the moved sysfb_apply_efi_quirks(pd) calls.
Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for
all arches")
Cc: sta...@vger.kernel.org
Cc: Javier Martinez Canillas
Cc: Thomas Zimmermann
Signed-o
Hi,
On 3/9/23 18:09, Daniel Thompson wrote:
> On Tue, Mar 07, 2023 at 01:05:40PM +0100, Hans de Goede wrote:
>> On some MacBooks both the apple_bl and the apple-gmux backlight drivers
>> may be able to export a /sys/class/backlight device.
>>
>> To avoid having 2 ba
backlight class device.
This is a preparation patch for moving the actual backlight class device
registering to drm_connector_funcs.late_register.
Signed-off-by: Hans de Goede
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 17 -
1 file changed, 8 insertions(+), 9 deletions
nd re-using the current
bl_idx for a potential other backlight device, dm->backlight_dev[bl_idx]
is now simply left NULL on failure. This is ok because all code
looking at dm->backlight_dev[i] also checks it is not NULL.
Link: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/730
-by: Hans de Goede
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 24 +--
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 757202af2eec..038bf897cc28
reworking update_connector_ext_caps() also remove the aconnector
and aconnector->dc_link NULL checks in this function. These are both
never NULL and are unconditionally derefed in its callers.
Signed-off-by: Hans de Goede
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 42 +++
.../gpu/drm/amd/displ
dps])"
check will thus always succeed and can be removed.
4) Add a bl_idx local variable to use as array index, rather then
using dm->num_of_edps to improve the code readability.
Signed-off-by: Hans de Goede
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 28 ++-
ed-off-by: Hans de Goede
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 009ef917dad4..42b88ab5552d
there.
Regards,
Hans
Hans de Goede (6):
drm/amd/display/amdgpu_dm: Fix backlight_device_register() error
handling
drm/amd/display/amdgpu_dm: Refactor register_backlight_device()
drm/amd/display/amdgpu_dm: Add a bl_idx to amdgpu_dm_connector
drm/amd/display/amdgpu_dm: Move most
1 - 100 of 1992 matches
Mail list logo
