[Bug 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299 --- Comment #4 from Frédéric Pierret (frederic.epi...@orange.fr) --- Hi, While debugging it I found the exception comes from gv100_disp_intr_exc_other in gv100.c because stat = 0x1800. I'm trying to figure out what messed up in the 'disp' structure but I'm doing it step by step by first searching for NULL pointers. Any advice for how to proceed? Thank you. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299 --- Comment #5 from Ilia Mirkin (imir...@alum.mit.edu) --- Your kernel log doesn't have anything too weird in it (which is good). However I did see a similar type of error with someone using coreboot (admittedly, with an MCP77 IGP). Are you using a non-original booting mechanism? Given that there's signed firmware situations going on, we can't just re-POST the GPU easily, unlike in the MCP77 case. The mmio read failures may be a red herring -- basically we try to figure out why the error happened, and get bad mmio reads in the process. Could just be that the error handler hasn't been properly adjusted for Turing, and reads from bad places. I'm afraid this is out of my knowledge base, sorry. Perhaps Ben will have something clever to say. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299 --- Comment #6 from Frédéric Pierret (frederic.epi...@orange.fr) --- (In reply to Ilia Mirkin from comment #5) > Your kernel log doesn't have anything too weird in it (which is good). > However I did see a similar type of error with someone using coreboot > (admittedly, with an MCP77 IGP). Are you using a non-original booting > mechanism? Given that there's signed firmware situations going on, we can't > just re-POST the GPU easily, unlike in the MCP77 case. I'm using standard default bios (legacy mode). > The mmio read failures may be a red herring -- basically we try to figure > out why the error happened, and get bad mmio reads in the process. Could > just be that the error handler hasn't been properly adjusted for Turing, and > reads from bad places. > > I'm afraid this is out of my knowledge base, sorry. Perhaps Ben will have > something clever to say. Hope so and thank you again for your feedback. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206231] R9 280X low performance with all games
https://bugzilla.kernel.org/show_bug.cgi?id=206231 --- Comment #45 from Sylvain BERTRAND (sylvain.bertr...@gmail.com) --- On Fri, Jan 24, 2020 at 09:47:44PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > In other words, this presumes the shaders submitted for compilation by dirt > rally engine are different each time the game is run ??? It may be related to the brand new mesa/src/gallium/auxiliary/util/u_live_shader_cache.c I don't know the inner details of this (I stay away from anything GL), but it seems there are some GL shader usages which which will trigger a full compilation of an already compiled shader. @alex, maybe that's what you were talking about? As I said, I may be totally wrong though. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Bug 206231] R9 280X low performance with all games
On Fri, Jan 24, 2020 at 09:47:44PM +, bugzilla-dae...@bugzilla.kernel.org wrote: > In other words, this presumes the shaders submitted for compilation by dirt > rally engine are different each time the game is run ??? It may be related to the brand new mesa/src/gallium/auxiliary/util/u_live_shader_cache.c I don't know the inner details of this (I stay away from anything GL), but it seems there are some GL shader usages which which will trigger a full compilation of an already compiled shader. @alex, maybe that's what you were talking about? As I said, I may be totally wrong though. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299 --- Comment #7 from Frédéric Pierret (frederic.epi...@orange.fr) --- With Marek, we think to found the problem. In nv50_disp_chan_mthd function, the exact NULL pointer reference is mthd->data[0]->mthd. Precisely, mthd->data is not null but mthd->data[0] seems so. Trying to access mthd->data[0] we get: BUG: kernel NULL pointer dereference, address: 0010 while trying to access mthd->data[0]->mthd, we get: BUG: kernel NULL pointer dereference, address: 0020 So this is exactly the issue. Any idea why mthd->data and not mthd->data[0]? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/5] drm/lima: add heap buffer support
On Thu, Jan 16, 2020 at 5:12 AM Qiang Yu wrote: > > Support heap buffer allocation which can grow the back memory > size when GP has an out of memory interrupt so that user don't > need to allocate a very large buffer at the beginning. Whole series: Reviewed-by: Vasily Khoruzhick > Qiang Yu (5): > drm/lima: update register info > drm/lima: add lima_vm_map_bo > drm/lima: support heap buffer creation > drm/lima: recover task by enlarging heap buffer > drm/lima: increase driver version to 1.1 > > drivers/gpu/drm/lima/lima_drv.c | 16 +++- > drivers/gpu/drm/lima/lima_drv.h | 1 + > drivers/gpu/drm/lima/lima_gem.c | 130 -- > drivers/gpu/drm/lima/lima_gem.h | 4 + > drivers/gpu/drm/lima/lima_gp.c| 51 +++- > drivers/gpu/drm/lima/lima_mmu.c | 5 ++ > drivers/gpu/drm/lima/lima_mmu.h | 1 + > drivers/gpu/drm/lima/lima_regs.h | 1 + > drivers/gpu/drm/lima/lima_sched.c | 35 ++-- > drivers/gpu/drm/lima/lima_sched.h | 6 ++ > drivers/gpu/drm/lima/lima_vm.c| 44 +- > drivers/gpu/drm/lima/lima_vm.h| 1 + > include/uapi/drm/lima_drm.h | 9 ++- > 13 files changed, 284 insertions(+), 20 deletions(-) > > -- > 2.17.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915
Manuel Ullmann (la...@posteo.de) changed:
What|Removed |Added
CC||la...@posteo.de
--- Comment #5 from Manuel Ullmann (la...@posteo.de) ---
Confirmed on navi14. Bisected it to 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4.
Log is indicating exactly nothing. I’ll attach them nonetheless, if you happen
to see more than me.
It’s just a wild guess, but could it be, that your indicator for a safe
lowering of the clock is not always a good indicator? I mean you know your code
a lot better than me. A clock, that is raised too high while voltage being too
low could however be a reason for the flickering on OpenGL operations, that I’m
seeing. Have not seen those on Vulkan or framebuffer though.
Anyway, have a look for yourself:
commit 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4
Author: Noah Abradjian
Date: Fri Sep 27 16:30:57 2019 -0400
drm/amd/display: Make clk mgr the only dto update point
[Why]
* Clk Mgr DTO update point did not cover all needed updates, as it included
a
check for plane_state which does not exist yet when the updater is called
on
driver startup
* This resulted in another update path in the pipe programming sequence,
based
on a dppclk update flag
* However, this alternate path allowed for stray DTO updates, some of which
would
occur in the wrong order during dppclk lowering and cause underflow
[How]
* Remove plane_state check and use of plane_res.dpp->inst, getting rid
of sequence dependencies (this results in extra dto programming for
unused
pipes but that doesn't cause issues and is a small cost)
* Allow DTOs to be updated even if global clock is equal, to account for
edge case exposed by diags tests
* Remove update_dpp_dto call in pipe programming sequence (leave update to
dppclk_control there, as that update is necessary and shouldn't occur in
clk
mgr)
* Remove call to optimize_bandwidth when committing state, as it is not
needed
and resulted in sporadic underflows even with other fixes in place
Signed-off-by: Noah Abradjian
Reviewed-by: Jun Lei
Acked-by: Leo Li
Signed-off-by: Alex Deucher
.../gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c | 14 +-
drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c | 3 ++-
drivers/gpu/drm/amd/display/dc/core/dc.c | 4
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_hwseq.c | 8 +---
4 files changed, 12 insertions(+), 17 deletions(-)
modified drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c
@@ -108,11 +108,12 @@ void dcn20_update_clocks_update_dpp_dto(struct
clk_mgr_internal *clk_mgr,
for (i = 0; i < clk_mgr->base.ctx->dc->res_pool->pipe_count; i++) {
int dpp_inst, dppclk_khz;
- if (!context->res_ctx.pipe_ctx[i].plane_state)
- continue;
-
- dpp_inst = context->res_ctx.pipe_ctx[i].plane_res.dpp->inst;
+ /* Loop index will match dpp->inst if resource exists,
+* and we want to avoid dependency on dpp object
+*/
+ dpp_inst = i;
dppclk_khz =
context->res_ctx.pipe_ctx[i].plane_res.bw.dppclk_khz;
+
clk_mgr->dccg->funcs->update_dpp_dto(
clk_mgr->dccg, dpp_inst, dppclk_khz);
}
@@ -235,6 +236,7 @@ void dcn2_update_clocks(struct clk_mgr *clk_mgr_base,
update_dispclk = true;
}
+
if (dc->config.forced_clocks == false || (force_reset &&
safe_to_lower)) {
if (dpp_clock_lowered) {
// if clock is being lowered, increase DTO before
lowering refclk
@@ -244,10 +246,12 @@ void dcn2_update_clocks(struct clk_mgr *clk_mgr_base,
// if clock is being raised, increase refclk before
lowering DTO
if (update_dppclk || update_dispclk)
dcn20_update_clocks_update_dentist(clk_mgr);
- if (update_dppclk)
+ // always update dtos unless clock is lowered and not
safe to lower
+ if (new_clocks->dppclk_khz >=
dc->current_state->bw_ctx.bw.dcn.clk.dppclk_khz)
dcn20_update_clocks_update_dpp_dto(clk_mgr,
context);
}
}
+
if (update_dispclk &&
dmcu && dmcu->funcs->is_dmcu_initialized(dmcu)) {
/*update dmcu for wait_loop count*/
modified drivers/gpu/drm/amd/display/dc/clk_mgr/dcn21/rn_clk_mgr.c
@@ -171,7 +171,8 @@ void rn_update_clocks(struct clk_mgr *clk_mgr_base,
// if clock is being raised, increase refclk before lowering
DTO
if (update_dppclk |
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 --- Comment #6 from Manuel Ullmann (la...@posteo.de) --- Created attachment 286981 --> https://bugzilla.kernel.org/attachment.cgi?id=286981&action=edit Xorg log on commit 50575eb5b339683ee148189beae5eb53ccb3158b -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 Manuel Ullmann (la...@posteo.de) changed: What|Removed |Added Attachment #286981|0 |1 is obsolete|| --- Comment #7 from Manuel Ullmann (la...@posteo.de) --- Created attachment 286983 --> https://bugzilla.kernel.org/attachment.cgi?id=286983&action=edit Xorg log of good commit 50575eb5b339683ee148189beae5eb53ccb3158b -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 --- Comment #9 from Manuel Ullmann (la...@posteo.de) --- Created attachment 286987 --> https://bugzilla.kernel.org/attachment.cgi?id=286987&action=edit Xorg log of bad commit 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 --- Comment #8 from Manuel Ullmann (la...@posteo.de) --- Created attachment 286985 --> https://bugzilla.kernel.org/attachment.cgi?id=286985&action=edit Kernel log of good commit 50575eb5b339683ee148189beae5eb53ccb3158b -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 --- Comment #10 from Manuel Ullmann (la...@posteo.de) --- Created attachment 286989 --> https://bugzilla.kernel.org/attachment.cgi?id=286989&action=edit Kernel log of bad commit 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299
--- Comment #8 from Frédéric Pierret (frederic.epi...@orange.fr) ---
We found more information!
The previous tests was done with those added lines:
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
@@ -75,13 +75,25 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
if (debug > subdev->debug)
return;
+ nvkm_warn(subdev, "mthd: %p", mthd);
+ nvkm_warn(subdev, "mthd->data: %p", mthd->data);
+ nvkm_warn(subdev, "&mthd->data[0]: %p", &mthd->data[0]);
+ nvkm_warn(subdev, "mthd->data[0].mthd: %p", mthd->data[0].mthd);
for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
which gaves as crashlog:
[ 45.513617] nouveau :26:00.0: disp: chid 73 stat 1080 reason 1
[PUSHBUFFER_ERR] mthd 0200 data badf5040 code badf5040
[ 45.513633] nouveau :26:00.0: disp: mthd: dfa55708
[ 45.513638] nouveau :26:00.0: disp: mthd->data: 858af80f
[ 45.513641] nouveau :26:00.0: disp: &mthd->data[0]: 858af80f
But replacing "%p" by "%lx", it revealed that mthd is NULL:
[ 74.753207] nouveau :26:00.0: disp: chid 73 stat 1080 reason 1
[PUSHBUFFER_ERR] mthd 0200 data badf5040 code badf5040
[ 74.753223] nouveau :26:00.0: disp: mthd: 0
[ 74.753226] nouveau :26:00.0: disp: mthd->data: 10
[ 74.753231] nouveau :26:00.0: disp: &mthd->data[0]: 10
[ 74.753241] BUG: kernel NULL pointer dereference, address: 0020
[ 74.753244] #PF: supervisor read access in kernel mode
That gives some hints!
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 206299] [nouveau/xen] RTX 20XX instant reboot
https://bugzilla.kernel.org/show_bug.cgi?id=206299
--- Comment #9 from Frédéric Pierret (frederic.epi...@orange.fr) ---
A rather simple and temporary fix we found is to add:
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
index bcf32d92ee5a..50e3539f33d2 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
@@ -74,6 +74,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
if (debug > subdev->debug)
return;
+ if (!mthd)
+ return;
for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
u32 base = chan->head * mthd->addr;
With that, it remains stable.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 205915] AMDGPU: Screen flicker after resume from suspend
https://bugzilla.kernel.org/show_bug.cgi?id=205915 --- Comment #11 from Manuel Ullmann (la...@posteo.de) --- Reverting 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4 on HEAD, currently 5.5-rc7+, seems to fix it. The revert should probably be limited to the 2 hunks in the clock manager files to preserve the underflow avoidance: - if (update_dppclk) + // always update dtos unless clock is lowered and not safe to lower + if (new_clocks->dppclk_khz >= dc->current_state->bw_ctx.bw.dcn.clk.dppclk_khz) For the sake of comleteness: Steps to reproduce: 1. Suspend with Navi and activated display core. 2. Resume. 3. Start glxgears. Actual results: Animation flickers. This happens on any OpenGL accelerated task, like Firefox with hardware acceleration or similar. Expected results: Flicker-free rendering. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 1962/2713] include/kcl/kcl_drm.h:191:9: error: too few arguments to function 'drm_encoder_init'
Hi Yifan,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f9a0b7ad3447d7766dda9923e63a5f4d0be7ce47
commit: 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff [1962/2713] drm/amdkcl: Test
whether drm_encoder_init() wants name
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout 35781c0b8d19ed0d1bdb8cfa85780841ea7985ff
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:98:1: error: conflicting types for
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fb_helper.h:589:1: note: previous definition of
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
>> include/kcl/kcl_drm.h:191:9: error: too few arguments to function
>> 'drm_encoder_init'
return drm_encoder_init(dev, encoder, funcs,
^~~~
In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~
vim +/drm_encoder_init +191 include/kcl/kcl_drm.h
5027d12c82b867 changzhu 2019-04-03 181
950c9c93299ece Junwei Zhang 2016-12-23 182 static inline int
kcl_drm_encoder_init(struct drm_device *dev,
950c9c93299ece Junwei Zhang 2016-12-23 183 struct
drm_encoder *encoder,
950c9c93299ece Junwei Zhang 2016-12-23 184 const struct
drm_encoder_funcs *funcs,
950c9c93299ece Junwei Zhang 2016-12-23 185 int encoder_type,
const char *name, ...)
950c9c93299ece Junwei Zhang 2016-12-23 186 {
35781c0b8d19ed Yifan Zhang 2019-07-15 187 #if
defined(HAVE_DRM_ENCODER_INIT_VALID_WITH_NAME)
950c9c93299ece Junwei Zhang 2016-12-23 188 return drm_encoder_init(dev,
encoder, funcs,
950c9c93299ece Junwei Zhang 2016-12-23 189 encoder_type,
name);
950c9c93299ece Junwei Zhang 2016-12-23 190 #else
950c9c93299ece Junwei Zhang 2016-12-23 @191 return drm_encoder_init(dev,
encoder, funcs,
950c9c93299ece Junwei Zhang 2016-12-23 192 encoder_type);
950c9c93299ece Junwei Zhang 2016-12-23 193 #endif
950c9c93299ece Junwei Zhang 2016-12-23 194 }
950c9c93299ece Junwei Zhang 2016-12-23 195
:: The code at line 191 was first introduced by commit
:: 950c9c93299eceb8cca4b12eb09a04a48d383ec6 drm/amdkcl: [4.5] fix drm
encoder and plane functions
:: TO: Junwei Zhang
:: CC: Chengming Gui
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[radeon-alex:amd-19.50 1963/2713] include/kcl/kcl_drm.h:206:10: error: too few arguments to function 'drm_crtc_init_with_planes'
Hi Slava,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.50
head: f9a0b7ad3447d7766dda9923e63a5f4d0be7ce47
commit: f2e0d469732d27bc612df52b42094309ba5877d9 [1963/2713] drm/amdkcl: Test
whether drm_crtc_init_with_planes() wants name
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.5.0-3) 7.5.0
reproduce:
git checkout f2e0d469732d27bc612df52b42094309ba5877d9
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h:98:1: error: conflicting types for
'drm_fb_helper_remove_conflicting_framebuffers'
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from include/kcl/kcl_drm.h:7:0,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_fb_helper.h:589:1: note: previous definition of
'drm_fb_helper_remove_conflicting_framebuffers' was here
drm_fb_helper_remove_conflicting_framebuffers(struct apertures_struct *a,
^
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_encoder_init':
include/kcl/kcl_drm.h:191:9: error: too few arguments to function
'drm_encoder_init'
return drm_encoder_init(dev, encoder, funcs,
^~~~
In file included from include/drm/drm_modeset_helper_vtables.h:33:0,
from include/drm/drm_atomic_helper.h:32,
from include/kcl/kcl_drm.h:10,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_encoder.h:183:5: note: declared here
int drm_encoder_init(struct drm_device *dev,
^~~~
In file included from drivers/gpu/drm/ttm/backport/backport.h:6:0,
from :0:
include/kcl/kcl_drm.h: In function 'kcl_drm_crtc_init_with_planes':
>> include/kcl/kcl_drm.h:206:10: error: too few arguments to function
>> 'drm_crtc_init_with_planes'
return drm_crtc_init_with_planes(dev, crtc, primary,
^
In file included from include/drm/drmP.h:68:0,
from include/kcl/kcl_drm.h:6,
from drivers/gpu/drm/ttm/backport/backport.h:6,
from :0:
include/drm/drm_crtc.h:1120:5: note: declared here
int drm_crtc_init_with_planes(struct drm_device *dev,
^
vim +/drm_crtc_init_with_planes +206 include/kcl/kcl_drm.h
950c9c93299ece Junwei Zhang 2016-12-23 195
950c9c93299ece Junwei Zhang 2016-12-23 196 static inline int
kcl_drm_crtc_init_with_planes(struct drm_device *dev, struct drm_crtc *crtc,
950c9c93299ece Junwei Zhang 2016-12-23 197 struct
drm_plane *primary,
950c9c93299ece Junwei Zhang 2016-12-23 198 struct
drm_plane *cursor,
950c9c93299ece Junwei Zhang 2016-12-23 199 const
struct drm_crtc_funcs *funcs,
950c9c93299ece Junwei Zhang 2016-12-23 200 const
char *name, ...)
950c9c93299ece Junwei Zhang 2016-12-23 201 {
f2e0d469732d27 Slava Grigorev 2018-07-17 202 #if
defined(HAVE_DRM_CRTC_INIT_WITH_PLANES_VALID_WITH_NAME)
950c9c93299ece Junwei Zhang 2016-12-23 203 return
drm_crtc_init_with_planes(dev, crtc, primary,
950c9c93299ece Junwei Zhang 2016-12-23 204
cursor, funcs, name);
950c9c93299ece Junwei Zhang 2016-12-23 205 #else
950c9c93299ece Junwei Zhang 2016-12-23 @206 return
drm_crtc_init_with_planes(dev, crtc, primary,
950c9c93299ece Junwei Zhang 2016-12-23 207
cursor, funcs);
950c9c93299ece Junwei Zhang 2016-12-23 208 #endif
950c9c93299ece Junwei Zhang 2016-12-23 209 }
950c9c93299ece Junwei Zhang 2016-12-23 210
:: The code at line 206 was first introduced by commit
:: 950c9c93299eceb8cca4b12eb09a04a48d383ec6 drm/amdkcl: [4.5] fix drm
encoder and plane functions
:: TO: Junwei Zhang
:: CC: Chengming Gui
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] matroxfb: add Matrox MGA-G200eW board support
Hi
Am 25.01.20 um 20:55 schrieb Rich Felker:
> Signed-off-by: Rich Felker
> --
> I've had this lying around a while and figure I should send it
> upsteam; it's needed to support the onboard video on my Spectre-free
> Atom S1260 server board.
This HW is supported by mgag200, which is maintained. Can't you use that?
Best regards
Thomas
>
> ---
> drivers/video/fbdev/matrox/matroxfb_base.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/video/fbdev/matrox/matroxfb_base.c
> b/drivers/video/fbdev/matrox/matroxfb_base.c
> index 1a555f70923a..ff344313860c 100644
> --- a/drivers/video/fbdev/matrox/matroxfb_base.c
> +++ b/drivers/video/fbdev/matrox/matroxfb_base.c
> @@ -1376,6 +1376,12 @@ static struct video_board vbG200 = {
> .accelID = FB_ACCEL_MATROX_MGAG200,
> .lowlevel = &matrox_G100
> };
> +static struct video_board vbG200eW = {
> + .maxvram = 0x80,
> + .maxdisplayable = 0x80,
> + .accelID = FB_ACCEL_MATROX_MGAG200,
> + .lowlevel = &matrox_G100
> +};
> /* from doc it looks like that accelerator can draw only to low 16MB :-(
> Direct accesses & displaying are OK for
> whole 32MB */
> static struct video_board vbG400 = {
> @@ -1494,6 +1500,13 @@ static struct board {
> MGA_G200,
> &vbG200,
> "MGA-G200 (PCI)"},
> + {PCI_VENDOR_ID_MATROX, 0x0532, 0xFF,
> + 0, 0,
> + DEVF_G200,
> + 25,
> + MGA_G200,
> + &vbG200eW,
> + "MGA-G200eW (PCI)"},
> {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_AGP, 0xFF,
> PCI_SS_VENDOR_ID_MATROX,PCI_SS_ID_MATROX_GENERIC,
> DEVF_G200,
> @@ -2136,6 +2149,8 @@ static const struct pci_device_id matroxfb_devices[] = {
> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_PCI,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> + {PCI_VENDOR_ID_MATROX, 0x0532,
> + PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G200_AGP,
> PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0},
> {PCI_VENDOR_ID_MATROX, PCI_DEVICE_ID_MATROX_G400,
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
