- 11 Nov, 2021 15 commits
-
-
Thomas Zimmermann authored
Add additional information on the semantics of the size fields in struct drm_mode_config. Also add a TODO to review all driver for correct usage of these fields. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-10-tzimmermann@suse.de
-
Thomas Zimmermann authored
Add constants for the maximum size of the shadow-plane surface size. Useful for shadow planes with virtual screen sizes. The current sizes are 4096 scanlines with 4096 pixels each. This seems reasonable for current hardware, but can be increased as necessary. In simpledrm, set the maximum framebuffer size from the constants for shadow planes. Implements support for virtual screen sizes and page flipping on the fbdev console. v3: * use decimal numbers for shadow-plane constants (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Enable the FB_DAMAGE_CLIPS property to reduce display-update overhead. Also fixes a warning in the kernel log. simple-framebuffer simple-framebuffer.0: [drm] drm_plane_enable_fb_damage_clips() not called Fix the computation of the blit rectangle. This wasn't an issue so far, as simpledrm always blitted the full framebuffer. The code now supports damage clipping and virtual screen sizes. v3: * fix drm_dev_enter() error path (Noralf) * remove unnecessary clipping from update function (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Allocating a shadow buffer of the height of the buffer object does not support fbdev overallocation. Use surface height instead. Signed-off-by:
-
Thomas Zimmermann authored
Move destination-buffer clipping from format-helper blit function into caller. Rename drm_fb_blit_rect_dstclip() to drm_fb_blit_toio(). Done for consistency with the rest of the interface. Remove drm_fb_blit_dstclip(), which isn't required. Signed-off-by:
-
Thomas Zimmermann authored
Move destination-buffer clipping from all format-helper conversion functions into callers. Support destination-buffer pitch. Only distinguish between system and I/O memory, but use same logic everywhere. Simply harmonize the interface and semantics of the existing code. Not all conversion helpers support all combinations of parameters. We have to add additional features when we need them. v2: * fix default destination pitch in drm_fb_xrgb8888_to_gray8() (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Add destination-buffer pitch as argument to drm_fb_swab(). Done for consistency with the rest of the interface. v2: * update documentation (Noralf) Signed-off-by:
-
Thomas Zimmermann authored
Move destination-buffer clipping from all format-helper memcpy function into callers. Support destination-buffer pitch. Only distinguish between system and I/O memory, but use same logic everywhere. Signed-off-by:
-
Thomas Zimmermann authored
Provide a function that computes the offset into a blit destination buffer. This will allow to move destination-buffer clipping into the format-helper callers. v4: * add missing '@' for parameter documentation * fix typo 'frambuffer' v2: * provide documentation (Sam) * return 'unsigned int' (Sam, Noralf) Signed-off-by:
-
Thomas Zimmermann authored
The hook gem_prime_mmap in struct drm_driver is deprecated. Document the new requirements. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211108102846.309-4-tzimmermann@suse.de
-
Thomas Zimmermann authored
Moving the driver-specific mmap code into a GEM object function allows for using DRM helpers for various mmap callbacks. The respective xen functions are being removed. The file_operations structure fops is now being created by the helper macro DEFINE_DRM_GEM_FOPS(). Signed-off-by:
Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211108102846.309-3-tzimmermann@suse.de
-
Christian König authored
Instead of dumping the fence info manually. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211103081231.18578-4-christian.koenig@amd.com
-
Christian König authored
Instead of hand rolling pretty much the same code. Signed-off-by:
-
Christian König authored
Add functions to dump dma_fence and dma_resv objects into a seq_file and use them for printing the debugfs information. v2: fix missing include reported by test robot. Signed-off-by:
-
xinhui pan authored
After we move BO to a new memory region, we should put it to the new memory manager's lru list regardless we unlock the resv or not. Cc: stable@vger.kernel.org Reviewed-by:
xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110043149.57554-1-xinhui.pan@amd.comSigned-off-by:
-
- 10 Nov, 2021 5 commits
-
-
Cai Huoqing authored
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little more concise. Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Reviewed-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by:
-
Tomi Valkeinen authored
DSS5's maximum tv pclk rate (i.e. HDMI) is set to 186MHz, which comes from the TRM (DPLL_HDMI_CLK1 frequency must be lower than 186 MHz). To support DRA76's wide screen HDMI feature, we need to increase this maximum rate. Testing shows that the PLL seems to work fine even with ~240MHz clocks, and even the HDMI output at that clock is stable enough for monitors to show a picture. This holds true for all DRA7 and AM5 SoCs (and probably also for OMAP5). However, the highest we can go without big refactoring to the clocking code is 192MHz, as that is the DSS func clock we get from the PRCM. So, increase the max HDMI pixel clock to 192MHz for now, to allow some more 2k+ modes to work. This patch never had a clear confirmation from HW people, but this change stayed on production trees for multiple years without any report on an eventual breakage. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Reviewed-by:
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
-
Cai Huoqing authored
Use the helper macro SET_RUNTIME_PM_OPS() instead of the verbose operators ".runtime_suspend/.runtime_resume", because the SET_RUNTIME_PM_OPS() is a nice helper macro that could be brought in to make code a little clearer, a little more concise. Signed-off-by:
-
Cai Huoqing authored
use SPDX-License-Identifier instead of a verbose license text Signed-off-by:
-
- 06 Nov, 2021 1 commit
-
-
Qiang Yu authored
Otherwise get following warning: DMA-API: lima 1c40000.gpu: mapping sg segment longer than device claims to support [len=4149248] [max=65536] See: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5496Reviewed-by:
Vasily Khoruzhick <anarsoul@gmail.com> Reported-by:
Roman Stratiienko <r.stratiienko@gmail.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211031041604.187216-1-yuq825@gmail.com
-
- 05 Nov, 2021 9 commits
-
-
Maxime Ripard authored
We currently rely on two functions, vc4_hdmi_supports_scrambling() and vc4_hdmi_mode_needs_scrambling() to determine if we should enable and disable the scrambler for any given mode. Since we might need to disable the controller at boot, we also always run vc4_hdmi_disable_scrambling() and thus call those functions without a mode yet, which in turns need to make some special casing in order for it to work. Instead of duplicating the check for whether or not we need to take care of the scrambler in both vc4_hdmi_enable_scrambling() and vc4_hdmi_disable_scrambling(), we can do that check only when we enable it and store whether or not it's been enabled in our private structure. We also need to initialize that flag at true to make sure we disable the scrambler at boot since we can't really know its state yet. This allows to simplify a bit that part of the driver, and removes one user of our copy of the CRTC adjusted mode outside of KMS (since vc4_hdmi_disable_scrambling() might be called from the hotplug interrupt handler). It also removes our last user of the legacy encoder->crtc pointer. Link: https://lore.kernel.org/r/20211025141113.702757-10-maxime@cerno.techAcked-by:
Maxime Ripard <maxime@cerno.tech>
-
Maxime Ripard authored
We currently poke at encoder->crtc in the ALSA code path to determine whether the HDMI output is enabled or not, and thus whether we should allow the audio output. However, that pointer is deprecated and shouldn't really be used by atomic drivers anymore. Since we have the infrastructure in place now, let's just create a flag that we toggle to report whether the controller is currently enabled and use that instead of encoder->crtc in ALSA. Link: https://lore.kernel.org/r/20211025141113.702757-9-maxime@cerno.techAcked-by:
-
Maxime Ripard authored
Even though we already check that the encoder->crtc pointer is there during in startup(), which is part of the open() path in ASoC, nothing guarantees that our encoder state won't change between the time when we open the device and the time we prepare it. Move the sanity checks we do in startup() to a helper and call it from prepare(). Link: https://lore.kernel.org/r/20211025141113.702757-8-maxime@cerno.tech Fixes: 91e99e11 ("drm/vc4: hdmi: Register HDMI codec") Acked-by:
-
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. However, in the vc4 HDMI driver we do use that pointer in the ALSA code path, and potentially in the hotplug interrupt handler path. These paths both need access to the CRTC adjusted mode in order for the proper dividers to be set for ALSA, and the scrambler state to be reinstated properly for hotplug. Let's copy this mode into our private encoder structure and reference it from there when needed. Since that part is shared between KMS and other paths, we need to protect it using our mutex. Link: https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/ Link: https://lore.kernel.org/r/20211025141113.702757-7-maxime@cerno.tech Fixes: bb7d7856 ("drm/vc4: Add HDMI audio support") Acked-by:
-
Maxime Ripard authored
The vc4 HDMI controller registers into the KMS, CEC and ALSA frameworks. However, no particular care is done to prevent the concurrent execution of different framework hooks from happening at the same time. In order to protect against that scenario, let's introduce a mutex that relevant ALSA and KMS hooks will need to take to prevent concurrent execution. CEC is left out at the moment though, since the .get_modes and .detect KMS hooks, when running cec_s_phys_addr_from_edid, can end up calling CEC's .adap_enable hook. This introduces some reentrancy that isn't easy to deal with properly. The CEC hooks also don't share much state with the rest of the driver: the registers are entirely separate, we don't share any variable, the only thing that can conflict is the CEC clock divider setup that can be affected by a mode set. However, after discussing it, it looks like CEC should be able to recover from this if it was to happen. Link: https://lore.kernel.org/r/20211025141113.702757-6-maxime@cerno.tech Fixes: bb7d7856 ("drm/vc4: Add HDMI audio support") Acked-by:
-
Maxime Ripard authored
The vc4 HDMI driver has multiple path shared between the CEC, ALSA and KMS frameworks, plus two interrupt handlers (CEC and hotplug) that will read and modify a number of registers. Even though not bug has been reported so far, it's definitely unsafe, so let's just add a spinlock to protect the register access of the HDMI controller. Link: https://lore.kernel.org/r/20211025141113.702757-5-maxime@cerno.tech Fixes: c8b75bca ("drm/vc4: Add KMS support for Raspberry Pi.") Acked-by:
-
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:
-
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:
-
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:
-
- 04 Nov, 2021 10 commits
-
-
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:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
-
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:
-
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:
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:
-
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:
-
