dri-devel February 2022

dri-devel@lists.freedesktop.org

394 participants
865 discussions

Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Document memory region specifier
by Thierry Reding 01 Apr '22

01 Apr '22

On Fri, Jul 02, 2021 at 05:16:25PM +0300, Dmitry Osipenko wrote: > 01.07.2021 21:14, Thierry Reding пишет: > > On Tue, Jun 08, 2021 at 06:51:40PM +0200, Thierry Reding wrote: > >> On Fri, May 28, 2021 at 06:54:55PM +0200, Thierry Reding wrote: > >>> On Thu, May 20, 2021 at 05:03:06PM -0500, Rob Herring wrote: > >>>> On Fri, Apr 23, 2021 at 06:32:30PM +0200, Thierry Reding wrote: > >>>>> From: Thierry Reding <treding(a)nvidia.com> > >>>>> > >>>>> Reserved memory region phandle references can be accompanied by a > >>>>> specifier that provides additional information about how that specific > >>>>> reference should be treated. > >>>>> > >>>>> One use-case is to mark a memory region as needing an identity mapping > >>>>> in the system's IOMMU for the device that references the region. This is > >>>>> needed for example when the bootloader has set up hardware (such as a > >>>>> display controller) to actively access a memory region (e.g. a boot > >>>>> splash screen framebuffer) during boot. The operating system can use the > >>>>> identity mapping flag from the specifier to make sure an IOMMU identity > >>>>> mapping is set up for the framebuffer before IOMMU translations are > >>>>> enabled for the display controller. > >>>>> > >>>>> Signed-off-by: Thierry Reding <treding(a)nvidia.com> > >>>>> --- > >>>>> .../reserved-memory/reserved-memory.txt | 21 +++++++++++++++++++ > >>>>> include/dt-bindings/reserved-memory.h | 8 +++++++ > >>>>> 2 files changed, 29 insertions(+) > >>>>> create mode 100644 include/dt-bindings/reserved-memory.h > >>>> > >>>> Sorry for being slow on this. I have 2 concerns. > >>>> > >>>> First, this creates an ABI issue. A DT with cells in 'memory-region' > >>>> will not be understood by an existing OS. I'm less concerned about this > >>>> if we address that with a stable fix. (Though I'm pretty sure we've > >>>> naively added #?-cells in the past ignoring this issue.) > >>> > >>> A while ago I had proposed adding memory-region*s* as an alternative > >>> name for memory-region to make the naming more consistent with other > >>> types of properties (think clocks, resets, gpios, ...). If we added > >>> that, we could easily differentiate between the "legacy" cases where > >>> no #memory-region-cells was allowed and the new cases where it was. > >>> > >>>> Second, it could be the bootloader setting up the reserved region. If a > >>>> node already has 'memory-region', then adding more regions is more > >>>> complicated compared to adding new properties. And defining what each > >>>> memory-region entry is or how many in schemas is impossible. > >>> > >>> It's true that updating the property gets a bit complicated, but it's > >>> not exactly rocket science. We really just need to splice the array. I > >>> have a working implemention for this in U-Boot. > >>> > >>> For what it's worth, we could run into the same issue with any new > >>> property that we add. Even if we renamed this to iommu-memory-region, > >>> it's still possible that a bootloader may have to update this property > >>> if it already exists (it could be hard-coded in DT, or it could have > >>> been added by some earlier bootloader or firmware). > >>> > >>>> Both could be addressed with a new property. Perhaps something like > >>>> 'iommu-memory-region = <&phandle>;'. I think the 'iommu' prefix is > >>>> appropriate given this is entirely because of the IOMMU being in the > >>>> mix. I might feel differently if we had other uses for cells, but I > >>>> don't really see it in this case. > >>> > >>> I'm afraid that down the road we'll end up with other cases and then we > >>> might proliferate a number of *-memory-region properties with varying > >>> prefixes. > >>> > >>> I am aware of one other case where we might need something like this: on > >>> some Tegra SoCs we have audio processors that will access memory buffers > >>> using a DMA engine. These processors are booted from early firmware > >>> using firmware from system memory. In order to avoid trashing the > >>> firmware, we need to reserve memory. We can do this using reserved > >>> memory nodes. However, the audio DMA engine also uses the SMMU, so we > >>> need to make sure that the firmware memory is marked as reserved within > >>> the SMMU. This is similar to the identity mapping case, but not exactly > >>> the same. Instead of creating a 1:1 mapping, we just want that IOVA > >>> region to be reserved (i.e. IOMMU_RESV_RESERVED instead of > >>> IOMMU_RESV_DIRECT{,_RELAXABLE}). > >>> > >>> That would also fall into the IOMMU domain, but we can't reuse the > >>> iommu-memory-region property for that because then we don't have enough > >>> information to decide which type of reservation we need. > >>> > >>> We could obviously make iommu-memory-region take a specifier, but we > >>> could just as well use memory-regions in that case since we have > >>> something more generic anyway. > >>> > >>> With the #memory-region-cells proposal, we can easily extend the cell in > >>> the specifier with an additional MEMORY_REGION_IOMMU_RESERVE flag to > >>> take that other use case into account. If we than also change to the new > >>> memory-regions property name, we avoid the ABI issue (and we gain a bit > >>> of consistency while at it). > >> > >> Ping? Rob, do you want me to add this second use-case to the patch > >> series to make it more obvious that this isn't just a one-off thing? Or > >> how do we proceed? > > > > Rob, given that additional use-case, do you want me to run with this > > proposal and send out an updated series? > > > What about variant with a "descriptor" properties that will describe > each region: > > fb_desc: display-framebuffer-memory-descriptor { > needs-identity-mapping; > } > > display@52400000 { > memory-region = <&fb ...>; > memory-region-descriptor = <&fb_desc ...>; > }; > > It could be a more flexible/extendible variant. This problem recently came up on #dri-devel again. Adding Alyssa and Sven who are facing a similar challenge on their work on Apple M1 (if I understood correctly). Also adding dri-devel for visibility since this is a very common problem for display in particular. On M1 the situation is slightly more complicated: the firmware will allocate a couple of buffers (including the framebuffer) in high memory (> 4 GiB) and use the IOMMU to map that into an IOVA region below 4 GiB so that the display hardware can access it. This makes it impossible to bypass the IOMMU like we do on other chips (in particular to work around the fault-by-default policy of the ARM SMMU driver). It also means that in addition to the simple reserved regions I mentioned we need for audio use-cases and identity mapping use-cases we need for display on Tegra, we now also need to be able to convey physical to IOVA mappings. Fitting the latter into the original proposal sounds difficult. A quick fix would've been to generate a mapping table in memory and pass that to the kernel using a reserved-memory node (similar to what's done for example on Tegra for the EMC frequency table on Tegra210) and mark it as such using a special flag. But that then involves two layers of parsing, which seems a bit suboptimal. Another way to shoehorn that into the original proposal would've been to add flags for physical and virtual address regions and use pairs to pass them using special flags. Again, this is a bit wonky because it needs these to be carefully parsed and matched up. Another downside is that we now have a situation where some of these regions are no longer "reserved-memory regions" in the traditional sense. This would require an additional flag in the reserved-memory region nodes to prevent the IOVA regions from being reserved. By the way, this is something that would also be needed for the audio use-case I mentioned before, because the physical memory at that address can still be used by an operating system. A more general solution would be to draw a bit from Dmitry's proposal and introduce a new top-level "iov-reserved-memory" node. This could be modelled on the existing reserved-memory node, except that the physical memory pages for regions represented by child nodes would not be marked as reserved. Only the IOVA range described by the region would be reserved subsequently by the IOMMU framework and/or IOMMU driver. The simplest case where we just want to reserve some IOVA region could then be done like this: iov-reserved-memory { /* * Probably safest to default to <2>, <2> here given * that most IOMMUs support either > 32 bits of IAS * or OAS. */ #address-cells = <2>; #size-cells = <2>; firmware: firmware@80000000 { reg = <0 0x80000000 0 0x01000000>; }; }; audio@30000000 { ... iov-memory-regions = <&firmware>; ... }; Mappings could be represented by an IOV reserved region taking a reference to the reserved-region that they map: reserved-memory { #address-cells = <2>; #size-cells = <2>; /* 16 MiB of framebuffer at top-of-memory */ framebuffer: framebuffer@1,ff000000 { reg = <0x1 0xff000000 0 0x01000000>; no-map; }; }; iov-reserved-memory { /* IOMMU supports only 32-bit output address space */ #address-cells = <1>; #size-cells = <1>; /* 16 MiB of framebuffer mapped to top of IOVA */ fb: fb@ff000000 { reg = <0 0xff000000 0 0x01000000>; memory-region = <&framebuffer>; }; }; display@40000000 { ... /* optional? */ memory-region = <&framebuffer>; iov-memory-regions = <&fb>; ... }; It's interesting how identity mapped regions now become a trivial special case of mappings. All that is needed is to make the reg property of the IOV reserved region correspond to the reg property of the normal reserved region. Alternatively, as a small optimization for lazy people like me, we could just allow these cases to omit the reg property and instead inherit it from the referenced reserved region. As the second example shows it might be convenient if memory-region could be derived from iov-memory-regions. This could be useful for cases where the driver wants to do something with the physical pages of the reserved region (such as mapping them and copying out the framebuffer data to another buffer so that the reserved memory can be recycled). If we have the IOV reserved region, we could provide an API to extract the physical reserved region (if it exists). That way we could avoid referencing it twice in DT. Then again, there's something elegant about the explicit second reference to. It indicates the intent that we may want to use the region for something other than just the IOV mapping. Anyway, this has been long enough. Let me know what you think. Alyssa, Sven, it'd be interesting to hear if you think this could work as a solution to the problem on M1. Rob, I think you might like this alternative because it basically gets rid of all the points in the original proposal that you were concerned about. Let me know what you think. Thierry

3 12

[PATCH i-g-t 00/11] Per client GPU utilisation
by Tvrtko Ursulin 01 Apr '22

01 Apr '22

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> This series contains four main components: 1. Per client support for intel_gpu_top. 2. IGT test for per client data exposed via fdinfo from i915. 3. Extracting intel_gpu_top code into shared IGT libraries - which makes possible to write: 4. Vendor agnostic rudimentary gputop tool. Since I had the intel_gpu_top code for years, this flow of the series is what I ended up with. But it also makes sense since we can have a cut point after intel_gpu_top, in case the common drm fdinfo specification does not end up getting enough traction. Example of the intel_gpu_top output: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz 70% RC6; 0.62/ 7.08 W; 760 irqs/s ENGINES BUSY MI_SEMA MI_WAIT Render/3D 23.06% |██████▊ | 0% 0% Blitter 0.00% | | 0% 0% Video 5.40% |█▋ | 0% 0% VideoEnhance 20.67% |██████ | 0% 0% PID NAME Render/3D Blitter Video VideoEnhance 3082 mpv | || ||▌ ||██ | 3117 neverball |█▉ || || || | 1 systemd |▍ || || || | 2338 gnome-shell | || || || | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Example of the gputop output: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ DRM minor 0 PID NAME render copy video 3816 kwin_x11 |███▎ || || || | 3523 Xorg |▊ || || || | 1120449 mpv | || ||▋ || | 1120529 glxgears |▋ || || || | 1120449 mpv |▍ || || || | 3860 plasmashell |▏ || || || | 4764 krunner | || || || | 575206 chrome | || || || | 833481 firefox | || || || | 892924 thunderbird | || || || | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Tvrtko Ursulin (11): lib: Helper library for parsing i915 fdinfo output tests/i915/drm_fdinfo: Basic and functional tests for GPU busyness exported via fdinfo intel-gpu-top: Add support for per client stats lib: Extract igt_drm_clients from intel_gpu_top libdrmfdinfo: Allow specifying custom engine map libdrmclients: Record client drm minor libdrmclient: Support multiple DRM cards libdrmfdinfo: Track largest engine index libdrmclient/intel_gpu_top: Decouple hardcoded engine assumptions libdrmclient: Enforce client status sort order in the library gputop: Basic vendor agnostic GPU top tool lib/igt_drm_clients.c | 443 +++++++++++++++++++++++++++++++ lib/igt_drm_clients.h | 104 ++++++++ lib/igt_drm_fdinfo.c | 200 ++++++++++++++ lib/igt_drm_fdinfo.h | 52 ++++ lib/meson.build | 15 ++ man/intel_gpu_top.rst | 4 + tests/i915/drm_fdinfo.c | 565 ++++++++++++++++++++++++++++++++++++++++ tests/meson.build | 8 + tools/gputop.c | 276 ++++++++++++++++++++ tools/intel_gpu_top.c | 497 ++++++++++++++++++++++++++++++++++- tools/meson.build | 7 +- 11 files changed, 2159 insertions(+), 12 deletions(-) create mode 100644 lib/igt_drm_clients.c create mode 100644 lib/igt_drm_clients.h create mode 100644 lib/igt_drm_fdinfo.c create mode 100644 lib/igt_drm_fdinfo.h create mode 100644 tests/i915/drm_fdinfo.c create mode 100644 tools/gputop.c -- 2.32.0

2 17

[Bug 214071] New: amdgpu idle power draw to high at +75Hz
by bugzilla-daemon＠bugzilla.kernel.org 31 Mar '22

31 Mar '22

https://bugzilla.kernel.org/show_bug.cgi?id=214071 Bug ID: 214071 Summary: amdgpu idle power draw to high at +75Hz Product: Drivers Version: 2.5 Kernel Version: 5.13.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: pb.g(a)gmx.de Regression: No For best viewing pleasure I usually set my monitor to 144Hz and native 1080p. At that refresh rate my RX6900XT draws about 35 Watts in idle situations Memory clock stays at 1000Hz. I have to lower the monitors refresh rate to 75Hz, then the card draws only 8 Watts in idle and memory clock goes significantly down to 96MHz. Using 100 or 120 Hz does not help. Situation in windows is different. The same hardware setup works in Windows10 at 1080p@144 with idle power draw of just 8 Watts. So my guess is this is a driver issue and not a hardware issue. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 4

[PATCH v2 00/12] iio: buffer-dma: write() and new DMABUF based API
by Paul Cercueil 30 Mar '22

30 Mar '22

Hi Jonathan, This is the V2 of my patchset that introduces a new userspace interface based on DMABUF objects to complement the fileio API, and adds write() support to the existing fileio API. Changes since v1: - the patches that were merged in v1 have been (obviously) dropped from this patchset; - the patch that was setting the write-combine cache setting has been dropped as well, as it was simply not useful. - [01/12]: * Only remove the outgoing queue, and keep the incoming queue, as we want the buffer to start streaming data as soon as it is enabled. * Remove IIO_BLOCK_STATE_DEQUEUED, since it is now functionally the same as IIO_BLOCK_STATE_DONE. - [02/12]: * Fix block->state not being reset in iio_dma_buffer_request_update() for output buffers. * Only update block->bytes_used once and add a comment about why we update it. * Add a comment about why we're setting a different state for output buffers in iio_dma_buffer_request_update() * Remove useless cast to bool (!!) in iio_dma_buffer_io() - [05/12]: Only allow the new IOCTLs on the buffer FD created with IIO_BUFFER_GET_FD_IOCTL(). - [12/12]: * Explicitly state that the new interface is optional and is not implemented by all drivers. * The IOCTLs can now only be called on the buffer FD returned by IIO_BUFFER_GET_FD_IOCTL. * Move the page up a bit in the index since it is core stuff and not driver-specific. The patches not listed here have not been modified since v1. Cheers, -Paul Alexandru Ardelean (1): iio: buffer-dma: split iio_dma_buffer_fileio_free() function Paul Cercueil (11): iio: buffer-dma: Get rid of outgoing queue iio: buffer-dma: Enable buffer write support iio: buffer-dmaengine: Support specifying buffer direction iio: buffer-dmaengine: Enable write support iio: core: Add new DMABUF interface infrastructure iio: buffer-dma: Use DMABUFs instead of custom solution iio: buffer-dma: Implement new DMABUF based userspace API iio: buffer-dmaengine: Support new DMABUF based userspace API iio: core: Add support for cyclic buffers iio: buffer-dmaengine: Add support for cyclic buffers Documentation: iio: Document high-speed DMABUF based API Documentation/driver-api/dma-buf.rst | 2 + Documentation/iio/dmabuf_api.rst | 94 +++ Documentation/iio/index.rst | 2 + drivers/iio/adc/adi-axi-adc.c | 3 +- drivers/iio/buffer/industrialio-buffer-dma.c | 610 ++++++++++++++---- .../buffer/industrialio-buffer-dmaengine.c | 42 +- drivers/iio/industrialio-buffer.c | 60 ++ include/linux/iio/buffer-dma.h | 38 +- include/linux/iio/buffer-dmaengine.h | 5 +- include/linux/iio/buffer_impl.h | 8 + include/uapi/linux/iio/buffer.h | 30 + 11 files changed, 749 insertions(+), 145 deletions(-) create mode 100644 Documentation/iio/dmabuf_api.rst -- 2.34.1

7 40

[PATCH] drm/amdgpu: fix that issue that the number of the crtc of the 3250c is not correct
by RyanLin 30 Mar '22

30 Mar '22

[Why] External displays take priority over internal display when there are fewer display controllers than displays. [How] The root cause is because of that number of the crtc is not correct. The number of the crtc on the 3250c is 3, but on the 3500c is 4. On the source code, we can see that number of the crtc has been fixed at 4. Needs to set the num_crtc to 3 for 3250c platform. Signed-off-by: RyanLin <Tsung-Hua.Lin(a)amd.com> Change-Id: I837df7101cc4849d2c3021fd529b4061edab4bb1 --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 40c91b448f7d..dbeef7b57a9b 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -2738,9 +2738,15 @@ static int dm_early_init(void *handle) break; #if defined(CONFIG_DRM_AMD_DC_DCN1_0) case CHIP_RAVEN: - adev->mode_info.num_crtc = 4; - adev->mode_info.num_hpd = 4; - adev->mode_info.num_dig = 4; + if (adev->rev_id >= 8) { //chip_name = "raven2"; + adev->mode_info.num_crtc = 3; + adev->mode_info.num_hpd = 3; + adev->mode_info.num_dig = 3; + } else { + adev->mode_info.num_crtc = 4; + adev->mode_info.num_hpd = 4; + adev->mode_info.num_dig = 4; + } break; #endif #if defined(CONFIG_DRM_AMD_DC_DCN2_0) -- 2.25.1

7 9

[PATCH v6 00/12] clk: Improve clock range handling
by Maxime Ripard 30 Mar '22

30 Mar '22

Hi, This is a follow-up of the discussion here: https://lore.kernel.org/linux-clk/20210319150355.xzw7ikwdaga2dwhv@gilmour/ and here: https://lore.kernel.org/all/20210914093515.260031-1-maxime@cerno.tech/ While the initial proposal implemented a new API to temporarily raise and lower clock rates based on consumer workloads, Stephen suggested an alternative approach implemented here. The main issue that needed to be addressed in our case was that in a situation where we would have multiple calls to clk_set_rate_range, we would end up with a clock at the maximum of the minimums being set. This would be expected, but the issue was that if one of the users was to relax or drop its requirements, the rate would be left unchanged, even though the ideal rate would have changed. So something like clk_set_rate(user1_clk, 1000); clk_set_min_rate(user1_clk, 2000); clk_set_min_rate(user2_clk, 3000); clk_set_min_rate(user2_clk, 1000); Would leave the clock running at 3000Hz, while the minimum would now be 2000Hz. This was mostly due to the fact that the core only triggers a rate change in clk_set_rate_range() if the current rate is outside of the boundaries, but not if it's within the new boundaries. That series changes that and will trigger a rate change on every call, with the former rate being tried again. This way, providers have a chance to follow whatever policy they see fit for a given clock each time the boundaries change. This series also implements some kunit tests, first to test a few rate related functions in the CCF, and then extends it to make sure that behaviour has some test coverage. Let me know what you think Maxime Changes from v5: - Changed clk_hw_create_clk for clk_hw_get_clk since the former isn't exported to modules. - Added fix for clk_hw_get_clk Changes from v4: - Rename the test file - Move all the tests to the first patch, and fix them up as fixes are done - Improved the test conditions - Added more tests - Improved commit messages - Fixed a regression where two disjoints clock ranges would now be accepted Changes from v3: - Renamed the test file and Kconfig option - Add option to .kunitconfig - Switch to kunit_kzalloc - Use KUNIT_EXPECT_* instead of KUNIT_ASSERT_* where relevant - Test directly relevant calls instead of going through a temporary variable - Switch to more precise KUNIT_ASSERT_* macros where relevant Changes from v2: - Rebased on current next - Rewrote the whole thing according to Stephen reviews - Implemented some kunit tests Changes from v1: - Return NULL in clk_request_start if clk pointer is NULL - Test for clk_req pointer in clk_request_done - Add another user in vc4 - Rebased on top of v5.15-rc1 Maxime Ripard (12): clk: Fix clk_hw_get_clk() when dev is NULL clk: Introduce Kunit Tests for the framework clk: Enforce that disjoints limits are invalid clk: Always clamp the rounded rate clk: Use clamp instead of open-coding our own clk: Always set the rate on clk_set_range_rate clk: Add clk_drop_range clk: bcm: rpi: Add variant structure clk: bcm: rpi: Set a default minimum rate clk: bcm: rpi: Run some clocks at the minimum rate allowed drm/vc4: Add logging and comments drm/vc4: hdmi: Remove clock rate initialization drivers/clk/.kunitconfig | 1 + drivers/clk/Kconfig | 7 + drivers/clk/Makefile | 1 + drivers/clk/bcm/clk-raspberrypi.c | 125 ++++- drivers/clk/clk.c | 76 ++- drivers/clk/clk_test.c | 790 ++++++++++++++++++++++++++++++ drivers/gpu/drm/vc4/vc4_hdmi.c | 13 - drivers/gpu/drm/vc4/vc4_kms.c | 11 + include/linux/clk.h | 11 + 9 files changed, 980 insertions(+), 55 deletions(-) create mode 100644 drivers/clk/clk_test.c -- 2.35.1

3 28

[PATCH 1/3] drm/msm/dpu: index dpu_kms->hw_vbif using vbif_idx
by Dmitry Baryshkov 29 Mar '22

29 Mar '22

Remove loops over hw_vbif. Instead always VBIF's idx as an index in the array. This fixes an error in dpu_kms_hw_init(), where we fill dpu_kms->hw_vbif[i], but check for an error pointer at dpu_kms->hw_vbif[vbif_idx]. Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++++---- drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 29 +++++++++++------------- 2 files changed, 17 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index d0653a9ec694..81a35c8d62e7 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -790,11 +790,9 @@ static void _dpu_kms_hw_destroy(struct dpu_kms *dpu_kms) _dpu_kms_mmu_destroy(dpu_kms); if (dpu_kms->catalog) { - for (i = 0; i < dpu_kms->catalog->vbif_count; i++) { - u32 vbif_idx = dpu_kms->catalog->vbif[i].id; - - if ((vbif_idx < VBIF_MAX) && dpu_kms->hw_vbif[vbif_idx]) - dpu_hw_vbif_destroy(dpu_kms->hw_vbif[vbif_idx]); + for (i = 0; i < ARRAY_SIZE(dpu_kms->hw_vbif); i++) { + if (dpu_kms->hw_vbif[i]) + dpu_hw_vbif_destroy(dpu_kms->hw_vbif[i]); } } @@ -1102,7 +1100,7 @@ static int dpu_kms_hw_init(struct msm_kms *kms) for (i = 0; i < dpu_kms->catalog->vbif_count; i++) { u32 vbif_idx = dpu_kms->catalog->vbif[i].id; - dpu_kms->hw_vbif[i] = dpu_hw_vbif_init(vbif_idx, + dpu_kms->hw_vbif[vbif_idx] = dpu_hw_vbif_init(vbif_idx, dpu_kms->vbif[vbif_idx], dpu_kms->catalog); if (IS_ERR_OR_NULL(dpu_kms->hw_vbif[vbif_idx])) { rc = PTR_ERR(dpu_kms->hw_vbif[vbif_idx]); diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c index 21d20373eb8b..cbbf77b17fc3 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c @@ -11,6 +11,14 @@ #include "dpu_hw_vbif.h" #include "dpu_trace.h" +static struct dpu_hw_vbif *dpu_get_vbif(struct dpu_kms *dpu_kms, enum dpu_vbif vbif_idx) +{ + if (vbif_idx > ARRAY_SIZE(dpu_kms->hw_vbif)) + return dpu_kms->hw_vbif[vbif_idx]; + + return NULL; +} + /** * _dpu_vbif_wait_for_xin_halt - wait for the xin to halt * @vbif: Pointer to hardware vbif driver @@ -148,20 +156,15 @@ static u32 _dpu_vbif_get_ot_limit(struct dpu_hw_vbif *vbif, void dpu_vbif_set_ot_limit(struct dpu_kms *dpu_kms, struct dpu_vbif_set_ot_params *params) { - struct dpu_hw_vbif *vbif = NULL; + struct dpu_hw_vbif *vbif; struct dpu_hw_mdp *mdp; bool forced_on = false; u32 ot_lim; - int ret, i; + int ret; mdp = dpu_kms->hw_mdp; - for (i = 0; i < ARRAY_SIZE(dpu_kms->hw_vbif); i++) { - if (dpu_kms->hw_vbif[i] && - dpu_kms->hw_vbif[i]->idx == params->vbif_idx) - vbif = dpu_kms->hw_vbif[i]; - } - + vbif = dpu_get_vbif(dpu_kms, params->vbif_idx); if (!vbif || !mdp) { DRM_DEBUG_ATOMIC("invalid arguments vbif %d mdp %d\n", vbif != NULL, mdp != NULL); @@ -204,7 +207,7 @@ void dpu_vbif_set_ot_limit(struct dpu_kms *dpu_kms, void dpu_vbif_set_qos_remap(struct dpu_kms *dpu_kms, struct dpu_vbif_set_qos_params *params) { - struct dpu_hw_vbif *vbif = NULL; + struct dpu_hw_vbif *vbif; struct dpu_hw_mdp *mdp; bool forced_on = false; const struct dpu_vbif_qos_tbl *qos_tbl; @@ -216,13 +219,7 @@ void dpu_vbif_set_qos_remap(struct dpu_kms *dpu_kms, } mdp = dpu_kms->hw_mdp; - for (i = 0; i < ARRAY_SIZE(dpu_kms->hw_vbif); i++) { - if (dpu_kms->hw_vbif[i] && - dpu_kms->hw_vbif[i]->idx == params->vbif_idx) { - vbif = dpu_kms->hw_vbif[i]; - break; - } - } + vbif = dpu_get_vbif(dpu_kms, params->vbif_idx); if (!vbif || !vbif->cap) { DPU_ERROR("invalid vbif %d\n", params->vbif_idx); -- 2.34.1

2 5

[Bug 213983] New: WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm]
by bugzilla-daemon＠bugzilla.kernel.org 29 Mar '22

29 Mar '22

https://bugzilla.kernel.org/show_bug.cgi?id=213983 Bug ID: 213983 Summary: WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm] Product: Drivers Version: 2.5 Kernel Version: 5.14-rc4 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: erhard_f(a)mailbox.org Regression: No Created attachment 298221 --> https://bugzilla.kernel.org/attachment.cgi?id=298221&action=edit kernel dmesg (5.14-rc4, AMD A10-7860K) System was running fine for hours but got this at reboot: [...] [35939.202358] ------------[ cut here ]------------ [35939.202603] WARNING: CPU: 3 PID: 520 at drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x7a/0x803 [ttm] [35939.202870] Modules linked in: rfkill dm_crypt nhpoly1305_sse2 nhpoly1305 chacha_generic chacha_x86_64 libchacha adiantum libpoly1305 algif_skcipher input_leds joydev led_class dm_mod hid_generic usbhid hid raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx amdgpu md_mod evdev f2fs crc32_generic lz4hc_compress lz4_compress lz4_decompress edac_mce_amd crc32_pclmul ext4 crc16 mbcache jbd2 ohci_pci snd_hda_codec_hdmi drm_ttm_helper ttm aesni_intel snd_hda_intel mfd_core libaes crypto_simd cryptd gpu_sched snd_intel_dspcfg i2c_algo_bit k10temp snd_hda_codec fam15h_power i2c_piix4 snd_hwdep drm_kms_helper snd_hda_core ohci_hcd cfbfillrect ehci_pci xhci_pci xhci_hcd ehci_hcd syscopyarea cfbimgblt snd_pcm sysfillrect sysimgblt usbcore fb_sys_fops snd_timer cfbcopyarea usb_common snd soundcore video acpi_cpufreq processor button zram nct6775 zsmalloc hwmon_vid hwmon drm nfsd fb fuse font fbdev auth_rpcgss drm_panel_orientation_quirks backlight lockd grace configfs sunrpc [35939.203200] efivarfs [35939.205121] CPU: 3 PID: 520 Comm: X Not tainted 5.14.0-rc4-bdver3 #2 [35939.212327] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./A88M-G/3.1, BIOS P1.40C 11/21/2016 [35939.219364] RIP: 0010:ttm_bo_release+0x7a/0x803 [ttm] [35939.219387] Code: e0 2a 48 c1 ea 03 8a 14 02 48 8b 04 24 83 e0 07 83 c0 03 38 d0 7c 0d 84 d2 74 09 48 8b 3c 24 e8 99 eb 7c dd 83 7b 4c 00 74 02 <0f> 0b 48 8d 43 18 48 89 c2 48 89 44 24 10 b8 ff ff 37 00 48 c1 ea [35939.230367] RSP: 0018:ffffc900050dfb08 EFLAGS: 00010202 [35939.230376] RAX: 0000000000000007 RBX: ffff8881716441f0 RCX: ffff8881716441f0 [35939.230381] RDX: 1ffff1102e2c8800 RSI: 0000000000000004 RDI: ffff8881716441f0 [35939.230387] RBP: ffff8881716441d8 R08: 0000000000000001 R09: ffffed102e2c883f [35939.230391] R10: ffff8881716441f3 R11: ffffffffc0b6a201 R12: ffff888115000010 [35939.264555] R13: ffff888115005608 R14: ffff888171644058 R15: ffffffff9f5cf160 [35939.264564] FS: 00007fe7325f9980(0000) GS:ffff8883e0580000(0000) knlGS:0000000000000000 [35939.264572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35939.264579] CR2: 00007fe73190d0e8 CR3: 0000000141978000 CR4: 00000000000506e0 [35939.264586] Call Trace: [35939.264591] ? fsnotify_grab_connector+0x8c/0x93 [35939.264608] amdgpu_bo_unref+0x30/0x57 [amdgpu] [35939.318763] amdgpu_gem_object_free+0x69/0x95 [amdgpu] [35939.319132] ? list_add+0xd1/0xd1 [amdgpu] [35939.319478] ? test_bit+0x1d/0x27 [35939.319489] drm_gem_dmabuf_release+0x5b/0x67 [drm] [35939.319551] dma_buf_release+0x113/0x1b6 [35939.319563] __dentry_kill+0x29e/0x302 [35939.319573] dput+0x184/0x1c3 [35939.319582] __fput+0x4dc/0x598 [35939.319590] task_work_run+0xfa/0x118 [35939.319599] do_exit+0x984/0x17ba [35939.319609] ? mm_update_next_owner+0x3fd/0x3fd [35939.319619] do_group_exit+0x229/0x229 [35939.319627] __x64_sys_exit_group+0x39/0x39 [35939.319635] do_syscall_64+0x75/0x88 [35939.319649] ? do_syscall_64+0xe/0x88 [35939.319658] entry_SYSCALL_64_after_hwframe+0x44/0xae [35939.319668] RIP: 0033:0x7fe731edd459 [35939.319676] Code: Unable to access opcode bytes at RIP 0x7fe731edd42f. [35939.319680] RSP: 002b:00007ffc8d3e1298 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 [35939.319691] RAX: ffffffffffffffda RBX: 00007fe731fc6920 RCX: 00007fe731edd459 [35939.319698] RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000 [35939.319704] RBP: 00007fe731fc6920 R08: fffffffffffffd40 R09: 00005630715eb7c0 [35939.319711] R10: 00007fe710db0a14 R11: 0000000000000246 R12: 0000000000000000 [35939.319716] R13: 0000000000000000 R14: 0000000000000668 R15: 0000000000000000 [35939.319724] ---[ end trace 0f92591c8b7a0f11 ]--- # inxi -bZ System: Kernel: 5.14.0-rc4-bdver3 x86_64 bits: 64 Desktop: MATE 1.24.1 Distro: Gentoo Base System release 2.7 Machine: Type: Desktop Mobo: ASRock model: A88M-G/3.1 serial: <superuser/root required> UEFI: American Megatrends v: P1.40C date: 11/21/2016 CPU: Info: Quad Core AMD A10-7860K Radeon R7 12 Compute Cores 4C+8G [MCP] speed: 1560 MHz min/max: 1400/3600 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Kaveri [Radeon R7 Graphics] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.11 driver: amdgpu,ati unloaded: fbdev,modesetting resolution: 1920x1080~60Hz OpenGL: renderer: AMD KAVERI (DRM 3.42.0 5.14.0-rc4-bdver3 LLVM 12.0.1) v: 4.6 Mesa 21.1.4 Network: Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 Drives: Local Storage: total: 9.33 TiB used: 4.13 TiB (44.3%) Info: Processes: 225 Uptime: 16m Memory: 13.32 GiB used: 1.38 GiB (10.3%) Shell: Bash inxi: 3.1.06 # lspci -s 00:01.0 -vv 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R7 Graphics] (rev d6) (prog-if 00 [VGA controller]) Subsystem: ASRock Incorporation Kaveri [Radeon R7 Graphics] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 62 IOMMU group: 0 Region 0: Memory at c0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at d0000000 (64-bit, prefetchable) [size=8M] Region 4: I/O ports at f000 [size=256] Region 5: Memory at feb00000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [48] Vendor Specific Information: Len=08 <?> Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0 ExtTag+ RBE+ FLReset- DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+ MaxPayload 256 bytes, MaxReadReq 512 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt+ EETLPPrefix+, MaxEETLPPrefixes 1 EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- OBFF Disabled, AtomicOpsCtl: ReqEn- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee04004 Data: 002a Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [270 v1] Secondary PCI Express LnkCtl3: LnkEquIntrruptEn- PerformEqu- LaneErrStat: 0 Capabilities: [2b0 v1] Address Translation Service (ATS) ATSCap: Invalidate Queue Depth: 00 ATSCtl: Enable+, Smallest Translation Unit: 00 Capabilities: [2c0 v1] Page Request Interface (PRI) PRICtl: Enable- Reset- PRISta: RF- UPRGI- Stopped+ Page Request Capacity: 00000020, Page Request Allocation: 00000000 Capabilities: [2d0 v1] Process Address Space ID (PASID) PASIDCap: Exec- Priv-, Max PASID Width: 10 PASIDCtl: Enable- Exec- Priv- Kernel driver in use: amdgpu Kernel modules: amdgpu -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

2 6

[PATCH] drm/imx: make static read-only array channel_offsets const
by Colin Ian King 29 Mar '22

29 Mar '22

The static array channel_offsets is read-only so it make sense to make it const. Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> --- drivers/gpu/ipu-v3/ipu-dc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c index ca96b235491a..b038a6d7307b 100644 --- a/drivers/gpu/ipu-v3/ipu-dc.c +++ b/drivers/gpu/ipu-v3/ipu-dc.c @@ -344,8 +344,9 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev, unsigned long base, unsigned long template_base) { struct ipu_dc_priv *priv; - static int channel_offsets[] = { 0, 0x1c, 0x38, 0x54, 0x58, 0x5c, - 0x78, 0, 0x94, 0xb4}; + static const int channel_offsets[] = { + 0, 0x1c, 0x38, 0x54, 0x58, 0x5c, 0x78, 0, 0x94, 0xb4 + }; int i; priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); -- 2.33.1

2 1

[PATCH] gpu: ipu-v3: Fix dev_dbg frequency output
by Mark Jonas 29 Mar '22

29 Mar '22

From: Leo Ruan <tingquan.ruan(a)cn.bosch.com> This commit corrects the printing of the IPU clock error percentage if it is between -0.1% to -0.9%. For example, if the pixel clock requested is 27.2 MHz but only 27.0 MHz can be achieved the deviation is -0.8%. But the fixed point math had a flaw and calculated error of 0.2%. Before: Clocks: IPU 270000000Hz DI 24716667Hz Needed 27200000Hz IPU clock can give 27000000 with divider 10, error 0.2% Want 27200000Hz IPU 270000000Hz DI 24716667Hz using IPU, 27000000Hz After: Clocks: IPU 270000000Hz DI 24716667Hz Needed 27200000Hz IPU clock can give 27000000 with divider 10, error -0.8% Want 27200000Hz IPU 270000000Hz DI 24716667Hz using IPU, 27000000Hz Signed-off-by: Leo Ruan <tingquan.ruan(a)cn.bosch.com> Signed-off-by: Mark Jonas <mark.jonas(a)de.bosch.com> --- drivers/gpu/ipu-v3/ipu-di.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c index b4a31d506fcc..74eca68891ad 100644 --- a/drivers/gpu/ipu-v3/ipu-di.c +++ b/drivers/gpu/ipu-v3/ipu-di.c @@ -451,8 +451,9 @@ static void ipu_di_config_clock(struct ipu_di *di, error = rate / (sig->mode.pixelclock / 1000); - dev_dbg(di->ipu->dev, " IPU clock can give %lu with divider %u, error %d.%u%%\n", - rate, div, (signed)(error - 1000) / 10, error % 10); + dev_dbg(di->ipu->dev, " IPU clock can give %lu with divider %u, error %c%d.%d%%\n", + rate, div, error < 1000 ? '-' : '+', + abs(error - 1000) / 10, abs(error - 1000) % 10); /* Allow a 1% error */ if (error < 1010 && error >= 990) { -- 2.17.1

4 5

← Newer
1
...
4
5
6
7
8
9
10
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel February 2022