- 09 Mar, 2022 13 commits
-
-
Douglas Anderson authored
I've spent quite a bit of time poking at this driver and it's used on several Chromebooks I'm involved with. I'd like to get notified about patches. Add myself as a reviewer. It's expected that changes will still be landed through drm-misc as they always have been. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220308110615.2.I4485769d5b25a8096508e839b8fea12ce7b836d3@changeid
-
Douglas Anderson authored
The bindings for bridge chips should also get the same maintainers entry so the right people get notified about bindings changes. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Neil Armstrong <narmstrong@baylibre.com> Acked-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
José Expósito <jose.exposito89@gmail.com> Reviewed-by:
Maxime Ripard <maxime@cerno.tech> Signed-off-by:
-
Chen-Yu Tsai authored
Currently the ssd130x driver only sets the segment remap setting when the device tree requests it; it however does not clear the setting if it is not requested. This leads to the setting incorrectly persisting if the hardware is always on and has no reset GPIO wired. This might happen when a developer is trying to find the correct settings for an unknown module, and cause the developer to get confused because the settings from the device tree are not consistently applied. Make the driver apply the segment remap setting consistently, setting the value correctly based on the device tree setting. This also makes this setting's behavior consistent with the other settings, which are always applied. Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Chen-Yu Tsai authored
The SSD130x's command to toggle COM scan direction uses bit 3 and only bit 3 to set the direction of the scanout. The driver has an incorrect GENMASK(3, 2), causing the setting to be set on bit 2, rendering it ineffective. Fix the mask to only bit 3, so that the requested setting is applied correctly. Fixes: a61732e8 ("drm: Add driver for Solomon SSD130x OLED displays") Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Tom Rix authored
Clang static analysis reports this issue anx7625.c:876:13: warning: The left operand of '&' is a garbage value if (!(bcap & 0xOA01)) { ~~~~ ^ bcap is only set by a successful call to anx7625_aux_trans(). So check. Fixes: cd1637c7 ("drm/bridge: anx7625: add HDCP support") Signed-off-by:Tom Rix <trix@redhat.com> Fixes: adca62ec ("drm/bridge: anx7625: Support reading edid through aux channel") Signed-off-by:
-
Rex-BC Chen authored
This device requires the packets on lanes aligned at the end to fix screen shift or scroll. Signed-off-by:
Jitao Shi <jitao.shi@mediatek.com> Signed-off-by:
Rex-BC Chen <rex-bc.chen@mediatek.com> Acked-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Xin Ji <xji@analogixsemi.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
-
Rex-BC Chen authored
Some DSI RX devices (for example, anx7625) require last alignment of packets on all lanes after each row of data is sent. Otherwise, there will be some issues of shift or scroll for screen. Take horizontal_sync_active_byte for a example, we roundup the HSA packet data to lane number, and the subtraction of 2 is the packet data value added by the roundup operation, making the long packets are integer multiples of lane number. This value (2) varies with the lane number, and that is the reason we do this operation when the lane number is 4. In the previous operation of function "mtk_dsi_config_vdo_timing", the length of HSA and HFP data packets has been adjusted to an integration multiple of lane number. Since the number of RGB data packets cannot be guaranteed to be an integer multiple of lane number, we modify the data packet length of HBP so that the number of HBP + RGB is equal to the lane number. So after sending a line of data (HSA + HBP + RGB + HFP), the data lanes are aligned. Signed-off-by:
Xinlei Lee <xinlei.lee@mediatek.com> Reviewed-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by:
-
Rex-BC Chen authored
Since a HS transmission is composed of an arbitrary number of bytes that may not be an integer multiple of lanes, some lanes may run out of data before others. (Defined in 6.1.3 of mipi_DSI_specification_v.01-02-00) However, for some DSI RX devices (for example, anx7625), there is a limitation that packet number should be the same on all DSI lanes. In other words, they need to end a HS at the same time. Because this limitation is for some specific DSI RX devices, it is more reasonable to put the enable control in these DSI RX drivers. If DSI TX driver knows the information, they can adjust the setting for this situation. Signed-off-by:
-
Noralf Trønnes authored
The datasheet lists the minimum Serial clock cycle (Write) as 66ns which is 15MHz. Mostly it can do much better than that and is in fact often run at 32MHz. With a clever driver that runs configuration commands at a low speed and only the pixel data at the maximum speed the configuration can't be messed up by transfer errors and the speed is only limited by the amount of pixel glitches that one is able to tolerate. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Acked-by:
Rob Herring <robh@kernel.org> Acked-by:
David Lechner <david@lechnology.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124150757.17929-4-noralf@tronnes.org
-
Noralf Trønnes authored
There are other ways than using a gpio to reset the controller so make this property optional. Signed-off-by:
-
Noralf Trønnes authored
The backlight property was lost during conversion to yaml in commit abdd9e37 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema"). Put it back. Fixes: abdd9e37 ("dt-bindings: display: sitronix,st7735r: Convert to DT schema") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
-
- 08 Mar, 2022 11 commits
-
-
Matthew Auld authored
Make sure we pull in the kernel-doc for this. Reported-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Arunpravin <Arunpravin.PaneerSelvam@amd.com> Cc: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220208151228.344997-1-matthew.auld@intel.comSigned-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
-
José Expósito authored
The function "drm_of_find_panel_or_bridge" has been deprecated in favor of "devm_drm_of_get_bridge". Switch to the new function and reduce boilerplate. Signed-off-by:
-
Maxime Ripard authored
The komeda KMS driver will call drm_plane_create_color_properties() with a default encoding and range values of BT601 and Limited Range, respectively. Since the initial value wasn't carried over in the state, the driver had to set it again in komeda_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Cc: Brian Starkey <brian.starkey@arm.com> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220221095918.18763-20-maxime@cerno.tech
-
Maxime Ripard authored
The komeda KMS driver will call drm_plane_create_zpos_property() with an init value of the plane index. Since the initial value wasn't carried over in the state, the driver had to set it again in komeda_plane_reset(). However, the helpers have been adjusted to set it properly at reset, so this is not needed anymore. Cc: Brian Starkey <brian.starkey@arm.com> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by:
-
Maxime Ripard authored
komeda_plane_reset() does the state initialisation by copying a lot of the code found in the __drm_atomic_helper_plane_reset(). Let's switch to that helper and reduce the boilerplate. Cc: Brian Starkey <brian.starkey@arm.com> Cc: "James (Qian) Wang" <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Cc: Mihail Atanassov <mihail.atanassov@arm.com> Signed-off-by:
-
Wan Jiabing authored
Fix the following coccicheck warning: ./drivers/gpu/drm/omapdrm/omap_overlay.c:89:22-25: ERROR: r_ovl is NULL but dereferenced. Here should be ovl->idx rather than r_ovl->idx. Fixes: e02b5cc9 ("drm/omap: Add a 'right overlay' to plane state") Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220307095612.409090-1-wanjiabing@vivo.com
-
- 07 Mar, 2022 2 commits
-
-
Dan Carpenter authored
Set the error code to -ENOMEM if drm_random_order() fails. Fixes: e6ff5ef8 ("drm/selftests: add drm buddy smoke testcase") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Arunpravin <Arunpravin.PaneerSelvam@amd.com> Signed-off-by:
-
Geert Uytterhoeven authored
It does not make sense to have a comma after a sentinel, as any new elements must be added before the sentinel. Signed-off-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
- 04 Mar, 2022 5 commits
-
-
Michal Suchanek authored
efifb is the only user of efifb_setup_from_dmi which is provided by sysfb which is selected by efifb. That makes the stub redundant. Signed-off-by:
Michal Suchanek <msuchanek@suse.de> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/7416c439d68e9e96068ea5c77e05c99c7df41750.1645822213.git.msuchanek@suse.de
-
Michal Suchanek authored
Since switch to simplefb/simpledrm VESA graphic mode selection with vga= kernel parameter is no longer available with legacy BIOS. The x86 realmode boot code enables the VESA graphic modes when option FB_BOOT_VESA_SUPPORT is enabled. This option is selected by vesafb but not simplefb/simpledrm. To enable use of VESA modes with simplefb in legacy BIOS boot mode drop dependency of BOOT_VESA_SUPPORT on FB, also drop the FB_ prefix. Select the option from sysfb rather than the drivers that depend on it. The BOOT_VESA_SUPPORT is not specific to framebuffer but rather to x86 platform, move it from fbdev to x86 Kconfig. Fixes: e3263ab3 ("x86: provide platform-devices for boot-framebuffers") Signed-off-by:
Borislav Petkov <bp@suse.de> Signed-off-by:
-
Michal Suchanek authored
efifb and vesafb requires sysfb implicitly but this is not stated in Kconfig. Add the dependency. With that all drivers that require sysfb depend on it so it can default to disabled. Signed-off-by:
-
Nikita Yushchenko authored
Hotplug events reported by bridge drivers over drm_bridge_hpd_notify() get ignored unless somebody calls drm_bridge_hpd_enable(). When the connector for the bridge is bridge_connector, such a call is done from drm_bridge_connector_enable_hpd(). However drm_bridge_connector_enable_hpd() is never called on init paths, documentation suggests that it is intended for suspend/resume paths. In result, once encoders are switched to bridge_connector, bridge-detected HPD stops working. This patch adds a call to that API on init path. This fixes HDMI HPD with rcar-du + adv7513 case when adv7513 reports HPD events via interrupts. Fixes: c24110a8 ("drm: rcar-du: Use drm_bridge_connector_init() helper") Signed-off-by:
Nikita Yushchenko <nikita.yoush@cogentembedded.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
-
Arunpravin authored
pass the correct size value computed using the max_order. <log snip> [ 68.124177][ T1] UBSAN: shift-out-of-bounds in include/linux/log2.h:67:13 [ 68.125333][ T1] shift exponent 4294967295 is too large for 32-bit type 'long unsigned int' [ 68.126563][ T1] CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-rc2-00311-g39ec47bbfd5d #2 [ 68.127758][ T1] Call Trace: [ 68.128187][ T1] dump_stack_lvl (lib/dump_stack.c:108) [ 68.128793][ T1] dump_stack (lib/dump_stack.c:114) [ 68.129331][ T1] ubsan_epilogue (lib/ubsan.c:152) [ 68.129958][ T1] __ubsan_handle_shift_out_of_bounds.cold (arch/x86/include/asm/smap.h:85) [ 68.130791][ T1] ? drm_block_alloc+0x28/0x80 [ 68.131582][ T1] ? rcu_read_lock_sched_held (kernel/rcu/update.c:125) [ 68.132215][ T1] ? kmem_cache_alloc (include/trace/events/kmem.h:54 mm/slab.c:3501) [ 68.132878][ T1] ? mark_free+0x2e/0x80 [ 68.133524][ T1] drm_buddy_init.cold (include/linux/log2.h:67 drivers/gpu/drm/drm_buddy.c:131) [ 68.134145][ T1] ? test_drm_cmdline_init (drivers/gpu/drm/selftests/test-drm_buddy.c:87) [ 68.134770][ T1] igt_buddy_alloc_limit (drivers/gpu/drm/selftests/test-drm_buddy.c:30) [ 68.135472][ T1] ? vprintk_default (kernel/printk/printk.c:2257) [ 68.136057][ T1] ? test_drm_cmdline_init (drivers/gpu/drm/selftests/test-drm_buddy.c:87) [ 68.136812][ T1] test_drm_buddy_init (drivers/gpu/drm/selftests/drm_selftest.c:77 drivers/gpu/drm/selftests/test-drm_buddy.c:95) [ 68.137475][ T1] do_one_initcall (init/main.c:1300) [ 68.138111][ T1] ? parse_args (kernel/params.c:609 kernel/params.c:146 kernel/params.c:188) [ 68.138717][ T1] do_basic_setup (init/main.c:1372 init/main.c:1389 init/main.c:1408) [ 68.139366][ T1] kernel_init_freeable (init/main.c:1617) [ 68.140040][ T1] ? rest_init (init/main.c:1494) [ 68.140634][ T1] kernel_init (init/main.c:1504) [ 68.141155][ T1] ret_from_fork (arch/x86/entry/entry_32.S:772) [ 68.141607][ T1] ================================================================================ [ 68.146730][ T1] ------------[ cut here ]------------ [ 68.147460][ T1] kernel BUG at drivers/gpu/drm/drm_buddy.c:140! [ 68.148280][ T1] invalid opcode: 0000 [#1] [ 68.148895][ T1] CPU: 0 PID: 1 Comm: swapper Not tainted 5.17.0-rc2-00311-g39ec47bbfd5d #2 [ 68.149896][ T1] EIP: drm_buddy_init (drivers/gpu/drm/drm_buddy.c:140 (discriminator 1)) For more details: https://lists.01.org/hyperkitty/list/lkp@lists.01.org/thread/FDIF3HCILZNN5UQAZMOR7E3MQSMHHKWU/Signed-off-by:
kernel test robot <oliver.sang@intel.com> Acked-by:
-
- 03 Mar, 2022 2 commits
-
-
Guo Zhengkui authored
Fix following coccicheck warning: drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c:316:11-12: WARNING this kind of initialization is deprecated. `void *map = map` has the same form of uninitialized_var() macro. I remove the redundant assignement. It has been tested with gcc (Debian 8.3.0-6) 8.3.0. The patch which removed uninitialized_var() is: https://lore.kernel.org/all/20121028102007.GA7547@gmail.com/ And there is very few "/* GCC */" comments in the Linux kernel code now. Signed-off-by:
Guo Zhengkui <guozhengkui@vivo.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Colin Ian King authored
Pointer mode is being assigned a value that is never read, it is being re-assigned later with a new value. The initialization is redundant and can be removed. Cleans up clang scan build warning: drivers/gpu/drm/solomon/ssd130x.c:582:27: warning: Value stored to 'mode' during its initialization is never read [deadcode.DeadStores] Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Acked-by:
-
- 02 Mar, 2022 7 commits
-
-
Tommy Haung authored
Add AST2600 chip support and setting. Signed-off-by:
Tommy Haung <tommy_huang@aspeedtech.com> Reviewed-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Tommy Haung authored
Add interrupt clear register define for further chip support. Signed-off-by:
-
Thomas Zimmermann authored
Add a TODO item for optimizing blitting and format-conversion helpers in DRM and fbdev. There's always demand for faster graphics output. v4: * fix typos (Sam) Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220223193804.18636-6-tzimmermann@suse.de
-
Thomas Zimmermann authored
Improve the performance of cfb_imageblit() by manually unrolling the inner blitting loop and moving some invariants out. The compiler failed to do this automatically. This change keeps cfb_imageblit() in sync with sys_imagebit(). A microbenchmark measures the average number of CPU cycles for cfb_imageblit() after a stabilizing period of a few minutes (i7-4790, FullHD, simpledrm, kernel with debugging). cfb_imageblit(), new: 15724 cycles cfb_imageblit(): old: 30566 cycles In the optimized case, cfb_imageblit() is now ~2x faster than before. v3: * fix commit description (Pekka) Signed-off-by:
-
Thomas Zimmermann authored
Fix coding style. No functional changes. Signed-off-by:
-
Thomas Zimmermann authored
Improve the performance of sys_imageblit() by manually unrolling the inner blitting loop and moving some invariants out. The compiler failed to do this automatically. The resulting binary code was even slower than the cfb_imageblit() helper, which uses the same algorithm, but operates on I/O memory. A microbenchmark measures the average number of CPU cycles for sys_imageblit() after a stabilizing period of a few minutes (i7-4790, FullHD, simpledrm, kernel with debugging). The value for CFB is given as a reference. sys_imageblit(), new: 25934 cycles sys_imageblit(), old: 35944 cycles cfb_imageblit(): 30566 cycles In the optimized case, sys_imageblit() is now ~30% faster than before and ~20% faster than cfb_imageblit(). v2: * move switch out of inner loop (Gerd) * remove test for alignment of dst1 (Sam) Signed-off-by:
-
Thomas Zimmermann authored
Improve the performance of sys_fillrect() by using word-aligned 32/64-bit mov instructions. While the code tried to implement this, the compiler failed to create fast instructions. The resulting binary instructions were even slower than cfb_fillrect(), which uses the same algorithm, but operates on I/O memory. A microbenchmark measures the average number of CPU cycles for sys_fillrect() after a stabilizing period of a few minutes (i7-4790, FullHD, simpledrm, kernel with debugging). The value for CFB is given as a reference. sys_fillrect(), new: 26586 cycles sys_fillrect(), old: 166603 cycles cfb_fillrect(): 41012 cycles In the optimized case, sys_fillrect() is now ~6x faster than before and ~1.5x faster than the CFB implementation. Signed-off-by:
-
