- 02 Apr, 2024 1 commit
-
-
Boris Brezillon authored
When mapping an IO region, the pseudo-file offset is dependent on the userspace architecture. panthor_device_mmio_offset() abstracts that away for us by turning a userspace MMIO offset into its kernel equivalent, but we were not updating vm_area_struct::vm_pgoff accordingly, leading us to attach the MMIO region to the wrong file offset. This has implications when we start mixing 64 bit and 32 bit apps, but that's only really a problem when we start having more that 2^43 bytes of memory allocated, which is very unlikely to happen. What's more problematic is the fact this turns our unmap_mapping_range(DRM_PANTHOR_USER_MMIO_OFFSET) calls, which are supposed to kill the MMIO mapping when entering suspend, into NOPs. Which means we either keep the dummy flush_id mapping active at all times, or we risk a BUS_FAULT if the MMIO region was mapped, and the GPU is suspended after that. Solve that by patching vm_pgoff early in panthor_mmap(). With this in place, we no longer need the panthor_device_mmio_offset() helper. v3: - No changes v2: - Kill panthor_device_mmio_offset() Fixes: 5fe909ca ("drm/panthor: Add the device logical block") Reported-by:
Adrián Larumbe <adrian.larumbe@collabora.com> Reported-by:
Lukas F. Hartmann <lukas@mntmn.com> Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/10835Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240326111205.510019-1-boris.brezillon@collabora.com
-
- 29 Mar, 2024 5 commits
-
-
Chris Morgan authored
The GameForce Chi is a handheld device with a 3.5" 640x480 ST7703 based display panel. Signed-off-by:
Chris Morgan <macromorgan@hotmail.com> Acked-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240325134959.11807-4-macroalpha82@gmail.comSigned-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325134959.11807-4-macroalpha82@gmail.com
-
Chris Morgan authored
The GameForce Chi panel is a panel specific to the GameForce Chi handheld device that measures 3.5" diagonally with a resolution of 640x480. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240325134959.11807-3-macroalpha82@gmail.comSigned-off-by:
-
Chris Morgan authored
GameForce is a company that produces handheld game consoles. https://gameforce.fun/Signed-off-by:
-
Christian Hewitt authored
Playing 4K media with 59.94 fractional rate (typically VP9) causes the screen to lose sync with the following error reported in the system log: [ 89.610280] Fatal Error, invalid HDMI vclk freq 593406 Modetest shows the following: 3840x2160 59.94 3840 4016 4104 4400 2160 2168 2178 2250 593407 flags: xxxx, xxxx, drm calculated value -------------------------------------^ Change the fractional rate calculation to stop DIV_ROUND_CLOSEST rounding down which results in vclk freq failing to match correctly. Fixes: e5fab2ec ("drm/meson: vclk: add support for YUV420 setup") Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Reviewed-by:
-
Ian Forbes authored
Remove unused structs, members, and file. Many of these are written but never read. Signed-off-by:
Ian Forbes <ian.forbes@broadcom.com> Signed-off-by:
Zack Rusin <zack.rusin@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240214210440.26167-1-ian.forbes@broadcom.com
-
- 28 Mar, 2024 15 commits
-
-
Adrián Larumbe authored
Also add a newline character at the end of the last one. Fixes: b12f3ea7 ("drm/panfrost: Replace fdinfo's profiling debugfs knob with sysfs") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/dri-devel/20240326160110.4c00e1e5@canb.auug.org.au/Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Tested-by:
-
Geert Uytterhoeven authored
There is no point in asking the user about enforcing the DRM compiler warning policy when configuring a kernel without DRM support. Fixes: f89632a9 ("drm: Add CONFIG_DRM_WERROR") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/631a1f4c066181b54617bfe2f38b0bd0ac865b68.1711474200.git.geert+renesas@glider.beSigned-off-by:
-
Maxime Ripard authored
The IT6505 bridge Kconfig symbol selects a Kconfig symbol that doesn't exist. Remove it. Reviewed-by:
Maxime Ripard <mripard@kernel.org>
-
Maxime Ripard authored
Most of our helpers have relied on being selected so far through Kconfig, but that creates issues when we have multiple layers of helpers with some depending on others. Indeed, select doesn't select a dependency's dependencies, and thus isn't super intuitive. Depends on however doesn't have that limitation, so we can just switch all the drivers that were selecting DRM_DISPLAY_HDMI_HELPER to depend on it. Reviewed-by:
-
Maxime Ripard authored
Most of our helpers have relied on being selected so far through Kconfig, but that creates issues when we have multiple layers of helpers with some depending on others. Indeed, select doesn't select a dependency's dependencies, and thus isn't super intuitive. Depends on however doesn't have that limitation, so we can just switch all the drivers that were selecting DRM_DISPLAY_HDCP_HELPER to depend on it. Reviewed-by:
-
Maxime Ripard authored
Most of our helpers have relied on being selected so far through Kconfig, but that creates issues when we have multiple layers of helpers with some depending on others. Indeed, select doesn't select a dependency's dependencies, and thus isn't super intuitive. Depends on however doesn't have that limitation, so we can just switch all the drivers that were selecting DRM_DISPLAY_DP_HELPER to depend on it. Reviewed-by:
-
Maxime Ripard authored
Most of our helpers have relied on being selected so far through Kconfig, but that creates issues when we have multiple layers of helpers with some depending on others. Indeed, select doesn't select a dependency's dependencies, and thus isn't super intuitive. Depends on however doesn't have that limitation, so we can just switch all the drivers that were selecting DRM_DISPLAY_DP_AUX_BUS to depend on it. Reviewed-by:
-
Maxime Ripard authored
Most of our helpers have relied on being selected so far through Kconfig, but that creates issues when we have multiple layers of helpers with some depending on others. Indeed, select doesn't select a dependency's dependencies, and thus isn't super intuitive. Depends on however doesn't have that limitation, so we can just switch all the drivers that were selecting DRM_DISPLAY_HELPER to depend on it. Reviewed-by:
-
Maxime Ripard authored
DRM_DW_HDMI has a number of dependencies that might not be enabled. However, drivers were used to selecting it while not enforcing the DRM_DW_HDMI dependencies. This could result in Kconfig warnings (and further build breakages) such as: Kconfig warnings: (for reference only) WARNING: unmet direct dependencies detected for DRM_DW_HDMI Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && DRM_BRIDGE [=y] && DRM_DISPLAY_HELPER [=n] Selected by [m]: - DRM_SUN8I_DW_HDMI [=m] && HAS_IOMEM [=y] && DRM_SUN4I [=m] Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202403262127.kZkttfNz-lkp@intel.com/Acked-by:
-
Maxime Ripard authored
All the helpers Kconfig symbols so far have relied on drivers selecting them, and that's what most drivers did. However, this creates an issue nowadays when helpers depend on each other, and select doesn't transitively select a dependency dependencies. Depends on doesn't have that limitation though, so let's convert those symbols to be dependable and use depends on between them too. Suggested-by:
Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
-
Maxime Ripard authored
The display kconfig helpers are not organized in any particular order, so let's move them around to create an alphabetical order. Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20240327-kms-kconfig-helpers-v3-5-eafee11b84b3@kernel.orgSigned-off-by:
-
Maxime Ripard authored
While most display helpers Kconfig symbols have the DRM_DISPLAY prefix, the DisplayPort CEC tunnelling implementation uses CONFIG_DRM_DISPLAY_DP_AUX_CEC. Since the number of users is limited, we can easily rename it to make it consistent. Reviewed-by:
-
Maxime Ripard authored
While most display helpers Kconfig symbols have the DRM_DISPLAY prefix, the DisplayPort-AUX chardev interface uses DRM_DP_AUX_CHARDEV. Since the number of users is limited and it's a selected symbol, we can easily rename it to make it consistent. Reviewed-by:
-
Maxime Ripard authored
While most display helpers Kconfig symbols have the DRM_DISPLAY prefix, the DisplayPort Tunnel debugging uses DRM_DISPLAY_DEBUG_DP_TUNNEL_STATE. Since the number of users is limited and it's a selected symbol, we can easily rename it to make it consistent. Reviewed-by:
-
Maxime Ripard authored
While most display helpers Kconfig symbols have the DRM_DISPLAY prefix, the DisplayPort AUX bus implementation uses DRM_DP_AUX_BUS. Since the number of users is limited and it's a selected symbol, we can easily rename it to make it consistent. Reviewed-by:
-
- 26 Mar, 2024 5 commits
-
-
Douglas Anderson authored
In response to my patch removing the "wait for HPD" logic at the beginning of the MSM DP transfer() callback [1], we had some debate about what the "This is an optional function" meant in the documentation of the wait_hpd_asserted() callback. Let's clarify. As talked about in the MSM DP patch [1], before wait_hpd_asserted() was introduced there was no great way for panel drivers to wait for HPD in the case that the "built-in" HPD signal was used. Panel drivers could only wait for HPD if a GPIO was used. At the time, we ended up just saying that if we were using the "built-in" HPD signal that DP AUX controllers needed to wait for HPD themselves at the beginning of their transfer() callback. The fact that the wait for HPD at the beginning of transfer() was awkward/problematic was the whole reason wait_hpd_asserted() was added. Let's make it obvious that if a DP AUX controller implements wait_hpd_asserted() that they don't need a loop waiting for HPD at the start of their transfer() function. We'll still allow DP controllers to work the old way but mark it as deprecated. [1] https://lore.kernel.org/r/20240315143621.v2.3.I535606f6d4f7e3e5588bb75c55996f61980183cd@changeidReviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240319135836.v2.1.I521dad0693cc24fe4dd14cba0c7048d94f5b6b41@changeid
-
Colin Ian King authored
There is a spelling mistake in a drm_err message. Fix it. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Acked-by:
-
Boris Brezillon authored
The kernel doc prefix is /** not /*. Reported-by:
-
Heiko Stuebner authored
The init sequence specifies the 0x11 and 0x29 dsi commands, which are the exit-sleep and display-on commands. In the actual prepare step the driver already uses the appropriate function calls for those, so drop the duplicates. Fixes: e5f9d543 ("drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant") Signed-off-by:
Heiko Stuebner <heiko.stuebner@cherry.de> Reviewed-by:
Quentin Schulz <quentin.schulz@theobroma-systems.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240320131232.327196-2-heiko@sntech.de
-
Heiko Stuebner authored
Similar to other variants, the LTK050H3148W wants to run in video mode when displaying data. So far only the Synopsis DSI driver was using this panel and it is always switching to video mode, independent of this flag being set. Other DSI drivers might handle this differently, so add the flag. Fixes: e5f9d543 ("drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variant") Signed-off-by:
-
- 25 Mar, 2024 9 commits
-
-
Pin-yen Lin authored
Add support for the AUO B120XAN01.0 panel. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
-
Adrián Larumbe authored
If job accounting is disabled, then both fdinfo's drm-engine and drm-cycle key values will remain immutable. In that case, it makes more sense not to display them at all to avoid confusing user space profiling tools. Signed-off-by:
-
Krzysztof Kozlowski authored
Allow width and height properties from panel-common.yaml, already used on some boards: sdm845-sony-xperia-tama-apollo.dtb: panel@0: 'height-mm', 'width-mm' do not match any of the regexes: 'pinctrl-[0-9]+' Acked-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240325103227.27474-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
The panel-common schema does not define what "ports" property is, so bring the definition by referencing the panel-common-dual.yaml. Panels can be single- or dual-link, depending on the compatible, thus add if:then:else: block narrowing ports per variant. Signed-off-by:
-
Krzysztof Kozlowski authored
The panel-common schema does not define what "ports" property is, so bring the definition by referencing the panel-common-dual.yaml. Panels can be single- or dual-link, thus require only one port@0. Signed-off-by:
-
Krzysztof Kozlowski authored
Add schema with common properties shared among dual-link panel ICs. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Arnd Bergmann authored
The array size calculation in pvr_vm_mips_fini() appears to be incorrect based on taking the size of the pointer rather than the size of the array, which manifests as a warning about signed integer overflow: In file included from include/linux/kernel.h:16, from drivers/gpu/drm/imagination/pvr_rogue_fwif.h:10, from drivers/gpu/drm/imagination/pvr_ccb.h:7, from drivers/gpu/drm/imagination/pvr_device.h:7, from drivers/gpu/drm/imagination/pvr_vm_mips.c:4: drivers/gpu/drm/imagination/pvr_vm_mips.c: In function 'pvr_vm_mips_fini': include/linux/array_size.h:11:25: error: overflow in conversion from 'long unsigned int' to 'int' changes value from '18446744073709551615' to '-1' [-Werror=overflow] 11 | #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr)) | ^ drivers/gpu/drm/imagination/pvr_vm_mips.c:106:24: note: in expansion of macro 'ARRAY_SIZE' 106 | for (page_nr = ARRAY_SIZE(mips_data->pt_pages) - 1; page_nr >= 0; page_nr--) { | ^~~~~~~~~~ Just use the number of array elements directly here, and in the corresponding init function for consistency. Fixes: 927f3e02 ("drm/imagination: Implement MIPS firmware processor and MMU support") Reviewed-by:Donald Robson <donald.robson@imgtec.com> Link: https://lore.kernel.org/lkml/9df9e4f87727399928c068dbbf614c9895ae15f9.camel@imgtec.com/Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Matt Coster <matt.coster@imgtec.com>
-
Steven Price authored
virt_to_pfn() isn't available on x86 (except to xen) so breaks COMPILE_TEST builds. Avoid its use completely by instead storing the struct page pointer allocated in panthor_device_init() and using page_to_pfn() instead. Signed-off-by:
-
Boris Brezillon authored
Putting a hard dependency on CONFIG_PM is not possible because of a circular dependency issue, and it's actually not desirable either. In order to support this use case, we forcibly resume at init time, and suspend at unplug time. v2: - Drop the #ifdef CONFIG_PM section around panthor_pm_ops's definition Reported-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240318153117.1321544-1-boris.brezillon@collabora.com
-
- 20 Mar, 2024 3 commits
-
-
Douglas Anderson authored
When the atna33xc20 driver was first written the resume code never returned an error. If there was a problem waiting for HPD it just printed a warning and moved on. This changed in response to review feedback [1] on a future patch but I accidentally didn't account for rolling back the regulator enable in the error cases. Do so now. [1] https://lore.kernel.org/all/5f3cf3a6-1cc2-63e4-f76b-4ee686764705@linaro.org/ Fixes: 3b5765df ("drm/panel: atna33xc20: Take advantage of wait_hpd_asserted() in struct drm_dp_aux") Acked-by:
-
Christian König authored
The BOs in a bulk move must share all the same reservation object to make sure that we lock the whole bulk during eviction. Actually document and enforce that with a warning. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240312105555.3065-1-christian.koenig@amd.com
-
Marek Vasut authored
In case the LCDIF is enabled in DT but unused, the clocks used by the LCDIF are not enabled. Those clocks may even have a use count of 0 in case there are no other users of those clocks. This can happen e.g. in case the LCDIF drives HDMI bridge which has no panel plugged into the HDMI connector. Do not attempt to disable clocks in the suspend callback and re-enable clocks in the resume callback unless the LCDIF is enabled and was in use before the system entered suspend, otherwise the driver might end up trying to disable clocks which are already disabled with use count 0, and would trigger a warning from clock core about this condition. Note that the lcdif_rpm_suspend() and lcdif_rpm_resume() functions internally perform the clocks disable and enable operations and act as runtime PM hooks too. Reviewed-by:
Liu Ying <victor.liu@nxp.com> Fixes: 9db35bb3 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by:
Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240226082644.32603-1-marex@denx.de
-
- 19 Mar, 2024 2 commits
-
-
Nathan Morrisson authored
Add support for the POWERTIP PH128800T006-ZHC01 10.1" (1280x800) LCD-TFT panel. Signed-off-by:
Nathan Morrisson <nmorrisson@phytec.com> Acked-by:
-
Nathan Morrisson authored
Add POWERTIP PH128800T-006-ZHC01 10.1" LCD-TFT LVDS panel compatible string. Signed-off-by:
-
