[PULL] drm-intel-fixes

Hi Dave & Daniel, Two final -fixes for v5.18. One is to reject DMC with out-of-spec MMIO (Cc: stable) and another to correctly mark guilty contexts on GuC reset. Regards, Joonas *** drm-intel-fixes-2022-05-19: - Reject DMC firmware with out-of-spec MMIO addresses. - Correctly mark guilty

Re: [PATCH v4 2/3] phy/qualcomm: add regulator_set_load to dp phy

On 18-05-22, 14:36, Kuogee Hsieh wrote: > This patch add regulator_set_load() before enable regulator at > DP phy driver. sigh! still wrong tags! > > Signed-off-by: Kuogee Hsieh > Reviewed-by: Stephen Boyd > --- > drivers/phy/qualcomm/phy-qcom-qmp.c | 12 > 1 file changed, 12

Re: [linux-next:master] BUILD REGRESSION 736ee37e2e8eed7fe48d0a37ee5a709514d478b3

On 5/18/22 17:55, kernel test robot wrote: tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next specific files for 20220518 Error/Warning reports: https://lore.kernel.org/linux-mm

Re: [Freedreno] [PATCH v2] drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path

On 5/18/2022 5:40 PM, Stephen Boyd wrote: Quoting Abhinav Kumar (2022-05-18 15:34:07) If there are errors while trying to enable the pm in the bind path, it will lead to unclocked access of hw revision register thereby crashing the device. This will not address why the pm_runtime_get_sync()

[linux-next:master] BUILD REGRESSION 736ee37e2e8eed7fe48d0a37ee5a709514d478b3

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 736ee37e2e8eed7fe48d0a37ee5a709514d478b3 Add linux-next specific files for 20220518 Error/Warning reports: https://lore.kernel.org/linux-mm/202204291924.vtgzmeri-...@intel.com https

Re: (EXT) [PATCH v0.5 0/9] i.MX8MP HDMI support

On 5/9/22 11:44, Alexander Stein wrote: Hi Lucas, Am Freitag, 6. Mai 2022, 20:10:25 CEST schrieb Lucas Stach: second round of the i.MX8MP HDMI work. Still not split up into proper parts for merging through the various trees this needs to go into, but should make it easy for people to test.

[PATCH v3 2/2] drm: lcdif: Add support for i.MX8MP LCDIF variant

Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. Add a separate driver which

[PATCH v3 1/2] dt-bindings: lcdif: Add compatible for i.MX8MP

Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. However, except for

Re: [PATCH v2] drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path

Quoting Abhinav Kumar (2022-05-18 15:34:07) > If there are errors while trying to enable the pm in the > bind path, it will lead to unclocked access of hw revision > register thereby crashing the device. > > This will not address why the pm_runtime_get_sync() fails > but at the very least we

[Bug 201497] [amdgpu]: '*ERROR* No EDID read' is back in 4.19

https://bugzilla.kernel.org/show_bug.cgi?id=201497 Rev (r...@pop.ms) changed: What|Removed |Added CC||r...@pop.ms --- Comment #24 from Rev

Re: [PATCH v2] drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path

On Wed, May 18, 2022 at 3:34 PM Abhinav Kumar wrote: > > If there are errors while trying to enable the pm in the > bind path, it will lead to unclocked access of hw revision > register thereby crashing the device. > > This will not address why the pm_runtime_get_sync() fails > but at the very

[PATCH] drm/bridge: ti-sn65dsi83: Handle dsi_lanes == 0 as invalid

Handle empty data-lanes = < >; property, which translates to dsi_lanes = 0 as invalid. Fixes: ceb515ba29ba6 ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Signed-off-by: Marek Vasut Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Lucas Stach Cc: Marek Vasut Cc: Maxime Ripard

[PATCH 2/3] drm/bridge: tc358767: Report DSI-to-(e)DP as supported

The DSI-to-e(DP) mode is now supported, update the driver comment to reflect this. No functional change. Fixes: 3080c21a043ab ("drm/bridge: tc358767: Add DSI-to-(e)DP mode support") Signed-off-by: Marek Vasut Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Lucas Stach Cc: Marek Vasut Cc: Maxime

[PATCH 3/3] drm/bridge: tc358767: Make sure Refclk clock are enabled

The Refclk may be supplied by SoC clock output instead of crystal oscillator, make sure the clock are enabled before any other action is performed with the bridge chip, otherwise it may either fail to operate at all, or miss reset GPIO toggle. Fixes: 7caff0fc4296e ("drm/bridge: tc358767: Add DPI

[PATCH 1/3] drm/bridge: tc358767: Handle dsi_lanes == 0 as invalid

Handle empty data-lanes = < >; property, which translates to dsi_lanes = 0 as invalid. Fixes: bbfd3190b6562 ("drm/bridge: tc358767: Add DSI-to-DPI mode support") Signed-off-by: Marek Vasut Cc: Jonas Karlman Cc: Laurent Pinchart Cc: Lucas Stach Cc: Marek Vasut Cc: Maxime Ripard Cc: Neil

Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering

On 18.05.2022 16:05, Marek Szyprowski wrote: Hi Dave, On 11.05.2022 17:47, Dave Stevenson wrote: On Wed, 11 May 2022 at 15:58, Marek Szyprowski wrote: On 05.04.2022 13:43, Dave Stevenson wrote: On Fri, 18 Mar 2022 at 12:25, Dave Stevenson wrote: On Fri, 4 Mar 2022 at 15:18, Dave

[PATCH v2] drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path

If there are errors while trying to enable the pm in the bind path, it will lead to unclocked access of hw revision register thereby crashing the device. This will not address why the pm_runtime_get_sync() fails but at the very least we should be able to prevent the crash by handling the error

Re: [PATCH v4 1/3] phy/qualcomm: add regulator_set_load to edp phy

On Thu, 19 May 2022 at 00:36, Kuogee Hsieh wrote: > > This patch add regulator_set_load() before enable regulator at > eDP phy driver. > > Signed-off-by: Kuogee Hsieh > --- > drivers/phy/qualcomm/phy-qcom-edp.c | 10 +- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git

Re: [PATCH v4 3/3] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller

On Thu, 19 May 2022 at 00:36, Kuogee Hsieh wrote: > > Vdda regulators are related to both eDP and DP phy so that it should be > managed at eDP and DP phy driver instead of controller. This patch removes > vdda regulators related functions out of eDP/DP controller. > > Signed-off-by: Kuogee Hsieh

Re: [PATCH v4 2/3] phy/qualcomm: add regulator_set_load to dp phy

On Thu, 19 May 2022 at 00:36, Kuogee Hsieh wrote: > > This patch add regulator_set_load() before enable regulator at > DP phy driver. > > Signed-off-by: Kuogee Hsieh > Reviewed-by: Stephen Boyd > --- > drivers/phy/qualcomm/phy-qcom-qmp.c | 12 > 1 file changed, 12 insertions(+) >

[PATCH v4 3/3] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller

Vdda regulators are related to both eDP and DP phy so that it should be managed at eDP and DP phy driver instead of controller. This patch removes vdda regulators related functions out of eDP/DP controller. Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd ---

[PATCH v4 2/3] phy/qualcomm: add regulator_set_load to dp phy

This patch add regulator_set_load() before enable regulator at DP phy driver. Signed-off-by: Kuogee Hsieh Reviewed-by: Stephen Boyd --- drivers/phy/qualcomm/phy-qcom-qmp.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/phy/qualcomm/phy-qcom-qmp.c

[PATCH v4 1/3] phy/qualcomm: add regulator_set_load to edp phy

This patch add regulator_set_load() before enable regulator at eDP phy driver. Signed-off-by: Kuogee Hsieh --- drivers/phy/qualcomm/phy-qcom-edp.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/phy/qualcomm/phy-qcom-edp.c

[PATCH v4 0/3] eDP/DP Phy vdda realted function

1) add regulator_set_load() to eDP phy 2) add regulator_set_load() to DP phy 3) remove vdda related function out of eDP/DP controller Kuogee Hsieh (3): phy/qualcomm: add regulator_set_load to edp phy phy/qualcomm: add regulator_set_load to dp phy drm/msm/dp: delete vdda regulator related

Re: [PATCH v3 3/3] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller

Quoting Kuogee Hsieh (2022-05-18 13:24:04) > Vdda regulators are related to both eDP and DP phy so that it should be > managed at eDP and DP phy driver instead of controller. This patch removes > vdda regulators related functions out of eDP/DP controller. > > Signed-off-by: Kuogee Hsieh > ---

[pull] amdgpu, amdkfd drm-next-5.19

Hi Dave, Daniel, Stuff for 5.19. A bit late for new stuff, but it's just additional enablement for new IPs so they shouldn't affect existing parts. The rest is just the usual fixes. The following changes since commit 81c5495910e81c2cadcb9118ca0c8803ab3bde61: drm/amdgpu: Remove duplicated

Re: [PATCH 1/1] drm/panfrost: Add support for devcoredump

On Tue, May 17, 2022 at 10:42 AM Adrián Larumbe wrote: > > In the event of a job timeout, debug dump information will be written into > /sys/class/devcoredump. > > Inspired by etnaviv's similar feature. > > Signed-off-by: Adrián Larumbe > --- > drivers/gpu/drm/panfrost/Kconfig | 1 + >

Re: [PATCH v3 2/3] phy/qualcomm: add regulator_set_load to dp phy

Quoting Kuogee Hsieh (2022-05-18 13:24:03) > This patch add regulator_set_load() before enable regulator at > DP phy driver. > > Changes in v2: > -- no regulator_set_load() before disable regulator > > Changes in v3: > -- split into two patches Same changelog comment > > Signed-off-by: Kuogee

Re: [PATCH v3 1/3] phy/qualcomm: add regulator_set_load to edp phy

Should subject be "phy: qcom:" prefix? Quoting Kuogee Hsieh (2022-05-18 13:24:02) > This patch add regulator_set_load() before enable regulator at > eDP phy driver. > > Changes in v3: > -- no regulator_set_load before disable regulator > -- no supply name string change at probe > -- split into

[PATCH v3 2/3] phy/qualcomm: add regulator_set_load to dp phy

This patch add regulator_set_load() before enable regulator at DP phy driver. Changes in v2: -- no regulator_set_load() before disable regulator Changes in v3: -- split into two patches Signed-off-by: Kuogee Hsieh --- drivers/phy/qualcomm/phy-qcom-qmp.c | 12 1 file changed, 12

[PATCH v3 3/3] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller

Vdda regulators are related to both eDP and DP phy so that it should be managed at eDP and DP phy driver instead of controller. This patch removes vdda regulators related functions out of eDP/DP controller. Signed-off-by: Kuogee Hsieh --- drivers/gpu/drm/msm/dp/dp_parser.c | 14 --

[PATCH v3 1/3] phy/qualcomm: add regulator_set_load to edp phy

This patch add regulator_set_load() before enable regulator at eDP phy driver. Changes in v3: -- no regulator_set_load before disable regulator -- no supply name string change at probe -- split into two patches Signed-off-by: Kuogee Hsieh --- drivers/phy/qualcomm/phy-qcom-edp.c | 10 +-

[PATCH v3 0/3] eDP/DP Phy vdda realted function

1) add regulator_set_load() to eDP phy 2) add regulator_set_load() to DP phy 3) remove vdda related function out of eDP/DP controller Kuogee Hsieh (3): phy/qualcomm: add regulator_set_load to edp phy phy/qualcomm: add regulator_set_load to dp phy drm/msm/dp: delete vdda regulator related

[pull] amdgpu drm-fixes-5.18

Hi Dave, Daniel, Just one suspend/resume regression fix. The following changes since commit 42226c989789d8da4af1de0c31070c96726d990c: Linux 5.18-rc7 (2022-05-15 18:08:58 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git

Re: [PATCH v2 0/2] eDP/DP Phy vdda realted function

On 5/18/2022 10:31 AM, Dmitry Baryshkov wrote: On 18/05/2022 20:29, Kuogee Hsieh wrote: On 5/18/2022 10:16 AM, Dmitry Baryshkov wrote: On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: 1) add regulator_set_load() to eDP/DP phy 2) remove vdda related function out of eDP/DP controller

Re: [PATCH] drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path

Quoting Abhinav Kumar (2022-05-18 12:55:40) > If there are errors while trying to enable the pm in the > bind path, it will lead to unclocked access of hw revision > register thereby crashing the device. > > This will not address why the pm_runtime_get_sync() fails > but at the very least we

[PATCH] drm/msm/dpu: handle pm_runtime_get_sync() errors in bind path

If there are errors while trying to enable the pm in the bind path, it will lead to unclocked access of hw revision register thereby crashing the device. This will not address why the pm_runtime_get_sync() fails but at the very least we should be able to prevent the crash by handling the error

Re: [PATCH] drm/msm/dpu: limit writeback modes according to max_linewidth

On 14/05/2022 01:59, Abhinav Kumar wrote: Writeback modes were being added according to mode_config.max_width but this is assigned to double of max_mixer_width. For compositors/clients using a single SSPP, this will fail the dpu_plane's atomic check as it checks for max_linewidth. Limit

RE: [PATCH] video: hyperv_fb: Allow resolutions with size > 64 MB for Gen1

> From: Dexuan Cui > Sent: Wednesday, May 4, 2022 10:05 AM > To: Haiyang Zhang ; Wei Liu ; > > ... > > When I initially implemented this driver 10 years ago, I believe there > > was smaller limit for the fb... But I think this patch is good for the > > newer MMIO alloc scheme. I hope to see

Re: [PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

Hello, On Wed, May 18, 2022 at 08:30:06PM +0200, Thomas Zimmermann wrote: > Open Firmware provides basic display output via the 'display' node. > DT platform code already provides a device that represents the node's > framebuffer. Add a DRM driver for the device. The display mode and > color

Re: [PATCH v3] uapi/drm/i915: Document memory residency and Flat-CCS capability of obj

Media driver never creates a BO with more than one backing regions. Acked-by: Tony Ye Thanks, Tony On 5/2/2022 7:15 AM, Ramalingam C wrote: Capture the impact of memory region preference list of the objects, on their memory residency and Flat-CCS capability. v2: Fix the Flat-CCS

[PATCH 0/2] drm: Add driverof PowerPC OF displays

PowerPC's Open Firmware offers a simple display buffer for graphics output. Add ofdrm, a DRM driver for the device. As with the existing simpledrm driver, the graphics hardware is pre-initialized by the firmware. The driver only provides blitting, no actual DRM modesetting is possible. Thomas

[PATCH 2/2] drm/tiny: Add ofdrm for Open Firmware framebuffers

Open Firmware provides basic display output via the 'display' node. DT platform code already provides a device that represents the node's framebuffer. Add a DRM driver for the device. The display mode and color format is pre-initialized by the system's firmware. Runtime modesetting via DRM is not

[PATCH 1/2] MAINTAINERS: Broaden scope of simpledrm entry

There will be more DRM drivers for firmware-provided framebuffers. Use the existing entry for simpledrm instead of adding a new one for each driver. Also add DRM's aperture helpers, which are part of the driver's infrastructure. Signed-off-by: Thomas Zimmermann --- MAINTAINERS | 4 +++- 1 file

Re: [PATCH v2 1/2] phy/qcom: add regulator_set_load to edp/dp phy

On 5/18/2022 10:52 AM, Dmitry Baryshkov wrote: On 18/05/2022 20:36, Kuogee Hsieh wrote: On 5/18/2022 10:12 AM, Dmitry Baryshkov wrote: On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: This patch add regulator_set_load() to both eDP and DP phy driver to have totally control regulators.

Re: [PATCH v2 1/2] phy/qcom: add regulator_set_load to edp/dp phy

On 18/05/2022 20:36, Kuogee Hsieh wrote: On 5/18/2022 10:12 AM, Dmitry Baryshkov wrote: On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: This patch add regulator_set_load() to both eDP and DP phy driver to have totally control regulators. Changes in v2: -- no regulator_set_laod() before

Re: nouveau lockdep deadlock report with 5.18-rc6

Yeah I noticed this as well, I will try to bisect this the next change that I get On Tue, 2022-05-17 at 13:10 +0200, Hans de Goede wrote: > 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

Re: [PATCH 12/14] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails

On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote: > Typically the acpi_video driver will initialize before nouveau, which > used to cause /sys/class/backlight/acpi_video0 to get registered and then > nouveau would register its own nv_backlight device later. After which > the

Re: [PATCH v2 1/2] phy/qcom: add regulator_set_load to edp/dp phy

On 5/18/2022 10:12 AM, Dmitry Baryshkov wrote: On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: This patch add regulator_set_load() to both eDP and DP phy driver to have totally control regulators. Changes in v2: -- no regulator_set_laod() before disable regulator Signed-off-by: Kuogee

Re: [PATCH v2 0/2] eDP/DP Phy vdda realted function

On 18/05/2022 20:29, Kuogee Hsieh wrote: On 5/18/2022 10:16 AM, Dmitry Baryshkov wrote: On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: 1) add regulator_set_load() to eDP/DP phy 2) remove vdda related function out of eDP/DP controller These patches touch two subsystems and have a

Re: [PATCH v2 0/2] eDP/DP Phy vdda realted function

On 5/18/2022 10:16 AM, Dmitry Baryshkov wrote: On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: 1) add regulator_set_load() to eDP/DP phy 2) remove vdda related function out of eDP/DP controller These patches touch two subsystems and have a dependency between them. How do we merge them?

Re: [PATCH v2 0/2] eDP/DP Phy vdda realted function

On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: > > 1) add regulator_set_load() to eDP/DP phy > 2) remove vdda related function out of eDP/DP controller These patches touch two subsystems and have a dependency between them. How do we merge them? > > Kuogee Hsieh (2): > phy/qcom: add

Re: [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.

On Wed, 2022-05-18 at 15:39 +, Sean Christopherson wrote: > On Wed, May 18, 2022, Maxim Levitsky wrote: > > On Wed, 2022-05-18 at 16:28 +0800, Chao Gao wrote: > > > > struct kvm_arch { > > > > @@ -1258,6 +1260,7 @@ struct kvm_arch { > > > > hpa_t hv_root_tdp; > > > >

Re: [RFC PATCH v3 01/19] KVM: x86: document AVIC/APICv inhibit reasons

On Wed, 2022-05-18 at 15:56 +, Sean Christopherson wrote: > On Wed, Apr 27, 2022, Maxim Levitsky wrote: > > These days there are too many AVIC/APICv inhibit > > reasons, and it doesn't hurt to have some documentation > > for them. > > Please wrap at ~75 chars. > > > Signed-off-by: Maxim

Re: [PATCH v2 2/2] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller

On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: > > Vdda regulators are related to both eDP and DP phy so that it should be > managed at eDP and DP phy driver instead of controller. This patch remove removes > vdda regulators related functions out of eDP/DP controller. > Signed-off-by: Kuogee

Re: [PATCH v2 1/2] phy/qcom: add regulator_set_load to edp/dp phy

On Wed, 18 May 2022 at 19:43, Kuogee Hsieh wrote: > > This patch add regulator_set_load() to both eDP and DP phy driver > to have totally control regulators. > > Changes in v2: > -- no regulator_set_laod() before disable regulator > > Signed-off-by: Kuogee Hsieh > --- >

Re: [PATCH 05/14] drm/nouveau: Don't register backlight when another backlight should be used

Reviewed-by: Lyude Paul Also, ack on this being pushed to drm-misc, along with any other patches I r-b On Tue, 2022-05-17 at 17:23 +0200, Hans de Goede wrote: > Before this commit when we want userspace to use the acpi_video backlight > device we register both the GPU's native backlight device

Re: [PATCH] drm/bridge: fix anx6345 power up sequence

On Thu, Apr 28, 2022 at 8:58 AM Torsten Duwe wrote: > > On Mon, 18 Apr 2022 17:25:57 -0700 > Vasily Khoruzhick wrote: > > > On Sun, Apr 17, 2022 at 11:52 AM Vasily Khoruzhick > > wrote: > > > > The change looks good to me, but I'll need some time to actually > > > test it. If you don't hear

[PATCH v2 2/2] drm/msm/dp: delete vdda regulator related functions from eDP/DP controller

Vdda regulators are related to both eDP and DP phy so that it should be managed at eDP and DP phy driver instead of controller. This patch remove vdda regulators related functions out of eDP/DP controller. Signed-off-by: Kuogee Hsieh --- drivers/gpu/drm/msm/dp/dp_parser.c | 14 --

[PATCH v2 1/2] phy/qcom: add regulator_set_load to edp/dp phy

This patch add regulator_set_load() to both eDP and DP phy driver to have totally control regulators. Changes in v2: -- no regulator_set_laod() before disable regulator Signed-off-by: Kuogee Hsieh --- drivers/phy/qualcomm/phy-qcom-edp.c | 25 +

[PATCH v2 0/2] eDP/DP Phy vdda realted function

1) add regulator_set_load() to eDP/DP phy 2) remove vdda related function out of eDP/DP controller Kuogee Hsieh (2): phy/qcom: add regulator_set_load to edp/dp phy drm/msm/dp: delete vdda regulator related functions from eDP/DP controller drivers/gpu/drm/msm/dp/dp_parser.c | 14 --

Re: [PATCH v1 1/2] phy/qcom: add regulator_set_load to edp/dp phy

On 5/18/2022 2:29 AM, Vinod Koul wrote: On 17-05-22, 10:25, Kuogee Hsieh wrote: pls use the correct subsystem tag, "phy: xxx" in this case This patch add regulator_set_load() to both eDP and DP phy driver to have totally control regulators. Can you explain what is meant by "totally control

Re: [RFC] drm/kms: control display brightness through drm_connector properties

On Wed, May 18, 2022 at 02:59:58PM +0200, Hans de Goede wrote: > Hi, > > On 4/14/22 15:10, Jani Nikula wrote: > > There are some cases where we can actually get a rough PWM/luminance > > curve from i915 opregion. I think maybe 16 data points. We've never > > exposed that. My idea was that you'd

Re: [RFC] drm/kms: control display brightness through drm_connector properties

On Wed, 18 May 2022, Hans de Goede wrote: > So how about: display_brightness or panel_brightness ? This is a prime opportunity to look at all the existing properties, and come up with a new combination of capitalization, spacing, hyphens, underscores, etc. to accompany the total lack of

Re: [PATCH v2 05/12] drm: bridge: samsung-dsim: Add DSI init in bridge pre_enable()

On 11.05.2022 17:02, Marek Szyprowski wrote: > On 04.05.2022 13:40, Jagan Teki wrote: >> Host transfer() in DSI master will invoke only when the DSI commands >> are sent from DSI devices like DSI Panel or DSI bridges and this >> host transfer wouldn't invoke for I2C-based-DSI bridge drivers. >> >>

Re: [Intel-gfx] [V2 3/3] drm/amd/display: Move connector debugfs to drm

On 5/18/22 01:38, Modem, Bhanuprakash wrote: > On Mon-16-05-2022 02:09 pm, Jani Nikula wrote: >> On Mon, 02 May 2022, Harry Wentland wrote: >>> Both the kernel and IGT series look good to me. >>> >>> I recommend you merge the entire kernel set as one into drm-next. We >>> can pull it into

Re: [greybus-dev] Re: [PATCH] [v2] Kbuild: move to -std=gnu11

On 5/18/22 00:46, Arnd Bergmann wrote: On Mon, May 16, 2022 at 3:19 PM Guenter Roeck wrote: On 5/16/22 06:31, Greg KH wrote: On Mon, May 16, 2022 at 06:10:23AM -0700, Guenter Roeck wrote: On Mon, Feb 28, 2022 at 11:27:43AM +0100, Arnd Bergmann wrote: From: Arnd Bergmann During a patch

Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering

Hi Dave, On 11.05.2022 17:47, Dave Stevenson wrote: > On Wed, 11 May 2022 at 15:58, Marek Szyprowski > wrote: >> On 05.04.2022 13:43, Dave Stevenson wrote: >>> On Fri, 18 Mar 2022 at 12:25, Dave Stevenson >>> wrote: On Fri, 4 Mar 2022 at 15:18, Dave Stevenson wrote: > Hi All

[PATCH 2/5] dma-buf: cleanup dma_fence_unwrap implementation

Move the code from the inline functions into exported functions. Signed-off-by: Christian König Acked-by: Daniel Vetter --- drivers/dma-buf/Makefile | 2 +- drivers/dma-buf/dma-fence-unwrap.c | 59 ++ include/linux/dma-fence-unwrap.h | 52

[PATCH 5/5] drm: use dma_fence_unwrap_merge() in drm_syncobj

The unwrap merge function is now intended for this use case. Signed-off-by: Christian König Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_syncobj.c | 57 +-- 1 file changed, 7 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c

[PATCH 4/5] dma-buf: generalize dma_fence unwrap & merging v3

Introduce a dma_fence_unwrap_merge() macro which allows to unwrap fences which potentially can be containers as well and then merge them back together into a flat dma_fence_array. v2: rename the function, add some more comments about how the wrapper is used, move filtering of signaled fences

[PATCH 3/5] dma-buf: return only unsignaled fences in dma_fence_unwrap_for_each v3

dma_fence_chain containers cleanup signaled fences automatically, so filter those out from arrays as well. v2: fix missing walk over the array v3: massively simplify the patch and actually update the description. Signed-off-by: Christian König --- include/linux/dma-fence-unwrap.h | 6 +- 1

[PATCH 1/5] dma-buf: cleanup dma_fence_unwrap selftest v2

The selftests, fix the error handling, remove unused functions and stop leaking memory in failed tests. v2: fix the memory leak correctly. Signed-off-by: Christian König --- drivers/dma-buf/st-dma-fence-unwrap.c | 48 +++ 1 file changed, 19 insertions(+), 29

[no subject]

Just sending that to intel-gfx to let the CI systems take a look at it. Regards, Christian.

Re: [PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers

[Public] DCN 3.1.6 needs it, but I don't know if yellow carp needs it. I think this is only applicable to kernel 5.18. @Kazlauskas, Nicholas can you verify? Alex From: VURDIGERENATARAJ, CHANDAN Sent: Wednesday, May 18,

Re: [RFC] drm/kms: control display brightness through drm_connector properties

Hi, On 4/14/22 15:10, Jani Nikula wrote: > On Thu, 07 Apr 2022, Hans de Goede wrote: >> 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/ >> >>

Re: [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.

On Wed, 2022-05-18 at 19:51 +0800, Chao Gao wrote: > On Wed, May 18, 2022 at 12:50:27PM +0300, Maxim Levitsky wrote: > > > > struct kvm_arch { > > > > @@ -1258,6 +1260,7 @@ struct kvm_arch { > > > > hpa_t hv_root_tdp; > > > > spinlock_t hv_root_tdp_lock; > > > > #endif > > > > +

RE: [PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers

Hi, Is S0i3 verified for DCN 3.1.6 with this? BR, Chandan V N >From: Eric Yang > >[ Upstream commit 9b9bd3f640640f94272a461b2dfe558f91b322c5 ] > > [Why] >Z10 and S0i3 have some shared path. Previous code clean up , incorrectly >removed these pointers, which breaks s0i3 restore > > [How] >Do

[PATCH AUTOSEL 5.15 07/17] fbdev: Prevent possible use-after-free in fb_release()

From: Daniel Vetter [ Upstream commit 89bfd4017e58faaf70411555e7f508495114e90b ] Most fbdev drivers have issues with the fb_info lifetime, because call to framebuffer_release() from their driver's .remove callback, rather than doing from fbops.fb_destroy callback. Doing that will destroy the

[PATCH AUTOSEL 5.15 06/17] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"

From: Javier Martinez Canillas [ Upstream commit 135332f34ba2662bc1e32b5c612e06a8cc41a053 ] This reverts commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a. That commit attempted to fix a NULL pointer dereference, caused by the struct fb_info associated with a framebuffer device to not longer be

[PATCH AUTOSEL 5.17 13/23] drm/amd/display: undo clearing of z10 related function pointers

From: Eric Yang [ Upstream commit 9b9bd3f640640f94272a461b2dfe558f91b322c5 ] [Why] Z10 and S0i3 have some shared path. Previous code clean up , incorrectly removed these pointers, which breaks s0i3 restore [How] Do not clear the function pointers based on Z10 disable. Reviewed-by: Nicholas

[PATCH AUTOSEL 5.17 08/23] fbdev: Prevent possible use-after-free in fb_release()

From: Daniel Vetter [ Upstream commit 89bfd4017e58faaf70411555e7f508495114e90b ] Most fbdev drivers have issues with the fb_info lifetime, because call to framebuffer_release() from their driver's .remove callback, rather than doing from fbops.fb_destroy callback. Doing that will destroy the

[PATCH AUTOSEL 5.17 07/23] Revert "fbdev: Make fb_release() return -ENODEV if fbdev was unregistered"

From: Javier Martinez Canillas [ Upstream commit 135332f34ba2662bc1e32b5c612e06a8cc41a053 ] This reverts commit aafa025c76dcc7d1a8c8f0bdefcbe4eb480b2f6a. That commit attempted to fix a NULL pointer dereference, caused by the struct fb_info associated with a framebuffer device to not longer be

Re: [PATCH v2] dma-buf: Move sysfs work out of DMA-BUF export path

On Tue, May 17, 2022 at 04:09:36PM -0700, T.J. Mercier wrote: > On Mon, May 16, 2022 at 11:13 PM Greg Kroah-Hartman > wrote: > > > > On Mon, May 16, 2022 at 05:08:05PM -0700, T.J. Mercier wrote: > > > On Mon, May 16, 2022 at 12:21 PM Christian König > > > wrote: > > > > > > > > Am 16.05.22 um

Re: [PATCH v2] dma-buf: Move sysfs work out of DMA-BUF export path

Am 18.05.22 um 01:09 schrieb T.J. Mercier: [SNIP] Perhaps we should go just one step further and make a misc device node for dmabug debugging information to be in and just have userspace poll/read on the device node and we spit the info that used to be in debugfs out through that? That way

[PATCH v2 3/3] drm/panel: simple: add bus-format support for panel-dpi

From: Max Krummenacher Evaluate the device tree bus-format property to set bus_format for a 'panel-dpi' panel. Additionally infer the bpc value from the given bus-format. Valid values for bus-format are found in: This completes the addition of panel-dpi to completely specify a panel-simple

[PATCH v2 2/3] dt-bindings: display: startek, startek-kd050c: allow bus-format property

From: Max Krummenacher Allow to specify the optional bus-format property newly added to panel-dpi. Signed-off-by: Max Krummenacher --- Changes in v2: - New commit .../bindings/display/panel/startek,startek-kd050c.yaml | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH v2 1/3] dt-bindings: display: add new bus-format property for panel-dpi

From: Max Krummenacher The property is used to set the enum bus_format and infer the bpc for a panel defined by 'panel-dpi'. This specifies how the panel is connected to the display interface. Signed-off-by: Max Krummenacher --- Changes in v2: - Fix errors found by dt_binding_check

[PATCH v2 0/3] drm/panel: simple: add bus-format support for panel-dpi

From: Max Krummenacher Commit 4a1d0dbc8332 ("drm/panel: simple: add panel-dpi support") added support for defining a panel from device tree provided data. However support for setting the bus format is missing, so that with the current implementation a 'panel-dpi' panel can only be used if the

Re: [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.

On Wed, May 18, 2022 at 12:50:27PM +0300, Maxim Levitsky wrote: >> > struct kvm_arch { >> > @@ -1258,6 +1260,7 @@ struct kvm_arch { >> >hpa_t hv_root_tdp; >> >spinlock_t hv_root_tdp_lock; >> > #endif >> > + bool apic_id_changed; >> >> What's the value of this boolean? No one reads it.

Re: [PATCH -next] drm/i915: fix compilation errors caused by `-fsanitize=shift`

On Tue, 17 May 2022, "GONG, Ruiqi" wrote: > Fix the compilation errors produced by building recent mainline on x86 > with allmodconfig: > > (1st type of errors) > drivers/gpu/drm/i915/display/intel_ddi.c:1916:2: error: case label does not > reduce to an integer constant > case

Re: [PATCH 11/11] drm/i915: Fix undefined behavior due to shift overflowing the constant

On Wed, 18 May 2022, Borislav Petkov wrote: > On Tue, May 17, 2022 at 04:05:46PM -0700, Randy Dunlap wrote: >> >> >> On 4/5/22 08:15, Borislav Petkov wrote: >> > From: Borislav Petkov >> > >> > Fix: >> > >> > In file included from :0:0: >> > drivers/gpu/drm/i915/gt/uc/intel_guc.c: In

Re: [PATCH v6, 6/7] media: mediatek: vcodec: prevent kernel crash when scp ipi timeout

On 5/18/22 13:29, yunfei.d...@mediatek.com wrote: > Dear Hans, > > Thanks for your review. > On Wed, 2022-05-18 at 11:37 +0200, Hans Verkuil wrote: >> Hi Yunfei, >> >> On 5/13/22 11:25, Yunfei Dong wrote: >>> When SCP timeout during playing video, kernel crashes with >>> following >>> message.

Re: [PATCH 1/1] drm/panfrost: Add support for devcoredump

On 17/05/2022 18:42, Adrián Larumbe wrote: > In the event of a job timeout, debug dump information will be written into > /sys/class/devcoredump. > > Inspired by etnaviv's similar feature. > > Signed-off-by: Adrián Larumbe Nice! Some comments below. > --- > drivers/gpu/drm/panfrost/Kconfig

Re: [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

On Wed, 18 May 2022, Hans de Goede wrote: > Hi, > > On 5/18/22 10:44, Jani Nikula wrote: >> On Tue, 17 May 2022, Hans de Goede wrote: >>> Hi All, >>> >>> As mentioned in my RFC titled "drm/kms: control display brightness through >>> drm_connector properties": >>>

Re: [PATCH 01/14] ACPI: video: Add a native function parameter to acpi_video_get_backlight_type()

Hi, On 5/18/22 10:55, Jani Nikula wrote: > On Tue, 17 May 2022, Hans de Goede wrote: >> ATM on x86 laptops where we want userspace to use the acpi_video backlight >> device we often register both the GPU's native backlight device and >> acpi_video's firmware acpi_video# backlight device. This

Re: [PATCH 00/14] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display

Hi, On 5/18/22 10:44, Jani Nikula wrote: > On Tue, 17 May 2022, Hans de Goede wrote: >> Hi All, >> >> As mentioned in my RFC titled "drm/kms: control display brightness through >> drm_connector properties": >> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fe...@redhat.com/ >>

Re: [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.

On Wed, 2022-05-18 at 16:28 +0800, Chao Gao wrote: > On Wed, Apr 27, 2022 at 11:02:57PM +0300, Maxim Levitsky wrote: > > Neither of these settings should be changed by the guest and it is > > a burden to support it in the acceleration code, so just inhibit > > it instead. > > > > Also add a

Re: [PATCH v6, 6/7] media: mediatek: vcodec: prevent kernel crash when scp ipi timeout

Hi Yunfei, On 5/13/22 11:25, Yunfei Dong wrote: > When SCP timeout during playing video, kernel crashes with following > message. It's caused by accessing NULL pointer in vpu_dec_ipi_handler. > This patch doesn't solve the root cause of NULL pointer, but merely > prevent kernel crashed when

[PATCH V11 04/22] LoongArch: Add writecombine support for drm

LoongArch maintains cache coherency in hardware, but its WUC attribute (Weak-ordered UnCached, which is similar to WC) is out of the scope of cache coherency machanism. This means WUC can only used for write-only memory regions. Cc: dri-devel@lists.freedesktop.org Reviewed-by: WANG Xuerui

  1   2   >