- 13 Dec, 2023 3 commits
-
-
Andy Yan authored
At first we thought the half_block_en bit in AFBCD_CTRL register only work in afbc mode. But the fact is that it control the line buffer in all mode(afbc/tile/linear), so we need configure it in all case. As the cluster windows of rk3568 only supports afbc format so is therefore not affected. Signed-off-by:
Andy Yan <andy.yan@rock-chips.com> Reviewed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231211115730.1784893-1-andyshrk@163.com
-
Andy Yan authored
This reverts commit b63a553e. regcache_sync will try to reload the configuration in regcache to hardware, but the registers of 4 Cluster windows and Esmart1/2/3 on the upcoming rk3588 can not be set successfully before internal PD power on. Also it's better to keep the hardware register as it is before we really enable it. So let's revert this version, and keep the first version: commit afa965a4 ("drm/rockchip: vop2: fix suspend/resume") Signed-off-by:
-
Andy Yan authored
The output interface related definition can shared between vop and vop2, move them to rockchip_drm_drv.h can avoid duplicated definition. Signed-off-by:
-
- 11 Dec, 2023 17 commits
-
-
Uwe Kleine-König authored
It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so let the auxiliary device be the parent of the pwm device. Note that getting a reference to the ti-sn65dsi86's pwm using pwm_get() isn't affected by this change as ti_sn65dsi86_add_aux_device() sets the auxiliary device's of_node to that of the main device. Also change PM runtime tracking and diagnostic messages to use that one. After enabling runtime PM operation for the auxiliary device, all works as expected as parent devices are handled just fine. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Nikita Travkin <nikita@trvn.ru> # Acer Aspire 1 Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Elmar Albert authored
G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of a TFT LCD panel, a driver circuit, and LED backlight system. The screen format is intended to support the 16:9 FHD, 1920(H) x 1080(V) screen and 16.7M colors (RGB 8-bits) with LED backlight driving circuit. All input signals are LVDS interface compatible. G156HAN04.0 is designed for a display unit of notebook style personal computer and industrial machine. Signed-off-by:
Elmar Albert <ealbert@data-modul.com> Signed-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20231209063714.1381913-2-marex@denx.deSigned-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231209063714.1381913-2-marex@denx.de
-
Elmar Albert authored
Document support for the AUO G156HAN04.0 LVDS display. G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of a TFT LCD panel, a driver circuit, and LED backlight system. The screen format is intended to support the 16:9 FHD, 1920(H) x 1080(V) screen and 16.7M colors (RGB 8-bits) with LED backlight driving circuit. All input signals are LVDS interface compatible. G156HAN04.0 is designed for a display unit of notebook style personal computer and industrial machine. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Michael Trimarchi authored
Tianma TM041XDHG01 utilizes the Ilitek ILI9805 controller. Add this panel's initialzation sequence and timing to ILI9805 driver. Signed-off-by:
Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by:
Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/r/20231207141723.108004-10-dario.binacchi@amarulasolutions.comSigned-off-by:
-
Michael Trimarchi authored
The GPM1790A0 panel is based on the Ilitek ILI9805 Controller. Add a driver for it. Signed-off-by:
-
Michael Trimarchi authored
Add documentation for "ilitek,ili9805" panel. Signed-off-by:
-
Michael Trimarchi authored
The LS068B3SX02 panel is based on the Synaptics R63353 Controller. Add a driver for it. Signed-off-by:
-
Chris Morgan authored
The Powkiddy RG-ARC is a series of 2 handheld devices, each with a 4 inch 480x640 display. Add support for the display. Signed-off-by:
Chris Morgan <macromorgan@hotmail.com> Reviewed-by:
-
Chris Morgan authored
The RG-ARC panel is a panel specific to the Anbernic RG-ARC. It is 4 inches in size (diagonally) with a resolution of 480x640. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
-
Chris Morgan authored
The AVCL register, according to the datasheet, comes in increments of -0.2v between -4.4v (represented by 0x0) to -5.0v (represented by 0x3). The current calculation is done by adding the defined AVCL value in mV to -4400 and then dividing by 200 to get the register value. Unfortunately if I subtract -4400 from -4400 I get -8800, which divided by 200 gives me -44. If I instead subtract -4400 from -4400 I get 0, which divided by 200 gives me 0. Based on the datasheet this is the expected register value. Fixes: 83b7a8e7 ("drm/panel/panel-sitronix-st7701: Parametrize voltage and timing") Signed-off-by:
-
John Watts authored
This is a small 3.5" 640x480 IPS LCD panel. Signed-off-by:
John Watts <contact@jookia.org> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231210-fs035vg158-v5-7-d75adc75571f@jookia.orgSigned-off-by:
-
John Watts authored
Fascontek manufactures LCD panels such as the FS035VG158. Signed-off-by:
-
John Watts authored
Remove common properties listed in common yaml files. Add required properties needed to describe the panel. Signed-off-by:
-
John Watts authored
This display is extremely similar to the LTK035C5444T, but still has some minor variations in panel initialization. Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by:
-
John Watts authored
Panel initialization registers are per-display and not tied to the controller itself. Different panels will specify their own registers. Attach the sequences to the panel info struct so future panels can specify their own sequences. Signed-off-by:
-
John Watts authored
SPI drivers needs their own list of compatible device IDs in order for automatic module loading to work. Add those for this driver. Signed-off-by:
-
John Watts authored
Many of these registers have a known name in the public datasheet. Document them as comments for reference. Signed-off-by:
-
- 08 Dec, 2023 4 commits
-
-
Dan Carpenter authored
This code dereferences "page->pvr_dev" and then checked for NULL on the next line. Re-order it to avoid a potential NULL pointer dereference. Fixes: ff5f643d ("drm/imagination: Add GEM and VM related code") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by:
Frank Binns <frank.binns@imgtec.com> Signed-off-by:
-
Yang Li authored
./drivers/gpu/drm/imagination/pvr_fw_trace.c:251:2-3: Unneeded semicolon Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=7694Signed-off-by:
Yang Li <yang.lee@linux.alibaba.com> Signed-off-by:
-
Dmitry Baryshkov authored
As the renamed drm_atomic_helper_check_wb_connector_state() now accepts drm_writeback_connector as the first argument (instead of drm_encoder), move the VKMS writeback atomic_check from drm_encoder_helper_funcs to drm_connector_helper_funcs. Also drop the vkms_wb_encoder_helper_funcs, which have become empty now. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
-
Dmitry Baryshkov authored
The drm_atomic_helper_check_wb_encoder_state() function doesn't use encoder for anything other than getting the drm_device instance. The function's description talks about checking the writeback connector state, not the encoder state. Moreover, there is no such thing as an encoder state, encoders generally do not have a state on their own. Rename the function to drm_atomic_helper_check_wb_connector_state() and change arguments to drm_writeback_connector and drm_atomic_state. Signed-off-by:
-
- 07 Dec, 2023 16 commits
-
-
Pin-yen Lin authored
Move the KDC panel entry to make the list sorted by the vendor string. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
-
Rob Herring authored
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it was merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. Soon the implicit includes are going to be removed. of_device.h isn't needed, but of.h is for of_node_put(). Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reviewed-by:
-
Rodrigo Vivi authored
Nothing else to be done on this front from Xe perspective. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231201042158.80009-6-rodrigo.vivi@intel.comAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
The must-have part of the documentation was already added to the existing /gpu/drm-vm-bind-async. The other extra discussion around GPUVM helpers are currently active in the community. None of those discussion should block Xe since documentation, specially around locking was completed in a community consensus. Signed-off-by:
-
Rodrigo Vivi authored
As already indicated in this block, the consensus was already reached out and documented as: The ASYNC VM_BIND document </gpu/drm-vm-bind-async> However this was item was not moved to the completed section. Let's move and clean up the WIP block. Signed-off-by:
-
Rodrigo Vivi authored
Current drm-xe-next doesn't have any drm/scheduler patch that is not already accepted in drm-misc-next. This completed this goal with the consensus of how the drm/scheduler fits to the fw scheduling and the relationship between drm_gpu_scheduler and drm_sched_entity. Signed-off-by:
-
Matthew Brost authored
No DRM scheduler changes required, drivers just return NULL in run_job vfunc. The rough consensus is that no helper or extra scaffolding is needed around long-running jobs and no further changes to drm-scheduler. At least for now. Other drivers that currently do long-running workloads have no plat to use drm-scheduler. Besides, the current consensus is that this solution of simply returning NULL to the run_job function should work without extra code duplication or complication. On top of that, this item was already a non-blocking one for upstreaming Xe, so let's move that to the 'Completed' section and revisit the long-running solution as a community after Xe is integrated in DRM. Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Marek Szyprowski authored
encoder->funcs entry might be NULL, so check it first before calling its methods. This fixes NULL pointer dereference observed on Rasberry Pi 3b/4b boards. Fixes: caf525ed ("drm/encoder: register per-encoder debugfs dir") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Tested-by:
Nishanth Menon <nm@ti.com> Reviewed-by:
-
Nathan Chancellor authored
sparse complains: drivers/usb/typec/tcpm/qcom/qcom_pmic_typec.c: note: in included file: include/drm/bridge/aux-bridge.h:29:16: sparse: sparse: Using plain integer as NULL pointer Return NULL to clear up the warning. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312060025.BdeqZrWx-lkp@intel.com/ Fixes: e560518a ("drm/bridge: implement generic DP HPD bridge") Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Nathan Chancellor authored
CONFIG_DRM_AUX_HPD_BRIDGE depends on CONFIG_OF but that dependency is not included when CONFIG_TYPEC_QCOM_PMIC selects it, resulting in a Kconfig warning when CONFIG_OF is disabled: WARNING: unmet direct dependencies detected for DRM_AUX_HPD_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && OF [=n] Selected by [m]: - TYPEC_QCOM_PMIC [=m] && USB_SUPPORT [=y] && TYPEC [=m] && TYPEC_TCPM [=m] && (ARCH_QCOM || COMPILE_TEST [=y]) && (DRM [=m] || DRM [=m]=n) && DRM_BRIDGE [=y] Only select CONFIG_DRM_AUX_HPD_BRIDGE with both CONFIG_DRM_BRIDGE and CONFIG_OF to clear up the warning. Fixes: 7d9f1b72 ("usb: typec: qcom-pmic-typec: switch to DRM_AUX_HPD_BRIDGE") Signed-off-by:Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
-
Nathan Chancellor authored
CONFIG_DRM_AUX_BRIDGE depends on CONFIG_OF but that dependency is not included when CONFIG_TYPEC_MUX_NB7VPQ904M selects it, resulting in a Kconfig warning when CONFIG_OF is disabled: WARNING: unmet direct dependencies detected for DRM_AUX_BRIDGE Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && OF [=n] Selected by [y]: - TYPEC_MUX_NB7VPQ904M [=y] && USB_SUPPORT [=y] && TYPEC [=y] && I2C [=y] && (DRM [=y] || DRM [=y]=n) && DRM_BRIDGE [=y] Only select CONFIG_DRM_AUX_BRIDGE with both CONFIG_DRM_BRIDGE and CONFIG_OF to clear up the warning. Fixes: c5d296ba ("usb: typec: nb7vpq904m: switch to DRM_AUX_BRIDGE") Signed-off-by: -
Tomi Valkeinen authored
It's been reported that DSI host driver's detach can be called without the attach ever happening: https://lore.kernel.org/all/20230412073954.20601-1-tony@atomide.com/ After reading the code, I think this is what happens: We have a DSI host defined in the device tree and a DSI peripheral under that host (i.e. an i2c device using the DSI as data bus doesn't exhibit this behavior). The host driver calls mipi_dsi_host_register(), which causes (via a few functions) mipi_dsi_device_add() to be called for the DSI peripheral. So now we have a DSI device under the host, but attach hasn't been called. Normally the probing of the devices continues, and eventually the DSI peripheral's driver will call mipi_dsi_attach(), attaching the peripheral. However, if the host driver's probe encounters an error after calling mipi_dsi_host_register(), and before the peripheral has called mipi_dsi_attach(), the host driver will do cleanups and return an error from its probe function. The cleanups include calling mipi_dsi_host_unregister(). mipi_dsi_host_unregister() will call two functions for all its DSI peripheral devices: mipi_dsi_detach() and mipi_dsi_device_unregister(). The latter makes sense, as the device exists, but the former may be wrong as attach has not necessarily been done. To fix this, track the attached state of the peripheral, and only detach from mipi_dsi_host_unregister() if the peripheral was attached. Note that I have only tested this with a board with an i2c DSI peripheral, not with a "pure" DSI peripheral. However, slightly related, the unregister machinery still seems broken. E.g. if the DSI host driver is unbound, it'll detach and unregister the DSI peripherals. After that, when the DSI peripheral driver unbound it'll call detach either directly or using the devm variant, leading to a crash. And probably the driver will crash if it happens, for some reason, to try to send a message via the DSI bus. But that's another topic. Tested-by:
H. Nikolaus Schaller <hns@goldelico.com> Acked-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230921-dsi-detach-fix-v1-1-d0de2d1621d9@ideasonboard.com
-
Tomi Valkeinen authored
If the hpd_pin is invalid, the driver returns 'ret'. But 'ret' contains 0, instead of an error value. Return -EINVAL instead. Fixes: f25ee501 ("drm/bridge: tc358767: add IRQ and HPD support") Acked-by:
-
Tomi Valkeinen authored
'ret' could be uninitialized at the end of the function, although it's not clear if that can happen in practice. Fixes: 6a3608ea ("drm: bridge: cdns-mhdp8546: Enable HDCP") Acked-by:
-
Tomi Valkeinen authored
smatch reports: drivers/gpu/drm/drm_framebuffer.c:654 drm_mode_getfb2_ioctl() error: uninitialized symbol 'ret'. 'ret' is possibly not set when there are no errors, causing the error above. I can't say if that ever happens in real-life, but in any case I think it is good to initialize 'ret' to 0. Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by:
-
Tomi Valkeinen authored
smatch reports: drivers/gpu/drm/drm_file.c:967 drm_show_memory_stats() error: uninitialized symbol 'supported_status'. 'supported_status' is only set in one code path. I'm not familiar with the code to say if that path will always be ran in real life, but whether that is the case or not, I think it is good to initialize 'supported_status' to 0 to silence the warning (and possibly fix a bug). Reviewed-by:
-
