- 30 Nov, 2020 1 commit
-
-
Tomi Valkeinen authored
When the SDI output was converted to DRM bridge, the atomic versions of enable and disable funcs were used. This was not intended, as that would require implementing other atomic funcs too. This leads to: WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 drm_atomic_helper_commit_modeset_enables+0x134/0x268 and display not working. Fix this by using the legacy enable/disable funcs. Fixes: 8bef8a6d ("drm/omap: sdi: Register a drm_bridge") Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by:
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com> Tested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: stable@vger.kernel.org # v5.7+ Link: https://patchwork.freedesktop.org/patch/msgid/20201127085241.848461-1-tomi.valkeinen@ti.com
-
- 29 Nov, 2020 2 commits
-
-
Sebastian Reichel authored
The probe routine acquires the reset GPIO using GPIOD_OUT_LOW. Directly afterwards it calls acx565akm_detect(), which sets the GPIO value to HIGH. If the bootloader initialized the GPIO to HIGH before the probe routine was called, there is only a very short time period of a few instructions where the reset signal is LOW. Exact time depends on compiler optimizations, kernel configuration and alignment of the stars, but I expect it to be always way less than 10us. There are no public datasheets for the panel, but acx565akm_power_on() has a comment with timings and reset period should be at least 10us. So this potentially brings the panel into a half-reset state. The result is, that panel may not work after boot and can get into a working state by re-enabling it (e.g. by blanking + unblanking), since that does a clean reset cycle. This bug has recently been hit by Ivaylo Dimitrov, but there are some older reports which are probably the same bug. At least Tony Lindgren, Peter Ujfalusi and Jarkko Nikula have experienced it in 2017 describing the blank/unblank procedure as possible workaround. Note, that the bug really goes back in time. It has originally been introduced in the predecessor of the omapfb driver in commit 3c45d05b ("OMAPDSS: acx565akm panel: handle gpios in panel driver") in 2012. That driver eventually got replaced by a newer one, which had the bug from the beginning in commit 84192742 ("OMAPDSS: Add Sony ACX565AKM panel driver") and still exists in fbdev world. That driver has later been copied to omapdrm and then was used as a basis for this driver. Last but not least the omapdrm specific driver has been removed in commit 45f16c82 ("drm/omap: displays: Remove unused panel drivers"). Reported-by:
Jarkko Nikula <jarkko.nikula@bitmer.com> Reported-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Reported-by:
Tony Lindgren <tony@atomide.com> Reported-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201127200429.129868-1-sebastian.reichel@collabora.com
-
Paul Kocialkowski authored
In the Rockchip DRM LVDS component driver, the endpoint id provided to drm_of_find_panel_or_bridge is grabbed from the endpoint's reg property. However, the property may be missing in the case of a single endpoint. Initialize the endpoint_id variable to 0 to avoid using an uninitialized variable in that case. Fixes: 34cc0aa2 ("drm/rockchip: Add support for Rockchip Soc LVDS") Signed-off-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201110200430.1713467-1-paul.kocialkowski@bootlin.com
-
- 26 Nov, 2020 4 commits
-
-
Christian König authored
This wasn't initialized for pre NV50 hardware. Signed-off-by:
Christian König <christian.koenig@amd.com> Reported-and-Tested-by:
Mark Hounschell <markh@compro.net> Reviewed-by:
Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/series/84298/
-
Daniel Abrecht authored
This will make sure applications which use the IN_FORMATS blob to figure out which modifiers they can use will pick up the linear modifier which is needed by mxsfb. Such applications will not work otherwise if an incompatible implicit modifier ends up being selected. Before commit ae1ed009 ("drm: mxsfb: Stop using DRM simple display pipeline helper"), the DRM simple display pipeline helper took care of this. Signed-off-by:
Daniel Abrecht <public@danielabrecht.ch> Fixes: ae1ed009 ("drm: mxsfb: Stop using DRM simple display pipeline helper") Reviewed-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Lucas Stach authored
The conversion away from the simple display pipeline helper missed to convert the prepare_fb plane callback, so no fences are attached to the atomic state, breaking synchronization with other devices. Fix this by plugging in the drm_gem_fb_prepare_fb helper function. Fixes: ae1ed009 ("drm: mxsfb: Stop using DRM simple display pipeline helper") Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Reviewed-by:
-
Matti Hamalainen authored
Commit 03e0d26f ("drm/nouveau: slowpath for pushbuf ioctl") included a logic-bug which results in the relocations not actually getting applied at all as the call to nouveau_gem_pushbuf_reloc_apply() is never reached. This causes a regression with graphical corruption, triggered when relocations need to be done (for example after a suspend/resume cycle.) Fix by setting *apply_relocs value only if there were more than 0 relocations. Additionally, the never reached code had a leftover u_free() call, which, after fixing the logic, now got called and resulted in a double-free. Fix by removing one u_free(), moving the other and adding check for errors. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Matti Hamalainen <ccr@tnsp.org> Fixes: 03e0d26f ("drm/nouveau: slowpath for pushbuf ioctl") References: https://gitlab.freedesktop.org/drm/nouveau/-/issues/11Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201120152338.1203257-1-ccr@tnsp.org
-
- 25 Nov, 2020 1 commit
-
-
Thomas Zimmermann authored
The gamma LUT has to be reloaded after changing the primary plane's color format. This used to be done implicitly by the CRTC atomic_enable() helper after updating the primary plane. With the recent reordering of the steps, the primary plane's setup was moved last and invalidated the gamma LUT. Fix this by setting the LUT from within atomic_flush(). Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
- 23 Nov, 2020 2 commits
-
-
Maxime Ripard authored
The current HVS muxing code will consider the CRTCs in a given state to setup their muxing in the HVS, and disable the other CRTCs muxes. However, it's valid to only update a single CRTC with a state, and in this situation we would mux out a CRTC that was enabled but left untouched by the new state. Fix this by setting a flag on the CRTC state when the muxing has been changed, and only change the muxing configuration when that flag is there. Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Tested-by:
Hoegeun Kwon <hoegeun.kwon@samsung.com> Reviewed-by:
-
Maxime Ripard authored
If a CRTC is enabled but not active, and that we're then doing a page flip on another CRTC, drm_atomic_get_crtc_state will bring the first CRTC state into the global state, and will make us wait for its vblank as well, even though that might never occur. Instead of creating the list of the free channels each time atomic_check is called, and calling drm_atomic_get_crtc_state to retrieve the allocated channels, let's create a private state object in the main atomic state, and use it to store the available channels. Since vc4 has a semaphore (with a value of 1, so a lock) in its commit implementation to serialize all the commits, even the nonblocking ones, we are free from the use-after-free race if two subsequent commits are not ran in their submission order. Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically") Signed-off-by:
-
- 19 Nov, 2020 10 commits
-
-
Maxime Ripard authored
There's cross-talk on the RPi4 between the 2.4GHz channels used by the WiFi chip and some resolutions, most notably 1440p at 60Hz. In such a case, we can either reject entirely the mode, or lower slightly the pixel frequency to remove the overlap. Let's go for the latter. Signed-off-by:
-
Maxime Ripard authored
The RaspberryPi4 has both a WiFi chip and HDMI outputs capable of doing 4k. Unfortunately, the 1440p resolution at 60Hz has a TMDS rate on the HDMI cable right in the middle of the first Wifi channel. Add a property to our HDMI controller, that could be reused by other similar HDMI controllers, to allow the OS to take whatever measure is necessary to avoid that crosstalk. Signed-off-by:
Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201029134018.1948636-1-maxime@cerno.tech
-
Maxime Ripard authored
We've had a number of muxing corner-cases with specific ways to reproduce them, so let's document them to make sure they aren't lost and introduce regressions later on. Signed-off-by:
-
Maxime Ripard authored
The code that assigns HVS channels during atomic_check is starting to grow a bit big, let's move it into a separate function. Signed-off-by:
-
Maxime Ripard authored
The NUM_CHANNELS define has a pretty generic name and was right before the function using it. Let's move to something that makes the hardware-specific nature more obvious, and to a more appropriate place. Signed-off-by:
-
Maxime Ripard authored
NUM_OUTPUTS isn't used anymore, let's remove it. Signed-off-by:
-
Maxime Ripard authored
Even though it was pointed in the review by Daniel, and I thought to have fixed it while applying the patches, but it turns out I forgot to commit the fixes in the process. Properly fix it this time. Fixes: dcda7c28 ("drm/vc4: kms: Add functions to create the state objects") Signed-off-by:
-
Maxime Ripard authored
The FIFO between the pixelvalve and the HDMI controller runs at 2 pixels per clock cycle, and cannot deal with odd timings. Let's reject any mode with such timings. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201029122522.1917579-2-maxime@cerno.tech
-
Maxime Ripard authored
The HDMI controller cannot go above a certain pixel rate limit depending on the generations, but that limit is only enforced in mode_valid at the moment, which means that we won't advertise modes that exceed that limit, but the userspace is still free to try to setup a mode that would. Implement atomic_check to make sure we check it in that scenario too. Signed-off-by:
-
Maxime Ripard authored
Merge tag 'drm/sun4i-dma-fix-pull-request' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-misc-fixes Fix for drm/sun4i shared with arm-soc This patch is a preliminary fix that will conflict with subsequent work merged through arm-soc. Signed-off-by:
-
- 18 Nov, 2020 1 commit
-
-
Maxime Ripard authored
Commit e0d07278 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") introduced a regression in our code since the second backed to probe will now get -EINVAL back from dma_direct_set_offset and will prevent the entire DRM device from probing. Ignore -EINVAL as a temporary measure to get it back working, before removing that call entirely. Fixes: e0d07278 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Acked-by:
-
- 17 Nov, 2020 1 commit
-
-
Xiongfeng Wang authored
Fix to return a negative error code from the error handling case instead of 0 in function sun8i_dw_hdmi_bind(). Fixes: b7c7436a ("drm/sun4i: Implement A83T HDMI driver") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
-
- 12 Nov, 2020 1 commit
-
-
Jonathan Liu authored
It has been observed that resetting force in the detect function can result in the PHY being powered down in response to hot-plug detect being asserted, even when the HDMI connector is forced on. Enabling debug messages and adding a call to dump_stack() in dw_hdmi_phy_power_off() shows the following in dmesg: [ 160.637413] dwhdmi-rockchip ff940000.hdmi: EVENT=plugin [ 160.637433] dwhdmi-rockchip ff940000.hdmi: PHY powered down in 0 iterations Call trace: dw_hdmi_phy_power_off dw_hdmi_phy_disable dw_hdmi_update_power dw_hdmi_detect dw_hdmi_connector_detect drm_helper_probe_detect_ctx drm_helper_hpd_irq_event dw_hdmi_irq irq_thread_fn irq_thread kthread ret_from_fork Fixes: 381f05a7 ("drm: bridge/dw_hdmi: add connector mode forcing") Signed-off-by:
Jonathan Liu <net147@gmail.com> Reviewed-by:
-
- 10 Nov, 2020 1 commit
-
-
Linus Walleij authored
Since we now turn off the EPOD regulator to reset the hardware, we need to balance the regulators after that point. If registering the master fails we only need to disable one regulator. Fix this by open-coding this leg of the error path. Fixes: c4842d4d ("drm/mcde: Fix display pipeline restart") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
-
- 09 Nov, 2020 2 commits
-
-
Thomas Zimmermann authored
The gma500 driver expects 3 pipelines in several it's IRQ functions. Accessing struct drm_device.vblank[], this fails with devices that only have 2 pipelines. An example KASAN report is shown below. [ 62.267688] ================================================================== [ 62.268856] BUG: KASAN: slab-out-of-bounds in psb_irq_postinstall+0x250/0x3c0 [gma500_gfx] [ 62.269450] Read of size 1 at addr ffff8880012bc6d0 by task systemd-udevd/285 [ 62.269949] [ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: G E 5.10.0-rc1-1-default+ #572 [ 62.270807] Hardware name: /DN2800MT, BIOS MTCDT10N.86A.0164.2012.1213.1024 12/13/2012 [ 62.271366] Call Trace: [ 62.271705] dump_stack+0xae/0xe5 [ 62.272180] print_address_description.constprop.0+0x17/0xf0 [ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx] [ 62.273474] __kasan_report.cold+0x20/0x38 [ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx] [ 62.274460] kasan_report+0x3a/0x50 [ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx] [ 62.275380] drm_irq_install+0x131/0x1f0 <...> [ 62.300751] Allocated by task 285: [ 62.301223] kasan_save_stack+0x1b/0x40 [ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0 [ 62.302293] drmm_kmalloc+0x55/0x100 [ 62.302773] drm_vblank_init+0x77/0x210 Resolve the issue by only handling vblank entries up to the number of CRTCs. I'm adding a Fixes tag for reference, although the bug has been present since the driver's initial commit. Signed-off-by:
-
Olaf Hering authored
hvfb_getmem uses vzalloc, therefore vmalloc.h should be included. Fixes commit d21987d7 ("video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver") Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
-
- 08 Nov, 2020 1 commit
-
-
Nishanth Menon authored
With the integration of chip-id detection scheme in kernel[1], there is no specific need to maintain multitudes of SoC specific config options, discussed as per [2], we have deprecated the usage in other places for v5.10-rc1. Fix the missing user so that we can clean up the configs in v5.11. [1] drivers/soc/ti/k3-socinfo.c commit 907a2b7e ("soc: ti: add k3 platforms chipid module driver") [2] https://lore.kernel.org/linux-arm-kernel/20200908112534.t5bgrjf7y3a6l2ss@akan/ Fixes: afba7e6c ("drm: bridge: cdns-mhdp8546: Add TI J721E wrapper") Cc: Swapnil Jakhade <sjakhade@cadence.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Yuti Amonkar <yamonkar@cadence.com> Cc: Jyri Sarha <jsarha@ti.com> Signed-off-by:
Nishanth Menon <nm@ti.com> Reviewed-by:
-
- 03 Nov, 2020 4 commits
-
-
Lee Jones authored
Commit 6735b463 ("Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts") introduced the following error when building rpc_defconfig (only this build appears to be affected): `acorndata_8x8' referenced in section `.text' of arch/arm/boot/compressed/ll_char_wr.o: defined in discarded section `.data' of arch/arm/boot/compressed/font.o `acorndata_8x8' referenced in section `.data.rel.ro' of arch/arm/boot/compressed/font.o: defined in discarded section `.data' of arch/arm/boot/compressed/font.o make[3]: *** [/scratch/linux/arch/arm/boot/compressed/Makefile:191: arch/arm/boot/compressed/vmlinux] Error 1 make[2]: *** [/scratch/linux/arch/arm/boot/Makefile:61: arch/arm/boot/compressed/vmlinux] Error 2 make[1]: *** [/scratch/linux/arch/arm/Makefile:317: zImage] Error 2 The .data section is discarded at link time. Reinstating acorndata_8x8 as const ensures it is still available after linking. Do the same for the other 12 built-in fonts as well, for consistency purposes. Cc: <stable@vger.kernel.org> Cc: Russell King <linux@armlinux.org.uk> Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Fixes: 6735b463 ("Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts") Signed-off-by:
Lee Jones <lee.jones@linaro.org> Co-developed-by:
Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by:
-
Maxime Ripard authored
The commit dcda7c28 ("drm/vc4: kms: Add functions to create the state objects") removed the last users of the vc4 variable, but didn't remove that variable resulting in a warning. Fixes: dcda7c28 ("drm/vc4: kms: Add functions to create the state objects") Reported-by:
-
Steven Price authored
When unloading the call to pm_runtime_put_sync_suspend() will attempt to turn the GPU cores off, however panfrost_device_fini() will have turned the clocks off. This leads to the hardware locking up. Instead don't call pm_runtime_put_sync_suspend() and instead simply mark the device as suspended using pm_runtime_set_suspended(). And also include this on the error path in panfrost_probe(). Fixes: aebe8c22 ("drm/panfrost: Fix possible suspend in panfrost_remove") Signed-off-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201030145833.29006-1-steven.price@arm.com
-
Boris Brezillon authored
panfrost_ioctl_madvise() and panfrost_gem_purge() acquire the mappings and shmem locks in different orders, thus leading to a potential the mappings lock first. Fixes: bdefca2d ("drm/panfrost: Add the panfrost_gem_mapping concept") Cc: <stable@vger.kernel.org> Cc: Christian Hewitt <christianshewitt@gmail.com> Reported-by:
Christian Hewitt <christianshewitt@gmail.com> Signed-off-by:
-
- 02 Nov, 2020 6 commits
-
-
Maxime Ripard authored
In order to make the vc4_kms_load code and error path a bit easier to read and extend, add functions to create state objects, and use managed actions to cleanup if needed. Signed-off-by:
-
Maxime Ripard authored
We can simplify a bit the bind code, its error path and unbind by using the managed devm_drm_dev_alloc function. Acked-by:
-
Maxime Ripard authored
We have a helper to retrieve the vc4_dev structure from the drm_device one when needed, so let's use it consistently. Acked-by:
-
Maxime Ripard authored
The job queue needs to be cleaned up using vc4_gem_destroy, but it's not used consistently (vc4_drv's bind calls it in its error path, but doesn't in unbind), and we can make that automatic through a managed action. Let's remove the requirement to call vc4_gem_destroy. Fixes: d5b1a78a ("drm/vc4: Add support for drawing 3D frames.") Acked-by:
-
Maxime Ripard authored
Using drmm_mode_config_init instead of drm_mode_config_init allows us to cleanup a bit the error path. Signed-off-by:
-
Maxime Ripard authored
The BO cache needs to be cleaned up using vc4_bo_cache_destroy, but it's not used consistently (vc4_drv's bind calls it in its error path, but doesn't in unbind), and we can make that automatic through a managed action. Let's remove the requirement to call vc4_bo_cache_destroy. Fixes: c826a6e1 ("drm/vc4: Add a BO cache.") Acked-by:
-
- 01 Nov, 2020 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fixes from Thomas Gleixner: "Three fixes all related to #DB: - Handle the BTF bit correctly so it doesn't get lost due to a kernel #DB - Only clear and set the virtual DR6 value used by ptrace on user space triggered #DB. A kernel #DB must leave it alone to ensure data consistency for ptrace. - Make the bitmasking of the virtual DR6 storage correct so it does not lose DR_STEP" * tag 'x86-urgent-2020-11-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/debug: Fix DR_STEP vs ptrace_get_debugreg(6) x86/debug: Only clear/set ->virtual_dr6 for userspace #DB x86/debug: Fix BTF handling -
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Thomas Gleixner: "A few fixes for timers/timekeeping: - Prevent undefined behaviour in the timespec64_to_ns() conversion which is used for converting user supplied time input to nanoseconds. It lacked overflow protection. - Mark sched_clock_read_begin/retry() to prevent recursion in the tracer - Remove unused debug functions in the hrtimer and timerlist code" * tag 'timers-urgent-2020-11-01' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: time: Prevent undefined behaviour in timespec64_to_ns() timers: Remove unused inline funtion debug_timer_free() hrtimer: Remove unused inline function debug_hrtimer_free() time/sched_clock: Mark sched_clock_read_begin/retry() as notrace
-
