summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2021-11-11drm: Clarify semantics of struct drm_mode_config.{min, max}_{width, height}Thomas Zimmermann2-0/+28
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
2021-11-11drm/simpledrm: Support virtual screen sizesThomas Zimmermann2-2/+25
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 <tzimmermann@suse.de> Acked-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-9-tzimmermann@suse.de
2021-11-11drm/simpledrm: Enable FB_DAMAGE_CLIPS propertyThomas Zimmermann1-9/+19
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 <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-8-tzimmermann@suse.de
2021-11-11drm/fb-helper: Allocate shadow buffer of surface heightThomas Zimmermann1-1/+1
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 <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-7-tzimmermann@suse.de
2021-11-11drm/format-helper: Streamline blit-helper interfaceThomas Zimmermann3-56/+19
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 <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-6-tzimmermann@suse.de
2021-11-11drm/format-helper: Rework format-helper conversion functionsThomas Zimmermann7-90/+97
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 <tzimmermann@suse.de> Tested-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-5-tzimmermann@suse.de
2021-11-11drm/format-helper: Add destination-buffer pitch to drm_fb_swab()Thomas Zimmermann4-9/+21
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 <tzimmermann@suse.de> Tested-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-4-tzimmermann@suse.de
2021-11-11drm/format-helper: Rework format-helper memcpy functionsThomas Zimmermann7-30/+41
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 <tzimmermann@suse.de> Tested-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-3-tzimmermann@suse.de
2021-11-11drm/format-helper: Export drm_fb_clip_offset()Thomas Zimmermann2-2/+21
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 <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211110103702.374-2-tzimmermann@suse.de
2021-11-11drm: Update documentation and TODO of gem_prime_mmap hookThomas Zimmermann2-15/+7
The hook gem_prime_mmap in struct drm_driver is deprecated. Document the new requirements. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20211108102846.309-4-tzimmermann@suse.de
2021-11-11drm/xen: Implement mmap as GEM object functionThomas Zimmermann3-87/+44
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: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211108102846.309-3-tzimmermann@suse.de
2021-11-11drm/etnaviv: use dma_resv_describeChristian König1-19/+7
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
2021-11-11drm/msm: use the new dma_resv_describeChristian König1-19/+1
Instead of hand rolling pretty much the same code. 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-3-christian.koenig@amd.com
2021-11-11dma-buf: add dma_fence_describe and dma_resv_describe v2Christian König5-10/+43
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: Christian König <christian.koenig@amd.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211103081231.18578-2-christian.koenig@amd.com
2021-11-11drm/ttm: Put BO in its memory manager's lru listxinhui pan1-0/+2
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: Christian König <christian.koenig@amd.com> Signed-off-by: xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211110043149.57554-1-xinhui.pan@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-11-10drm/tidss: Make use of the helper macro SET_RUNTIME_PM_OPS()Cai Huoqing1-9/+2
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 <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210907033526.1612-1-caihuoqing@baidu.com
2021-11-10drm/omap: increase DSS5 max tv pclk to 192MHzTomi Valkeinen1-1/+1
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: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211012133939.2145462-1-narmstrong@baylibre.com
2021-11-10drm/omap: Make use of the helper function devm_platform_ioremap_resourcexxx()Cai Huoqing9-34/+11
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 <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210831135707.4676-1-caihuoqing@baidu.com
2021-11-10drm/omap: dss: Make use of the helper macro SET_RUNTIME_PM_OPS()Cai Huoqing4-8/+4
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 <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210828084811.104-1-caihuoqing@baidu.com
2021-11-10drm/omapdrm: Convert to SPDX identifierCai Huoqing6-62/+6
use SPDX-License-Identifier instead of a verbose license text Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210822072323.408-1-caihuoqing@baidu.com
2021-11-06drm/lima: fix warning when CONFIG_DEBUG_SG=y & CONFIG_DMA_API_DEBUG=yQiang Yu1-0/+1
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/5496 Reviewed-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
2021-11-05drm/vc4: hdmi: Introduce a scdc_enabled flagMaxime Ripard2-10/+18
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.tech Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: hdmi: Introduce an output_enabled flagMaxime Ripard2-4/+18
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.tech Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: hdmi: Check the device state in prepare()Maxime Ripard1-7/+28
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: 91e99e113929 ("drm/vc4: hdmi: Register HDMI codec") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: hdmi: Prevent access to crtc->state outside of KMSMaxime Ripard2-12/+32
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: bb7d78568814 ("drm/vc4: Add HDMI audio support") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: hdmi: Use a mutex to prevent concurrent framework accessMaxime Ripard2-6/+126
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: bb7d78568814 ("drm/vc4: Add HDMI audio support") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: hdmi: Add a spinlock to protect register accessMaxime Ripard4-10/+236
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: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: crtc: Copy assigned channel to the CRTCMaxime Ripard4-2/+24
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: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: Fix non-blocking commit getting stuck foreverMaxime Ripard3-3/+23
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: 56d1fe0979dc ("drm/vc4: Make pageflip completion handling more robust.") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-05drm/vc4: crtc: Drop feed_txp from stateMaxime Ripard5-10/+12
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 39fcb2808376 ("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: 008095e065a8 ("drm/vc4: Add support for the transposer block") Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-11-04drm/bridge: analogix_dp: Make PSR-exit block lessBrian Norris1-2/+12
Prior to commit 6c836d965bad ("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: 6c836d965bad ("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
2021-11-04drm/bridge: anx7625: add HDMI audio functionXin Ji2-0/+231
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
2021-11-04drm/bridge: anx7625: add MIPI DPI input featureXin Ji2-60/+205
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
2021-11-04drm/bridge: anx7625: fix not correct return valueXin Ji1-2/+2
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
2021-11-04dt-bindings:drm/bridge:anx7625:add vendor defineXin Ji1-2/+63
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
2021-11-04drm/vc4: Increase the core clock based on HVS loadMaxime Ripard3-9/+118
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
2021-11-04drm/vc4: hdmi: Enable the scrambler on reconnectionMaxime Ripard1-0/+3
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: c85695a2016e ("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
2021-11-04drm/vc4: hdmi: Raise the maximum clock rateMaxime Ripard1-1/+1
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
2021-11-04drm/vc4: Leverage the load tracker on the BCM2711Maxime Ripard4-21/+10
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
2021-11-04drm/vc4: crtc: Add some loggingMaxime Ripard1-0/+6
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
2021-11-04drm/vc4: crtc: Rework the encoder retrieval code (again)Maxime Ripard2-24/+10
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
2021-11-04drm/vc4: crtc: Add encoder to vc4_crtc_config_pv prototypeMaxime Ripard1-4/+3
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
2021-11-04drm/vc4: Make vc4_crtc_get_encoder publicMaxime Ripard2-4/+9
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
2021-11-04drm/vc4: hdmi: Fix HPD GPIO detectionMaxime Ripard1-3/+3
Prior to commit 6800234ceee0 ("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: 6800234ceee0 ("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
2021-11-04drm/vc4: hdmi: Remove the DDC probing for status detectionMaxime Ripard1-2/+0
Commit 9d44abbbb8d5 ("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 b1b8f45b3130 ("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
2021-11-04drm/radeon: use dma_resv_wait_timeout() instead of manually waitingChristian König1-8/+5
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
2021-11-03drm/etnaviv: stop getting the excl fence separately hereChristian König1-1/+1
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
2021-11-02i915/display/dp: send a more fine-grained link-status ueventSimon Ser1-1/+1
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
2021-11-02drm/probe-helper: use drm_kms_helper_connector_hotplug_eventSimon Ser1-8/+17
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
2021-11-02amdgpu: use drm_kms_helper_connector_hotplug_eventSimon Ser2-6/+6
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
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 11:54:21 +0000