user/sven/linux.git/include/drm, branch v5.4.269

drm/mipi-dsi: Fix detach call without attach

2024-02-23T07:25:00Z

[ Upstream commit 90d50b8d85834e73536fdccd5aa913b30494fef0 ] 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 Acked-by: Maxime Ripard Reviewed-by: Sebastian Reichel Tested-by: Tony Lindgren Signed-off-by: Tomi Valkeinen Link: https://patchwork.freedesktop.org/patch/msgid/20230921-dsi-detach-fix-v1-1-d0de2d1621d9@ideasonboard.com Signed-off-by: Sasha Levin

drm/bridge: Fix typo in post_disable() description

2024-01-25T22:34:27Z

[ Upstream commit 288b039db225676e0c520c981a1b5a2562d893a3 ] s/singals/signals/ Fixes: 199e4e967af4 ("drm: Extract drm_bridge.h") Signed-off-by: Dario Binacchi Signed-off-by: Robert Foss Link: https://patchwork.freedesktop.org/patch/msgid/20231124094253.658064-1-dario.binacchi@amarulasolutions.com Signed-off-by: Sasha Levin

drm/display/dp: Fix the DP DSC Receiver cap size

2023-08-30T14:27:26Z

commit 5ad1ab30ac0809d2963ddcf39ac34317a24a2f17 upstream. DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh. Fix the DSC RECEIVER CAP SIZE accordingly. Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define and missing SHIFT") Cc: Anusha Srivatsa Cc: Manasi Navare Cc: # v5.0+ Signed-off-by: Ankit Nautiyal Reviewed-by: Stanislav Lisovskiy Signed-off-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/20230818044436.177806-1-ankit.k.nautiyal@intel.com Signed-off-by: Greg Kroah-Hartman

drm/panel: Add and fill drm_panel type field

2023-07-27T06:37:29Z

[ Upstream commit 9a2654c0f62a1704f36acb6329f9ccbd539f75ad ] Add a type field to the drm_panel structure to report the panel type, using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS, eDP, DSI and DPI). This will be used to initialise the corresponding connector type. Update all panel drivers accordingly. The panel-simple driver only specifies the type for the known to be LVDS panels, while all other panels are left as unknown and will be converted on a case-by-case basis as they all need to be carefully reviewed. Signed-off-by: Laurent Pinchart Reviewed-by: Boris Brezillon Reviewed-by: Linus Walleij Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20190904132804.29680-2-laurent.pinchart@ideasonboard.com Stable-dep-of: 2c56a751845d ("drm/panel: simple: Add connector_type for innolux_at043tn24") Signed-off-by: Sasha Levin

drm/panel: Initialise panel dev and funcs through drm_panel_init()

2023-07-27T06:37:29Z

[ Upstream commit 6dbe0c4b0fc0646442b2b1580d022404e582fd7b ] Instead of requiring all drivers to set the dev and funcs fields of drm_panel manually after calling drm_panel_init(), pass the data as arguments to the function. This simplifies the panel drivers, and will help future refactoring when adding new arguments to drm_panel_init(). The panel drivers have been updated with the following Coccinelle semantic patch, with manual inspection to verify that no call to drm_panel_init() with a single argument still exists. @@ expression panel; expression device; identifier ops; @@ drm_panel_init(&panel + , device, &ops ); ... ( -panel.dev = device; -panel.funcs = &ops; | -panel.funcs = &ops; -panel.dev = device; ) Suggested-by: Sam Ravnborg Signed-off-by: Laurent Pinchart Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20190823193245.23876-3-laurent.pinchart@ideasonboard.com Stable-dep-of: 2c56a751845d ("drm/panel: simple: Add connector_type for innolux_at043tn24") Signed-off-by: Sasha Levin

drm: Initialize struct drm_crtc_state.no_vblank from device settings

2023-03-11T15:43:46Z

[ Upstream commit 7beb691f1e6f349c9df3384a85e7a53c5601aaaf ] At the end of a commit, atomic helpers can generate a fake VBLANK event automatically. Originally implemented for writeback connectors, the functionality can be used by any driver and/or hardware without proper VBLANK interrupt. The patch updates the documentation to make this behaviour official: settings struct drm_crtc_state.no_vblank to true enables automatic generation of fake VBLANK events. The new interface drm_dev_has_vblank() returns true if vblanking has been initialized for a device, or false otherwise. Atomic helpers use this function when initializing no_vblank in the CRTC state in drm_atomic_helper_check_modeset(). If vblanking has been initialized for a device, no_blank is disabled. Otherwise it's enabled. Hence, atomic helpers will automatically send out fake VBLANK events with any driver that did not initialize vblanking. v5: * more precise documentation and commit message v4: * replace drm_crtc_has_vblank() with drm_dev_has_vblank() * add drm_dev_has_vblank() in this patch * move driver changes into separate patches v3: * squash all related changes patches into this patch Signed-off-by: Thomas Zimmermann Acked-by: Gerd Hoffmann Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200129120531.6891-2-tzimmermann@suse.de Stable-dep-of: 13fcfcb2a9a4 ("drm/msm/mdp5: Add check for kzalloc") Signed-off-by: Sasha Levin

drm/bridge: Introduce drm_bridge_get_next_bridge()

2023-03-11T15:43:45Z

[ Upstream commit fadf872d9d9274a3be34d8438e0f6bb465c8f98b ] And use it in drivers accessing the bridge->next field directly. This is part of our attempt to make the bridge chain a double-linked list based on the generic list helpers. Signed-off-by: Boris Brezillon Reviewed-by: Neil Armstrong Reviewed-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-3-boris.brezillon@collabora.com Stable-dep-of: 13fcfcb2a9a4 ("drm/msm/mdp5: Add check for kzalloc") Signed-off-by: Sasha Levin

drm/bridge: Rename bridge helpers targeting a bridge chain

2023-03-11T15:43:45Z

[ Upstream commit ea099adfdf4bf35903dc1c0f59a0d60175759c70 ] Change the prefix of bridge helpers targeting a bridge chain from drm_bridge_ to drm_bridge_chain_ to better reflect the fact that the operation will happen on all elements of chain, starting at the bridge passed in argument. Signed-off-by: Boris Brezillon Reviewed-by: Neil Armstrong Acked-by: Laurent Pinchart Link: https://patchwork.freedesktop.org/patch/msgid/20191203141515.3597631-2-boris.brezillon@collabora.com Stable-dep-of: 13fcfcb2a9a4 ("drm/msm/mdp5: Add check for kzalloc") Signed-off-by: Sasha Levin

drm/mipi-dsi: Fix byte order of 16-bit DCS set/get brightness

2023-03-11T15:43:45Z

[ Upstream commit c9d27c6be518b4ef2966d9564654ef99292ea1b3 ] The MIPI DCS specification demands that brightness values are sent in big endian byte order. It also states that one parameter (i.e. one byte) shall be sent/received for 8 bit wide values, and two parameters shall be used for values that are between 9 and 16 bits wide. Add new functions to properly handle 16-bit brightness in big endian, since the two 8- and 16-bit cases are distinct from each other. [richard: use separate functions instead of switch/case] [richard: split into 16-bit component] Fixes: 1a9d759331b8 ("drm/dsi: Implement DCS set/get display brightness") Signed-off-by: Daniel Mentz Link: https://android.googlesource.com/kernel/msm/+/754affd62d0ee268c686c53169b1dbb7deac8550 [richard: fix 16-bit brightness_get] Signed-off-by: Richard Acayan Tested-by: Caleb Connolly Reviewed-by: Neil Armstrong Reviewed-by: Sam Ravnborg Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/20230116224909.23884-2-mailingradian@gmail.com Signed-off-by: Sasha Levin

drm: fix EDID struct for old ARM OABI format

2022-06-14T16:11:31Z

[ Upstream commit 47f15561b69e226bfc034e94ff6dbec51a4662af ] When building the kernel for arm with the "-mabi=apcs-gnu" option, gcc will force alignment of all structures and unions to a word boundary (see also STRUCTURE_SIZE_BOUNDARY and the "-mstructure-size-boundary=XX" option if you're a gcc person), even when the members of said structures do not want or need said alignment. This completely messes up the structure alignment of 'struct edid' on those targets, because even though all the embedded structures are marked with "__attribute__((packed))", the unions that contain them are not. This was exposed by commit f1e4c916f97f ("drm/edid: add EDID block count and size helpers"), but the bug is pre-existing. That commit just made the structure layout problem cause a build failure due to the addition of the BUILD_BUG_ON(sizeof(*edid) != EDID_LENGTH); sanity check in drivers/gpu/drm/drm_edid.c:edid_block_data(). This legacy union alignment should probably not be used in the first place, but we can fix the layout by adding the packed attribute to the union entries even when each member is already packed and it shouldn't matter in a sane build environment. You can see this issue with a trivial test program: union { struct { char c[5]; }; struct { char d; unsigned e; } __attribute__((packed)); } a = { "1234" }; where building this with a normal "gcc -S" will result in the expected 5-byte size of said union: .type a, @object .size a, 5 but with an ARM compiler and the old ABI: arm-linux-gnu-gcc -mabi=apcs-gnu -mfloat-abi=soft -S t.c you get .type a, %object .size a, 8 instead, because even though each member of the union is packed, the union itself still gets aligned. This was reported by Sudip for the spear3xx_defconfig target. Link: https://lore.kernel.org/lkml/YpCUzStDnSgQLNFN@debian/ Reported-by: Sudip Mukherjee Acked-by: Arnd Bergmann Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin