- 12 Jul, 2022 3 commits
-
-
Jian Zhang authored
In exynos7_decon_resume, When it fails, we must use clk_disable_unprepare() to free resource that have been used. Fixes: 6f83d208 ("drm/exynos: use DRM_DEV_ERROR to print out error message") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Jian Zhang <zhangjian210@huawei.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Krzysztof Kozlowski authored
Emails to Joonyoung Shim bounce ("550 5.1.1 Recipient address rejected: User unknown"), so remove him from maintainers of DT bindings (display, phy). Signed-off-by:Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Krzysztof Kozlowski authored
Emails to Joonyoung Shim bounce ("550 5.1.1 Recipient address rejected: User unknown"), so move him to credits file. Signed-off-by:
-
- 01 Jul, 2022 1 commit
-
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2022-06-29' of git://anongit.freedesktop.org/drm/drm-intel into drm-next UAPI Changes: - Expose per tile media freq factor in sysfs (Ashutosh Dixit, Dale B Stimson) - Document memory residency and Flat-CCS capability of obj (Ramalingam C) - Disable GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK on Xe_HP+ (Matt Roper) Cross-subsystem Changes: - Rename intel-gtt symbols (Lucas De Marchi) Core Changes: Driver Changes: - Support programming the EU priority in the GuC descriptor (DG2) (Matthew Brost) - DG2 HuC loading support (Daniele Ceraolo Spurio) - Fix build error without CONFIG_PM (YueHaibing) - Enable THP on Icelake and beyond (Tvrtko Ursulin) - Only setup private tmpfs mount when needed and fix logging (Tvrtko Ursulin) - Make __guc_reset_context aware of guilty engines (Umesh Nerlige Ramappa) - DG2 small bar memory probing fixes (Nirmoy Das) - Remove unnecessary GuC err capture noise (Alan Previn) - Fix i915_gem_object_ggtt_pin_ww regression on old platforms (Maarten Lankhorst) - Fix undefined behavior in GuC backend due to shift overflowing the constant (Borislav Petkov) - New DG2 workarounds (Swathi Dhanavanthri, Anshuman Gupta) - Report no hwconfig support on ADL-N (Balasubramani Vivekanandan) - Fix error_state_read ptr + offset use (Alan Previn) - Expose per tile media freq factor in sysfs (Ashutosh Dixit, Dale B Stimson) - Fix memory leaks in per-gt sysfs (Ashutosh Dixit) - Fix dma_resv fence handling in multi-batch execbuf (Nirmoy Das) - Add extra registers to GPU error dump on Gen11+ (Stuart Summers) - More PVC+DG2 workarounds (Matt Roper) - Improve user experience and driver robustness under SIGINT or similar (Tvrtko Ursulin) - Don't show engine classes not present (Tvrtko Ursulin) - Improve on suspend / resume time with VT-d enabled (Thomas Hellström) - Add missing else (katrinzhou) - Don't leak lmem mapping in vma_evict (Juha-Pekka Heikkila) - Add smem fallback allocation for dpt (Juha-Pekka Heikkila) - Tweak the ordering in cpu_write_needs_clflush (Matthew Auld) - Do not access rq->engine without a reference (Niranjana Vishwanathapura) - Revert "drm/i915: Hold reference to intel_context over life of i915_request" (Niranjana Vishwanathapura) - Don't update engine busyness stats too frequently (Alan Previn) - Add additional steps for Wa_22011802037 for execlist backend (Umesh Nerlige Ramappa) - Fix a lockdep warning at error capture (Nirmoy Das) - Ponte Vecchio prep work and new blitter engines (Matt Roper, John Harrison, Lucas De Marchi) - Read correct RP_STATE_CAP register (PVC) (Matt Roper) - Define MOCS table for PVC (Ayaz A Siddiqui) - Driver refactor and support Ponte Vecchio forcewake handling (Matt Roper) - Remove additional 3D flags from PIPE_CONTROL (Ponte Vecchio) (Stuart Summers) - XEHPSDV and PVC do not use HuC (Daniele Ceraolo Spurio) - Extract stepping information from PCI revid (Ponte Vecchio) (Matt Roper) - Add initial PVC workarounds (Stuart Summers) - SSEU handling driver refactor and Ponte Vecchio support (Matt Roper) - GuC depriv applies to PVC (Matt Roper) - Add register steering (Ponte Vecchio) (Matt Roper) - Add recommended MMIO setting (Ponte Vecchio) (Matt Roper) - Move multicast register handling to a dedicated file (Matt Roper) - Cleanup interface for MCR operations (Matt Roper) - Extend i915_vma_pin_iomap() (CQ Tang) - Re-do the intel-gtt split (Lucas De Marchi) - Correct duplicated/misplaced GT register definitions (Matt Roper) - Prefer "XEHP_" prefix for registers (Matt Roper) - Don't use DRM_DEBUG_WARN_ON for unexpected l3bank/mslice config (Tvrtko Ursulin) - Don't use DRM_DEBUG_WARN_ON for ring unexpectedly not idle (Tvrtko Ursulin) - Make drop_pages() return bool (Lucas De Marchi) - Fix CFI violation with show_dynamic_id() (Nathan Chancellor) - Use i915_probe_error instead of drm_error in GuC code (Vinay Belgaumkar) - Fix use of static in macro mismatch (Andi Shyti) - Update tiled blits selftest (Bommu Krishnaiah) - Future-proof platform checks (Matt Roper) - Only include what's needed (Jani Nikula) - remove accidental static from a local variable (Jani Nikula) - Add global forcewake request to drpc (Vinay Belgaumkar) - Fix spelling typo in comment (pengfuyuan) - Increase timeout for live_parallel_switch selftest (Akeem G Abodunrin) - Use non-blocking H2G for waitboost (Vinay Belgaumkar) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/YrwtLM081SQUG1Dc@tursulin-desk
-
- 30 Jun, 2022 3 commits
-
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for v5.20: UAPI Changes: * fourcc: Update documentation Cross-subsystem Changes: * iosys-map: Rework iosys_map_{rd,wr} for improved performance * vfio: Use aperture helpers Core Changes: * aperture: Export for use with other subsystems * connector: Remove deprecated ida_simple_get() * crtc: Add helper with general state checks, convert drivers * format-helper: Add Kunit tests for RGB32 to RGB8 Driver Changes: * ast: Fix black screen on resume * bridge: tc358767: Simplify DSI lane handling * mcde: Fix ref-count leak * mxsfb/lcdif: Support i.MX8MP LCD controller * stm/ltdc: Support dynamic Z order; Support mirroring; Fixes and cleanups * vc4: Many small fixes throughout the driver Signed-off-by: -
Lucas De Marchi authored
Like was done for read, provide the equivalent for write. Even if current users are not in the hot path, this should future-proof it. v2: - Remove default from _Generic() - callers wanting to write more than u64 should use iosys_map_memcpy_to() - Add WRITE_ONCE() cases dereferencing the pointer when using system memory v3: - Fix precedence issue when casting inside WRITE_ONCE(). By not using () around vaddr__ the offset was not part of the cast, but rather added to it, producing a wrong address - Remove compiletime_assert() as WRITE_ONCE() already contains it Signed-off-by:Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Reviewed-by: Christian König <christian.koenig@amd.com> # v1 Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220628191016.3899428-2-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Instead of always falling back to memcpy_fromio() for any size, prefer using read{b,w,l}(). When reading struct members it's common to read individual integer variables individually. Going through memcpy_fromio() for each of them poses a high penalty. Employ a similar trick as __seqprop() by using _Generic() to generate only the specific call based on a type-compatible variable. For a pariticular i915 workload producing GPU context switches, __get_engine_usage_record() is particularly hot since the engine usage is read from device local memory with dgfx, possibly multiple times since it's racy. Test execution time for this test shows a ~12.5% improvement with DG2: Before: nrepeats = 1000; min = 7.63243e+06; max = 1.01817e+07; median = 9.52548e+06; var = 526149; After: nrepeats = 1000; min = 7.03402e+06; max = 8.8832e+06; median = 8.33955e+06; var = 333113; Other things attempted that didn't prove very useful: 1) Change the _Generic() on x86 to just dereference the memory address 2) Change __get_engine_usage_record() to do just 1 read per loop, comparing with the previous value read 3) Change __get_engine_usage_record() to access the fields directly as it was before the conversion to iosys-map (3) did gave a small improvement (~3%), but doesn't seem to scale well to other similar cases in the driver. Additional test by Chris Wilson using gem_create from igt with some changes to track object creation time. This happens to accidentally stress this code path: Pre iosys_map conversion of engine busyness: lmem0: Creating 262144 4KiB objects took 59274.2ms Unpatched: lmem0: Creating 262144 4KiB objects took 108830.2ms With readl (this patch): lmem0: Creating 262144 4KiB objects took 61348.6ms s/readl/READ_ONCE/ lmem0: Creating 262144 4KiB objects took 61333.2ms So we do take a little bit more time than before the conversion, but that is due to other factors: bringing the READ_ONCE back would be as good as just doing this conversion. v2: - Remove default from _Generic() - callers wanting to read more than u64 should use iosys_map_memcpy_from() - Add READ_ONCE() cases dereferencing the pointer when using system memory v3: - Fix precedence issue when casting inside READ_ONCE(). By not using () around vaddr__ the offset was not part of the cast, but rather added to it, producing a wrong address - Remove compiletime_assert() as READ_ONCE() already contains it Signed-off-by:
-
- 29 Jun, 2022 1 commit
-
-
Nirmoy Das authored
For some platfroms we use stop_machine version of gen8_ggtt_insert_page/gen8_ggtt_insert_entries to avoid a concurrent GGTT access bug but this causes a circular locking dependency warning: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ggtt->error_mutex); lock(dma_fence_map); lock(&ggtt->error_mutex); lock(cpu_hotplug_lock); Fix this by calling gen8_ggtt_insert_page/gen8_ggtt_insert_entries directly at error capture which is concurrent GGTT access safe because reset path make sure of that. v2: Fix rebase conflict and added a comment. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5595Reviewed-by:Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Suggested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624110821.29190-1-nirmoy.das@intel.com
-
- 28 Jun, 2022 32 commits
-
-
Marek Vasut authored
Add support for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. Add a separate driver which is really a fork of MXSFB driver with the i.MX8MP LCDIF variant handling filled in. Tested-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Tested-by:
Martyn Welch <martyn.welch@collabora.com> Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stefan Agner <stefan@agner.ch> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220628174152.167284-2-marex@denx.de
-
Marek Vasut authored
Add compatible string for i.MX8MP LCDIF variant. This is called LCDIFv3 and is completely different from the LCDIFv3 found in i.MX23 in that it has a completely scrambled register layout compared to all previous LCDIF variants. The new LCDIFv3 also supports 36bit address space. However, except for the complete bit reshuffling, this is still LCDIF and it still works like one. Acked-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Marek Vasut authored
The DSI lane count can be accessed via the dsi device pointer, make use of that. No functional change. Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220624181902.151959-1-marex@denx.de
-
Jiang Jian authored
there is an unexpected word 'for' in the comments that need to be dropped file - ./drivers/gpu/drm/selftests/test-drm_dp_mst_helper.c line - 3 * Test cases for for the DRM DP MST helpers changed to: * Test cases for the DRM DP MST helpers Signed-off-by:
Jiang Jian <jiangjian@cdjrlc.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Dave Stevenson authored
With the change to 2 pixels/clock, the pixel doubling in the PV results in doubling each pair of pixels, ie ABABCDCD instead of AABBCCDD. Move the pixel doubling to the HDMI block, however this means that DBLCLK modes now fall foul of requiring even values for all the horizontal timing parameters. As both 480i and 576i fail this, attempt to fix up DBLCLK modes that have odd timings values. Fixes: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-34-maxime@cerno.techSigned-off-by:
Maxime Ripard <maxime@cerno.tech>
-
Dave Stevenson authored
For interlaced modes the timings were not being correctly programmed into the HDMI block, so correct them. Fixes: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by:
-
Dom Cobley authored
Whenever the maximum BPC is changed, vc4_hdmi_encoder_compute_config() might pick up a different BPC or format depending on the display capabilities. That change will have a number of side effects, including the clock rates and whether the scrambling is enabled. However, only drm_crtc_state.connectors_changed will be set to true, since that properly only affects the connector. This means that while drm_atomic_crtc_needs_modeset() will return true, and thus drm_atomic_helper_commit_modeset_enables() will call our encoder atomic_enable() hook, mode_changed will be false. So crtc_set_mode() will not call our encoder .atomic_mode_set() hook. We use this hook in vc4 to set the vc4_hdmi_connector_state.output_bpc (and output_format), and will then reuse the value in .atomic_enable() to select whether or not scrambling should be enabled. However, since our clock rate is pre-computed during .atomic_check(), we end up with the clocks properly configured, but the scrambling disabled, leading to a blank screen. Let's set mode_changed to true in our HDMI driver to force the update of output_bpc, and thus prevent the issue entirely. Fixes: ba8c0fae ("drm/vc4: hdmi: Enable 10/12 bpc output") Signed-off-by:
Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-32-maxime@cerno.techSigned-off-by:
-
Mateusz Kwiatkowski authored
Increase the number of post-sync blanking lines on odd fields instead of decreasing it on even fields. This makes the total number of lines properly match the modelines. Additionally fix the value of PV_VCONTROL_ODD_DELAY, which did not take pixels_per_clock into account, causing some displays to invert the fields when driven by bcm2711. Fixes: 682e62c4 ("drm/vc4: Fix support for interlaced modes on HDMI.") Signed-off-by:
Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-31-maxime@cerno.techSigned-off-by:
-
Dom Cobley authored
Our HDMI controllers supports Stereo output so let's enable it. Signed-off-by:
-
Dave Stevenson authored
The MISC_CONTROL register allows configuration of pixel repetition for pixel doubling in the HDMI block instead of PixelValve. It was already defined for vc5, so add it for vc4. Signed-off-by:
-
Dave Stevenson authored
The block can detect what the incoming image timings are for debug purposes. Add them to the list of registers understood by the driver to allow easy dumping of the values. Signed-off-by:
-
Dom Cobley authored
This bit ensures data island packets are never generated when disallowed by HDCP. As no Pi boards support HDCP this is providing an unnecessary restriction Signed-off-by:
-
Dom Cobley authored
This path actually occurs when audio is started during a hdmi mode set. As the data will be written by vc4_hdmi_set_infoframes when packet RAM is enabled again, don't treat as an error Signed-off-by:
-
Dom Cobley authored
The current HDMI driver, in vc4_hdmi_audio_can_stream() checks whether the display output is enabled. This has been there in one form or the other since the introduction of the audio support in the VC4 HDMI driver in commit bb7d7856 ("drm/vc4: Add HDMI audio support"), but no justification for this check is in the commit message, or in the discussions around the patches. One can only assume this was done to prevent a user from playing audio on the ALSA soundcard when the monitor doesn't support it. However, this is causing some issues. Indeed, Kodi, for example, was hitting some errors if it was streaming audio during a modeset. With the theory above, it does make sense, but the display and audio threads are typically completely different processes with no opportunity to synchronise which makes it hard to workaround. Removing that check also doesn't seem to cause any trouble, so let's just remove it. Signed-off-by:
-
Dave Stevenson authored
The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain attached to the HDMI block, handled in Linux through runtime_pm. That power domain is shared with the VEC block, so even if we put our runtime_pm reference in the HDMI driver it would keep being on. If the VEC is disabled though, the power domain would be disabled and we would lose any initialization done in our bind implementation. That initialization involves calling the reset function and initializing the CEC registers. Let's move the initialization to our runtime_resume implementation so that we initialize everything properly if we ever need to. Fixes: c86b4121 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm") Signed-off-by:
-
Dave Stevenson authored
If the controller isn't clocked or its domain powered up, the register accesses will either stall the CPU or return garbage, respectively. Thus, we had a warning in our register access function to complain when that kind of risky accesses were performed. In order to check the runtime_pm power state, we were using pm_runtime_active(), but it turns out that it will become active only once the runtime_resume hook has been executed. This prevents us from doing any WARN-free register access in our runtime_resume() implementation, while this is valid. Let's switch to pm_runtime_status_suspended() instead. Fixes: 14e193b9 ("drm/vc4: hdmi: Warn if we access the controller while disabled") Signed-off-by:
-
Dave Stevenson authored
The HDMI block can repeat pixels for double clocked modes, and the firmware is now configuring the block to do this as the PV is doing it incorrectly when at 2pixels/clock. If the kernel doesn't reset it then we end up with strange modes. Reset MISC_CONTROL. Fixes: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by:
-
Dom Cobley authored
We are getting occasional VC4_HD_MAI_CTL_ERRORF in HDMI_MAI_CTL which seem to correspond with audio dropouts. Reduce the threshold where we deassert DREQ to avoid the fifo overfilling Fixes: bb7d7856 ("drm/vc4: Add HDMI audio support") Signed-off-by:
-
Dom Cobley authored
Using a hdmi analyser the bytes in packet ram registers beyond the length were visible in the infoframes and it flagged the checksum as invalid. Zeroing unused words of packet RAM avoids this Fixes: 21317b3f ("drm/vc4: Set up the AVI and SPD infoframes.") Signed-off-by:
-
Dave Stevenson authored
The vc5 HDMI registers hadn't been added into the debugfs register sets, therefore weren't dumped on request. Add them in. Fixes: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by:
-
Phil Elwell authored
The dmas property is used to hold the dmaengine channel used for audio output. Older device trees were missing that property, so if it's not there we disable the audio output entirely. However, some overlays have set an empty value to that property, mostly to workaround the fact that overlays cannot remove a property. Let's add a test for that case and if it's empty, let's disable it as well. Cc: <stable@vger.kernel.org> Signed-off-by:
Phil Elwell <phil@raspberrypi.org> Link: https://lore.kernel.org/r/20220613144800.326124-18-maxime@cerno.techSigned-off-by:
-
Dave Stevenson authored
vc4_dsi_encoder_disable is partially an open coded version of drm_bridge_chain_disable, but it missed a termination condition in the loop for ->disable which meant that no post_disable calls were made. Add in the termination clause. Fixes: 033bfe75 ("drm/vc4: dsi: Fix bridge chain handling") Signed-off-by:
-
Dave Stevenson authored
DSI0 seemingly had very little or no testing as a load of the register mappings were incorrect/missing, so host transfers always timed out due to enabling/checking incorrect bits in the interrupt enable and status registers. Fixes: 4078f575 ("drm/vc4: Add DSI driver") Signed-off-by:
-
Dave Stevenson authored
vc4_dsi was registering both dsi0 and dsi1 as VC4_ENCODER_TYPE_DSI1 which seemed to work OK for a single DSI display, but fails if there are two DSI displays connected. Update to register the correct type. Fixes: 4078f575 ("drm/vc4: Add DSI driver") Signed-off-by:
-
Dave Stevenson authored
For slightly unknown reasons, dsi0 takes a different pixel format to dsi1, and that has to be set in the pixel valve. Amend the setup accordingly. Fixes: a86773d1 ("drm/vc4: Add support for feeding DSI encoders from the pixel valve.") Signed-off-by:
-
Dave Stevenson authored
The divider calculations tried to find the divider just faster than the clock requested. However if it required a divider of 7 then the for loop aborted without handling the "error" case, and could end up with a clock lower than requested. The integer divider from parent PLL to DSI clock is also capable of going up to /255, not just /7 that the driver was trying. This allows for slower link frequencies on the DSI bus where the resolution permits. Correct the loop so that we always have a clock greater than requested, and covering the whole range of dividers. Fixes: 86c1b9ef ("drm/vc4: Adjust modes in DSI to work around the integer PLL divider.") Signed-off-by:
-
Dave Stevenson authored
On Pi0-3 the driver allocates a buffer and requests a DMA channel because the ARM can't write to DSI1's registers directly. However, we never release that buffer or channel. Let's add a device-managed action to release each. Fixes: 4078f575 ("drm/vc4: Add DSI driver") Signed-off-by:
-
Dave Stevenson authored
In a couple of error/incomplete configuration cases, the DPI_FORMAT bits wouldn't get set. Enforce our RGB888 default in all these cases. Signed-off-by:
-
Dave Stevenson authored
DRM provides flags for inverting pixel clock and output enable signals, but these were not mapped to the relevant registers. Add those mappings. Signed-off-by:
-
Dave Stevenson authored
The hardware can combine H&V syncs onto the output enable line as composite syncs, so add the relevant configuration to do that. Signed-off-by:
-
Dave Stevenson authored
This allows easy analysis of display lists when debugging. Signed-off-by:
-
Dave Stevenson authored
Move from only supporting the default of pre-multiplied alpha to supporting user specified blend mode using the standardised property. Signed-off-by:
-
