summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-06-10drm/panel: ilitek-ili9881c: Add configuration for 7" Raspberry Pi 720x1280Marek Vasut
Add configuration for the 7" Raspberry Pi 720x1280 DSI panel based on ili9881. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250608142908.54121-3-marek.vasut+renesas@mailbox.org
2025-06-10drm/panel: ilitek-ili9881c: Allow configuration of the number of lanesMarek Vasut
Not all panels use all 4 data lanes, so allow configuration based on the compatible string. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250608142908.54121-2-marek.vasut+renesas@mailbox.org
2025-06-10dt-bindings: ili9881c: Document 7" Raspberry Pi 720x1280Marek Vasut
Document the 7" Raspberry Pi 720x1280 DSI panel based on ili9881. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250608142908.54121-1-marek.vasut+renesas@mailbox.org
2025-06-10dt-bindings: display: st7701: Add Winstar wf40eswaa6mnn0 panelStefan Eichenberger
The Winstar wf40eswaa6mnn0 panel is a square 4.0" TFT LCD with a resolution of 480x480 pixels. Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250606114644.105371-3-eichest@gmail.com
2025-06-10drm/panel: st7701: Add Winstar wf40eswaa6mnn0 panel supportStefan Eichenberger
The Winstar wf40eswaa6mnn0 panel is a square 4.0" TFT LCD with a resolution of 480x480 pixels. This panel is driven by the Sitronix ST7701 controller and uses a MIPI DSI interface. The settings are based on the panel's datasheet and the init sequence provided by Winstar. It was tested on a Verdin iMX8MP from Toradex with a Carrier Board providing a MIPI DSI interface. Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250606114644.105371-2-eichest@gmail.com
2025-06-10drm/panel: visionox-rm69299: support the variant found in the SHIFT6mqCaleb Connolly
Add support for another variant of the rm69299 panel. This panel is 1080x2160 and is found in the shift-axolotl (SHIFT6mq). Signed-off-by: Caleb Connolly <caleb@connolly.tech> [narmstrong: moved to panel_desc] Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-6-c2c2d52abd51@linaro.org
2025-06-10drm/panel: visionox-rm69299: switch to devm_regulator_bulk_get_const()Neil Armstrong
Switch to devm_regulator_bulk_get_const() to move the supply data to const. Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-4-c2c2d52abd51@linaro.org
2025-06-10drm/panel: visionox-rm69299: switch to _multi variantsNeil Armstrong
Switch to the DSI _multi variants to simplify error handling. Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-3-c2c2d52abd51@linaro.org
2025-06-10drm/panel: visionox-rm69299: add plumbing to support panel variantsNeil Armstrong
In order to support a panel variant, add plumbing code to pass init sequence and mode as compatible data. Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-2-c2c2d52abd51@linaro.org
2025-06-10dt-bindings: display: visionox-rm69299: document new compatible stringCaleb Connolly
Document a new compatible string for the second panel variant. Signed-off-by: Caleb Connolly <caleb@connolly.tech> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250509-topic-misc-shift6-panel-v2-1-c2c2d52abd51@linaro.org
2025-06-09drm: renesas: rz-du: Implement MIPI DSI host transfersHugo Villeneuve
Add support for sending MIPI DSI command packets from the host to a peripheral. This is required for panels that need configuration before they accept video data. Also for long reads to work properly, set DCS maximum return packet size to the value of the DMA buffer size. Based on Renesas Linux kernel v5.10 repos [1]. Link: https://github.com/renesas-rz/rz_linux-cip.git Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com> Tested-by: Chris Brandt <Chris.Brandt@renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://lore.kernel.org/r/20250604145306.1170676-2-hugo@hugovil.com
2025-06-06accel/qaic: delete qaic_bo.handleSimona Vetter
Handles are per-file, not global, so this makes no sense. Plus it's set only after calling drm_gem_handle_create(), and drivers are not allowed to further initialize a bo after that function has published it already. It is also entirely unused, which helps enormously with removing it :-) Since we're still holding a reference to the bo nothing bad can happen, hence not cc: stable material. Cc: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Cc: Carl Vanderlip <quic_carlv@quicinc.com> Cc: linux-arm-msm@vger.kernel.org Signed-off-by: Simona Vetter <simona.vetter@ffwll.ch> Signed-off-by: Simona Vetter <simona.vetter@intel.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250528091307.1894940-5-simona.vetter@ffwll.ch
2025-06-06drm/tests: bridge: add KUnit tests for devm_drm_bridge_alloc()Luca Ceresoli
Add KUnit tests for the newly introduced devm_drm_bridge_alloc(). Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-3-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/bridge: add a .destroy funcLuca Ceresoli
Some users of DRM bridges may need to execute specific code just before deallocation. As of now the only known user would be KUnit tests. Suggested-by: Maxime Ripard <mripard@kernel.org> Acked-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-2-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/tests: bridge: convert to devm_drm_bridge_alloc() APILuca Ceresoli
Use the new DRM bridge allocation API, which is the only supported now, for the kunit tests. This change is more massive than for the typical DRM bridge driver because struct drm_bridge_init_priv currently embeds a struct drm_bridge, which is not supported anymore. We now have to use devm_drm_bridge_alloc() to dynamically allocate a "private driver struct", which is a bit awkward here because there is no real bridge driver. Thus let's add a "dummy" DRM bridge struct to represent it. As a nice cleanup we can now move the enable_count and disable_count members, which are counting bridge-specific events, into the new "private driver struct" (and avoid adding new unnecessary indirections). Also add a trivial bridge_to_dummy_bridge() function just like many drivers do. Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://lore.kernel.org/r/20250606-drm-bridge-alloc-doc-test-v9-1-b5bf7b43ed92@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/bridge: cdns-dsi: Use pre_enable/post_disable to enable/disableAradhya Bhatia
The cdns-dsi controller requires that it be turned on completely before the input DPI's source has begun streaming[0]. Not having that, allows for a small window before cdns-dsi enable and after cdns-dsi disable where the previous entity (in this case tidss's videoport) to continue streaming DPI video signals. This small window where cdns-dsi is disabled but is still receiving signals causes the input FIFO of cdns-dsi to get corrupted. This causes the colors to shift on the output display. The colors can either shift by one color component (R->G, G->B, B->R), or by two color components (R->B, G->R, B->G). Since tidss's videoport starts streaming via crtc enable hooks, we need cdns-dsi to be up and running before that. Now that the bridges are pre_enabled before crtc is enabled, and post_disabled after crtc is disabled, use the pre_enable and post_disable hooks to get cdns-dsi ready and running before the tidss videoport to get pass the color shift issues. [0]: See section 12.6.5.7.3 "Start-up Procedure" in J721E SoC TRM TRM Link: http://www.ti.com/lit/pdf/spruil1 Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-5-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Re-order bridge chain pre-enable and post-disableAradhya Bhatia
Move the bridge pre_enable call before crtc enable, and the bridge post_disable call after the crtc disable. The sequence of enable after this patch will look like: bridge[n]_pre_enable ... bridge[1]_pre_enable crtc_enable encoder_enable bridge[1]_enable ... bridge[n]_enable And, the disable sequence for the display pipeline will look like: bridge[n]_disable ... bridge[1]_disable encoder_disable crtc_disable bridge[1]_post_disable ... bridge[n]_post_disable The definition of bridge pre_enable hook says that, "The display pipe (i.e. clocks and timing signals) feeding this bridge will not yet be running when this callback is called". Since CRTC is also a source feeding the bridge, it should not be enabled before the bridges in the pipeline are pre_enabled. Fix that by re-ordering the sequence of bridge pre_enable and bridge post_disable. While at it, update the drm bridge API documentation as well. Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-4-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Separate out bridge pre_enable/post_disable from ↵Aradhya Bhatia
enable/disable The encoder-bridge ops occur by looping over the new connector states of the display pipelines. The enable sequence runs as follows - - pre_enable(bridge), - enable(encoder), - enable(bridge), while the disable sequnce runs as follows - - disable(bridge), - disable(encoder), - post_disable(bridge). Separate out the pre_enable(bridge), and the post_disable(bridge) operations into separate functions each. This patch keeps the sequence same for any singular disaplay pipe, but changes the sequence across multiple display pipelines. This patch is meant to be an interim patch, to cleanly pave the way for the sequence re-ordering patch, and maintain bisectability in the process. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Jayesh Choudhary <j-choudhary@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-3-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/atomic-helper: Refactor crtc & encoder-bridge op loops into separate ↵Aradhya Bhatia
functions The way any singular display pipeline, in need of a modeset, gets enabled is as follows - crtc enable (all) bridge pre-enable encoder enable (all) bridge enable - and the disable sequence is exactly the reverse of this. The crtc operations occur by looping over the old and new crtc states, while the encoder and bridge operations occur together, by looping over the connector states of the display pipelines. Refactor these operations - crtc enable/disable, and encoder & bridge (pre/post) enable/disable - into separate functions each, to make way for the re-ordering of the enable/disable sequences. This patch doesn't alter the sequence of crtc/encoder/bridge operations in any way, but helps to cleanly pave the way for the next two patches, by maintaining logical bisectability. Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Aradhya Bhatia <aradhya.bhatia@linux.dev> Tested-by: Devarsh Thakkar <devarsht@ti.com> Link: https://lore.kernel.org/r/20250605171524.27222-2-aradhya.bhatia@linux.dev Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-06drm/panthor: Clean up 64-bit register definitionsKarunika Choo
With the introduction of 64-bit register accessors, the separate *_HI definitions are no longer necessary. This change removes them and renames the corresponding *_LO entries for cleaner and more consistent register definitions. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Suggested-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Add 64-bit and poll register accessorsKarunika Choo
This patch adds 64-bit register accessors to simplify register access in Panthor. It also adds 32-bit and 64-bit variants for read_poll_timeout. This patch also updates Panthor to use the new 64-bit accessors and poll functions. Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Karunika Choo <karunika.choo@arm.com> Link: https://lore.kernel.org/r/20250606101835.41840-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Fix the user MMIO offset logic for emulatorsBoris Brezillon
Currently, we pick the MMIO offset based on the size of the pgoff_t type seen by the process that manipulates the FD, such that a 32-bit process can always map the user MMIO ranges. But this approach doesn't work well for emulators like FEX, where the emulator is a 64-bit binary which might be executing 32-bit code. In that case, the kernel thinks it's the 64-bit process and assumes DRM_PANTHOR_USER_MMIO_OFFSET_64BIT is in use, but the UMD library expects DRM_PANTHOR_USER_MMIO_OFFSET_32BIT, because it can't mmap() anything above the pgoff_t size. In order to solve that, we need a way to explicitly set the user MMIO offset from the UMD, such that the kernel doesn't have to guess it from the TIF_32BIT flag set on user thread. We keep the old behavior if DRM_PANTHOR_SET_USER_MMIO_OFFSET is never called. Changes in v2: - Drop the lock/immutable fields and allow SET_USER_MMIO_OFFSET requests to race with mmap() requests - Don't do the is_user_mmio_offset test twice in panthor_mmap() - Improve the uAPI docs Changes in v3: - Bump to version 1.5 instead of 1.4 after rebasing - Add R-bs - Fix/rephrase comment as suggested by Liviu Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://lore.kernel.org/r/20250606080932.4140010-3-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-06drm/panthor: Add missing explicit padding in drm_panthor_gpu_infoBoris Brezillon
drm_panthor_gpu_info::shader_present is currently automatically offset by 4 byte to meet Arm's 32-bit/64-bit field alignment rules, but those constraints don't stand on 32-bit x86 and cause a mismatch when running an x86 binary in a user emulated environment like FEX. It's also generally agreed that uAPIs should explicitly pad their struct fields, which we originally intended to do, but a mistake slipped through during the submission process, leading drm_panthor_gpu_info::shader_present to be misaligned. This uAPI change doesn't break any of the existing users of panthor which are either arm32 or arm64 where the 64-bit alignment of u64 fields is already enforced a the compiler level. Changes in v2: - Rename the garbage field into pad0 and adjust the comment accordingly - Add Liviu's A-b Changes in v3: - Add R-bs Fixes: 0f25e493a246 ("drm/panthor: Add uAPI") Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250606080932.4140010-2-boris.brezillon@collabora.com Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
2025-06-05drm/hyperv: Add support for drm_panicRyosuke Yasuoka
Add drm_panic module for hyperv drm so that panic screen can be displayed on panic. Signed-off-by: Ryosuke Yasuoka <ryasuoka@redhat.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250526090117.80593-2-ryasuoka@redhat.com Signed-off-by: Jocelyn Falempe <jfalempe@redhat.com>
2025-06-05drm/panel-edp: Clarify the `prepare_to_enable` description in commentsDouglas Anderson
It's unclear why I originally wrote in the description of `prepare_to_enable` that "This is not specified in a standard way on eDP timing diagrams" and then also wrote "It is effectively the time from HPD going high till you can turn on the backlight." It seems pretty clear that it's (T4+T5+T6+T8)-min. Either I was confused when I wrote this or I was looking at some strange panel datasheet that I can no longer find. Update the description of the field so it's easier for people to fill this in. Couch the description with "usually" in case there really was some weird datasheet where things were specified in a different way. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250521173204.1.Ic0375a9360698592f27afbf1f60f4996d504ed4f@changeid
2025-06-05drm/panel: himax-hx8394: Add Support for Huiling hl055fhav028cChris Morgan
Add support for the Huiling hl055fhav028c panel as used on the Gameforce Ace handheld gaming console. This panel uses a Himax HX8399C display controller and requires a sparsely documented vendor provided init sequence. The display resolution is 1080x1920 and is 70mm by 127mm as stated in the manufacturer's documentation. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603193930.323607-2-macroalpha82@gmail.com
2025-06-05dt-bindings: display: himax-hx8394: Add Huiling hl055fhav028cChris Morgan
Add compatible string for the Huiling hl055fhav028c. This panel is based on the Himax HX8399C display controller which is extremely similar to the existing HX8394. Add a new constant for himax,hx8399c for this new display controller as well. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603193930.323607-3-macroalpha82@gmail.com
2025-06-05dt-bindings: vendor-prefixes: Add prefix for HuilingChris Morgan
Shenzhen Huiling Information Technology Co. Ltd. specializes in the research and manufacturing of display and touch screens for industrial usage. https://en.szhuiling.com/ Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603193930.323607-2-macroalpha82@gmail.com
2025-06-05drm/panel-simple: add AUO P238HAN01 panel entryMichael Walle
Timings taken from the datasheet and the display is working in DE mode, thus the datasheet only specifies the blanking period. sync, back porch and front porch are arbitrarily chosen. The datasheet can be found at [1] but for reference these are the relevant timings: sym | | min | typ | max | unit | ------|--------------+------+------+------+------+ Tv | V period | 1094 | 1130 | 1836 | Th | | V active | 1080 | 1080 | 1080 | Th | | V blanking | 14 | 50 | 756 | Th | Fv | V frequency | 49 | 60 | 76 | Hz | Th | H period | 1000 | 1050 | 1678 | Tclk | | H active | 960 | 960 | 960 | Tclk | | H blanking | 40 | 90 | 718 | Tclk | Fh | H frequency | 53.7 | 67.8 | 90.0 | kHz | Tclk | LVDS clock | 53.7 | 71.2 | 90.0 | MHz | Keep in mind that this is a dual link LVDS panel and the horizontal timings are only for one half of the panel. [1] https://www.fortec-integrated.de/fileadmin/pdf/produkte/TFT-Displays/AUO/P238HAN01.0_Datasheet.pdf Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250520074439.655749-2-mwalle@kernel.org
2025-06-05dt-bindings: display: simple: add AUO P238HAN01 panelMichael Walle
Add AUO P238HAN01 23.8" 1920x1080 LVDS panel compatible string. Signed-off-by: Michael Walle <mwalle@kernel.org> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250520074439.655749-1-mwalle@kernel.org
2025-06-05drm/panel: ili9341: Remove unused member from struct ili9341Andy Shevchenko
struct device *dev from struct ili9341 is not used anywhere, remove it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250519133345.257138-1-andriy.shevchenko@linux.intel.com
2025-06-05MAINTAINERS: Update my email address for DRM Panel reviewsJessica Zhang
Update my email with *.qualcomm.com address Signed-off-by: Jessica Zhang <jessica.zhang@oss.qualcomm.com> Acked-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20250603-panel-maintainer-update-v1-1-224aaa222d99@oss.qualcomm.com
2025-06-05drm/ttm: handle undefined printf arg evaluation order in debugfsDave Airlie
When you read this debugfs file it's isn't guaranteed the count will happen before the scan, but I think the intent is that it does. printf argument evaluation order is undefined. Cc: Christian Koenig <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250603220901.1217161-1-airlied@gmail.com
2025-06-04drm/ttm: Fix build with CONFIG_DEBUG_FS=nLucas De Marchi
Move the define outside the ifdef for CONFIG_DEBUG_FS to fix the build. This currently breaks drm kunit tests: $ ./tools/testing/kunit/kunit.py run --kunitconfig drivers/gpu/drm/ttm/tests/.kunitconfig ERROR:root:../drivers/gpu/drm/ttm/ttm_pool.c: In function ‘ttm_pool_mgr_init’: ../drivers/gpu/drm/ttm/ttm_pool.c:1335:30: error: ‘TTM_SHRINKER_BATCH’ undeclared (first use in this function) 1335 | mm_shrinker->batch = TTM_SHRINKER_BATCH; Fixes: 22b929b25293 ("drm/ttm: Increase pool shrinker batch target") Cc: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603184750.3304647-2-lucas.demarchi@intel.com
2025-06-04ttm/pool: allow debugfs dumps for numa pools.Dave Airlie
Currently you can't see per-device numa aware pools properly. Cc: Christian König <christian.koenig@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/r/20250602204013.1104258-1-airlied@gmail.com
2025-06-03drm/i915: Use dma-fence driver and timeline name helpersTvrtko Ursulin
Access the dma-fence internals via the previously added helpers. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-6-tvrtko.ursulin@igalia.com
2025-06-03sync_file: Use dma-fence driver and timeline name helpersTvrtko Ursulin
Access the dma-fence internals via the previously added helpers. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-5-tvrtko.ursulin@igalia.com
2025-06-03dma-fence: Add helpers for accessing driver and timeline nameTvrtko Ursulin
Add some helpers in order to enable preventing dma-fence users accessing the implementation details directly and make the implementation itself use them. This will also enable later adding some asserts to a consolidated location. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-4-tvrtko.ursulin@igalia.com
2025-06-03dma-fence: Use a flag for 64-bit seqnosTvrtko Ursulin
With the goal of reducing the need for drivers to touch (and dereference) fence->ops, we move the 64-bit seqnos flag from struct dma_fence_ops to the fence->flags. Drivers which were setting this flag are changed to use new dma_fence_init64() instead of dma_fence_init(). v2: * Streamlined init and added kerneldoc. * Rebase for amdgpu userq which landed since. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Reviewed-by: Christian König <christian.koenig@amd.com> # v1 Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250515095004.28318-3-tvrtko.ursulin@igalia.com
2025-06-03drm/ttm: Increase pool shrinker batch targetTvrtko Ursulin
The default core shrink target of 128 pages (SHRINK_BATCH) is quite low relative to how cheap TTM pool shrinking is, and how the free pages are distributed in page order pools. We can make the target a bit more aggressive by making it roughly the average number of pages across all pools, freeing more of the cached pages every time shrinker core invokes our callback. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603112750.34997-3-tvrtko.ursulin@igalia.com
2025-06-03drm/ttm: Respect the shrinker core free targetTvrtko Ursulin
Currently the TTM shrinker aborts shrinking as soon as it frees pages from any of the page order pools and by doing so it can fail to respect the freeing target which was configured by the shrinker core. We use the wording "can fail" because the number of freed pages will depend on the presence of pages in the pools and the order of the pools on the LRU list. For example if there are no free pages in the high order pools the shrinker core may require multiple passes over the TTM shrinker before it will free the default target of 128 pages (assuming there are free pages in the low order pools). This inefficiency can be compounded by the pool LRU where multiple further calls into the TTM shrinker are required to end up looking at the pool with pages. Improve this by never freeing less than the shrinker core has requested. At the same time we start reporting the number of scanned pages (freed in this case), which prevents the core shrinker from giving up on the TTM shrinker too soon and moving on. v2: * Simplify loop logic. (Christian) * Improve commit message. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Link: https://lore.kernel.org/r/20250603112750.34997-2-tvrtko.ursulin@igalia.com
2025-06-03Merge drm-next-2025-05-28 into drm-misc-nextMaxime Ripard
Christian needs a recent drm-next branch to merge fence patches. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-06-03drm/udl: use DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGTShixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes: udl 2-1.4:1.0: swiotlb buffer is full (sz: 2097152 bytes), total 65536 (slots), used 1 (slots) Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250522070714.439824-3-oushixiong1025@163.com
2025-06-03drm/ast: use DRM_GEM_SHMEM_DRIVER_OPS_NO_MAP_SGTShixiong Ou
Import dmabuf without mapping its sg_table to avoid issues likes: ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots) Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250522070714.439824-2-oushixiong1025@163.com
2025-06-03drm/shmem-helper: Import dmabuf without mapping its sg_tableShixiong Ou
[WHY] 1. Drivers using DRM_GEM_SHADOW_PLANE_HELPER_FUNCS and DRM_GEM_SHMEM_DRIVER_OPS (e.g., udl, ast) do not require sg_table import. They only need dma_buf_vmap() to access the shared buffer's kernel virtual address. 2. On certain Aspeed-based boards, a dma_mask of 0xffff_ffff may trigger SWIOTLB during dmabuf import. However, IO_TLB_SEGSIZE restricts the maximum DMA streaming mapping memory, resulting in errors like: ast 0000:07:00.0: swiotlb buffer is full (sz: 3145728 bytes), total 32768 (slots), used 0 (slots) [HOW] Provide a gem_prime_import implementation without sg_table mapping to avoid issues (e.g., "swiotlb buffer is full"). Drivers that do not require sg_table can adopt this. Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20250522070714.439824-1-oushixiong1025@163.com
2025-06-02drm/panfrost: Fix panfrost device variable name in devfreqAdrián Larumbe
Commit 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency") was a Panfrost port of a similar fix in Panthor. Fix the Panfrost device pointer variable name so that it follows Panfrost naming conventions. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Fixes: 64111a0e22a9 ("drm/panfrost: Fix incorrect updating of current device frequency") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250520174634.353267-6-adrian.larumbe@collabora.com
2025-06-02drm/panfrost: show device-wide list of DRM GEM objects over DebugFSAdrián Larumbe
This change is essentially a Panfrost port of commit a3707f53eb3f ("drm/panthor: show device-wide list of DRM GEM objects over DebugFS"). The DebugFS file is almost the same as in Panthor, minus the GEM object usage flags, since Panfrost has no kernel-only BO's. Two additional GEM state flags which are displayed but aren't relevant to Panthor are 'Purged' and 'Purgeable', since Panfrost implements an explicit shrinker and a madvise ioctl to flag objects as reclaimable. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250520174634.353267-5-adrian.larumbe@collabora.com
2025-06-02drm/panfrost: Add driver IOCTL for setting BO labelsAdrián Larumbe
Allow UM to label a BO for which it possesses a DRM handle. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250520174634.353267-4-adrian.larumbe@collabora.com
2025-06-02drm/panfrost: Internally label some BOsAdrián Larumbe
Perfcnt samples buffer is not exposed to UM, but we would like to keep a tag on it as a potential debug aid. PRIME imported GEM buffers are UM exposed, but since the usual Panfrost UM driver code path is not followed in their creation, they might remain unlabelled for their entire lifetime, so a generic tag was deemed preferable. The tag is assigned before a UM handle is created so it doesn't contradict the logic about labelling internal BOs. Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250520174634.353267-3-adrian.larumbe@collabora.com
2025-06-02drm/panfrost: Add BO labelling to PanfrostAdrián Larumbe
Functions for labelling UM-exposed an internal BOs are provided. An example of the latter would be the Perfcnt sample buffer. This commit is done in preparation of a following one that will allow UM to set BO labels through a new ioctl(). Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://lore.kernel.org/r/20250520174634.353267-2-adrian.larumbe@collabora.com
generated by cgit (git 2.34.1) at 2025-09-07 05:14:24 +0000