- Nov 05, 2021
-
-
Maxime Ripard authored
Accessing the crtc->state pointer from outside the modesetting context is not allowed. We thus need to copy whatever we need from the KMS state to our structure in order to access it. In VC4, a number of users of that pointers have crept in over the years, and the previous commits removed them all but the HVS channel a CRTC has been assigned. Let's move this channel in struct vc4_crtc at atomic_begin() time, drop it from our private state structure, and remove our use of crtc->state from our vblank handler entirely. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Link: https://lore.kernel.org/r/20211025141113.702757-4-maxime@cerno.tech Fixes: 87ebcd42 ("drm/vc4: crtc: Assign output to channel automatically") Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
In some situation, we can end up being stuck on a non-blocking that went through properly. The situation that seems to trigger it reliably is to first start a non-blocking commit, and then right after, and before we had any vblank interrupt), start a blocking commit. This will lead to the first commit workqueue to be scheduled, setup the display, while the second commit is waiting for the first one to be completed. The vblank interrupt will then be raised, vc4_crtc_handle_vblank() will run and will compare the active dlist in the HVS channel to the one associated with the crtc->state. However, at that point, the second commit is waiting using drm_atomic_helper_wait_for_dependencies that occurs after drm_atomic_helper_swap_state has been called, so crtc->state points to the second commit state. vc4_crtc_handle_vblank() will compare the two dlist addresses and since they don't match will ignore the interrupt. The vblank event will never be reported, and the first and second commit will wait for the first commit completion until they timeout. The underlying reason is that it was never safe to do so. Indeed, accessing the ->state pointer access synchronization is based on ownership guarantees that can only occur within the functions and hooks defined as part of the KMS framework, and obviously the irq handler isn't one of them. The rework to move to generic helpers only uncovered the underlying issue. However, since the code path between drm_atomic_helper_wait_for_dependencies() and drm_atomic_helper_wait_for_vblanks() is serialised and we can't get two commits in that path at the same time, we can work around this issue by setting a variable associated to struct drm_crtc to the dlist we expect, and then using it from the vc4_crtc_handle_vblank() function. Since that state is shared with the modesetting path, we also need to introduce a spinlock to protect the code shared between the interrupt handler and the modesetting path, protecting only our new variable for now. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Link: https://lore.kernel.org/r/20211025141113.702757-3-maxime@cerno.tech Fixes: 56d1fe09 ("drm/vc4: Make pageflip completion handling more robust.") Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
Accessing the crtc->state pointer from outside the modesetting context is not allowed. We thus need to copy whatever we need from the KMS state to our structure in order to access it. In VC4, a number of users of that pointers have crept in over the years, the first one being whether or not the downstream controller of the pixelvalve is our writeback controller. Fortunately for us, Since commit 39fcb280 ("drm/vc4: txp: Turn the TXP into a CRTC of its own") this is no longer something that can change from one commit to the other and is hardcoded. Let's set this flag in struct vc4_crtc if we happen to be the TXP, and drop the flag from our private state structure. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Link: https://lore.kernel.org/r/20211025141113.702757-2-maxime@cerno.tech Fixes: 008095e0 ("drm/vc4: Add support for the transposer block") Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Maxime Ripard <maxime@cerno.tech>
-
- Nov 04, 2021
-
-
Brian Norris authored
Prior to commit 6c836d96 ("drm/rockchip: Use the helpers for PSR"), "PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor started using the blocking variant, for a variety of reasons -- quoting Sean Paul's potentially-faulty memory: """ - To avoid racing a subsequent PSR entry (if exit takes a long time) - To avoid racing disable/modeset - We're not displaying new content while exiting PSR anyways, so there is minimal utility in allowing frames to be submitted - We're lying to userspace telling them frames are on the screen when we're just dropping them on the floor """ However, I'm finding that this blocking transition is causing upwards of 60+ ms of unneeded latency on PSR-exit, to the point that initial cursor movements when leaving PSR are unbearably jumpy. It turns out that we need to meet in the middle somewhere: Sean is right that we were "lying to userspace" with a non-blocking PSR-exit, but the new blocking behavior is also waiting too long: According to the eDP specification, the sink device must support PSR entry transitions from both state 4 (ACTIVE_RESYNC) and state 0 (INACTIVE). It also states that in ACTIVE_RESYNC, "the Sink device must display the incoming active frames from the Source device with no visible glitches and/or artifacts." Thus, for our purposes, we only need to wait for ACTIVE_RESYNC before moving on; we are ready to display video, and subsequent PSR-entry is safe. Tested on a Samsung Chromebook Plus (i.e., Rockchip RK3399 Gru Kevin), where this saves about 60ms of latency, for PSR-exit that used to take about 80ms. Fixes: 6c836d96 ("drm/rockchip: Use the helpers for PSR") Cc: <stable@vger.kernel.org> Cc: Zain Wang <wzz@rock-chips.com> Cc: Tomasz Figa <tfiga@chromium.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Sean Paul <seanpaul@chromium.org> Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211103135112.v3.1.I67612ea073c3306c71b46a87be894f79707082df@changeid
-
Xin Ji authored
Add audio HDMI codec function support, enable it through device true flag "analogix,audio-enable". Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211104033857.2634562-1-xji@analogixsemi.com
-
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:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211104033639.2634502-1-xji@analogixsemi.com
-
Xin Ji authored
At some time, the original code may return non zero value, force return 0 if operation finished. Reviewed-by:
Robert Foss <robert.foss@linaro.org> Signed-off-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211104033609.2634452-1-xji@analogixsemi.com
-
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:
Xin Ji <xji@analogixsemi.com> Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211104033444.2634397-1-xji@analogixsemi.com
-
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 <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-10-maxime@cerno.tech
-
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:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20211025152903.1088803-9-maxime@cerno.tech
-
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 <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-8-maxime@cerno.tech
-
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 <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-7-maxime@cerno.tech
-
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 <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-6-maxime@cerno.tech
-
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 <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-5-maxime@cerno.tech
-
Maxime Ripard authored
We'll need that function in vc4_kms to compute the core clock rate requirements. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-4-maxime@cerno.tech
-
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 <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-3-maxime@cerno.tech
-
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:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20211025152903.1088803-2-maxime@cerno.tech
-
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
-
- Nov 03, 2021
-
-
Christian König authored
Just grab all fences in one go. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211028132630.2330-3-christian.koenig@amd.com
-
- Nov 02, 2021
-
-
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:
Simon Ser <contact@emersion.fr> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-6-contact@emersion.fr
-
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:
Simon Ser <contact@emersion.fr> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-5-contact@emersion.fr
-
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 <contact@emersion.fr> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-4-contact@emersion.fr
-
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 <contact@emersion.fr> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-3-contact@emersion.fr
-
Simon Ser authored
This function sends a hotplug uevent with a CONNECTOR property. Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211018084707.32253-2-contact@emersion.fr
-
- Nov 01, 2021
-
-
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:
Christian König <christian.koenig@amd.com> Tested-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://www.spinics.net/lists/dri-devel/msg321250.html
-
- Oct 31, 2021
-
-
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.net Acked-by:
Sam Ravnborg <sam@ravnborg.org>
-
- Oct 30, 2021
-
-
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:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-7-paul@crapouillou.net Tested-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 <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-6-paul@crapouillou.net Tested-by:
Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
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 <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-5-paul@crapouillou.net Tested-by:
Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
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 <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-4-paul@crapouillou.net Tested-by:
Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
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 <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-3-paul@crapouillou.net Tested-by:
Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
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:
Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20211026181240.213806-2-paul@crapouillou.net Tested-by:
Nikolaus Schaller <hns@goldelico.com> Reviewed-by:
Christophe Branchereau <cbranchereau@gmail.com>
-
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:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20211027212506.3418521-1-marcel@ziswiler.com
-
- Oct 29, 2021
-
-
Christian König authored
Makes the handling a bit more complex, but avoids the use of dma_resv_get_excl_unlocked(). Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211005113742.1101-27-christian.koenig@amd.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 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.com Signed-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:
Colin Ian King <colin.king@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210930101941.16546-1-colin.king@canonical.com Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
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.com Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
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:
kernel test robot <lkp@intel.com> Fixes: cea86c5b ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip") Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211028163548.273736-1-bjorn.andersson@linaro.org Signed-off-by:
Robert Foss <robert.foss@linaro.org>
-