- 22 May, 2023 5 commits
-
-
Marek Vasut authored
Implement support for DSI clock and data lane DN/DP polarity swap by means of decoding 'lane-polarities' DT property. The controller does support DN/DP swap of clock lane and all data lanes, the controller does not support polarity swap of individual data lane bundles, add a check which verifies all data lanes have the same polarity. This has been validated on an imx8mm board that actually has the MIPI DSI clock lanes inverted. Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230514114625.98372-2-festevam@gmail.com
-
Fabio Estevam authored
The Samsung DSIM IP block allows the inversion of the clock and data lanes. Add an optional property called 'lane-polarities' that describes the polarities of the MIPI DSI clock and data lanes. This property is useful for properly describing the hardware when the board designer decided to switch the polarities of the MIPI DSI clock and/or data lanes. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Artur Weber authored
Add myself as maintainer of the Samsung S6D7AA0 panel driver. Signed-off-by:
Artur Weber <aweber.kernel@gmail.com> Reviewed-by:
-
Artur Weber authored
Initial driver for S6D7AA0-controlled panels. Currently, the following panels are supported: - S6D7AA0-LSL080AL02 (Samsung Galaxy Tab 3 8.0) - S6D7AA0-LSL080AL03 (Samsung Galaxy Tab A 8.0 2015) - S6D7AA0-LTL101AT01 (Samsung Galaxy Tab A 9.7 2015) It should be possible to extend this driver to work with other panels using this IC. Tested-by: Nikita Travkin <nikita@trvn.ru> #ltl101at01 Signed-off-by:
-
Artur Weber authored
Add bindings for the S6D7AA0 LCD panel controller, including the S6D7AA0-LSL080AL02 panel used in the Samsung Galaxy Tab 3 8.0 family of tablets, and the S6D7AA0-LSL080AL03 and S6D7AA0-LTL101AT01 panels used in the Samsung Galaxy Tab A 8.0 and 9.7 2015. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
- 19 May, 2023 2 commits
-
-
Luben Tuikov authored
Rename drm_sched_wakeup() to drm_sched_wakeup_if_canqueue() since the former is misleading, as it wakes up the GPU scheduler _only if_ more jobs can be queued to the underlying hardware. This distinction is important to make, since the wake conditional in the GPU scheduler thread wakes up when other conditions are also true, e.g. when there are jobs to be cleaned. For instance, a user might want to wake up the scheduler only because there are more jobs to clean, but whether we can queue more jobs is irrelevant. v2: Separate "canqueue" to "can_queue". (Alex D.) Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by:
Luben Tuikov <luben.tuikov@amd.com> Link: https://lore.kernel.org/r/20230517233550.377847-2-luben.tuikov@amd.comReviewed-by:
Alex Deucher <Alexander.Deucher@amd.com>
-
Luben Tuikov authored
Rename drm_sched_ready() to drm_sched_can_queue(). "ready" can mean many things and is thus meaningless in this context. Instead, rename to a name which precisely conveys what is being checked. Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <Alexander.Deucher@amd.com> Signed-off-by:
-
- 18 May, 2023 7 commits
-
-
Thomas Zimmermann authored
Update the names of the fb_mem*() helpers to be consistent with their regular counterparts. Hence, fb_memset() now becomes fb_memset_io(), fb_memcpy_fromfb() now becomes fb_memcpy_fromio() and fb_memcpy_tofb() becomes fb_memcpy_toio(). No functional changes. v6: * update new file fb_io_fops.c Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230512102444.5438-8-tzimmermann@suse.de
-
Thomas Zimmermann authored
Implement framebuffer I/O helpers, such as fb_read*() and fb_write*(), in the architecture's <asm/fb.h> header file or the generic one. The common case has been the use of regular I/O functions, such as __raw_readb() or memset_io(). A few architectures used plain system- memory reads and writes. Sparc used helpers for its SBus. The architectures that used special cases provide the same code in their __raw_*() I/O helpers. So the patch replaces this code with the __raw_*() functions and moves it to <asm-generic/fb.h> for all architectures. v8: * remove garbage after commit-message tags v6: * fix fb_readq()/fb_writeq() on 64-bit mips (kernel test robot) v5: * include <linux/io.h> in <asm-generic/fb>; fix s390 build v4: * ia64, loongarch, sparc64: add fb_mem*() to arch headers to keep current semantics (Arnd) v3: * implement all architectures with generic helpers * support reordering and native byte order (Geert, Arnd) Signed-off-by:
-
Thomas Zimmermann authored
Replace include statements for <asm/fb.h> with <linux/fb.h>. Fixes the coding style: if a header is available in asm/ and linux/, it is preferable to include the header from linux/. This only affects a few source files, most of which already include <linux/fb.h>. Suggested-by:
-
Thomas Zimmermann authored
The code uses writel() and similar I/O-memory helpers. Include the header file to get the declarations. Signed-off-by:
-
Thomas Zimmermann authored
The code uses readl() and writel(). Include the header file to get the declarations. Signed-off-by:
-
Thomas Zimmermann authored
Fix coding style. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Cast I/O offsets to pointers to use them with I/O functions. The I/O functions expect pointers of type 'volatile void __iomem *', but the offsets are plain integers. Build warnings are ../drivers/video/fbdev/hitfb.c: In function 'hitfb_accel_wait': ../arch/x86/include/asm/hd64461.h:18:33: warning: passing argument 1 of 'fb_readw' makes pointer from integer without a cast [-Wint-conversion] 18 | #define HD64461_IO_OFFSET(x) (HD64461_IOBASE + (x)) | ^~~~~~~~~~~~~~~~~~~~~~ | | | unsigned int ../arch/x86/include/asm/hd64461.h:93:33: note: in expansion of macro 'HD64461_IO_OFFSET' 93 | #define HD64461_GRCFGR HD64461_IO_OFFSET(0x1044) /* Accelerator Configuration Register */ | ^~~~~~~~~~~~~~~~~ ../drivers/video/fbdev/hitfb.c:47:25: note: in expansion of macro 'HD64461_GRCFGR' 47 | while (fb_readw(HD64461_GRCFGR) & HD64461_GRCFGR_ACCSTATUS) ; | ^~~~~~~~~~~~~~ In file included from ../arch/x86/include/asm/fb.h:15, from ../include/linux/fb.h:19, from ../drivers/video/fbdev/hitfb.c:22: ../include/asm-generic/fb.h:52:57: note: expected 'const volatile void *' but argument is of type 'unsigned int' 52 | static inline u16 fb_readw(const volatile void __iomem *addr) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ This patch only fixes the build warnings. It's not clear if the I/O offsets can legally be passed to the I/O helpers. It was apparently broken in 2007 when custom inw()/outw() helpers got removed by commit 34a780a0 ("sh: hp6xx pata_platform support."). Fixing the driver would require setting the I/O base address. Reported-by:kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202305102136.eMjTSPwH-lkp@intel.com/Signed-off-by:
Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230512102444.5438-2-tzimmermann@suse.de
-
- 17 May, 2023 3 commits
-
-
Alexander Stein authored
DSI device registering and attaching needs to be undone upon deregistration. This fixes module unload/load. Fixes: bbfd3190 ("drm/bridge: tc358767: Add DSI-to-DPI mode support") Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Robert Foss <rfoss@kernel.org> Signed-off-by:
-
Jani Nikula authored
Make the struct ttm_device_funcs pointers const so the data can be placed in rodata. Cc: Christian Koenig <christian.koenig@amd.com> Cc: Huang Rui <ray.huang@amd.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Sui Jingfeng authored
Signed-off-by:
-
- 16 May, 2023 4 commits
-
-
Cong Yang authored
There is a problem of screen shake on the old panel. So increase the panel GOP component pull-down circuit size in hardware, and update the initialization code at the same time. The new initialization code mainly modifles the following. a)adjusted for GOP timing. When Display sleep in, raise all GOP signals to VGHO and then drop to GND. b)Increased the Vertical back Porch and Vertical pulse width, so need to update vsync_end and vtotal and CLK in drm_display_mode. Signed-off-by:
Cong Yang <yangcong5@huaqin.corp-partner.google.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> [dianders: fixed spelling mistake in subject] Signed-off-by:
-
Francesco Dolcini authored
Remove unneeded stray semicolon. Reported-by:
Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by:
-
Anup Sharma authored
There is no need to exclusively set the .owner member of the struct device_driver when defining the platform_driver struct. The Linux core takes care of setting the .owner member as part of the call to module_platform_driver() helper function. Issue identified using the platform_no_drv_owner.cocci Coccinelle semantic patch as: drivers/gpu/drm/bridge/samsung-dsim.c:1957:6-11: No need to set .owner here. The core will do it. No functional changes are intended. Signed-off-by:
Anup Sharma <anupnewsmail@gmail.com> Reviewed-by:
-
Marek Vasut authored
The TC358867/TC9595 devices are compatible with the predecessor TC358767. Document compatible strings for the new devices, so they can be discerned in board DTs. Update the title to match description in the process. Signed-off-by:
-
- 15 May, 2023 6 commits
-
-
Maíra Canal authored
Currently, the pixel conversion isn't rounding the fixed-point values before assigning it to the RGB coefficients, which is causing the IGT pixel-format tests to fail. So, use the drm_fixp2int_round() fixed-point helper to round the values when assigning it to the RGB coefficients. Tested with igt@kms_plane@pixel-format and igt@kms_plane@pixel-format-source-clamping. [v2]: * Use drm_fixp2int_round() to fix the pixel conversion instead of casting the values to s32 (Melissa Wen). Fixes: 89b03aea ("drm/vkms: fix 32bit compilation error by replacing macros") Signed-off-by:Maíra Canal <mcanal@igalia.com> Reviewed-by:
Arthur Grillo <arthurgrillo@riseup.net> Signed-off-by:
Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230512104044.65034-2-mcanal@igalia.com
-
Maíra Canal authored
Create a new fixed-point helper to allow us to return the rounded value of our fixed point value. [v2]: * Create the function drm_fixp2int_round() (Melissa Wen). [v3]: * Use drm_fixp2int() instead of shifting manually (Arthur Grillo). Signed-off-by: -
Shuijing Li authored
For "boe,tv105wum-nw0" this special panel, it is stipulated in the panel spec that MIPI needs to keep the LP11 state before the lcm_reset pin is pulled high. Signed-off-by:
Shuijing Li <shuijing.li@mediatek.com> Signed-off-by:
Xinlei Lee <xinlei.lee@mediatek.com> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by:
-
Shuijing Li authored
Reduce the delay after LCM reset by removing an extra delay in the initialization commands array. The required delay of at least 6ms after reset is guaranteed by boe_panel_prepare(). Signed-off-by:
-
Javier Martinez Canillas authored
This is a leftover from an early iteration of the driver when it was still named ssd1307 instead of ssd130x. Change it for consistency with the rest. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Huacai Chen authored
Consider a configuration like this: 1, efifb (or simpledrm) is built-in; 2, a native display driver (such as radeon) is also built-in. As Javier said, this is not a common configuration (the native display driver is usually built as a module), but it can happen and cause some trouble. In this case, since efifb, radeon and sysfb are all in device_initcall() level, the order in practise is like this: efifb registered at first, but no "efi-framebuffer" device yet. radeon registered later, and /dev/fb0 created. sysfb_init() comes at last, it registers "efi-framebuffer" and then causes an error message "efifb: a framebuffer is already registered". Make sysfb_init() to be subsys_ initcall_sync() can avoid this. And Javier Martinez Canillas is trying to make a more general solution in commit 873eb3b1 ("fbdev: Disable sysfb device registration when removing conflicting FBs"). However, this patch still makes sense because it can make the screen display as early as possible (We cannot move to subsys_initcall, since sysfb_init() should be executed after PCI enumeration). Reviewed-by:
Huacai Chen <chenhuacai@loongson.cn> Signed-off-by:
-
- 11 May, 2023 5 commits
-
-
Liu Ying authored
Add BOE EV121WXM-N10-1850 12.1" WXGA (1280x800) TFT LCD panel support. The panel has a LVDS display interface. The panel's product specification can be found at: http://www.onetech.com.tw/files/EV121WXM-N10-1850ProductSpecification_20180801.pdfSigned-off-by:
Liu Ying <victor.liu@nxp.com> Reviewed-by:
-
Liu Ying authored
Add BOE EV121WXM-N10-1850 12.1" WXGA (1280x800) TFT LCD panel compatible string. The panel has a LVDS display interface. The panel's product specification can be found at: http://www.onetech.com.tw/files/EV121WXM-N10-1850ProductSpecification_20180801.pdfAcked-by:
-
Dmitry Baryshkov authored
Drop sharp_nt_panel_disable() and sharp_nt_panel_enable(), which bear no useful code. Also drop sharp_nt_panel::enable and sharp_nt_panel::mode fields which also provide no use now. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
-
Dmitry Baryshkov authored
Using current settings causes panel flickering on APQ8074 dragonboard. Adjust panel settings to follow the vendor-provided mode. This also enables MIPI_DSI_MODE_VIDEO_SYNC_PULSE, which is also specified by the vendor dtsi for the mentioned dragonboard. Fixes: ee017238 ("drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel") Signed-off-by:
-
XuDong Liu authored
Smatch reports: drivers/gpu/drm/sun4i/sun4i_tcon.c:805 sun4i_tcon_init_clocks() warn: 'tcon->clk' from clk_prepare_enable() not released on lines: 792,801. In the function sun4i_tcon_init_clocks(), tcon->clk and tcon->sclk0 are not disabled in the error handling, which affects the release of these variable. Although sun4i_tcon_bind(), which calls sun4i_tcon_init_clocks(), use sun4i_tcon_free_clocks to disable the variables mentioned, but the error handling branch of sun4i_tcon_init_clocks() ignores the required disable process. To fix this issue, use the devm_clk_get_enabled to automatically balance enable and disabled calls. As original implementation use sun4i_tcon_free_clocks() to disable clk explicitly, we delete the related calls and error handling that are no longer needed. Fixes: 9026e0d1 ("drm: Add Allwinner A10 Display Engine support") Fixes: b14e945b ("drm/sun4i: tcon: Prepare and enable TCON channel 0 clock at init") Fixes: 8e924047 ("drm/sun4i: support TCONs without channel 1") Fixes: 34d698f6 ("drm/sun4i: Add has_channel_0 TCON quirk") Signed-off-by:
XuDong Liu <m202071377@hust.edu.cn> Reviewed-by:
Dongliang Mu <dzm91@hust.edu.cn> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230430112347.4689-1-m202071377@hust.edu.cn
-
- 10 May, 2023 2 commits
-
-
Roman Beranek authored
In DSI mode, TCON0's data clock is required to run at 1/4 the per-lane bit rate. Signed-off-by:
Roman Beranek <me@crly.cz> Signed-off-by:
-
Roman Beranek authored
While the rate of TCON0's DCLK matches dotclock for parallel and LVDS outputs, this doesn't hold for DSI. The 'D' in DCLK actually stands for 'Data' according to Allwinner's manuals. The clock is mostly referred to as dclk throughout this driver already anyway, so stick with that. Signed-off-by:
-
- 09 May, 2023 3 commits
-
-
Maxime Ripard authored
Start the 6.5 release cycle. Signed-off-by: -
Maíra Canal authored
I've been contributing to VKMS with improvements, reviews, testing and debugging. Therefore, add myself as a co-maintainer of the VKMS driver. Acked-by:
Melissa Wen <mwen@igalia.com> Reviewed-by:
-
Jani Nikula authored
Add documentation for the DRM_MODE_TV_MODE_MAX enumerator to fix the kernel-doc warning: include/drm/drm_connector.h:204: warning: Enum value 'DRM_MODE_TV_MODE_MAX' not described in enum 'drm_connector_tv_mode' Signed-off-by:
Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20230504123444.1843795-1-jani.nikula@intel.com
-
- 08 May, 2023 3 commits
-
-
Brandon Pollack authored
added documentation to drm_dev_unregister clarifying that devres managed devices allocated with devm_drm_dev_alloc do not require calls to drm_dev_put. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Brandon Pollack <brpol@chromium.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230425080240.3582324-1-brpol@chromium.org
-
Thomas Zimmermann authored
Implement DRM fbdev helpers for reading and writing framebuffer memory with the respective fbdev functions. Removes duplicate code. v2: * rename fb_cfb_() to fb_io_() (Geert) Signed-off-by:
-
Thomas Zimmermann authored
Move the existing I/O read and write code for I/O memory into the new helpers fb_cfb_read() and fb_cfb_write(). Make them the default fp_ops. No functional changes. In the near term, the new functions will be useful to the DRM subsystem, which currently provides it's own implementation. It can then use the shared code. In the longer term, it might make sense to revise the I/O helper's default status and make them opt-in by the driver. Systems that don't use them would not contain the code any longer. v2: * add detailed commit message (Javier) * rename fb_cfb_() to fb_io_() (Geert) * add fixes that got lost while moving the code (Geert) Signed-off-by:
-
