Re: [PATCH 2/2] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static

On 20/04/2024 04:41, Dmitry Baryshkov wrote: Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being declared. Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/ Signed-off-by: Dmitry Baryshkov No fixed either ?

Re: [PATCH 1/2] drm/panel/lg-sw43408: depends on CONFIG_DRM_DISPLAY_DP_HELPER

On 20/04/2024 04:41, Dmitry Baryshkov wrote: This panel driver uses DSC PPS functions and as such depends on the DRM_DISPLAY_DP_HELPER. Add missing dependency Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202404200800.kysryyli-...@intel.com/ No Fixes ? Signed

Re: [PATCH 6/6] drm/panel: visionox-rm69299: stop calling regulator_set_load manually

On 04/04/2024 12:08, Dmitry Baryshkov wrote: Use .init_load_uA part of the bulk regulator API instead of calling register_set_load() manually. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/panel/panel-visionox-rm69299.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletio

Re: [PATCH 5/6] drm/panel: novatek-nt36672a: stop calling regulator_set_load manually

On 04/04/2024 12:08, Dmitry Baryshkov wrote: Use .init_load_uA part of the bulk regulator API instead of calling register_set_load() manually. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/panel/panel-novatek-nt36672a.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-)

Re: [PATCH 3/6] drm/panel: novatek-nt36672e: stop setting register load before disable

On 04/04/2024 12:08, Dmitry Baryshkov wrote: It is pointless to set register load before disabling the register. This vote is going to be dropped as soon as the register is disabled. Drop these register_set_load calls. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/panel/panel-novatek-nt

Re: [PATCH] drm/panel: jdi-fhd-r63452: make use of prepare_prev_first

ret) --- base-commit: a59668a9397e7245b26e9be85d23f242ff757ae8 change-id: 20240423-jdi-fix-986a796a3101 Best regards, Reviewed-by: Neil Armstrong

Re: [PATCH v2] drm/bridge: adv7511: make it honour next bridge in DT

On 31/03/2024 22:45, Dmitry Baryshkov wrote: DT bindings for adv7511 and adv7533 bridges specify HDMI output to be present at the port@1. This allows board DT to add e.g. HDMI connector nodes or any other next chained bridge. Make adv7511 driver discover that bridge and attach it to the chain. S

Re: [PATCH] drm/bridge: adv7511: make it honour next bridge in DT

On 09/03/2024 16:33, Dmitry Baryshkov wrote: DT bindings for adv7511 and adv7533 bridges specify HDMI output to be present at the port@1. This allows board DT to add e.g. HDMI connector nodes or any other next chained bridge. Make adv7511 driver discover that bridge and attach it to the chain. S

Re: [PATCH v2 1/3] drm/panthor: introduce job cycle and timestamp accounting

On Tue, 23 Apr 2024 22:32:34 +0100 Adrián Larumbe wrote: > Enable calculations of job submission times in clock cycles and wall > time. This is done by expanding the boilerplate command stream when running > a job to include instructions that compute said times right before an after > a user CS.

Re: [PATCH 1/4] drm/tiny: ili9225: drop driver owner assignment

On 27/03/2024 18:48, Krzysztof Kozlowski wrote: > Core in spi_register_driver() already sets the .owner, so driver > does not need to. > > Signed-off-by: Krzysztof Kozlowski > --- > drivers/gpu/drm/tiny/ili9225.c | 1 - > 1 file changed, 1 deletion(-) It has been almost a month. Any comments on

Re: [PATCH] drm/etnaviv: drop driver owner assignment

On 01/04/2024 12:26, Christian Gmeiner wrote: >> >> Core in platform_driver_register() already sets the .owner, so driver >> does not need to. Whatever is set here will be anyway overwritten by >> main driver calling platform_driver_register(). >> >> Signed-off-by: Krzysztof Kozlowski > > Review

Re: [PATCH 1/2] drm/bridge: chipone-icn6211: drop driver owner assignment

On 30/03/2024 21:27, Krzysztof Kozlowski wrote: > Core in mipi_dsi_driver_register() already sets the .owner, so driver > does not need to. > > Signed-off-by: Krzysztof Kozlowski > --- It has been almost a month. Any comments on this patchset? Best regards, Krzysztof

Re: [PATCH 1/4] drm/sti: dvo: drop driver owner assignment

On 30/03/2024 21:38, Krzysztof Kozlowski wrote: > Core in platform_driver_register() already sets the .owner, so driver > does not need to. Whatever is set here will be anyway overwritten by > main driver calling platform_driver_register(). > > Signed-off-by: Krzysztof Kozlowski > --- It has be

[PATCH] drm/etnaviv: Create an accel device node if compute-only

If we expose a render node for NPUs without rendering capabilities, the userspace stack will offer it to compositors and applications for rendering, which of course won't work. Userspace is probably right in not questioning whether a render node might not be capable of supporting rendering, so cha

[PATCH v2 19/19] const_structs.checkpatch: add lcd_ops

'struct lcd_ops' is not modified by core code. Suggested-by: Thomas Weißschuh Signed-off-by: Krzysztof Kozlowski --- Patch making lcd_ops const in progress: https://lore.kernel.org/r/20240414-video-backlight-lcd-ops-v1-0-9b37fcbf5...@kernel.org Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo H

[PATCH v2 18/19] fbdev: omap: lcd_ams_delta: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Thomas Zimmermann Signed-off-by: Krzysztof Kozlowski --- Depends on the first patch in the series. --- drivers/video/fbdev/omap/lcd_ams_delta.c | 2 +- 1 file changed, 1 ins

[PATCH v2 17/19] fbdev: imx: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Thomas Zimmermann Signed-off-by: Krzysztof Kozlowski --- Depends on the first patch in the series. --- drivers/video/fbdev/imxfb.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH v2 16/19] fbdev: clps711x: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Thomas Zimmermann Signed-off-by: Krzysztof Kozlowski --- Depends on the first patch in the series. --- drivers/video/fbdev/clps711x-fb.c | 2 +- 1 file changed, 1 insertion(

[PATCH v2 15/19] HID: picoLCD: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Bruno Prémont Signed-off-by: Krzysztof Kozlowski --- Depends on the first patch in the series. --- drivers/hid/hid-picolcd_lcd.c | 2 +- 1 file changed, 1 insertion(+), 1 de

[PATCH v2 14/19] backlight: tdo24m: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/tdo24m.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/back

[PATCH v2 13/19] backlight: platform_lcd: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/platform_lcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vide

[PATCH v2 12/19] backlight: otm3225a: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/otm3225a.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/ba

[PATCH v2 11/19] backlight: ltv350qv: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/ltv350qv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/ba

[PATCH v2 10/19] backlight: lms501kf03: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/lms501kf03.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/

[PATCH v2 09/19] backlight: lms283gf05: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/lms283gf05.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/

[PATCH v2 08/19] backlight: l4f00242t03: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/l4f00242t03.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video

[PATCH v2 07/19] backlight: jornada720_lcd: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/jornada720_lcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vi

[PATCH v2 06/19] backlight: ili9320: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/ili9320.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/bac

[PATCH v2 05/19] backlight: ili922x: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/ili922x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/bac

[PATCH v2 04/19] backlight: hx8357: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/hx8357.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/back

[PATCH v2 03/19] backlight: corgi_lcd: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/corgi_lcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/b

[PATCH v2 02/19] backlight: ams369fg06: Constify lcd_ops

'struct lcd_ops' is not modified by core backlight code, so it can be made const for increased code safety. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/ams369fg06.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/

[PATCH v2 01/19] backlight: Constify lcd_ops

'struct lcd_ops' passed in lcd_device_register() is not modified by core backlight code, so it can be made const for code safety. This allows drivers to also define the structure as const. Reviewed-by: Daniel Thompson Signed-off-by: Krzysztof Kozlowski --- drivers/video/backlight/lcd.c | 4 ++-

[PATCH v2 00/19] backlight: Constify lcd_ops

Hi, Changes in v2: - Collect tags, including wrongly places Thomas' tag (which requires me to manually edit 15 other patches to drop it). - Combine here checkpatch patch: https://lore.kernel.org/all/20240414185440.288812-1-k...@kernel.org/ - Link to v1: https://lore.kernel.org/r/20240414-vide

[PATCH 2/2] drm/tegra: gem: Don't attach dma-bufs when not needed

From: Mikko Perttunen The dma-buf import code currently attaches and maps all imported dma-bufs to the drm device to get their sgt for mapping to the directly managed IOMMU domain. In many cases, like for newer chips (Tegra186+), the directly managed IOMMU domain is, however, not used. Mapping t

[PATCH 1/2] drm/tegra: gem: Open code drm_prime_gem_destroy

From: Mikko Perttunen Since we aren't using drm_gem_prime_import(_dev), for clarity don't use the corresponding destroy function either. Signed-off-by: Mikko Perttunen --- drivers/gpu/drm/tegra/gem.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/

[PATCH RESEND v9 7/8] drm: atmel-hlcdc: add support for DSI output formats

Add support for the following DPI mode if the encoder type is DSI as per the XLCDC IP datasheet: - 16BPPCFG1 - 16BPPCFG2 - 16BPPCFG3 - 18BPPCFG1 - 18BPPCFG2 - 24BPP Signed-off-by: Manikandan Muralidharan [durai.manicka...@microchip.com: update output format using is_xlcdc flag] Signed-off-by: Dur

[PATCH RESEND v9 8/8] drm: atmel-hlcdc: add LCD controller layer definition for sam9x75

Add the LCD controller layer definition and descriptor structure for sam9x75 for the following layers: - Base Layer - Overlay1 Layer - Overlay2 Layer - High End Overlay Signed-off-by: Manikandan Muralidharan Acked-by: Sam Ravnborg --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 100 +

[PATCH RESEND v9 6/8] drm: atmel-hlcdc: add vertical and horizontal scaling support for XLCDC

Update the vertical and horizontal scaler registers of XLCDC IP with Bilinear and Bicubic co-efficients taps for Chroma and Luma componenets of the Pixel. Signed-off-by: Manikandan Muralidharan Acked-by: Sam Ravnborg --- drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h | 4 .../gpu/drm/atmel

[PATCH RESEND v9 5/8] drm: atmel-hlcdc: add DPI mode support for XLCDC

Add support for Display Pixel Interface (DPI) Compatible Mode support in atmel-hlcdc driver for XLCDC IP along with legacy pixel mapping. DPI mode BIT is configured in LCDC_CFG5 register. Signed-off-by: Manikandan Muralidharan [durai.manicka...@microchip.com: update DPI mode bit using is_xlcdc fl

[PATCH RESEND v9 3/8] drm: atmel_hlcdc: replace regmap_read with regmap_read_poll_timeout

Replace regmap_read with regmap_read_poll_timeout to neatly handle retries Signed-off-by: Manikandan Muralidharan --- .../gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c| 44 +++ 1 file changed, 25 insertions(+), 19 deletions(-) diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_cr

[PATCH RESEND v9 4/8] drm: atmel_hlcdc: Add support for XLCDC using IP specific driver ops

Add XLCDC specific driver ops and is_xlcdc flag to separate the functionality and to access the controller registers. HEO scaling, window resampling, Alpha blending, YUV-to-RGB conversion in XLCDC is derived and handled using additional configuration bits and registers. Writing one to the Enable fi

[PATCH RESEND v9 2/8] drm: atmel-hlcdc: Define XLCDC specific registers

From: Durai Manickam KR The register address of the XLCDC IP used in SAM9X7 SoC family are different from the previous HLCDC. Defining those address space with valid macros. Signed-off-by: Durai Manickam KR [manikanda...@microchip.com: Remove unused macro definitions] Signed-off-by: Manikandan

[PATCH RESEND v9 1/8] drm: atmel-hlcdc: add driver ops to differentiate HLCDC and XLCDC IP

Add LCD IP specific ops in driver data to differentiate HLCDC and XLCDC code within the atmel-hlcdc driver files. XLCDC in SAM9X7 has different sets of registers and additional configuration bits when compared to previous HLCDC IP. Read/write operation on the controller register and functionality i

[PATCH RESEND v9 0/8] Add support for XLCDC to sam9x7 SoC family.

This patch series aims to add support for XLCDC IP of sam9x7 SoC family to the DRM subsystem.XLCDC IP has additional registers and new configuration bits compared to the existing register set of HLCDC IP. The new compatible string "microchip,sam9x75-xlcdc" is defined for sam9x75 variant of the sam9

Re: [PATCH v3 4/4] drm/xe/FLR: Support PCIe FLR

On 24/04/24 05:19, Michał Winiarski wrote: > On Mon, Apr 22, 2024 at 12:27:56PM +0530, Aravind Iddamsetty wrote: >> PCI subsystem provides callbacks to inform the driver about a request to >> do function level reset by user, initiated by writing to sysfs entry >> /sys/bus/pci/devices/.../reset. T

Re: [PATCH v2] software node: Implement device_get_match_data fwnode callback

Hi, On 2024/4/24 05:37, Dmitry Baryshkov wrote: On Wed, Apr 24, 2024 at 12:49:18AM +0800, Sui Jingfeng wrote: Hi, Thanks a for you reviewing my patch. On 2024/4/23 21:28, Andy Shevchenko wrote: On Tue, Apr 23, 2024 at 12:46:58AM +0800, Sui Jingfeng wrote: Because the software node backend

Re: [PATCH v2 3/6] drm/xe: Add helper to accumulate exec queue runtime

On Tue, Apr 23, 2024 at 04:56:48PM -0700, Lucas De Marchi wrote: > From: Umesh Nerlige Ramappa > > Add a helper to accumulate per-client runtime of all its > exec queues. Currently that is done in 2 places: > > 1. when the exec_queue is destroyed > 2. when the sched job is completed

Re: [PATCH v3 4/4] drm/xe/FLR: Support PCIe FLR

On 23/04/24 20:34, Nilawar, Badal wrote: > > > On 22-04-2024 12:27, Aravind Iddamsetty wrote: >> PCI subsystem provides callbacks to inform the driver about a request to >> do function level reset by user, initiated by writing to sysfs entry >> /sys/bus/pci/devices/.../reset. This will allow the

Re: [PATCH] drm/amdgpu: Fixup bad vram size on gmc v6 and v7

On Tue, Apr 23, 2024 at 10:30 PM Qiang Ma wrote: > > On Mon, 22 Apr 2024 16:47:36 +0200 > Christian König wrote: > > > Am 22.04.24 um 16:40 schrieb Alex Deucher: > > > On Mon, Apr 22, 2024 at 9:00 AM Christian König > > > wrote: > > >> Am 22.04.24 um 14:33 schrieb Qiang Ma: > > >>> On Mon, 22 Ap

Re: [PATCH v2 2/7] drm/panel: himax-hx83102: Break out as separate driver

Hi, Thanks reply. Doug Anderson 于2024年4月24日周三 00:26写道： > > Hi, > > On Tue, Apr 23, 2024 at 2:37 AM cong yang > wrote: > > > > > > +static int starry_init_cmd(struct hx83102 *ctx) > > > > +{ > > > > + struct mipi_dsi_device *dsi = ctx->dsi; > > > > + > > > > + mipi_dsi_dcs_write_seq(

Re: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range

On Tue, Apr 23, 2024 at 03:17:03PM -0600, Zeng, Oak wrote: > Hi Jason, > > Sorry for a late reply. I have been working on a v2 of this series: > https://patchwork.freedesktop.org/series/132229/. This version addressed some > of your concerns, such as removing the global character device, removin

[PATCH v3 7/7] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel

The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller which fits in nicely with the existing panel-himax-hx83102 driver. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang --- Chage since V3: - inital cmds use lowercasehex. V2: https://lore.ke

[PATCH v3 6/7] dt-bindings: display: panel: Add compatible for IVO t109nw41

The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel with himax-hx83102 controller. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang --- Chage since V3: - Update commit message. V2: https://lore.kernel.org/all/20240422090310.3311429-7-yangco...@huaqin.corp-partner

[PATCH v3 5/7] drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel

The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller which fits in nicely with the existing panel-himax-hx83102 driver. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang --- Chage since V3: - inital cmds use lowercasehex. V2: https://lor

[PATCH v3 4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60

The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel with himax-hx83102 controller. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang --- Chage since V3: - Update commit message. V2: https://lore.kernel.org/all/20240422090310.3311429-5-yangco...@huaqin.corp-par

Re: [PATCH] drm/amdgpu: Fixup bad vram size on gmc v6 and v7

On Mon, 22 Apr 2024 16:47:36 +0200 Christian König wrote: > Am 22.04.24 um 16:40 schrieb Alex Deucher: > > On Mon, Apr 22, 2024 at 9:00 AM Christian König > > wrote: > >> Am 22.04.24 um 14:33 schrieb Qiang Ma: > >>> On Mon, 22 Apr 2024 11:40:26 +0200 > >>> Christian König wrote: > >>> > >

[PATCH v3 3/7] arm64: defconfig: Enable HIMAX_HX83102 panel

DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6. Since the arm64 defconfig had the BOE panel driver enabled, let's also enable the himax driver. Signed-off-by: Cong Yang Reviewed-by: Douglas Anderson --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(

[PATCH v3 2/7] drm/panel: himax-hx83102: Break out as separate driver

The Starry HX83102 based mipi panel should never have been part of the boe tv101wum driver. Discussion with Doug and Linus in V1 [1], we need a separate driver to enable the hx83102 controller. In hx83102 driver, add DSI commands as macros. So it can add some panels with same control model in the

[PATCH v3 1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings

In V1, discussed with Doug and Linus [1], we need break out as separate driver for the himax83102-j02 controller. Beacuse "starry,himax83102-j02" and in this series "BOE nv110wum-l60" "IVO t109nw41" panels use same controller, they have some common CMDS. So add new documentation for this panels. [

[PATCH v3 0/7] Break out as separate driver and add BOE nv110wum-l60 IVO t109nw41 MIPI-DSI panel

Discussion with Doug and Linus in V1, we need a separate driver to enable the hx83102 controller. So this series this series mainly Break out as separate driver for Starry-himax83102-j02 panels from boe tv101wum driver. Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver. Add comp

Re: [PATCH v2 4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60

Hi, Thanks for review. Rob Herring 于2024年4月22日周一 23:16写道： > > On Mon, Apr 22, 2024 at 05:03:07PM +0800, Cong Yang wrote: > > The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, which fits in nicely > > with the existing himax-hx83102 driver. > > From a h/w perspective, the reason to share the

Re: [PATCH] drm/panel-edp: Add panel CSOT MNB601LS1-1

Hi Doug, thank you! We had reported this info to the CSOT to correct the vendor id. If they confirm to fix this with the same product ID, we will submit a patch to fix this. Doug Anderson 于2024年4月24日周三 01:01写道： > > Hi, > > On Mon, Apr 22, 2024 at 6:28 PM Xuxin Xiong > wrote: > > > > Yes, I read

[PATCH v2 1/6] drm/xe/lrc: Add helper to capture context timestamp

From: Umesh Nerlige Ramappa Add a helper to capture CTX_TIMESTAMP from the context image so it can be used to calculate the runtime. v2: Add kernel-doc to clarify expectation from caller Signed-off-by: Umesh Nerlige Ramappa Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/xe/regs/xe_lrc_la

[PATCH v2 4/6] drm/xe: Promote xe_hw_engine_class_to_str()

Move it out of the sysfs compilation unit so it can be re-used in other places. Reviewed-by: Nirmoy Das Reviewed-by: Oak Zeng Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/xe/xe_hw_engine.c | 18 ++ drivers/gpu/drm/xe/xe_hw_engine.h | 1 + drivers/

[PATCH v2 3/6] drm/xe: Add helper to accumulate exec queue runtime

From: Umesh Nerlige Ramappa Add a helper to accumulate per-client runtime of all its exec queues. Currently that is done in 2 places: 1. when the exec_queue is destroyed 2. when the sched job is completed Signed-off-by: Umesh Nerlige Ramappa Signed-off-by: Lucas De Marchi ---

[PATCH v2 2/6] drm/xe: Add helper to capture engine timestamp

Just like CTX_TIMESTAMP is used to calculate runtime, add a helper to get the timestamp for the engine so it can be used to calculate the "engine time" with the same unit as the runtime is recorded. Reviewed-by: Umesh Nerlige Ramappa Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/xe/xe_hw_e

[PATCH v2 0/6] drm/xe: Per client usage

Add per-client usage statistics to xe. This ports xe to use the common method in drm to export the usage to userspace per client (where 1 client == 1 drm fd open). However insted of using the current format measured in nsec, this creates a new one. The intention here is not to mix the GPU clock do

[PATCH v2 5/6] drm/xe: Add XE_ENGINE_CLASS_OTHER to str conversion

XE_ENGINE_CLASS_OTHER was missing from the str conversion. Add it and remove the default handling so it's protected by -Wswitch-enum. Currently the only user is xe_hw_engine_class_sysfs_init(), which already skips XE_ENGINE_CLASS_OTHER, so there's no change in behavior. Reviewed-by: Nirmoy Das Si

[PATCH v2 6/6] drm/xe/client: Print runtime to fdinfo

Print the accumulated runtime for client when printing fdinfo. Each time a query is done it first does 2 things: 1) loop through all the exec queues for the current client and accumulate the runtime, per engine class. CTX_TIMESTAMP is used for that, being read from the context image. 2) Rea

Re: [PATCH v3 4/4] drm/xe/FLR: Support PCIe FLR

On Mon, Apr 22, 2024 at 12:27:56PM +0530, Aravind Iddamsetty wrote: > PCI subsystem provides callbacks to inform the driver about a request to > do function level reset by user, initiated by writing to sysfs entry > /sys/bus/pci/devices/.../reset. This will allow the driver to handle FLR > without

Re: [PATCH v3 0/5] drm/v3d: Fix GPU stats inconsistencies and race-condition

On 4/23/24 04:05, Maxime Ripard wrote: Hi, On Mon, Apr 22, 2024 at 01:08:44PM -0300, Maíra Canal wrote: @drm-misc maintainers, is there any chance you could backport commit 35f4f8c9fc97 ("drm/v3d: Don't increment `enabled_ns` twice") [1] to drm- misc-next? I would like to apply this series to

[PATCH v2] drm/panfrost: Fix dma_resv deadlock at drm object pin time

When Panfrost must pin an object that is being prepared a dma-buf attachment for on behalf of another driver, the core drm gem object pinning code already takes a lock on the object's dma reservation. However, Panfrost GEM object's pinning callback would eventually try taking the lock on the same

[PATCH] drm/panel: jdi-fhd-r63452: make use of prepare_prev_first

) drm_panel_init(&ctx->panel, dev, &jdi_fhd_r63452_panel_funcs, DRM_MODE_CONNECTOR_DSI); + ctx->panel.prepare_prev_first = true; ret = drm_panel_of_backlight(&ctx->panel); if (ret) --- base-commit: a59668a9397e7245b26e9be85d23f242ff757ae8 ch

Re: Add working backlight for "ada lovelace" missing case.

Hello, I would confirm that this patch works for my machine: 01:00.0 VGA compatible controller: NVIDIA Corporation AD107M [GeForce RTX 4050 Max-Q / Mobile] (rev a1) 01:00.1 Audio device: NVIDIA Corporation Device 22be (rev a1) System Information Manufacturer: LENOVO Product Nam

After suspend/resume cycle ASPEED VGA monitor suffers with "No Signal" state.

Hello, An Aspeed VGA monitor, in my case AST 2400, after a suspend/resume cycle suffers with a "No Signal" state. This is also true of a IPMI/BMC remote console. To restore the "Signal" state requires a reboot or the following workaround. To restore the "Signal" state without rebooting issue th

Re: [PATCH] drm: Fix no_vblank field references in documentation

On 4/16/24 2:02 PM, Randy Dunlap wrote: > > > On 4/16/24 2:00 PM, Marijn Suijten wrote: >> Hi Randy, >> >> [..] >> >>> Do you see differences in the generated html for these changes? >> >> I have not yet generated the HTML locally to test this patch, but will >> surely do >> if that's a requi

[PATCH 5.15 65/71] drm/vmwgfx: Sort primary plane formats by order of preference

5.15-stable review patch. If anyone has any objections, please let me know. -- From: Zack Rusin commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream. The table of primary plane formats wasn't sorted at all, leading to applications picking our least desirable formats by def

[PATCH 6.1 129/141] drm/vmwgfx: Fix crtcs atomic check conditional

6.1-stable review patch. If anyone has any objections, please let me know. -- From: Zack Rusin commit a60ccade88f926e871a57176e86a34bbf0db0098 upstream. The conditional was supposed to prevent enabling of a crtc state without a set primary plane. Accidently it also prevented d

[PATCH 6.1 128/141] drm/vmwgfx: Sort primary plane formats by order of preference

6.1-stable review patch. If anyone has any objections, please let me know. -- From: Zack Rusin commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream. The table of primary plane formats wasn't sorted at all, leading to applications picking our least desirable formats by defa

[PATCH 6.1 001/141] drm/vmwgfx: Enable DMA mappings with SEV

6.1-stable review patch. If anyone has any objections, please let me know. -- From: Zack Rusin [ Upstream commit 4c08f01934ab67d1d283d5cbaa52b923abcfe4cd ] Enable DMA mappings in vmwgfx after TTM has been fixed in commit 3bf3710e3718 ("drm/ttm: Add a generic TTM memcpy move fo

[PATCH 6.6 146/158] drm/vmwgfx: Fix crtcs atomic check conditional

6.6-stable review patch. If anyone has any objections, please let me know. -- From: Zack Rusin commit a60ccade88f926e871a57176e86a34bbf0db0098 upstream. The conditional was supposed to prevent enabling of a crtc state without a set primary plane. Accidently it also prevented d

[PATCH 6.6 145/158] drm/vmwgfx: Sort primary plane formats by order of preference

6.6-stable review patch. If anyone has any objections, please let me know. -- From: Zack Rusin commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream. The table of primary plane formats wasn't sorted at all, leading to applications picking our least desirable formats by defa

[PATCH 6.8 147/158] drm/vmwgfx: Fix crtcs atomic check conditional

6.8-stable review patch. If anyone has any objections, please let me know. -- From: Zack Rusin commit a60ccade88f926e871a57176e86a34bbf0db0098 upstream. The conditional was supposed to prevent enabling of a crtc state without a set primary plane. Accidently it also prevented d

[PATCH 6.8 146/158] drm/vmwgfx: Sort primary plane formats by order of preference

6.8-stable review patch. If anyone has any objections, please let me know. -- From: Zack Rusin commit d4c972bff3129a9dd4c22a3999fd8eba1a81531a upstream. The table of primary plane formats wasn't sorted at all, leading to applications picking our least desirable formats by defa

Re: [PATCH v2] software node: Implement device_get_match_data fwnode callback

On Wed, Apr 24, 2024 at 12:49:18AM +0800, Sui Jingfeng wrote: > Hi, > > Thanks a for you reviewing my patch. > > > On 2024/4/23 21:28, Andy Shevchenko wrote: > > On Tue, Apr 23, 2024 at 12:46:58AM +0800, Sui Jingfeng wrote: > > > Because the software node backend of the fwnode API framework lack

[PATCH v2 3/3] drm/panthor: Enable fdinfo for memory stats

When vm-binding an already-created BO, the entirety of its virtual size is then backed by system memory, so its RSS is always the same as its virtual size. Also, we consider a PRIME imported BO to be resident if its matching dma_buf has an open attachment, which means its backing storage had alrea

[PATCH v2 2/3] drm/panthor: Add DRM fdinfo support

Drawing from the FW-calculated values in the previous commit, we can increase the numbers for an open file by collecting them from finished jobs when updating their group synchronisation objects. Signed-off-by: Adrián Larumbe --- drivers/gpu/drm/panthor/panthor_devfreq.c | 10 + drivers/gpu/

[PATCH v2 0/3] Support fdinfo runtime and memory stats on Panthor

This patch series enables userspace utilities like gputop and nvtop to query a render context's fdinfo file and figure out rates of engine and memory utilisation. Changelog: v2: - Split original first patch in two, one for FW CS cycle and timestamp calculations and job accounting memory manageme

[PATCH v2 1/3] drm/panthor: introduce job cycle and timestamp accounting

Enable calculations of job submission times in clock cycles and wall time. This is done by expanding the boilerplate command stream when running a job to include instructions that compute said times right before an after a user CS. Those numbers are stored in the queue's group's sync objects BO, r

Re: [PATCH v1 2/2] drm/panel: kd101ne3: add new panel driver

On Tue, Apr 23, 2024 at 01:41:59PM -0700, Doug Anderson wrote: > Hi, > > On Tue, Apr 23, 2024 at 11:10 AM Hsin-Yi Wang wrote: > > > > > > > > +#define _INIT_DCS_CMD(...) { \ > > > > > > + .type = INIT_DCS_CMD, \ > > > > > > + .len = sizeof((char[]){__VA_ARGS__}), \ > > > > > > + .data

RE: [PATCH 06/23] drm/xe/svm: Introduce a helper to build sg table from hmm range

Hi Jason, Sorry for a late reply. I have been working on a v2 of this series: https://patchwork.freedesktop.org/series/132229/. This version addressed some of your concerns, such as removing the global character device, removing svm process concept (need further clean up per Matt's feedback).

Re: [PATCH] drm/exynos: fix .get_modes return value in case of errors

On 23.04.2024 22:44, Marek Szyprowski wrote: > Commit 7af03e688792 ("drm/probe-helper: warn about negative > .get_modes()") clarified, that .get_modes callback must not return > negative values on failure, so fix sub-drivers to return 0 in case of > errors. This fixes strange Exynos DRM initializat

[PATCH] drm/exynos: fix .get_modes return value in case of errors

Commit 7af03e688792 ("drm/probe-helper: warn about negative .get_modes()") clarified, that .get_modes callback must not return negative values on failure, so fix sub-drivers to return 0 in case of errors. This fixes strange Exynos DRM initialization failure on boot (timeout waiting for VSYNC) obser

Re: [PATCH] drm: zynqmp_dpsub: Always register bridge

Hi, On 3/22/24 02:01, Tomi Valkeinen wrote: > Hi, > > On 08/03/2024 22:47, Sean Anderson wrote: >> We must always register the DRM bridge, since zynqmp_dp_hpd_work_func >> calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be >> initialized. We do this before zynqmp_dpsub_drm_init si

Re: [PATCH v1 2/2] drm/panel: kd101ne3: add new panel driver

Hi, On Tue, Apr 23, 2024 at 11:10 AM Hsin-Yi Wang wrote: > > > > > > +#define _INIT_DCS_CMD(...) { \ > > > > > + .type = INIT_DCS_CMD, \ > > > > > + .len = sizeof((char[]){__VA_ARGS__}), \ > > > > > + .data = (char[]){__VA_ARGS__} } > > > > > + > > > > > +#define _INIT_DELAY_CMD(...)

Re: [PATCH 1/2] drm/amd/display: clean inconsistent indenting

On 2/13/24 3:43 PM, Joao Paulo Pereira da Silva wrote: From: jppaulo Clean some wrong indenting that throw errors in checkpatch. Signed-off-by: Joao Paulo Pereira da Silva --- drivers/gpu/drm/amd/display/dc/core/dc.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --gi

Re: [PATCH] drm/amd/display: Remove duplicated function signature from dcn3.01 DCCG

On 2/22/24 7:19 AM, David Tadokoro wrote: In the header file dc/dcn301/dcn301_dccg.h, the function dccg301_create is declared twice, so remove duplication. Signed-off-by: David Tadokoro --- drivers/gpu/drm/amd/display/dc/dcn301/dcn301_dccg.h | 6 -- 1 file changed, 6 deletions(-) dif

[PATCH] [RFC] dma-buf: fix race condition between poll and close

Syzbot has found the race condition where 'fput()' is in progress when 'dma_buf_poll()' makes an attempt to hold the 'struct file' with zero 'f_count'. So use explicit 'atomic_long_inc_not_zero()' to detect such a case and cancel an undergoing poll activity with EPOLLERR. Reported-by: syzbot+5d4cb

[linux-next:master] BUILD REGRESSION a59668a9397e7245b26e9be85d23f242ff757ae8

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: a59668a9397e7245b26e9be85d23f242ff757ae8 Add linux-next specific files for 20240423 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202404231839.ohiy9lw8-...@intel.com Error

  1   2   3   >