[Bug 106757] Qt's QOpenGLWidget renders a blank screen under XWayland
https://bugs.freedesktop.org/show_bug.cgi?id=106757 Michael Arnold changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Michael Arnold --- Under Fedora 29 (Mesa 18.2.4) and Qt 5.12 Beta 4 this issue is no longer present. -- 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
[Bug 108710] Since 4.20 kernel Vega 56 hangs when I surf pages in steam client
https://bugs.freedesktop.org/show_bug.cgi?id=108710 --- Comment #1 from mikhail.v.gavri...@gmail.com --- Created attachment 142440 --> https://bugs.freedesktop.org/attachment.cgi?id=142440&action=edit yet another dmesg -- 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] drm/edid: Add 6 bpc quirk for edp panel enabling.
BOE panel (ID: 0x0770) that reports "DFP 1.x compliant TMDS".
But it's 6bpc panel only instead of 8 bpc.
Add panel ID to edid quirk list and set 6 bpc as default to
work around this issue.
Cc: Jani Nikula
Cc: Maarten Lankhorst
Cc: Gustavo Padovan
Cc: Cooper Chiou
Signed-off-by: Lee, Shawn C
---
drivers/gpu/drm/drm_edid.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 08821dfa3327..8c93779d3b2f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -119,6 +119,9 @@ static const struct edid_quirk {
/* SDC panel of Lenovo B50-80 reports 8 bpc, but is a 6 bpc panel */
{ "SDC", 0x3652, EDID_QUIRK_FORCE_6BPC },
+ /* BOE model 0x0770 reports 8 bpc, but is a 6 bpc panel */
+ { "BOE", 0x0770, EDID_QUIRK_FORCE_6BPC },
+
/* BOE model 0x0771 reports 8 bpc, but is a 6 bpc panel */
{ "BOE", 0x0771, EDID_QUIRK_FORCE_6BPC },
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [kbuild-all] [PATCH] fbcon: Silence fbcon logo on 'quiet' boots
On 10/29/2018 11:15 PM, Prarit Bhargava wrote: On 10/29/2018 09:56 AM, kbuild test robot wrote: Hi Prarit, Thank you for the patch! Yet something to improve: [auto build test ERROR on sof-driver-fuweitax/master] [also build test ERROR on v4.19 next-20181029] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Prarit-Bhargava/fbcon-Silence-fbcon-logo-on-quiet-boots/20181029-211617 base: https://github.com/fuweitax/linux master config: m68k-multi_defconfig (attached as .config) compiler: m68k-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=m68k All errors (new ones prefixed by >>): drivers/video/fbdev/core/fbcon.c: In function 'fbcon_prepare_logo': drivers/video/fbdev/core/fbcon.c:680:13: error: invalid storage class for function 'set_blitting_type' static void set_blitting_type(struct vc_data *vc, struct fb_info *info) ^ drivers/video/fbdev/core/fbcon.c:680:1: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] static void set_blitting_type(struct vc_data *vc, struct fb_info *info) ^~ drivers/video/fbdev/core/fbcon.c:690:12: error: invalid storage class for function 'fbcon_invalid_charcount' static int fbcon_invalid_charcount(struct fb_info *info, unsigned charcount) ^~~ drivers/video/fbdev/core/fbcon.c:698:12: error: invalid storage class for function 'con2fb_acquire_newinfo' static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info *info, ^~ drivers/video/fbdev/core/fbcon.c:734:12: error: invalid storage class for function 'con2fb_release_oldinfo' static int con2fb_release_oldinfo(struct vc_data *vc, struct fb_info *oldinfo, ^~ drivers/video/fbdev/core/fbcon.c:780:13: error: invalid storage class for function 'con2fb_init_display' static void con2fb_init_display(struct vc_data *vc, struct fb_info *info, ^~~ drivers/video/fbdev/core/fbcon.c:825:12: error: invalid storage class for function 'set_con2fb_map' static int set_con2fb_map(int unit, int newidx, int user) ^~ drivers/video/fbdev/core/fbcon.c:882:12: error: invalid storage class for function 'var_to_display' static int var_to_display(struct display *disp, ^~ drivers/video/fbdev/core/fbcon.c:906:13: error: invalid storage class for function 'display_to_var' static void display_to_var(struct fb_var_screeninfo *var, ^~ drivers/video/fbdev/core/fbcon.c:925:20: error: invalid storage class for function 'fbcon_startup' static const char *fbcon_startup(void) ^ drivers/video/fbdev/core/fbcon.c:1036:13: error: invalid storage class for function 'fbcon_init' static void fbcon_init(struct vc_data *vc, int init) ^~ drivers/video/fbdev/core/fbcon.c:1183:13: error: invalid storage class for function 'fbcon_free_font' static void fbcon_free_font(struct display *p, bool freefont) ^~~ drivers/video/fbdev/core/fbcon.c:1191:13: error: invalid storage class for function 'set_vc_hi_font' static void set_vc_hi_font(struct vc_data *vc, bool set); ^~ drivers/video/fbdev/core/fbcon.c:1193:13: error: invalid storage class for function 'fbcon_deinit' static void fbcon_deinit(struct vc_data *vc) ^~~~ drivers/video/fbdev/core/fbcon.c: In function 'fbcon_deinit': drivers/video/fbdev/core/fbcon.c:1229:3: error: implicit declaration of function 'set_vc_hi_font'; did you mean 'seq_path_root'? [-Werror=implicit-function-declaration] set_vc_hi_font(vc, false); ^~ Hmm ... this doesn't look like anything that is at fault with my patch. There's a lot of warnings here, and perhaps another fix is required to make sure that the configs are set correctly? I can certainly take a look in another patch but AFAICT this isn't an issue with my patch. Please accept my apologies for taking your time, we will look into it. Best Regards, Rong Chen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99923] HITMAN (2016) having lighting and artefacting, and overly light room.
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #43 from Gregor Münch ---
I really like to say that its fixed but either a system or a game update made
the game crash on start.
HitmanPro.sh: Zeile 421: 13106 Speicherzugriffsfehler (Speicherabzug
geschrieben) ${GAME_LAUNCH_PREFIX} ${GAME_SIGNAL_WRAPPER}
"${GAMEROOT}/bin/${FERAL_GAME_NAME}" "$@"
--
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
[Bug 108711] GPU crash in some opengl 1.x applications on vega gpu
https://bugs.freedesktop.org/show_bug.cgi?id=108711 Bug ID: 108711 Summary: GPU crash in some opengl 1.x applications on vega gpu Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: mitt...@sibmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 142435 --> https://bugs.freedesktop.org/attachment.cgi?id=142435&action=edit trace that crashes gpu on replay Running some opengl applications results in random gpu crashes I have made trace with apitrace and can reproduce crash when replaying traces. Not every replay results in crash, so it is some random behaviour this is Ryzen 2400G APU OpenGL renderer string: AMD RAVEN (DRM 3.27.0, 4.18.0-rc7+, LLVM 8.0.0) OpenGL core profile version string: 4.5 (Core Profile) Mesa 19.0.0-devel (git-552642066f) llvm git 89fcd8b878977c9c467cb5d6e33a3404d2996822 Similar crashes was in mesa 17.x, 18.0, 18.2, 18.3 and amdgpu-pro drivers with 4.16 vanilla and 4.18 amdgpu-drm-next kernels, but i was not able to reproduce it at short time (it needed about 5-10 minutes playing game to crash) [839408.306382] amdgpu :08:00.0: [gfxhub] VMC page fault (src_id:0 ring:158 vmid:1 pasid:32778, for process xash64 pid 6233 thread xash64:cs0 pid 6273 ) [839408.306384] amdgpu :08:00.0: at address 0x from 27 [839408.306385] amdgpu :08:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x0010153C [839418.327341] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=119603881, emitted seq=119603883 Trace in attachment creaded with llvmpipe, but crashes in some replays second trace, which resulted in crash while recording (broken in the end): http://rgho.st/private/8HvcFZtwT/04b55f00128bc9e81f4cf3c4a205015a -- 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] udlfb: fix NULL pointer dereference in dlfb_usb_probe()
If memory allocation for dlfb fails, error handling code
unconditionally dereference NULL pointer.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
Fixes: 68a958a915ca ("udlfb: handle unplug properly")
---
drivers/video/fbdev/udlfb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/video/fbdev/udlfb.c b/drivers/video/fbdev/udlfb.c
index 070026a7e55a..9643fe7c8349 100644
--- a/drivers/video/fbdev/udlfb.c
+++ b/drivers/video/fbdev/udlfb.c
@@ -1590,7 +1590,7 @@ static int dlfb_usb_probe(struct usb_interface *intf,
int i;
const struct device_attribute *attr;
struct dlfb_data *dlfb;
- struct fb_info *info;
+ struct fb_info *info = NULL;
int retval = -ENOMEM;
struct usb_device *usbdev = interface_to_usbdev(intf);
@@ -1701,8 +1701,8 @@ static int dlfb_usb_probe(struct usb_interface *intf,
return 0;
error:
- if (dlfb->info) {
- dlfb_ops_destroy(dlfb->info);
+ if (info) {
+ dlfb_ops_destroy(info);
} else if (dlfb) {
usb_put_dev(dlfb->udev);
kfree(dlfb);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/panel: Remove set but not used variable 'config'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/panel/panel-truly-nt35597.c: In function
'truly_nt35597_panel_add':
drivers/gpu/drm/panel/panel-truly-nt35597.c:488:31: warning:
variable 'config' set but not used [-Wunused-but-set-variable]
It never used since introdution in
1dd0b147c1ff ("drm/panel: Add support for Truly NT35597 panel driver")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/panel/panel-truly-nt35597.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-truly-nt35597.c
b/drivers/gpu/drm/panel/panel-truly-nt35597.c
index fc2a66c..2d5a540 100644
--- a/drivers/gpu/drm/panel/panel-truly-nt35597.c
+++ b/drivers/gpu/drm/panel/panel-truly-nt35597.c
@@ -485,9 +485,7 @@ static int truly_nt35597_panel_add(struct truly_nt35597
*ctx)
{
struct device *dev = ctx->dev;
int ret, i;
- const struct nt35597_config *config;
- config = ctx->config;
for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++)
ctx->supplies[i].supply = regulator_names[i];
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH DRM] drm: msm: disp: dpu1: Use DRM_DEV_* instead of DPU_*
On Wed, Nov 7, 2018 at 12:25 AM Sean Paul wrote: > > On Sat, Oct 20, 2018 at 11:33:54PM +0530, Mamta Shukla wrote: > > Use DRM_DEV_ERROR/DEBUG instead of DPU_ERROR/DEBUG to generate > > drm-formatted specific log messages in the Kernel log in case of > > multiple instances. > > > > Signed-off-by: Mamta Shukla > > Hi Mamta, > Thanks for sending this patch, but I don't think it's going to even compile. > DRM_DEV_* takes a struct device * pointer as the first argument, and it's not > being passed in anywhere. Make sure you compile test with CONFIG_DRM_MSM > enabled > Thank you for pointing this out. Definitely DRM_DEV_* requires pointer to function or the device pointer along with message string. I had compiled this before submitting the patch. But I missed out enabling the DRM_MSM. Is it good to write v2 of above patch with mentioning/stating pointer to function so that in DEBUG message function name is also available with error message? > > --- > > drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 58 +++ > > drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 60 +++ > > drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 176 > > ++--- > > drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c| 134 > > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 40 ++--- > > .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 42 ++--- > > drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c| 10 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_cdm.c | 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c| 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c| 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c| 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 2 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_irq.c| 4 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 90 +-- > > drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 10 +- > > drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 134 > > drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 96 +-- > > drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 32 ++-- > > 21 files changed, 451 insertions(+), 451 deletions(-) > > > > /snip > > -- > Sean Paul, Software Engineer, Google / Chromium OS -- Mamta Shukla ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/qxl: remove set but not used variable 'map'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/qxl/qxl_object.c: In function 'qxl_bo_kunmap_atomic_page':
drivers/gpu/drm/qxl/qxl_object.c:189:21: warning:
variable 'map' set but not used [-Wunused-but-set-variable]
Signed-off-by: YueHaibing
---
drivers/gpu/drm/qxl/qxl_object.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_object.c b/drivers/gpu/drm/qxl/qxl_object.c
index f67a3c5..b1706cb 100644
--- a/drivers/gpu/drm/qxl/qxl_object.c
+++ b/drivers/gpu/drm/qxl/qxl_object.c
@@ -186,13 +186,9 @@ void qxl_bo_kunmap_atomic_page(struct qxl_device *qdev,
struct qxl_bo *bo, void *pmap)
{
struct ttm_mem_type_manager *man =
&bo->tbo.bdev->man[bo->tbo.mem.mem_type];
- struct io_mapping *map;
- if (bo->tbo.mem.mem_type == TTM_PL_VRAM)
- map = qdev->vram_mapping;
- else if (bo->tbo.mem.mem_type == TTM_PL_PRIV)
- map = qdev->surface_mapping;
- else
+ if ((bo->tbo.mem.mem_type != TTM_PL_VRAM) &&
+ (bo->tbo.mem.mem_type != TTM_PL_PRIV))
goto fallback;
io_mapping_unmap_atomic(pmap);
@@ -200,7 +196,7 @@ void qxl_bo_kunmap_atomic_page(struct qxl_device *qdev,
(void) ttm_mem_io_lock(man, false);
ttm_mem_io_free(bo->tbo.bdev, &bo->tbo.mem);
ttm_mem_io_unlock(man);
- return ;
+ return;
fallback:
qxl_bo_kunmap(bo);
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 17/25] dt-bindings: panel: Add Bananapi S070WV20-CT16 ICN6211 MIPI-DSI to RGB bridge
On Wed, Nov 7, 2018 at 2:41 PM Andrzej Hajda wrote: > > On 06.11.2018 19:08, Jagan Teki wrote: > > On Wed, Oct 31, 2018 at 2:45 PM Andrzej Hajda wrote: > >> On 31.10.2018 09:58, Chen-Yu Tsai wrote: > >>> On Wed, Oct 31, 2018 at 4:53 PM Andrzej Hajda wrote: > On 26.10.2018 16:43, Jagan Teki wrote: > > Bananapi S070WV20-CT16 ICN6211 is 800x480, 4-lane MIPI-DSI to RGB > > bridge panel, which is available on same PCB with 24-bit RGB interface. > > > > So, this patch adds DSI specific binding details on existing > > dt-bindings file. > > > > Signed-off-by: Jagan Teki > > --- > > Changes for v3: > > - Use existing binding doc and update dsi details > > Changes for v2: > > - none > > > > .../display/panel/bananapi,s070wv20-ct16.txt | 31 +-- > > 1 file changed, 29 insertions(+), 2 deletions(-) > > > > diff --git > > a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > > > b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > index 35bc0c839f49..b7855dc7c66f 100644 > > --- > > a/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > +++ > > b/Documentation/devicetree/bindings/display/panel/bananapi,s070wv20-ct16.txt > > @@ -1,12 +1,39 @@ > > Banana Pi 7" (S070WV20-CT16) TFT LCD Panel > > > > +S070WV20-CT16 is 7" 800x480 panel connected through a 24-bit RGB > > interface. > > + > > +Depending on the variant, the PCB attached to the panel module either > > +supports DSI, or DSI + 24-bit RGB. DSI is converted to 24-bit RGB via > > +an onboard ICN6211 MIPI DSI - RGB bridge chip, then fed to the panel > > +itself > As I understand this is display board, which contains 'pure' RGB panel > S070WV20-CT16 and optionally ICN6211 DSI->RGB bridge. > These are separate devices, just connected by vendor to simplify its > assembly. Why don't you create then bridge driver for ICN6211 and RGB > panel driver for S070WV20-CT16 - it looks more generic. > Then you can describe both in dts and voila. > Creating drivers for every combo of devices (panel + bridge), just > because some vendor sells them together seems incorrect - we have > devicetree for it. > >>> Rob suggested this, and also the opposite: using the same > >>> "bananapi,s070wv20-ct16" > >>> compatible string for both types of connections, and have the driver deal > >>> with > >>> detecting the bus type. > >>> > >>> The thing about the bridge chip is that there's no available datasheet > >>> that > >>> describes all the parts of the init sequence, in fact none at all. I > >>> managed > >>> to work out some bits, but the others remain a mystery and must be > >>> hard-coded > >>> to match the panel. That would work against having a generic bridge > >>> driver. > >> > >> But it is common for many chips - 1st version of the driver is developed > >> on one platform and it supports only one configuration, if next platform > >> with the same cheap appears the driver is augmented if necessary. > > At-least few of the commands from panel initialization code, the > > respective opcode data values are based on panel timings and even > > clock value is different in DSI. I think it look hard to try bridge > > driver for these restrictions, do you have any suggestions? > > > Where do you see an issue? Since panel is RGB it should have no > initialization sequence (beside regulator/gpio power on/off), so the > only thing to do is to figure out which regulators/gpios belongs to > which component - with publicly available specs it should be doable. > > The whole initialization sequence is for the bridge, so you put it into > bridge driver, for starters it can be hardcoded. Yes, I understand we can move regulators/gpio setup separately and though we hardcode the init sequence there is difference in clock for DSI(which I mentioned in previous mail). DSI panel can't work with clock used by RGB panel-simple. > > Then you can: > > 1. Try to find other users of this ICN6211 chip and compare > initialization sequences to guess purpose of registers. > > 2. Try to get specs of the chip (ask vendor, distributor, grep Internet). As we mentioned (even Chen-Yu), we are unable to find the proper spec for this panel, all we taken reference from AW BSP code. > > 3. Do nothing - if there will be other users of the bridge they will do > this work. Don't know how we can go with generic bridge driver irrespective of these particular wrinkles, let me know if you have any suggestions. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Performance regression in ast drm driver
On Fri, 9 Nov 2018 10:04:03 +1000, David Airlie wrote: > This seems likely to be a hw problem with PCI writes to the AST "GPU", > since it's just some sort of RAM + ARM on the end of a PCIE bus, we've > definitely seen possible issues in the past with write combining > around some of the mga GPUs with some CPUs. > > Have we seen the problem across a number of AST devices? The reports I received from customers were all on AST 2500 devices (on Supermicro X11DPi-N, Supermicro X11DPH-T and Asus WS C621 Sage). I was able to reproduce "the problem" on my old Asus Z6NA-D6 which has either an AST 2050 device if I trust the board specifications on asus.com, or an AST 1100 if I trust /var/log/Xorg.0.log. Note however that I am still not certain that the problem I am seeing is the same as what both customers reported. It is possible that we have 2 different issues. -- Jean Delvare SUSE L3 Support ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -next] drm/sti: remove set but not used variable 'priv'
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/sti/sti_crtc.c: In function 'sti_crtc_vblank_cb':
drivers/gpu/drm/sti/sti_crtc.c:255:22: warning:
variable 'priv' set but not used [-Wunused-but-set-variable]
It never used since introduction in
9e1f05b28009 ("drm/sti: rename files and functions")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/sti/sti_crtc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index 61c2379..ed76e52e 100644
--- a/drivers/gpu/drm/sti/sti_crtc.c
+++ b/drivers/gpu/drm/sti/sti_crtc.c
@@ -252,10 +252,8 @@ int sti_crtc_vblank_cb(struct notifier_block *nb,
struct sti_compositor *compo;
struct drm_crtc *crtc = data;
struct sti_mixer *mixer;
- struct sti_private *priv;
unsigned int pipe;
- priv = crtc->dev->dev_private;
pipe = drm_crtc_index(crtc);
compo = container_of(nb, struct sti_compositor, vtg_vblank_nb[pipe]);
mixer = compo->mixer[pipe];
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight: pwm_bl: re-add driver internal enabled tracking
Hi Heiko,
Many thanks to catch and dig into this, I did more tests but I was not able to
reproduce the issue with my nfs environment. Anyway the patch looks good to me
and fixes the issue for you, so
On 9/11/18 10:48, Heiko Stuebner wrote:
> Commit e6bcca0890b9 ("backlight: pwm_bl: Switch to using "atomic" PWM API")
> removed the driver internal enabled tracking in favor of simply checking
> the pwm state.
>
> This can lead to issues as all of gpio-, regulator- and pwm-state are used
> to determine the initial state and the bootloader or kernel can leave them
> in an inconsistent state at boot.
>
> In my case on rk3399-kevin, the pwm backlight is build as module and the
> kernel disables the supply regulator as unused while keeping the pwm running
> thus pwm_bl calling pwm_backlight_power_off() during probe and creating an
> unmatched regulator-disable call, as it never got enabled from the pwm-bl
> before.
>
> To prevent these consistency issues, reintroduce the driver-internal
> tracking of the enabled state.
>
> Fixes: e6bcca0890b9 ("backlight: pwm_bl: Switch to using "atomic" PWM API")
> Signed-off-by: Heiko Stuebner
> ---
> drivers/video/backlight/pwm_bl.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/video/backlight/pwm_bl.c
> b/drivers/video/backlight/pwm_bl.c
> index 678b27063198..bcd08b41765d 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -30,6 +30,7 @@ struct pwm_bl_data {
> struct device *dev;
> unsigned intlth_brightness;
> unsigned int*levels;
> + boolenabled;
> struct regulator*power_supply;
> struct gpio_desc*enable_gpio;
> unsigned intscale;
> @@ -50,7 +51,7 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
> int err;
>
> pwm_get_state(pb->pwm, &state);
> - if (state.enabled)
> + if (pb->enabled)
> return;
>
> err = regulator_enable(pb->power_supply);
> @@ -65,6 +66,8 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb)
>
> if (pb->enable_gpio)
> gpiod_set_value_cansleep(pb->enable_gpio, 1);
> +
> + pb->enabled = true;
> }
>
> static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> @@ -72,7 +75,7 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> struct pwm_state state;
>
> pwm_get_state(pb->pwm, &state);
> - if (!state.enabled)
> + if (!pb->enabled)
> return;
>
> if (pb->enable_gpio)
> @@ -86,6 +89,7 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
> pwm_apply_state(pb->pwm, &state);
>
> regulator_disable(pb->power_supply);
> + pb->enabled = false;
> }
>
> static int compute_duty_cycle(struct pwm_bl_data *pb, int brightness)
> @@ -483,6 +487,7 @@ static int pwm_backlight_probe(struct platform_device
> *pdev)
> pb->check_fb = data->check_fb;
> pb->exit = data->exit;
> pb->dev = &pdev->dev;
> + pb->enabled = false;
> pb->post_pwm_on_delay = data->post_pwm_on_delay;
> pb->pwm_off_delay = data->pwm_off_delay;
>
>
Reviewed-by: Enric Balletbo i Serra
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107296] WARNING: CPU: 0 PID: 370 at drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:1355 dcn_bw_update_from_pplib+0x16b/0x280 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=107296 --- Comment #5 from darkbasic --- I confirm, the same with B450M + 2400g and 4.18/4.19/4.20-rc1. -- 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
[Bug 108710] Since 4.20 kernel Vega 56 hangs when I surf pages in steam client
https://bugs.freedesktop.org/show_bug.cgi?id=108710 Bug ID: 108710 Summary: Since 4.20 kernel Vega 56 hangs when I surf pages in steam client Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 142434 --> https://bugs.freedesktop.org/attachment.cgi?id=142434&action=edit dmesg $ inxi -bM System:Host: localhost.localdomain Kernel: 4.20.0-0.rc1.git4.1.fc30.x86_64 x86_64 bits: 64 Desktop: Gnome 3.30.1 Distro: Fedora release 30 (Rawhide) Machine: Type: Desktop Mobo: ASUSTeK model: ROG STRIX X470-I GAMING v: Rev 1.xx serial: UEFI: American Megatrends v: 0901 date: 07/23/2018 CPU: 8-Core: AMD Ryzen 7 2700X type: MT MCP speed: 3427 MHz min/max: 2200/4000 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] driver: amdgpu v: kernel Display: wayland server: Fedora Project X.org 1.20.3 driver: amdgpu resolution: 3840x2160~60Hz OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.27.0 4.20.0-0.rc1.git4.1.fc30.x86_64 LLVM 7.0.0) v: 4.5 Mesa 18.2.4 Network: Device-1: Intel I211 Gigabit Network driver: igb Device-2: Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter driver: r8822be Drives:Local Storage: total: 11.36 TiB used: 5.93 TiB (52.2%) Info: Processes: 455 Uptime: 16m Memory: 31.30 GiB used: 15.99 GiB (51.1%) Shell: bash inxi: 3.0.27 [ 3852.511166] gmc_v9_0_process_interrupt: 56 callbacks suppressed [ 3852.511182] amdgpu :0b:00.0: [mmhub] VMC page fault (src_id:0 ring:169 vmid:0 pasid:0, for process pid 0 thread pid 0) [ 3852.511184] amdgpu :0b:00.0: in page starting at address 0x00401080c000 from 18 [ 3852.511186] amdgpu :0b:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00040152 [ 3862.673344] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma1 timeout, signaled seq=72072, emitted seq=72074 [ 3862.673356] [drm] GPU recovery disabled. [ 4044.170764] sysrq: SysRq : Show Blocked State [ 4044.170959] taskPC stack pid father [ 4044.171026] kworker/u32:5 D10872 253 2 0x8000 [ 4044.171060] Workqueue: events_unbound commit_work [drm_kms_helper] [ 4044.171063] Call Trace: [ 4044.171073] ? __schedule+0x2f3/0xb90 [ 4044.171077] ? __lock_acquire+0x279/0x1650 [ 4044.171085] ? dma_fence_default_wait+0x242/0x330 [ 4044.171089] schedule+0x2f/0x90 [ 4044.171092] schedule_timeout+0x31c/0x4f0 [ 4044.171096] ? find_held_lock+0x34/0xa0 [ 4044.171099] ? find_held_lock+0x34/0xa0 [ 4044.171104] ? mark_held_locks+0x57/0x80 [ 4044.171134] ? _raw_spin_unlock_irqrestore+0x4b/0x60 [ 4044.171140] ? dma_fence_default_wait+0x242/0x330 [ 4044.171143] dma_fence_default_wait+0x26e/0x330 [ 4044.171147] ? dma_fence_release+0x120/0x120 [ 4044.171153] dma_fence_wait_timeout+0x182/0x200 [ 4044.171160] reservation_object_wait_timeout_rcu+0x236/0x4e0 [ 4044.171263] amdgpu_dm_do_flip+0x112/0x380 [amdgpu] [ 4044.171378] amdgpu_dm_atomic_commit_tail+0x6d0/0xd30 [amdgpu] [ 4044.171386] ? _raw_spin_unlock_irq+0x29/0x40 [ 4044.171391] ? wait_for_completion_timeout+0x73/0x1a0 [ 4044.171408] commit_tail+0x3d/0x70 [drm_kms_helper] [ 4044.171413] process_one_work+0x27d/0x600 [ 4044.171423] worker_thread+0x3c/0x390 [ 4044.171428] ? drain_workqueue+0x180/0x180 [ 4044.171433] kthread+0x120/0x140 [ 4044.171437] ? kthread_park+0x80/0x80 [ 4044.171442] ret_from_fork+0x27/0x50 [ 4044.172479] (time-dir) D13944 15221 1 0x [ 4044.172487] Call Trace: [ 4044.172496] ? __schedule+0x2f3/0xb90 [ 4044.172501] ? prepare_to_wait_event+0xd2/0x180 [ 4044.172508] schedule+0x2f/0x90 [ 4044.172514] drm_sched_entity_flush+0x1df/0x1f0 [gpu_sched] [ 4044.172518] ? finish_wait+0x80/0x80 [ 4044.172580] amdgpu_ctx_mgr_entity_flush+0x7c/0xc0 [amdgpu] [ 4044.172637] amdgpu_flush+0x1f/0x30 [amdgpu] [ 4044.172640] filp_close+0x34/0x70 [ 4044.172645] __x64_sys_close+0x1e/0x50 [ 4044.172649] do_syscall_64+0x60/0x1f0 [ 4044.172653] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 4044.172656] RIP: 0033:0x7f5a96622ec7 [ 4044.172662] Code: Bad RIP value. [ 4044.172665] RSP: 002b:7ffcce3d00e0 EFLAGS: 0293 ORIG_RAX: 0003 [ 4044.172668] RAX: ffda RBX: 007c RCX: 7f5a96622ec7 [ 4044.172671] RDX: RSI: 7ffcce3d0180 RDI: 007c [ 4044.172673] RBP: 55d29a73aa60 R08: 55d29a73b676 R09: [ 4044.172675] R10: 7f5a965bbae0 R11: 0293 R12: 7f5a95939750 [ 4044.172677] R13: R14: 0001 R15: 7ffcce3d0180 [ 4057.229953] INFO: task kworker/u32:5:253 blocked for more than 120 seconds. [ 4057.229957] Tainted: GWC
Re: [PATCH 2/3] backlight/arcxcnn fix vendor prefix
Hi! > The vendor-prefixes.txt file properly refers to ArcticSand > as arctic but the driver improperly abbreviated the prefix > to arc. This was a mistake in the original patch > > Signed-off-by: Brian Dodge > --- > drivers/video/backlight/arcxcnn_bl.c | 22 +++--- > 1 file changed, 11 insertions(+), 11 deletions(-) > > * > - * Copyright 2016 ArcticSand, Inc. > - * Author : Brian Dodge > + * Copyright 2018 pSemi, Inc. > + * Author : Brian Dodge Ummm. Copyright 2016-2018? > @@ -202,27 +202,27 @@ static void arcxcnn_parse_dt(struct arcxcnn *lp) > if (ret == 0) > lp->pdata->initial_brightness = prog_val; > > - ret = of_property_read_u32(node, "arc,led-config-0", &prog_val); > + ret = of_property_read_u32(node, "arctic,led-config-0", &prog_val); > if (ret == 0) > lp->pdata->led_config_0 = (u8)prog_val; > If there's a dts using this, you want to update it at the same time. You may want to support both names going forward. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] backlight/arcxcnn user proper vendor prefix in device tree bindings
On Thu 2018-11-01 18:35:29, Brian Dodge wrote: > The vendor-prefixes.txt file properly refers to ArcticSand > as "arctic" while the actual backlight driver and the > device tree bindings for it improperly use "arc". The > bindings are also modified to support newer backlight chips > in the arcxcnn family > > Signed-off-by: Brian Dodge Acked-by: Pavel Machek -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108709] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
https://bugs.freedesktop.org/show_bug.cgi?id=108709 Bug ID: 108709 Summary: WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80 Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: mikhail.v.gavri...@gmail.com Created attachment 142433 --> https://bugs.freedesktop.org/attachment.cgi?id=142433&action=edit dmesg $ inxi -bM System:Host: localhost.localdomain Kernel: 4.20.0-0.rc1.git4.1.fc30.x86_64 x86_64 bits: 64 Desktop: Gnome 3.30.1 Distro: Fedora release 30 (Rawhide) Machine: Type: Desktop Mobo: ASUSTeK model: ROG STRIX X470-I GAMING v: Rev 1.xx serial: UEFI: American Megatrends v: 0901 date: 07/23/2018 CPU: 8-Core: AMD Ryzen 7 2700X type: MT MCP speed: 2805 MHz min/max: 2200/4000 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Vega 10 XL/XT [Radeon RX Vega 56/64] driver: amdgpu v: kernel Display: wayland server: Fedora Project X.org 1.20.3 driver: amdgpu resolution: 3840x2160~60Hz OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.27.0 4.20.0-0.rc1.git4.1.fc30.x86_64 LLVM 7.0.0) v: 4.5 Mesa 18.2.4 Network: Device-1: Intel I211 Gigabit Network driver: igb Device-2: Realtek RTL8822BE 802.11a/b/g/n/ac WiFi adapter driver: r8822be Drives:Local Storage: total: 11.36 TiB used: 5.93 TiB (52.2%) Info: Processes: 440 Uptime: 37m Memory: 31.30 GiB used: 16.56 GiB (52.9%) Shell: bash inxi: 3.0.27 [5.591649] [drm] amdgpu: 8176M of VRAM memory ready [5.591653] [drm] amdgpu: 8176M of GTT memory ready. [5.591743] [drm] GART: num cpu pages 131072, num gpu pages 131072 [5.591908] [drm] PCIE GART of 512M enabled (table at 0x00F40090). [5.595509] [drm] use_doorbell being set to: [true] [5.595622] [drm] use_doorbell being set to: [true] [5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17 [5.595969] [drm] PSP loading UVD firmware [5.596266] [ cut here ] [5.596268] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: (null) [5.596285] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80 [5.596286] Modules linked in: amdgpu(+) hid_logitech_hidpp(+) chash gpu_sched amd_iommu_v2 ttm drm_kms_helper crc32c_intel drm hid_sony ff_memless igb hid_logitech_dj nvme dca i2c_algo_bit nvme_core wmi pinctrl_amd uas usb_storage [5.596299] CPU: 0 PID: 507 Comm: systemd-udevd Tainted: GW 4.20.0-0.rc1.git4.1.fc30.x86_64 #1 [5.596301] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0901 07/23/2018 [5.596303] RIP: 0010:debug_print_object+0x6a/0x80 [5.596305] Code: 8b 43 10 83 c2 01 8b 4b 14 4c 89 e6 89 15 e6 82 b0 02 4c 8b 45 00 48 c7 c7 60 fd 34 a6 48 8b 14 c5 a0 da 08 a6 e8 6a 6a b8 ff <0f> 0b 5b 83 05 d0 45 3e 01 01 5d 41 5c c3 83 05 c5 45 3e 01 01 c3 [5.596306] RSP: 0018:a02ac863f8c0 EFLAGS: 00010282 [5.596307] RAX: RBX: a02ac863f8e0 RCX: 0006 [5.596308] RDX: 0007 RSI: 9160e9a7bfe8 RDI: 9160f91d6c60 [5.596310] RBP: a6742740 R08: 0002 R09: [5.596311] R10: R11: R12: a634ff69 [5.596312] R13: 000b79d0 R14: a80f76d8 R15: 00266000 [5.596313] FS: 7f762abf7940() GS:9160f900() knlGS: [5.596314] CS: 0010 DS: ES: CR0: 80050033 [5.596315] CR2: 55fdc593f000 CR3: 0007e999c000 CR4: 003406f0 [5.596317] Call Trace: [5.596321] debug_object_assert_init+0x14a/0x180 [5.596327] del_timer+0x2e/0x90 [5.596383] amdgpu_fence_process+0x47/0x100 [amdgpu] [5.596430] amdgpu_uvd_resume+0xf6/0x120 [amdgpu] [5.596475] uvd_v7_0_sw_init+0xe0/0x280 [amdgpu] [5.596523] amdgpu_device_init.cold.30+0xf97/0x14b6 [amdgpu] [5.596563] ? amdgpu_driver_load_kms+0x53/0x330 [amdgpu] [5.596604] amdgpu_driver_load_kms+0x86/0x330 [amdgpu] [5.596614] drm_dev_register+0x115/0x150 [drm] [5.596654] amdgpu_pci_probe+0xbd/0x120 [amdgpu] [5.596658] local_pci_probe+0x41/0x90 [5.596661] pci_device_probe+0x188/0x1a0 [5.59] really_probe+0xf8/0x3b0 [5.596669] driver_probe_device+0xb3/0xf0 [5.596672] __driver_attach+0xe1/0x110 [5.596674] ? driver_probe_device+0xf0/0xf0 [5.596676] bus_for_each_dev+0x79/0xc0 [5.596679] bus_add_driver+0x155/0x230 [5.596681] ? 0xc07d9000 [5.596683] driver_register+0x6b/0xb0 [5.596685] ? 0xc07d9000 [5.596688] do_one_initcall+0x5d/0x2be [5.596691] ? rcu_read_
