- 04 Nov, 2021 14 commits
-
-
Xin Ji authored
The basic anx7625 driver only support MIPI DSI rx signal input. This patch add MIPI DPI rx input configuration support, after apply this patch, the driver can support DSI rx or DPI rx by adding 'bus-type' in DT. Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
-
Xin Ji authored
At some time, the original code may return non zero value, force return 0 if operation finished. Reviewed-by:
-
Xin Ji authored
Add 'bus-type' and 'data-lanes' define for port0. Add DP tx lane0, lane1 swing register setting array, and audio enable flag. The device which cannot pass DP tx PHY CTS caused by long PCB trace or embedded MUX, adjusting ANX7625 PHY parameters can pass the CTS test. The adjusting type include Pre-emphasis, Vp-p, Rterm(Resistor Termination) and Rsel(Driven Strength). Each lane has maximum 20 registers for these settings. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Maxime Ripard authored
Depending on a given HVS output (HVS to PixelValves) and input (planes attached to a channel) load, the HVS needs for the core clock to be raised above its boot time default. Failing to do so will result in a vblank timeout and a stalled display pipeline. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-11-maxime@cerno.tech
-
Maxime Ripard authored
If we have a state already and disconnect/reconnect the display, the SCDC messages won't be sent again since we didn't go through a disable / enable cycle. In order to fix this, let's call the vc4_hdmi_enable_scrambling function in the detect callback if there is a mode and it needs the scrambler to be enabled. Fixes: c85695a2 ("drm/vc4: hdmi: Enable the scrambler") Signed-off-by:
-
Maxime Ripard authored
Now that we have the infrastructure in place, we can raise the maximum pixel rate we can reach for HDMI0 on the BCM2711. HDMI1 is left untouched since its pixelvalve has a smaller FIFO and would need a clock faster than what we can provide to support the same modes. Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Maxime Ripard authored
The load tracker was initially designed to report and warn about a load too high for the HVS. To do so, it computes for each plane the impact it's going to have on the HVS, and will warn (if it's enabled) if we go over what the hardware can process. While the limits being used are a bit irrelevant to the BCM2711, the algorithm to compute the HVS load will be one component used in order to compute the core clock rate on the BCM2711. Let's remove the hooks to prevent the load tracker to do its computation, but since we don't have the same limits, don't check them against them, and prevent the debugfs file to enable it from being created. Signed-off-by:
-
Maxime Ripard authored
The encoder retrieval code has been a source of bugs and glitches in the past and the crtc <-> encoder association been wrong in a number of different ways. Add some logging to quickly spot issues if they occur. Signed-off-by:
-
Maxime Ripard authored
It turns out the encoder retrieval code, in addition to being unnecessarily complicated, has a bug when only the planes and crtcs are affected by a given atomic commit. Indeed, in such a case, either drm_atomic_get_old_connector_state or drm_atomic_get_new_connector_state will return NULL and thus our encoder retrieval code will not match on anything. We can however simplify the code by using drm_for_each_encoder_mask, the drm_crtc_state storing the encoders a given CRTC is connected to directly and without relying on any other state. Signed-off-by:
-
Maxime Ripard authored
vc4_crtc_config_pv() retrieves the encoder again, even though its only caller, vc4_crtc_atomic_enable(), already did. Pass the encoder pointer as an argument instead of going through all the connectors to retrieve it again. Signed-off-by:
-
Maxime Ripard authored
We'll need that function in vc4_kms to compute the core clock rate requirements. Signed-off-by:
-
Maxime Ripard authored
Prior to commit 6800234c ("drm/vc4: hdmi: Convert to gpiod"), in the detect hook, if we had an HPD GPIO we would only rely on it and return whatever state it was in. However, that commit changed that by mistake to only consider the case where we have a GPIO and it returns a logical high, and would fall back to the other methods otherwise. Since we can read the EDIDs when the HPD signal is low on some displays, we changed the detection status from disconnected to connected, and we would ignore an HPD pulse. Fixes: 6800234c ("drm/vc4: hdmi: Convert to gpiod") Signed-off-by:
-
Maxime Ripard authored
Commit 9d44abbb ("drm/vc4: Fall back to using an EDID probe in the absence of a GPIO.") added some code to read the EDID through DDC in the HDMI driver detect hook since the Pi3 had no HPD GPIO back then. However, commit b1b8f45b ("ARM: dts: bcm2837: Add missing GPIOs of Expander") changed that a couple of years later. This causes an issue though since some TV (like the LG 55C8) when it comes out of standy will deassert the HPD line, but the EDID will remain readable. It causes an issues nn platforms without an HPD GPIO, like the Pi4, where the DDC probing will be our primary mean to detect a display, and thus we will never detect the HPD pulse. This was fine before since the pulse was small enough that we would never detect it, and we also didn't have anything (like the scrambler) that needed to be set up in the display. However, now that we have both, the display during the HPD pulse will clear its scrambler status, and since we won't detect the disconnect/reconnect cycle we will never enable the scrambler back. As our main reason for that DDC probing is gone, let's just remove it. Signed-off-by:
-
Christian König authored
Don't touch the exclusive fence manually here, but rather use the general dma_resv function. We did that for better hw reset handling but this doesn't necessary work correctly. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Alex Deuche <alexander.deucher@amd.com> Acked-by:
Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211028132630.2330-6-christian.koenig@amd.com
-
- 03 Nov, 2021 1 commit
-
-
Christian König authored
Just grab all fences in one go. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211028132630.2330-3-christian.koenig@amd.com
-
- 02 Nov, 2021 6 commits
-
-
Simon Ser authored
When link-status changes, send a hotplug uevent which contains the connector ID. That way, user-space can more easily figure out that only this connector has been updated. Changes in v4: avoid sending two uevents (Ville) Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-7-contact@emersion.fr
-
Simon Ser authored
If an hotplug event only updates a single connector, use drm_kms_helper_connector_hotplug_event instead of drm_kms_helper_hotplug_event. Changes in v4: - Simplify loop logic (Ville, Sam) - Update drm_connector_helper_hpd_irq_event (Maxime) Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
-
Simon Ser authored
When updating a single connector, use drm_kms_helper_connector_hotplug_event instead of drm_kms_helper_hotplug_event. Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
-
Simon Ser authored
In drm_connector_register, use drm_sysfs_connector_hotplug_event instead of drm_sysfs_hotplug_event, because the hotplug event only updates a single connector. Signed-off-by:
-
Simon Ser authored
This function is the same as drm_kms_helper_hotplug_event, but takes a connector instead of a device. Signed-off-by:
-
Simon Ser authored
This function sends a hotplug uevent with a CONNECTOR property. Signed-off-by:
-
- 01 Nov, 2021 1 commit
-
-
Andrey Grodzovsky authored
Probelm: Singlaning one sched fence from within another's sched fence singal callback generates lockdep splat because the both have same lockdep class of their fence->lock Fix: Fix bellow stack by rescheduling to irq work of signaling and killing of jobs that left when entity is killed. [11176.741181] dump_stack+0x10/0x12 [11176.741186] __lock_acquire.cold+0x208/0x2df [11176.741197] lock_acquire+0xc6/0x2d0 [11176.741204] ? dma_fence_signal+0x28/0x80 [11176.741212] _raw_spin_lock_irqsave+0x4d/0x70 [11176.741219] ? dma_fence_signal+0x28/0x80 [11176.741225] dma_fence_signal+0x28/0x80 [11176.741230] drm_sched_fence_finished+0x12/0x20 [gpu_sched] [11176.741240] drm_sched_entity_kill_jobs_cb+0x1c/0x50 [gpu_sched] [11176.741248] dma_fence_signal_timestamp_locked+0xac/0x1a0 [11176.741254] dma_fence_signal+0x3b/0x80 [11176.741260] drm_sched_fence_finished+0x12/0x20 [gpu_sched] [11176.741268] drm_sched_job_done.isra.0+0x7f/0x1a0 [gpu_sched] [11176.741277] drm_sched_job_done_cb+0x12/0x20 [gpu_sched] [11176.741284] dma_fence_signal_timestamp_locked+0xac/0x1a0 [11176.741290] dma_fence_signal+0x3b/0x80 [11176.741296] amdgpu_fence_process+0xd1/0x140 [amdgpu] [11176.741504] sdma_v4_0_process_trap_irq+0x8c/0xb0 [amdgpu] [11176.741731] amdgpu_irq_dispatch+0xce/0x250 [amdgpu] [11176.741954] amdgpu_ih_process+0x81/0x100 [amdgpu] [11176.742174] amdgpu_irq_handler+0x26/0xa0 [amdgpu] [11176.742393] __handle_irq_event_percpu+0x4f/0x2c0 [11176.742402] handle_irq_event_percpu+0x33/0x80 [11176.742408] handle_irq_event+0x39/0x60 [11176.742414] handle_edge_irq+0x93/0x1d0 [11176.742419] __common_interrupt+0x50/0xe0 [11176.742426] common_interrupt+0x80/0x90 Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Suggested-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Suggested-by:
-
- 30 Oct, 2021 1 commit
-
-
Paul Cercueil authored
Commit 1bdb542d ("drm/ingenic: Simplify code by using hwdescs array") caused the dma_hwdesc_phys_f{0,1} variables to be used while uninitialized in a mmio register write, which most certainly broke the ingenic-drm driver. However, the very same patchset also submitted commit 60554662 ("drm/ingenic: Upload palette before frame"), which restored a correct behaviour by doing the register writes in a different place in the code. What's left of this, is just to remove the bogus register writes in the probe function. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reported-by:
kernel test robot <lkp@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211030100032.42066-1-paul@crapouillou.netAcked-by:
-
- 29 Oct, 2021 11 commits
-
-
Paul Cercueil authored
Attach a top-level bridge to each encoder, which will be used for negociating the bus format and flags. All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR. Signed-off-by:
Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
Paul Cercueil authored
When using C8 color mode, make sure that the palette is always uploaded before a frame; otherwise the very first frame will have wrong colors. Do that by changing the link order of the DMA descriptors. v3: Fix ingenic_drm_get_new_priv_state() called instead of ingenic_drm_get_priv_state() Signed-off-by: -
Paul Cercueil authored
Setting the DMA descriptor chain register in the probe function has been fine until now, because we only ever had one descriptor per foreground. As the driver will soon have real descriptor chains, and the DMA descriptor chain register updates itself to point to the current descriptor being processed, this register needs to be reset after a full modeset to point to the first descriptor of the chain. Signed-off-by:
-
Paul Cercueil authored
The IPU scaling information is computed in the plane's ".atomic_check" callback, and used in the ".atomic_update" callback. As such, it is state-specific, and should be moved to a private state structure. Signed-off-by:
-
Paul Cercueil authored
Until now, the ingenic-drm as well as the ingenic-ipu drivers used to put state-specific information in their respective private structure. Add boilerplate code to support private objects in the two drivers, so that state-specific information can be put in the state-specific private structure. Signed-off-by:
-
Paul Cercueil authored
Instead of having one 'hwdesc' variable for the plane #0, one for the plane #1 and one for the palette, use a 'hwdesc[3]' array, where the DMA hardware descriptors are indexed by the plane's number. v2: dma_hwdesc_addr() extended to support palette hwdesc. The palette hwdesc is now hwdesc[3] to simplify things. Add ingenic_drm_configure_hwdesc*() functions to factorize code. Signed-off-by: -
Marcel Ziswiler authored
Today's -next fails building arm64 defconfig as follows: ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vunmap from namespace DMA_BUF, but does not import it. ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vmap from namespace DMA_BUF, but does not import it. Fix this by importing DMA_BUF namespace into drm_cma_helper.ko. Also fix the problem with drm_shmem_helper.ko. Reported-by:
Linux Kernel Functional Testing <lkft@linaro.org> Fixes: 4b2b5e14 ("drm: Move GEM memory managers into modules") Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
-
Christian König authored
Makes the handling a bit more complex, but avoids the use of dma_resv_get_excl_unlocked(). Signed-off-by:
-
Colin Ian King authored
The left shift of unsigned int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where value is 32 or more this can lead to an overflow (value can be in range 0..MAX_CAPSET_ID (63). Fix this by shifting the value 1ULL instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: 4fb530e5 ("drm/virtio: implement context init: support init ioctl") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210930102748.16922-1-colin.king@canonical.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Colin Ian King authored
The left shift of unsigned int 32 bit integer constant 1 is evaluated using 32 bit arithmetic and then assigned to a signed 64 bit integer. In the case where i is 32 or more this can lead to an overflow. Fix this by shifting the value 1ULL instead. Addresses-Coverity: ("Uninitentional integer overflow") Fixes: 8d6b006e ("drm/virtio: implement context init: handle VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK") Signed-off-by: -
Chia-I Wu authored
Add Gurchetan Singh and me as reviewers for virtio-gpu. Signed-off-by:
Chia-I Wu <olvaffe@gmail.com> Acked-by:
Gurchetan Singh <gurchetansingh@chromium.org> Cc: David Airlie <airlied@linux.ie> Cc: Gerd Hoffmann <kraxel@redhat.com> Acked-by:
Daniel Stone <daniels@collabora.com> Link: http://patchwork.freedesktop.org/patch/msgid/20211028213446.955338-1-olvaffe@gmail.comSigned-off-by:
-
- 28 Oct, 2021 2 commits
-
-
Bjorn Andersson authored
When built without CONFIG_PWM there are no references to ti_sn65dsi86_read_u16(), avoid the W=1 build warning by marking the function as __maybe_unused. __maybe_unused is used insted of a #ifdef guard as it looks slighly cleaner and it avoids issues if in the future other permutations of the config options would use the function. Reported-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
-
Guangming Cao authored
In this patch(https://patchwork.freedesktop.org/patch/310349), it add a new IOCTL to support dma-buf user to set debug name. But it also added a limitation of this IOCTL, it needs the attachments of dmabuf should be empty, otherwise it will fail. For the original series, the idea was that allowing name change mid-use could confuse the users about the dma-buf. However, the rest of the series also makes sure each dma-buf have a unique inode(https://patchwork.freedesktop.org/patch/310387/), and any accounting should probably use that, without relying on the name as much. So, removing this restriction will let dma-buf userspace users to use it more comfortably and without any side effect. Signed-off-by:
Guangming Cao <Guangming.Cao@mediatek.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211014102551.54983-1-guangming.cao@mediatek.comReviewed-by:
-
- 27 Oct, 2021 4 commits
-
-
Anitha Chrisanthus authored
Enable support for fbcon (framebuffer console). v2: added missing static clk_enable v3: removed module parameter, use fbdev_emulation instead. Use preferred depth of 24 for color depth. (Thomas Z.) Signed-off-by:
Anitha Chrisanthus <anitha.chrisanthus@intel.com> Acked-by:
-
Rob Clark authored
Switch to the documented order dsi-host vs bridge probe. Tested-by:
Amit Pundir <amit.pundir@linaro.org> Tested-by:
Caleb Connolly <caleb.connolly@linaro.org> Tested-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Rob Clark <robdclark@chromium.org> Signed-off-by:
-
Maxime Ripard authored
Without proper care and an agreement between how DSI hosts and devices drivers register their MIPI-DSI entities and potential components, we can end up in a situation where the drivers can never probe. Most drivers were taking evasive maneuvers to try to workaround this, but not all of them were following the same conventions, resulting in various incompatibilities between DSI hosts and devices. Now that we have a sequence agreed upon and documented, let's convert kirin to it. Acked-by:
-
Maxime Ripard authored
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Acked-by:
-
