dri-devel September 2020

dri-devel@lists.freedesktop.org

359 participants
868 discussions

[PATCH 1/2] drm/qxl: don't touch mem.bus.offset
by Christian König 07 Sep '20

07 Sep '20

This is internal to TTM and should not be used by drivers directly. Drop the call to qxl_ttm_io_mem_reserve() and use mem->start instead. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/gpu/drm/qxl/qxl_object.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c index f838b6d689aa..b2a1fa61920b 100644 --- a/drivers/gpu/drm/qxl/qxl_object.c +++ b/drivers/gpu/drm/qxl/qxl_object.c @@ -167,6 +167,7 @@ int qxl_bo_kmap(struct qxl_bo *bo, void **ptr) void *qxl_bo_kmap_atomic_page(struct qxl_device *qdev, struct qxl_bo *bo, int page_offset) { + unsigned long offset; void *rptr; int ret; struct io_mapping *map; @@ -178,9 +179,8 @@ void *qxl_bo_kmap_atomic_page(struct qxl_device *qdev, else goto fallback; - ret = qxl_ttm_io_mem_reserve(bo->tbo.bdev, &bo->tbo.mem); - - return io_mapping_map_atomic_wc(map, bo->tbo.mem.bus.offset + page_offset); + offset = bo->tbo.mem.start << PAGE_SHIFT; + return io_mapping_map_atomic_wc(map, offset + page_offset); fallback: if (bo->kptr) { rptr = bo->kptr + (page_offset * PAGE_SIZE); -- 2.17.1

2 2

[PATCH v11 00/11] PCI: brcmstb: enable PCIe for STB chips
by Jim Quinlan 07 Sep '20

07 Sep '20

Patchset Summary: Enhance a PCIe host controller driver. Because of its unusual design we are foced to change dev->dma_pfn_offset into a more general role allowing multiple offsets. See the 'v1' notes below for more info. v11: Commit: "device-mapping: Introduce DMA range map, supplanting ..." -- Rebased to latest torvalds, Aug 20, 2020. -- Minor change in of_dma_get_range() to satisfy the kernel's robot tester. -- Use of PFN_DOWN(), PFN_PHYS() instead of explicit shifts (Andy) -- Eliminate extra return in dma_offset_from_xxx_addr() (Andy) -- Change dma_set_offset_range() to correctly handle the case of pre-existing DMA map and zero offset. v10: Commit: "device-mapping: Introduce DMA range map, supplanting ..." -- change title of commit; "bus core:" => "device-mapping:" -- instead of allocating the DMA map with devm, use kcalloc and call kfree() during device_release(). (RobH) Also, for three cases that want to use the same DMA map, copy the dma_range_map using a helper function. -- added a missing 'return = 0;' to of_dma_get_range(). (Nicolas) -- removed dma_range_overlaps(); instead return error if there is an existing DMA map. (Christoph). Commit: "PCI: brcmstb: Set additional internal memory DMA ..." -- Changed constant 1 to 1ULL. (Nicolas) Commit: "ata: ahci_brcm: Fix use of BCM7216 reset controller" This commit has been removed from this patchset and will be submitted on its own. v9: Commit: "device core: Introduce DMA range map, supplanting ..." -- A number of code improvements were implemented as suggested by ChristophH. Unfortunately, some of these changes reversed the implemented suggestions of other reviewers; for example, the new macros PFN_DMA_ADDR(), DMA_ADDR_PFN() have been pulled. v8: Commit: "device core: Introduce DMA range map, supplanting ..." -- To satisfy a specific m68 compile configuration, I moved the 'struct bus_dma_region; definition out of #ifdef CONFIG_HAS_DMA and also defined three inline functions for !CONFIG_HAS_DMA (kernel test robot). -- The sunXi drivers -- suc4i_csi, sun6i_csi, cedrus_hw -- set a pfn_offset outside of_dma_configure() but the code offers no insight on the size of the translation window. V7 had me using SIZE_MAX as the size. I have since contacted the sunXi maintainer and he said that using a size of SZ_4G would cover sunXi configurations. v7: Commit: "device core: Introduce DMA range map, supplanting ..." -- remove second kcalloc/copy in device.c (AndyS) -- use PTR_ERR_OR_ZERO() and PHYS_PFN() (AndyS) -- indentation, sizeof(struct ...) => sizeof(*r) (AndyS) -- add pfn.h definitions: PFN_DMA_ADDR(), DMA_ADDR_PFN() (AndyS) -- Fixed compile error in "sun6i_csi.c" (kernel test robot) Commit "ata: ahci_brcm: Fix use of BCM7216 reset controller" -- correct name of function in the commit msg (SergeiS) v6: Commit "device core: Introduce DMA range map": -- of_dma_get_range() now takes a single argument and returns either NULL, a valid map, or an ERR_PTR. (Robin) -- offsets are no longer a PFN value but an actual address. (Robin) -- the bus_dma_region struct stores the range size instead of the cpu_end and pci_end values. (Robin) -- devices that were setting a single offset with no boundaries have been modified to have boundaries; in a few places where this information was unavilable a /* FIXME: ... */ comment was added. (Robin) -- dma_attach_offset_range() can be called when an offset map already exists; if it's range is already present nothing is done and success is returned. (Robin) All commits: -- Man name/style/corrections/etc changed (Bjorn) -- rebase to Torvalds master v5: Commit "device core: Introduce multiple dma pfn offsets" -- in of/address.c: "map_size = 0" => "*map_size = 0" -- use kcalloc instead of kzalloc (AndyS) -- use PHYS_ADDR_MAX instead of "~(phys_addr_t)0" Commit "PCI: brcmstb: Set internal memory viewport sizes" -- now gives error on missing dma-ranges property. Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips" -- removed "Allof:" from brcm,scb-sizes definition (RobH) All Commits: -- indentation style, use max chars 100 (AndyS) -- rebased to torvalds master v4: Commit "device core: Introduce multiple dma pfn offsets" -- of_dma_get_range() does not take a dev param but instead takes two "out" params: map and map_size. We do this so that the code that parses dma-ranges is separate from the code that modifies 'dev'. (Nicolas) -- the separate case of having a single pfn offset has been removed and is now processed by going through the map array. (Nicolas) -- move attach_uniform_dma_pfn_offset() from of/address.c to dma/mapping.c so that it does not depend on CONFIG_OF. (Nicolas) -- devm_kcalloc => devm_kzalloc (DanC) -- add/fix assignment to dev->dma_pfn_offset_map for func attach_uniform_dma_pfn_offset() (DanC, Nicolas) -- s/struct dma_pfn_offset_region/struct bus_dma_region/ (Nicolas) -- s/attach_uniform_dma_pfn_offset/dma_attach_uniform_pfn_offset/ -- s/attach_dma_pfn_offset_map/dma_attach_pfn_offset_map/ -- More use of PFN_{PHYS,DOWN,UP}. (AndyS) Commit "of: Include a dev param in of_dma_get_range()" -- this commit was sqaushed with "device core: Introduce ..." v3: Commit "device core: Introduce multiple dma pfn offsets" Commit "arm: dma-mapping: Invoke dma offset func if needed" -- The above two commits have been squashed. More importantly, the code has been modified so that the functionality for multiple pfn offsets subsumes the use of dev->dma_pfn_offset. In fact, dma_pfn_offset is removed and supplanted by dma_pfn_offset_map, which is a pointer to an array. The more common case of a uniform offset is now handled as a map with a single entry, while cases requiring multiple pfn offsets use a map with multiple entries. Code paths that used to do this: dev->dma_pfn_offset = mydrivers_pfn_offset; have been changed to do this: attach_uniform_dma_pfn_offset(dev, pfn_offset); Commit "dt-bindings: PCI: Add bindings for more Brcmstb chips" -- Add if/then clause for required props: resets, reset-names (RobH) -- Change compatible list from const to enum (RobH) -- Change list of u32-tuples to u64 (RobH) Commit "of: Include a dev param in of_dma_get_range()" -- modify of/unittests.c to add NULL param in of_dma_get_range() call. Commit "device core: Add ability to handle multiple dma offsets" -- align comment in device.h (AndyS). -- s/cpu_beg/cpu_start/ and s/dma_beg/dma_start/ in struct dma_pfn_offset_region (AndyS). v2: Commit: "device core: Add ability to handle multiple dma offsets" o Added helper func attach_dma_pfn_offset_map() in address.c (Chistoph) o Helpers funcs added to __phys_to_dma() & __dma_to_phys() (Christoph) o Added warning when multiple offsets are needed and !DMA_PFN_OFFSET_MAP o dev->dma_pfn_map => dev->dma_pfn_offset_map o s/frm/from/ for dma_pfn_offset_frm_{phys,dma}_addr() (Christoph) o In device.h: s/const void */const struct dma_pfn_offset_region */ o removed 'unlikely' from unlikely(dev->dma_pfn_offset_map) since guarded by CONFIG_DMA_PFN_OFFSET_MAP (Christoph) o Since dev->dma_pfn_offset is copied in usb/core/{usb,message}.c, now dev->dma_pfn_offset_map is copied as well. o Merged two of the DMA commits into one (Christoph). Commit "arm: dma-mapping: Invoke dma offset func if needed": o Use helper functions instead of #if CONFIG_DMA_PFN_OFFSET Other commits' changes: o Removed need for carrying of_id var in priv (Nicolas) o Commit message rewordings (Bjorn) o Commit log messages filled to 75 chars (Bjorn) o devm_reset_control_get_shared()) => devm_reset_control_get_optional_shared (Philipp) o Add call to reset_control_assert() in PCIe remove routines (Philipp) v1: This patchset expands the usefulness of the Broadcom Settop Box PCIe controller by building upon the PCIe driver used currently by the Raspbery Pi. Other forms of this patchset were submitted by me years ago and not accepted; the major sticking point was the code required for the DMA remapping needed for the PCIe driver to work [1]. There have been many changes to the DMA and OF subsystems since that time, making a cleaner and less intrusive patchset possible. This patchset implements a generalization of "dev->dma_pfn_offset", except that instead of a single scalar offset it provides for multiple offsets via a function which depends upon the "dma-ranges" property of the PCIe host controller. This is required for proper functionality of the BrcmSTB PCIe controller and possibly some other devices. [1] https://lore.kernel.org/linux-arm-kernel/1516058925-46522-5-git-send-email-… Jim Quinlan (11): PCI: brcmstb: PCIE_BRCMSTB depends on ARCH_BRCMSTB dt-bindings: PCI: Add bindings for more Brcmstb chips PCI: brcmstb: Add bcm7278 register info PCI: brcmstb: Add suspend and resume pm_ops PCI: brcmstb: Add bcm7278 PERST# support PCI: brcmstb: Add control of rescal reset device-mapping: Introduce DMA range map, supplanting dma_pfn_offset PCI: brcmstb: Set additional internal memory DMA viewport sizes PCI: brcmstb: Accommodate MSI for older chips PCI: brcmstb: Set bus max burst size by chip type PCI: brcmstb: Add bcm7211, bcm7216, bcm7445, bcm7278 to match list .../bindings/pci/brcm,stb-pcie.yaml | 56 ++- arch/arm/include/asm/dma-mapping.h | 10 +- arch/arm/mach-keystone/keystone.c | 17 +- arch/sh/drivers/pci/pcie-sh7786.c | 9 +- arch/x86/pci/sta2x11-fixup.c | 7 +- drivers/acpi/arm64/iort.c | 5 +- drivers/base/core.c | 2 + drivers/gpu/drm/sun4i/sun4i_backend.c | 5 +- drivers/iommu/io-pgtable-arm.c | 2 +- .../platform/sunxi/sun4i-csi/sun4i_csi.c | 5 +- .../platform/sunxi/sun6i-csi/sun6i_csi.c | 4 +- drivers/of/address.c | 72 ++- drivers/of/device.c | 43 +- drivers/of/of_private.h | 10 +- drivers/of/unittest.c | 34 +- drivers/pci/controller/Kconfig | 3 +- drivers/pci/controller/pcie-brcmstb.c | 409 +++++++++++++++--- drivers/remoteproc/remoteproc_core.c | 8 +- .../staging/media/sunxi/cedrus/cedrus_hw.c | 7 +- drivers/usb/core/message.c | 9 +- drivers/usb/core/usb.c | 7 +- include/linux/device.h | 4 +- include/linux/dma-direct.h | 8 +- include/linux/dma-mapping.h | 36 ++ kernel/dma/coherent.c | 10 +- kernel/dma/mapping.c | 66 +++ 26 files changed, 668 insertions(+), 180 deletions(-) -- 2.17.1

5 13

[PATCH] gpu/drm: cleanup coding style a bit
by Bernard Zhao 07 Sep '20

07 Sep '20

Remove first assignment to info which is meaningless. Put the width and higth check first. This change is to make the code a bit readable. Signed-off-by: Bernard Zhao <bernard(a)vivo.com> --- drivers/gpu/drm/drm_framebuffer.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_framebuffer.c b/drivers/gpu/drm/drm_framebuffer.c index df656366a530..2f5b0c2bb0fe 100644 --- a/drivers/gpu/drm/drm_framebuffer.c +++ b/drivers/gpu/drm/drm_framebuffer.c @@ -176,8 +176,7 @@ static int framebuffer_check(struct drm_device *dev, int i; /* check if the format is supported at all */ - info = __drm_format_info(r->pixel_format); - if (!info) { + if (!__drm_format_info(r->pixel_format)) { struct drm_format_name_buf format_name; DRM_DEBUG_KMS("bad framebuffer format %s\n", @@ -186,9 +185,6 @@ static int framebuffer_check(struct drm_device *dev, return -EINVAL; } - /* now let the driver pick its own format info */ - info = drm_get_format_info(dev, r); - if (r->width == 0) { DRM_DEBUG_KMS("bad framebuffer width %u\n", r->width); return -EINVAL; @@ -199,6 +195,9 @@ static int framebuffer_check(struct drm_device *dev, return -EINVAL; } + /* now let the driver pick its own format info */ + info = drm_get_format_info(dev, r); + for (i = 0; i < info->num_planes; i++) { unsigned int width = fb_plane_width(r->width, info, i); unsigned int height = fb_plane_height(r->height, info, i); -- 2.28.0

2 1

[PATCH v1 0/2] video: fbdev: radeonfb: PCI PM framework upgrade and fix-ups.
by Vaibhav Gupta 07 Sep '20

07 Sep '20

Linux Kernel Mentee: Remove Legacy Power Management. The original goal of the patch series is to upgrade the power management framework of radeonfb fbdev driver. This has been done by upgrading .suspend() and .resume() callbacks. The upgrade makes sure that the involvement of PCI Core does not change the order of operations executed in a driver. Thus, does not change its behavior. During this process, it was found that "#if defined(CONFIG_PM)" at line 1434 is redundant. This was introduced in the commit 42ddb453a0cd ("radeon: Conditionally compile PM code"). ------------ Before 42ddb453a0cd: $ git show 65122f7e80b5:drivers/video/aty/radeon_pm.c | grep -n "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef" Based on output in terminal: 547:#ifdef CONFIG_PM |-- 959:#ifdef CONFIG_PPC_PMAC |-- 972:#endif |-- 1291:#ifdef CONFIG_PPC_OF |-- 1301:#endif /* CONFIG_PPC_OF */ |-- 1943:#ifdef CONFIG_PPC_OF |-- 2206:#if 0 /* Not ready yet */ |-- 2508:#endif /* 0 */ |-- 2510:#endif /* CONFIG_PPC_OF */ |-- 2648:#ifdef CONFIG_PPC_PMAC |-- 2654:#endif /* CONFIG_PPC_PMAC */ |-- 2768:#ifdef CONFIG_PPC_PMAC |-- 2774:#endif /* CONFIG_PPC_PMAC */ |-- 2791:#ifdef CONFIG_PPC_OF__disabled |-- 2801:#endif /* CONFIG_PPC_OF */ 2803:#endif /* CONFIG_PM */ ------------ After 42ddb453a0cd: $ git show 42ddb453a0cd:drivers/video/aty/radeon_pm.c | grep -n "#ifdef\|#if\|#else\|#endif\|#elif\|#ifndef" Based on output in terminal: 547:#ifdef CONFIG_PM |-- 959:#ifdef CONFIG_PPC_PMAC |-- 972:#endif |-- 1291:#ifdef CONFIG_PPC_OF |-- 1301:#endif /* CONFIG_PPC_OF */ |-- 1430:#if defined(CONFIG_PM) |-- 1431:#if defined(CONFIG_X86) || defined(CONFIG_PPC_PMAC) |-- 1944:#endif |-- 1946:#ifdef CONFIG_PPC_OF |-- 1947:#ifdef CONFIG_PPC_PMAC |-- 2208:#endif |-- 2209:#endif |-- 2211:#if 0 /* Not ready yet */ |-- 2513:#endif /* 0 */ |-- 2515:#endif /* CONFIG_PPC_OF */ |-- 2653:#ifdef CONFIG_PPC_PMAC |-- 2659:#endif /* CONFIG_PPC_PMAC */ |-- 2773:#ifdef CONFIG_PPC_PMAC |-- 2779:#endif /* CONFIG_PPC_PMAC */ |-- 2796:#ifdef CONFIG_PPC_OF__disabled |-- 2806:#endif /* CONFIG_PPC_OF */ 2808:#endif /* CONFIG_PM */ ------------ This also affected the CONFIG_PPC_OF container (line 1943 at commit 65122f7e80b5) The patch-series fixes it along with PM upgrade. All patches are compile-tested only. Test tools: - Compiler: gcc (GCC) 10.1.0 - allmodconfig build: make -j$(nproc) W=1 all Vaibhav Gupta (2): video: fbdev: aty: radeon_pm: remove redundant CONFIG_PM container fbdev: radeonfb:use generic power management drivers/video/fbdev/aty/radeon_base.c | 10 ++++--- drivers/video/fbdev/aty/radeon_pm.c | 38 ++++++++++++++++++++------- drivers/video/fbdev/aty/radeonfb.h | 3 +-- 3 files changed, 35 insertions(+), 16 deletions(-) -- 2.27.0

6 14

[Bug 208997] New: WARNING: CPU: 3 PID: 1633 at drivers/gpu/drm/drm_modeset_lock.c
by bugzilla-daemon＠bugzilla.kernel.org 07 Sep '20

07 Sep '20

https://bugzilla.kernel.org/show_bug.cgi?id=208997 Bug ID: 208997 Summary: WARNING: CPU: 3 PID: 1633 at drivers/gpu/drm/drm_modeset_lock.c Product: Drivers Version: 2.5 Kernel Version: 5.8.0 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: martin.tk(a)gmx.com Regression: No Created attachment 292059 --> https://bugzilla.kernel.org/attachment.cgi?id=292059&action=edit stack trace that's showing up in syslog Since upgrading to 5.8.0 version I noticed a stack trace popping up in my syslog. Actually, I haven't noticed it up until today. I haven't noticed anything in my hardware behaviour. All seems to be working as it used to. The stack trace keeps appearing on up until 5.8.3. I'm running Slackware current. I compiled the kernel myself, took it straight from kernel.org. Hardware: CPU: Phenom2 x4 965 motherboard is included in the log: Gigabyte Technology Co., Ltd. GA-MA770T-UD3/GA-MA770T-UD3 gpu: Radon RX550 (using kernel provided module). Attached are a few examples of the stack trace. Going by the date, the first few are on 5.8.0, the last are on 5.8.3. Cheers. Martin ps. I'm not sure about the component. -- You are receiving this mail because: You are watching the assignee of the bug.

1 2

[PATCH AUTOSEL 4.19 24/26] drm/amdgpu: Fix bug in reporting voltage for CIK
by Sasha Levin 07 Sep '20

07 Sep '20

From: Sandeep Raghuraman <sandy.8925(a)gmail.com> [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman <sandy.8925(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index 219440bebd052..72c0a2ae2dd4f 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3566,7 +3566,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1

1 0

[PATCH AUTOSEL 5.4 41/43] drm/amdgpu: Fix bug in reporting voltage for CIK
by Sasha Levin 07 Sep '20

07 Sep '20

From: Sandeep Raghuraman <sandy.8925(a)gmail.com> [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman <sandy.8925(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index e6da53e9c3f46..3a2a1dc9a786a 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3575,7 +3575,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1

1 0

[PATCH AUTOSEL 5.8 50/53] drm/amdgpu: Fix bug in reporting voltage for CIK
by Sasha Levin 07 Sep '20

07 Sep '20

From: Sandeep Raghuraman <sandy.8925(a)gmail.com> [ Upstream commit d98299885c9ea140c1108545186593deba36c4ac ] On my R9 390, the voltage was reported as a constant 1000 mV. This was due to a bug in smu7_hwmgr.c, in the smu7_read_sensor() function, where some magic constants were used in a condition, to determine whether the voltage should be read from PLANE2_VID or PLANE1_VID. The VDDC mask was incorrectly used, instead of the VDDGFX mask. This patch changes the code to use the correct defined constants (and apply the correct bitshift), thus resulting in correct voltage reporting. Signed-off-by: Sandeep Raghuraman <sandy.8925(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c index 753cb2cf6b77e..3adf9c1dfdbb0 100644 --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c @@ -3587,7 +3587,8 @@ static int smu7_read_sensor(struct pp_hwmgr *hwmgr, int idx, case AMDGPU_PP_SENSOR_GPU_POWER: return smu7_get_gpu_power(hwmgr, (uint32_t *)value); case AMDGPU_PP_SENSOR_VDDGFX: - if ((data->vr_config & 0xff) == 0x2) + if ((data->vr_config & VRCONF_VDDGFX_MASK) == + (VR_SVI2_PLANE_2 << VRCONF_VDDGFX_SHIFT)) val_vid = PHM_READ_INDIRECT_FIELD(hwmgr->device, CGS_IND_REG__SMC, PWR_SVI2_STATUS, PLANE2_VID); else -- 2.25.1

1 0

Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline
by Jian-Hong Pan 07 Sep '20

07 Sep '20

Hi Maxime, Thanks for version 5 patch series! I applied it based on linux-next tag next-20200828 and build it with the config [1] to test on RPi 4 However, It fails to get HDMI state machine clock and pixel bcb clock. Then, vc4-drm probes failed. Full dmseg [2]: [ 2.552675] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get HDMI state machine clock [ 2.557974] raspberrypi-firmware soc:firmware: Attached to firmware from 2020-06-01T13:23:40 [ 2.567612] of_clk_hw_onecell_get: invalid index 14 [ 2.567636] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get pixel bvb clock [ 2.567664] vc4-drm gpu: failed to bind fef00700.hdmi (ops vc4_hdmi_ops): -2 [ 2.567731] vc4-drm gpu: master bind failed: -2 [ 2.567755] vc4-drm: probe of gpu failed with error -2 I decompile bcm2711-rpi-4-b.dtb. Both hdmi@7ef00700 and hdmi@7ef05700 show the clocks member. hdmi@7ef00700 { compatible = "brcm,bcm2711-hdmi0"; reg = <0x7ef00700 0x300 0x7ef00300 0x200 0x7ef00f00 0x80 0x7ef00f80 0x80 0x7ef01b00 0x200 0x7ef01f00 0x400 0x7ef00200 0x80 0x7ef04300 0x100 0x7ef20000 0x100>; reg-names = "hdmi\0dvp\0phy\0rm\0packet\0metadata\0csc\0cec\0hd"; clock-names = "hdmi\0bvb\0audio\0cec"; resets = <0x17 0x00>; ddc = <0x18>; dmas = <0x19 0x0a>; dma-names = "audio-rx"; status = "okay"; clocks = <0x10 0x0d 0x10 0x0e 0x17 0x00 0x1a>; }; hdmi@7ef05700 { compatible = "brcm,bcm2711-hdmi1"; reg = <0x7ef05700 0x300 0x7ef05300 0x200 0x7ef05f00 0x80 0x7ef05f80 0x80 0x7ef06b00 0x200 0x7ef06f00 0x400 0x7ef00280 0x80 0x7ef09300 0x100 0x7ef20000 0x100>; reg-names = "hdmi\0dvp\0phy\0rm\0packet\0metadata\0csc\0cec\0hd"; ddc = <0x1b>; clock-names = "hdmi\0bvb\0audio\0cec"; resets = <0x17 0x01>; dmas = <0x19 0x11>; dma-names = "audio-rx"; status = "okay"; clocks = <0x10 0x0d 0x10 0x0e 0x17 0x01 0x1a>; }; Also re-check runtime device tree, they are the same values as mentioned above: $ xxd /proc/device-tree/soc/hdmi@7ef00700/clocks 00000000: 0000 0010 0000 000d 0000 0010 0000 000e ................ 00000010: 0000 0017 0000 0000 0000 001a ............ $ xxd /proc/device-tree/soc/hdmi@7ef05700/clocks 00000000: 0000 0010 0000 000d 0000 0010 0000 000e ................ 00000010: 0000 0017 0000 0001 0000 001a ............ Do I miss something? [1]: https://gist.github.com/starnight/649ea5a8384313f0354aca504f78ad70#file-con… [2]: https://gist.github.com/starnight/649ea5a8384313f0354aca504f78ad70#file-dme… Jian-Hong Pan

2 1

Re: [PATCH v11 07/11] device-mapping: Introduce DMA range map, supplanting dma_pfn_offset
by Nicolas Saenz Julienne 07 Sep '20

07 Sep '20

Hi Christoph, a small fix to your fixes: On Tue, 2020-09-01 at 10:24 +0200, Christoph Hellwig wrote: > I've applied this to the dma-mapping tree. > > I had to resolve a conflict in drivers/of/address.c with a recent > mainline commit. I also applied the minor tweaks Andy pointed out > plus a few more style changes. A real change is that I changed the > prototype for dma_copy_dma_range_map to require less boilerplate code. diff --git a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c index 0b5f8d62f251..4cd012817af6 100644 --- a/drivers/usb/core/usb.c +++ b/drivers/usb/core/usb.c @@ -610,7 +610,7 @@ struct usb_device *usb_alloc_dev(struct usb_device *parent, * mask for the entire HCD, so don't do that. */ dev->dev.dma_mask = bus->sysdev->dma_mask; - if (!dma_copy_dma_range_map(&dev->dev, bus->sysdev)) + if (dma_copy_dma_range_map(&dev->dev, bus->sysdev)) dev_err(&dev->dev, "failed to copy DMA map\n"); set_dev_node(&dev->dev, dev_to_node(bus->sysdev)); dev->state = USB_STATE_ATTACHED; Regards, Nicolas

1 0

← Newer
1
...
73
74
75
76
77
78
79
...
87
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2020