[Bug 100666] amdgpu coolers never stoping linux
https://bugs.freedesktop.org/show_bug.cgi?id=100666 Denis Denisov changed: What|Removed |Added Priority|medium |high Severity|normal |major -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: DRM Format Modifiers in v4l2
On Fri, Sep 1, 2017 at 2:43 PM, Rob Clark wrote: > On Fri, Sep 1, 2017 at 3:13 AM, Laurent Pinchart > wrote: >> Hi Nicolas, >> >> On Thursday, 31 August 2017 19:12:58 EEST Nicolas Dufresne wrote: >>> Le jeudi 31 août 2017 à 17:28 +0300, Laurent Pinchart a écrit : >>> >> e.g. if I have two devices which support MODIFIER_FOO, I could attempt >>> >> to share a buffer between them which uses MODIFIER_FOO without >>> >> necessarily knowing exactly what it is/does. >>> > >>> > Userspace could certainly set modifiers blindly, but the point of >>> > modifiers is to generate side effects benefitial to the use case at hand >>> > (for instance by optimizing the memory access pattern). To use them >>> > meaningfully userspace would need to have at least an idea of the side >>> > effects they generate. >>> >>> Generic userspace will basically pick some random combination. >> >> In that case userspace could set no modifier at all by default (except in the >> case where unmodified formats are not supported by the hardware, but I don't >> expect that to be the most common case). >> >>> To allow generically picking the optimal configuration we could indeed rely >>> on the application knowledge, but we could also enhance the spec so that >>> the order in the enumeration becomes meaningful. >> >> I'm not sure how far we should go. I could imagine a system where the API >> would report capabilities for modifiers (e.g. this modifier lowers the >> bandwidth, this one enhances the quality, ...), but going in that direction, >> where do we stop ? In practice I expect userspace to know some information >> about the hardware, so I'd rather avoid over-engineering the API. >> > > I think in the (hopefully not too) long term, something like > https://github.com/cubanismo/allocator/ is the way forward. That > doesn't quite solve how v4l2 kernel part sorts out w/ corresponding > userspace .so what is preferable, but at least that is > compartmentalized to v4l2.. on the gl/vk side of things there will ofc > be a hardware specific userspace part that knows what it prefers. For > v4l2, it probably makes sense to sort out what the userspace level API > is and work backwards from there, rather than risk trying to design a > kernel uapi that might turn out to be the wrong thing. I thought for kms the plan is to make the ordering meaningful, because it doesn't necessarily match the gl/vk one. E.g. on intel gl would prefer Y compressed, Y, X, untiled. Whereas display would be Y compressed, X (much easier to scan out, in many cases allows more planes to be used), Y (is necessary for 90° rotation), untiled. So if drm_hwc really wants to use all the planes, it could prioritize the display over rendering and request X instead of Y tiled. I think the same would go for v4l. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102517] System hang/freeze Helium Rain
https://bugs.freedesktop.org/show_bug.cgi?id=102517 bferreira9...@gmail.com changed: What|Removed |Added OS|other |Linux (All) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] drm/amd/powerplay: initialize a variable before using it
Function vega10_apply_state_adjust_rules() only initializes
stable_pstate_sclk_dpm_percentage when
data->registry_data.stable_pstate_sclk_dpm_percentage is not between 1
and 100. The variable is then used to compute stable_pstate_sclk, which
therefore uses an uninitialized value.
Fix this by initializing stable_pstate_sclk_dpm_percentage to
data->registry_data.stable_pstate_sclk_dpm_percentage.
This issue has been found while building the kernel with clang. The
compiler reported a -Wsometimes-uninitialized warning.
Fixes: f83a9991648b ("drm/amd/powerplay: add Vega10 powerplay support (v5)")
Signed-off-by: Nicolas Iooss
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 197174e562d2..c8d28f78cd47 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -3043,6 +3043,8 @@ static int vega10_apply_state_adjust_rules(struct
pp_hwmgr *hwmgr,
if (phm_cap_enabled(hwmgr->platform_descriptor.platformCaps,
PHM_PlatformCaps_StablePState)) {
+ stable_pstate_sclk_dpm_percentage =
+ data->registry_data.stable_pstate_sclk_dpm_percentage;
PP_ASSERT_WITH_CODE(
data->registry_data.stable_pstate_sclk_dpm_percentage
>= 1 &&
data->registry_data.stable_pstate_sclk_dpm_percentage
<= 100,
--
2.14.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102500] [polaris10][amd-staging-4.12] GPU fault detected, somethimes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=102500 --- Comment #9 from Vedran Miletić --- (In reply to Dieter Nützel from comment #5) > (In reply to Dieter Nützel from comment #4) > > (In reply to Alex Deucher from comment #1) > > > can you bisect? > > > > Hello all, > > > > I get the same on 'amd-staging-drm-next' since 1. of Sep (kernel build time: > > 1. Sep 02:14 CEST) update, too. Will go to bisect in the evening. > > > > [ 262.462941] amdgpu :01:00.0: GPU fault detected: 146 0x0a023d14 > > [ 262.462946] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR > > 0x00101540 > > [ 262.462949] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS > > 0x0903D014 > > [ 262.462952] amdgpu :01:00.0: VM fault (0x14, vmid 4) at page 1054016, > > write from 'SDM1' (0x53 > > 444d31) (61) > > Yes, > > git revert fd8bf087dffc > > commit fd8bf087dffc0bce047c5aea2afcb8f821e48db1 > Author: Christian König > Date: Tue Aug 29 16:14:32 2017 +0200 > > drm/amdgpu: bump version for support of local BOs > > Signed-off-by: Christian König > Reviewed-by: Felix Kuehling > Signed-off-by: Alex Deucher > > Solve it on 'amd-staging-drm-next', too. Confirmed fixed by reverting on Vega 10. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/10] drm/i915/gvt: Use ARRAY_SIZE macro
Use ARRAY_SIZE macro, rather than explicitly coding some variant of it yourself. Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e 's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\) /ARRAY_SIZE(\1)/g' and manual check/verification. Signed-off-by: Thomas Meyer --- diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c index 3deadcbd5a24..7d8035093a1e 100644 --- a/drivers/gpu/drm/i915/gvt/vgpu.c +++ b/drivers/gpu/drm/i915/gvt/vgpu.c @@ -30,6 +30,7 @@ *Bing Niu * */ +#include #include "i915_drv.h" #include "gvt.h" @@ -115,7 +116,7 @@ int intel_gvt_init_vgpu_types(struct intel_gvt *gvt) */ low_avail = gvt_aperture_sz(gvt) - HOST_LOW_GM_SIZE; high_avail = gvt_hidden_sz(gvt) - HOST_HIGH_GM_SIZE; - num_types = sizeof(vgpu_types) / sizeof(vgpu_types[0]); + num_types = ARRAY_SIZE(vgpu_types); gvt->types = kzalloc(num_types * sizeof(struct intel_vgpu_type), GFP_KERNEL); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/10] drm/nouveau/bios/init: Use ARRAY_SIZE macro
Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.
Signed-off-by: Thomas Meyer
---
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
index b58ee99f7bfc..440efa333d6c 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
@@ -21,6 +21,7 @@
*
* Authors: Ben Skeggs
*/
+#include
#include
#include
#include
@@ -2271,7 +2272,7 @@ static struct nvbios_init_opcode {
[0xaa] = { init_reserved },
};
-#define init_opcode_nr (sizeof(init_opcode) / sizeof(init_opcode[0]))
+#define init_opcode_nr (ARRAY_SIZE(init_opcode))
int
nvbios_exec(struct nvbios_init *init)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/10] drm/amdgpu: Use ARRAY_SIZE macro
Use ARRAY_SIZE macro, rather than explicitly coding some variant of it
yourself.
Found with: find -type f -name "*.c" -o -name "*.h" | xargs perl -p -i -e
's/\bsizeof\s*\(\s*(\w+)\s*\)\s*\ /\s*sizeof\s*\(\s*\1\s*\[\s*0\s*\]\s*\)
/ARRAY_SIZE(\1)/g' and manual check/verification.
Signed-off-by: Thomas Meyer
---
diff --git a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
index 9804318f3488..7ef84d884714 100644
--- a/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
+++ b/drivers/gpu/drm/amd/amdgpu/mmhub_v1_0.c
@@ -20,6 +20,8 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
+#include
+
#include "amdgpu.h"
#include "mmhub_v1_0.h"
@@ -268,7 +270,7 @@ const struct pctl_data pctl0_data[] = {
{0x135, 0x12a810},
{0x149, 0x7a82c}
};
-#define PCTL0_DATA_LEN (sizeof(pctl0_data)/sizeof(pctl0_data[0]))
+#define PCTL0_DATA_LEN (ARRAY_SIZE(pctl0_data))
#define PCTL0_RENG_EXEC_END_PTR 0x151
#define PCTL0_STCTRL_REG_SAVE_RANGE0_BASE 0xa640
@@ -297,7 +299,7 @@ const struct pctl_data pctl1_data[] = {
{0x1be, 0x17a7dd},
{0x1d7, 0x12a810}
};
-#define PCTL1_DATA_LEN (sizeof(pctl1_data)/sizeof(pctl1_data[0]))
+#define PCTL1_DATA_LEN (ARRAY_SIZE(pctl1_data))
#define PCTL1_RENG_EXEC_END_PTR 0x1ea
#define PCTL1_STCTRL_REG_SAVE_RANGE0_BASE 0xa000
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=99710 --- Comment #7 from Sandeep --- I have the same GPU, and have also started experiencing system hangs since the past 1-2 months. I believe it may be related to this issue, since it only occurs when using 3D graphics in some form, either while playing Left 4 Dead 2 or when using the Chromium browser with GPU acceleration enabled. In the case of Left 4 Dead 2, the system always hangs unpredictably at some point. I am using the AMDGPU driver, with AMDGPU CIK support enabled. I tried running 4.13 stable today, and the crash still occurred. I will try older kernels to see if I am still able to reproduce. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv6 1/3] ARM:dt-bindings Intel FPGA Video and Image Processing Suite
Hi Laurent, On Mon, 2017-08-28 at 13:06 +0800, Ong, Hean Loong wrote: > Hi Laurent, > > On Thu, 2017-08-24 at 12:39 +0300, Laurent Pinchart wrote: > > > > Hi Hean Loong, > > > > On Thursday, 24 August 2017 08:41:50 EEST Ong, Hean Loong wrote: > > > > > > > > > Hi Laurent, > > > > > > I removed the examples for the HDMI in the draft below. The > > > connections > > > between the VIP and Display Port IP or any display connector are > > > determined by HW logic. There are currently no SW defined > > > encoders > > > or > > > connectors that is connected to the AVALON-ST other than the > > > Intel > > > VIP > > > Frame Buffer II. Therefore there are no examples for the Display > > > Port > > > encoder and connector. > > But there must be an encoder, even if its default configuration > > makes > > it > > usable without a softwarer driver at the moment. As the encoder is > > there in > > hardware, it should be described in DT. > > > I attach some links regarding the simple example designs for the > Display Port IP > > The link below has a example design of how the VIP is built along > with > the Display Port IP > into the FPGA connected to the DDR RAM accessed by ARM or any > controller. Please look at the > Introduction section of the link below > http://www.alterawiki.com/wiki/DisplayPort_Design_Example_14.0_(RX_an > d_ > TX)#DisplayPort_IP_Core > > The proposed design in the link above and the design we are > implementing are almost the same (FPGA part) > That the Intel(Altera) FPGA VIP is the sole interface for the ARM > controller to connect to via memory mapping > on the DDR > > Please go to Source Functional Description section in the PDF below. > It > has information > on how the encoder is built for the FPGA design of the Display Port > https://www.altera.com/ja_JP/pdfs/literature/ug/ug_displayport.pdf > > More information on the Display Port IP encoder could be found in the > link below. > The Tx Transceiver interface has some information on how the source > clocks works in > the FPGA tranceiver > https://www.altera.com/documentation/hco1410462777019.html#hco1410462 > 32 > 3311 Would the information provided in the above links suffice to explain the relationship between DDR, VIP and Display Port IP ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99710] [amdgpu R9 390] GPU hang when playing Hearthstone in Wine
https://bugs.freedesktop.org/show_bug.cgi?id=99710 --- Comment #8 from Sandeep --- Well, I tried running 4.11 RC3, and that also had the same problem. Will see if I can go further back (4.10, 4.9 etc.) and see if I can get it to work without problems. Otherwise, the problem lies somewhere else, but is definitely related to the GPU drivers, since it doesn't get triggered by anything else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler
On 09/01/2017 04:31 PM, Marek Szyprowski wrote:
Hi Hoegeun,
On 2017-09-01 03:47, Hoegeun Kwon wrote:
The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.
The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.
Also the scaling limits are related to post size, use pos size to
check the limits.
Signed-off-by: Hoegeun Kwon
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63
+
include/uapi/drm/exynos_drm.h | 2 ++
2 files changed, 42 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct
device *dev,
bool swap;
int i;
+config = &property->config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct
device *dev,
goto err_property;
}
-/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct
device *dev,
goto err_property;
}
+/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related to pos
+ * size, use pos size to check the limits.
+ */
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct
device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
(pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
DRM_ERROR("out of scale size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
(pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+(pos->h > pp->scale_max.vsize)) {
DRM_ERROR("out of scale size.\n");
goto err_property;
}
@@ -1676,6 +1684,15 @@ static int gsc_probe(struct platform_device
*pdev)
dev_warn(dev, "failed to get system register.\n");
ctx->sysreg = NULL;
}
+
+ret = of_property_read_u32(dev->of_node, "rot-ma
