dri-devel September 2018

dri-devel@lists.freedesktop.org

276 participants
1899 discussions

[PATCH] drm: Suppress user controlled spam for invalid drm_wait_vblank_ioctl
by Chris Wilson 04 Sep '18

04 Sep '18

The ioctl arguments are under control of the user and as such we should resist any temptation to flood the kernel logs with their errors. Relegate the DRM_ERROR to a DRM_DEBUG so the user has to opt into hearing of their own mistakes. (One day we will have a small ringbuffer attached to the task, so that the concerned process can inspect its own debug info for EINVAL without them being hitting syslog at all.) Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- drivers/gpu/drm/drm_vblank.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 28cdcf76b6f9..a528920542ca 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -1541,7 +1541,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void *data, if (vblwait->request.type & ~(_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK | _DRM_VBLANK_HIGH_CRTC_MASK)) { - DRM_ERROR("Unsupported type value 0x%x, supported mask 0x%x\n", + DRM_DEBUG("Unsupported type value 0x%x, supported mask 0x%x\n", vblwait->request.type, (_DRM_VBLANK_TYPES_MASK | _DRM_VBLANK_FLAGS_MASK | _DRM_VBLANK_HIGH_CRTC_MASK)); -- 2.19.0.rc1

2 2

[radeon-alex:drm-next-4.20-wip 99/258] include/asm-generic/div64.h:239:22: error: passing argument 1 of '__div64_32' from incompatible pointer type
by kbuild test robot 04 Sep '18

04 Sep '18

Hi Evan, FYI, the error/warning still remains. tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip head: 6abc0c8f8cf3e0c47707b01f027f9f9b9aa75646 commit: d617d4d73043bc4cbc316a7a1b4370fa5bc26a31 [99/258] drm/amd/powerplay: new interfaces for overdrive vega20 sclk and mclk config: microblaze-allyesconfig (attached as .config) compiler: microblaze-linux-gcc (GCC) 8.1.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout d617d4d73043bc4cbc316a7a1b4370fa5bc26a31 # save the attached .config to linux build tree GCC_VERSION=8.1.0 make.cross ARCH=microblaze :::::: branch date: 2 days ago :::::: commit date: 8 days ago All errors (new ones prefixed by >>): In file included from ./arch/microblaze/include/generated/asm/div64.h:1, from include/linux/kernel.h:207, from include/linux/delay.h:22, from drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24: drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c: In function 'vega20_set_sclk_od': include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ ^~ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1200:2: note: in expansion of macro 'do_div' do_div(od_sclk, 100); ^~~~~~ In file included from include/linux/kernel.h:10, from include/linux/delay.h:22, from drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24: include/asm-generic/div64.h:235:25: warning: right shift count >= width of type [-Wshift-count-overflow] } else if (likely(((n) >> 32) == 0)) { \ ^~ include/linux/compiler.h:76:40: note: in definition of macro 'likely' # define likely(x) __builtin_expect(!!(x), 1) ^ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1200:2: note: in expansion of macro 'do_div' do_div(od_sclk, 100); ^~~~~~ In file included from ./arch/microblaze/include/generated/asm/div64.h:1, from include/linux/kernel.h:207, from include/linux/delay.h:22, from drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24: >> include/asm-generic/div64.h:239:22: error: passing argument 1 of '__div64_32' from incompatible pointer type [-Werror=incompatible-pointer-types] __rem = __div64_32(&(n), __base); \ ^~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1200:2: note: in expansion of macro 'do_div' do_div(od_sclk, 100); ^~~~~~ include/asm-generic/div64.h:213:38: note: expected 'uint64_t *' {aka 'long long unsigned int *'} but argument is of type 'uint32_t *' {aka 'unsigned int *'} extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor); ~~~~~~~~~~^~~~~~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c: In function 'vega20_set_mclk_od': include/asm-generic/div64.h:222:28: warning: comparison of distinct pointer types lacks a cast (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ ^~ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1247:2: note: in expansion of macro 'do_div' do_div(od_mclk, 100); ^~~~~~ In file included from include/linux/kernel.h:10, from include/linux/delay.h:22, from drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24: include/asm-generic/div64.h:235:25: warning: right shift count >= width of type [-Wshift-count-overflow] } else if (likely(((n) >> 32) == 0)) { \ ^~ include/linux/compiler.h:76:40: note: in definition of macro 'likely' # define likely(x) __builtin_expect(!!(x), 1) ^ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1247:2: note: in expansion of macro 'do_div' do_div(od_mclk, 100); ^~~~~~ In file included from ./arch/microblaze/include/generated/asm/div64.h:1, from include/linux/kernel.h:207, from include/linux/delay.h:22, from drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:24: >> include/asm-generic/div64.h:239:22: error: passing argument 1 of '__div64_32' from incompatible pointer type [-Werror=incompatible-pointer-types] __rem = __div64_32(&(n), __base); \ ^~~~ drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/vega20_hwmgr.c:1247:2: note: in expansion of macro 'do_div' do_div(od_mclk, 100); ^~~~~~ include/asm-generic/div64.h:213:38: note: expected 'uint64_t *' {aka 'long long unsigned int *'} but argument is of type 'uint32_t *' {aka 'unsigned int *'} extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor); ~~~~~~~~~~^~~~~~~~ cc1: some warnings being treated as errors git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git git remote update radeon-alex git checkout d617d4d73043bc4cbc316a7a1b4370fa5bc26a31 vim +/__div64_32 +239 include/asm-generic/div64.h ^1da177e Linus Torvalds 2005-04-16 215 ^1da177e Linus Torvalds 2005-04-16 216 /* The unnecessary pointer compare is there ^1da177e Linus Torvalds 2005-04-16 217 * to check for type safety (n must be 64bit) ^1da177e Linus Torvalds 2005-04-16 218 */ ^1da177e Linus Torvalds 2005-04-16 219 # define do_div(n,base) ({ \ ^1da177e Linus Torvalds 2005-04-16 220 uint32_t __base = (base); \ ^1da177e Linus Torvalds 2005-04-16 221 uint32_t __rem; \ ^1da177e Linus Torvalds 2005-04-16 222 (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ 911918aa Nicolas Pitre 2015-11-02 223 if (__builtin_constant_p(__base) && \ 911918aa Nicolas Pitre 2015-11-02 224 is_power_of_2(__base)) { \ 911918aa Nicolas Pitre 2015-11-02 225 __rem = (n) & (__base - 1); \ 911918aa Nicolas Pitre 2015-11-02 226 (n) >>= ilog2(__base); \ 461a5e51 Nicolas Pitre 2015-10-30 227 } else if (__div64_const32_is_OK && \ 461a5e51 Nicolas Pitre 2015-10-30 228 __builtin_constant_p(__base) && \ 461a5e51 Nicolas Pitre 2015-10-30 229 __base != 0) { \ 461a5e51 Nicolas Pitre 2015-10-30 230 uint32_t __res_lo, __n_lo = (n); \ 461a5e51 Nicolas Pitre 2015-10-30 231 (n) = __div64_const32(n, __base); \ 461a5e51 Nicolas Pitre 2015-10-30 232 /* the remainder can be computed with 32-bit regs */ \ 461a5e51 Nicolas Pitre 2015-10-30 233 __res_lo = (n); \ 461a5e51 Nicolas Pitre 2015-10-30 234 __rem = __n_lo - __res_lo * __base; \ 911918aa Nicolas Pitre 2015-11-02 235 } else if (likely(((n) >> 32) == 0)) { \ ^1da177e Linus Torvalds 2005-04-16 236 __rem = (uint32_t)(n) % __base; \ ^1da177e Linus Torvalds 2005-04-16 237 (n) = (uint32_t)(n) / __base; \ ^1da177e Linus Torvalds 2005-04-16 238 } else \ ^1da177e Linus Torvalds 2005-04-16 @239 __rem = __div64_32(&(n), __base); \ ^1da177e Linus Torvalds 2005-04-16 240 __rem; \ ^1da177e Linus Torvalds 2005-04-16 241 }) ^1da177e Linus Torvalds 2005-04-16 242 :::::: The code at line 239 was first introduced by commit :::::: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2 :::::: TO: Linus Torvalds <torvalds(a)ppc970.osdl.org> :::::: CC: Linus Torvalds <torvalds(a)ppc970.osdl.org> --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 0

[drm-tip:drm-tip 144/320] debug.c:undefined reference to `save_stack_trace'
by kbuild test robot 04 Sep '18

04 Sep '18

Hi Daniel, FYI, the error/warning still remains. tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: 1b18cb66428cffa748719cf900b2decac3690029 commit: 7928ca5cc786fdc0269342f1b9e22c2af939b989 [144/320] RFC: debugobjects: capture stack traces at _init() time config: m68k-allyesconfig (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 git checkout 7928ca5cc786fdc0269342f1b9e22c2af939b989 # save the attached .config to linux build tree GCC_VERSION=7.2.0 make.cross ARCH=m68k :::::: branch date: 9 hours ago :::::: commit date: 3 weeks ago All errors (new ones prefixed by >>): kernel/dma/debug.o: In function `dma_entry_alloc': >> debug.c:(.text+0x11c2): undefined reference to `save_stack_trace' kernel/backtracetest.o: In function `backtrace_regression_test': backtracetest.c:(.text+0xd8): undefined reference to `save_stack_trace' mm/slub.o: In function `set_track': >> slub.c:(.text+0x12b4): undefined reference to `save_stack_trace' fs/btrfs/ref-verify.o: In function `btrfs_ref_tree_mod': ref-verify.c:(.text+0x92e): undefined reference to `save_stack_trace' lib/debugobjects.o: In function `save_stack.isra.0': >> debugobjects.c:(.text+0x9f2): undefined reference to `save_stack_trace' --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 0

[PATCH v9 0/2] Add XYUV format support
by Stanislav Lisovskiy 04 Sep '18

04 Sep '18

Introduced new XYUV scan-in format for framebuffer and added support for it to i915(SkyLake+). Stanislav Lisovskiy (2): drm: Introduce new DRM_FORMAT_XYUV drm/i915: Adding YUV444 packed format support for skl+ drivers/gpu/drm/drm_fourcc.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/intel_display.c | 15 +++++++++++++++ drivers/gpu/drm/i915/intel_sprite.c | 1 + include/uapi/drm/drm_fourcc.h | 1 + 5 files changed, 19 insertions(+), 1 deletion(-) -- 2.17.0

4 6

[radeon-alex:drm-next-4.20-wip 165/258] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:9: warning: missing braces around initializer
by kbuild test robot 04 Sep '18

04 Sep '18

tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip head: 6abc0c8f8cf3e0c47707b01f027f9f9b9aa75646 commit: dd73043534515c1b8bf31f78f0e9945f5d95e0e6 [165/258] drm/amd/display: implement DPMS DTN test v2 config: i386-randconfig-j3-201835 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: git checkout dd73043534515c1b8bf31f78f0e9945f5d95e0e6 # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c: In function 'dcn10_get_hubbub_state': >> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:9: warning: missing braces around initializer [-Wmissing-braces] struct dcn_hubbub_wm wm = {0}; ^ drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c:74:9: warning: (near initialization for 'wm.sets') [-Wmissing-braces] vim +74 drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_hw_sequencer_debug.c 70 71 static unsigned int dcn10_get_hubbub_state(struct dc *dc, char *pBuf, unsigned int bufSize) 72 { 73 struct dc_context *dc_ctx = dc->ctx; > 74 struct dcn_hubbub_wm wm = {0}; 75 int i; 76 77 unsigned int chars_printed = 0; 78 unsigned int remaining_buffer = bufSize; 79 80 const uint32_t ref_clk_mhz = dc_ctx->dc->res_pool->ref_clock_inKhz / 1000; 81 static const unsigned int frac = 1000; 82 83 hubbub1_wm_read_state(dc->res_pool->hubbub, &wm); 84 85 chars_printed = snprintf_count(pBuf, remaining_buffer, "wm_set_index,data_urgent,pte_meta_urgent,sr_enter,sr_exit,dram_clk_chanage\n"); 86 remaining_buffer -= chars_printed; 87 pBuf += chars_printed; 88 89 for (i = 0; i < 4; i++) { 90 struct dcn_hubbub_wm_set *s; 91 92 s = &wm.sets[i]; 93 94 chars_printed = snprintf_count(pBuf, remaining_buffer, "%x,%d.%03d,%d.%03d,%d.%03d,%d.%03d,%d.%03d\n", 95 s->wm_set, 96 (s->data_urgent * frac) / ref_clk_mhz / frac, (s->data_urgent * frac) / ref_clk_mhz % frac, 97 (s->pte_meta_urgent * frac) / ref_clk_mhz / frac, (s->pte_meta_urgent * frac) / ref_clk_mhz % frac, 98 (s->sr_enter * frac) / ref_clk_mhz / frac, (s->sr_enter * frac) / ref_clk_mhz % frac, 99 (s->sr_exit * frac) / ref_clk_mhz / frac, (s->sr_exit * frac) / ref_clk_mhz % frac, 100 (s->dram_clk_chanage * frac) / ref_clk_mhz / frac, (s->dram_clk_chanage * frac) / ref_clk_mhz % frac); 101 remaining_buffer -= chars_printed; 102 pBuf += chars_printed; 103 } 104 105 return bufSize - remaining_buffer; 106 } 107 --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 0

[PATCH] Document/gpu: Use new vm_fault_t type
by Souptick Joarder 04 Sep '18

04 Sep '18

We have introduce new return type vm_fault_t for fault handler. Update the document for the same. Signed-off-by: Souptick Joarder <jrdr.linux(a)gmail.com> --- v2: Revert spaces added in v1 Documentation/gpu/drm-mm.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 21b6b72..c3ae888 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -297,7 +297,7 @@ made up of several fields, the more interesting ones being: struct vm_operations_struct { void (*open)(struct vm_area_struct * area); void (*close)(struct vm_area_struct * area); - int (*fault)(struct vm_fault *vmf); + vm_fault_t (*fault)(struct vm_fault *vmf); }; -- 1.9.1

2 1

[PATCH libdrm] Add basic CONTRIBUTING file
by Daniel Vetter 04 Sep '18

04 Sep '18

I picked up a bunch of the pieces from wayland's version: https://gitlab.freedesktop.org/wayland/wayland/blob/master/CONTRIBUTING.md The weston one is fairly similar. Then I rather massively trimmed it down since in reality libdrm is a bit a dumping ground with very few real rules. The commit rights and CoC sections I've copied verbatim from igt respectively drm-misc. Weston/Wayland only differ in their pick of how many patches you need (10 instead of 5). I think for libdrm this is supremely relevant, since most everyone will get their commit rights by contributing already to the kernel or mesa and having commit rights there already. Anyway, I figured this is good to get the rules documented, even if there's mostly not many rules. Note: This references maintainers in a MAINTAINERS file, which needs to be created first. Note: With the gitlab migration the entire commit rights process is still a bit up in the air. But gitlab commit rights and roles are hierarchical, so we can do libdrm-only maintainer/commiter roles ("Owner" and "Developer" in gitlab-speak). This should avoid conflating libdrm roles with mesa roles, useful for those pushing to libdrm as primarily kernel contributors. v2: Comments from Emil: - Recommend subject prefix. - Fix copypaste fumbles, this isn't igt/wayland ... v3: Comments from Marek: - libdrm moved to mesa, update the document. Atm the entire account request situation is entirely not clear for gitlab and mesa projects, so that's a bit up in the air. Also, should probably send an announcement to dri-devel@, which didn't happen. - amd folks don't submit their patches to dri-devel, document that. Probably applies to other drivers too. v4: Comments from Rob: - Also include kernel/userspace in the commit counts criteria, due to libdrm's special role as a glue library. v5: Summarize the irc discussion on gitlab roles in the commit message a bit. v6: Some grammer stuff from Eric E. v7: Use --local in git config (Eric E.) Cc: Dave Airlie <airlied(a)gmail.com> Cc: Michel Dänzer <michel(a)daenzer.net> Cc: Emil Velikov <emil.velikov(a)collabora.com> Cc: Marek Olšák <marek.olsak(a)amd.com> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Eric Engestrom <eric.engestrom(a)intel.com> Reviewed-by: Rob Clark <robdclark(a)gmail.com> (v4) Reviewed-by: Eric Engestrom <eric.engestrom(a)intel.com> (v6) Acked-by: Emil Velikov <emil.l.velikov(a)gmail.com> (v6) Acked-by: Marek Olšák <marek.olsak(a)amd.com> (v5) References: https://gitlab.freedesktop.org/wayland/weston/blob/master/CONTRIBUTING.md References: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html#commit… References: https://cgit.freedesktop.org/drm/igt-gpu-tools/tree/CONTRIBUTING#n54 Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- CONTRIBUTING | 105 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 CONTRIBUTING diff --git a/CONTRIBUTING b/CONTRIBUTING new file mode 100644 index 000000000000..96f1e4fb0108 --- /dev/null +++ b/CONTRIBUTING @@ -0,0 +1,105 @@ +Contributing to libdrm +====================== + +Submitting Patches +------------------ + +Patches should be sent to dri-devel(a)lists.freedesktop.org, using git +send-email. For patches only touching driver specific code one of the driver +mailing lists (like amd-gfx(a)lists.freedesktop.org) is also appropriate. See git +documentation for help: + +http://git-scm.com/documentation + +Since dri-devel is a very busy mailing list please use --subject-prefix="PATCH +libdrm" to make it easier to find libdrm patches. This is best done by running + + git config --local format.subjectprefix "PATCH libdrm" + +The first line of a commit message should contain a prefix indicating what part +is affected by the patch followed by one sentence that describes the change. For +examples: + + amdgpu: Use uint32_t i in amdgpu_find_bo_by_cpu_mapping + +The body of the commit message should describe what the patch changes and why, +and also note any particular side effects. For a recommended reading on +writing commit messages, see: + +http://who-t.blogspot.de/2009/12/on-commit-messages.html + +Your patches should also include a Signed-off-by line with your name and email +address. If you're not the patch's original author, you should also gather +S-o-b's by them (and/or whomever gave the patch to you.) The significance of +this is that it certifies that you created the patch, that it was created under +an appropriate open source license, or provided to you under those terms. This +lets us indicate a chain of responsibility for the copyright status of the code. +For more details: + +https://developercertificate.org/ + +We won't reject patches that lack S-o-b, but it is strongly recommended. + +Review and Merging +------------------ + +Patches should have at least one positive review (Reviewed-by: tag) or +indication of approval (Acked-by: tag) before merging. For any code shared +between drivers this is mandatory. + +Please note that kernel/userspace API header files have special rules, see +include/drm/README. + +Coding style in the project loosely follows the CodingStyle of the linux kernel: + +https://www.kernel.org/doc/html/latest/process/coding-style.html?highlight=coding%20style + +Commit Rights +------------- + +Commit rights will be granted to anyone who requests them and fulfills the +below criteria: + +- Submitted a few (5-10 as a rule of thumb) non-trivial (not just simple + spelling fixes and whitespace adjustment) patches that have been merged + already. Since libdrm is just a glue library between the kernel and userspace + drivers, merged patches to those components also count towards the commit + criteria. + +- Are actively participating on discussions about their work (on the mailing + list or IRC). This should not be interpreted as a requirement to review other + peoples patches but just make sure that patch submission isn't one-way + communication. Cross-review is still highly encouraged. + +- Will be regularly contributing further patches. This includes regular + contributors to other parts of the open source graphics stack who only + do the oddball rare patch within libdrm itself. + +- Agrees to use their commit rights in accordance with the documented merge + criteria, tools, and processes. + +To apply for commit rights ("Developer" role in gitlab) send a mail to +dri-devel(a)lists.freedesktop.org and please ping the maintainers if your request +is stuck. + +Committers are encouraged to request their commit rights get removed when they +no longer contribute to the project. Commit rights will be reinstated when they +come back to the project. + +Maintainers and committers should encourage contributors to request commit +rights, as especially junior contributors tend to underestimate their skills. + +Code of Conduct +--------------- + +Please be aware the fd.o Code of Conduct also applies to libdrm: + +https://www.freedesktop.org/wiki/CodeOfConduct/ + +See the gitlab project owners for contact details of the libdrm maintainers. + +Abuse of commit rights, like engaging in commit fights or willfully pushing +patches that violate the documented merge criteria, will also be handled through +the Code of Conduct enforcement process. + +Happy hacking! -- 2.18.0

4 3

Re: [RFC] drm/amdgpu: Add macros and documentation for format modifiers.
by Bas Nieuwenhuizen 04 Sep '18

04 Sep '18

+everyone again On Tue, Sep 4, 2018 at 2:39 PM Bas Nieuwenhuizen <bas(a)basnieuwenhuizen.nl> wrote: > > On Tue, Sep 4, 2018 at 2:22 PM Daniel Stone <daniel(a)fooishbar.org> wrote: > > > > Hi, > > > > On Tue, 4 Sep 2018 at 11:44, Christian König > > <ckoenig.leichtzumerken(a)gmail.com> wrote: > > > Am 04.09.2018 um 12:15 schrieb Daniel Stone: > > > > Right. The conclusion, after people went through and started sorting > > > > out the kinds of formats for which they would _actually_ export real > > > > colour buffers for, that most vendors definitely have fewer than > > > > 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936 > > > > possible formats to represent, very likely fewer than > > > > 340,282,366,920,938,463,463,374,607,431,768,211,456 formats, probably > > > > fewer than 72,057,594,037,927,936 formats, and even still generally > > > > fewer than 281,474,976,710,656 if you want to be generous and leave 8 > > > > bits of the 56 available. > > > > > > The problem here is that at least for some parameters we actually don't > > > know which formats are actually used. > > > > > > The following are not real world examples, but just to explain the > > > general problem. > > > > > > The memory configuration for example can be not ASIC specific, but > > > rather determined by whoever took the ASIC and glued it together with > > > VRAM on a board. It is not likely that somebody puts all the VRAM chips > > > on one channel, but it is still perfectly possible. > > > > > > Same is true for things like harvesting, e.g. of 16 channels halve of > > > them could be bad and we need to know which to actually use. > > > > Sure, that's fine, but I'm not sure why, for instance, 'half of the > > memory channels are bad and must be avoided' would be attached to a > > format in the same way that macrotile size/depth would be? Similarly, > > what happens if you encode a channel or lane blacklist mask into a > > modifier, and then you import a buffer with that modifier into a > > client API on another device. Does that also apply to the other device > > or only the source device? > > > > How then do you handle the capability query between them: is it > > relevant to device B attempting to import and sample from an image > > that device A only has a 128-bit memory bus because of SKU > > configuration? How does generic userspace look at a token which > > encodes all of this information and know that the buffer is > > interchangeable between devices? > > So my idea here is to encode all the bits that determine format in a > way that as much as possible if it > results in the same layout it should get the same modifier(i.e. remove > useless info): > > https://lists.freedesktop.org/archives/dri-devel/2018-September/188418.html > > An example of the per-chip things is the PIPE_CONFIG, which is used > for address calculation in the macro-tiled mode: > > https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/amd/addrlib/r800/s… > > two chips with different PIPE_CONFIG will have different texture > layouts, as the address swizzles are different. > > So it gets included in the modifier (the PIPE_CONFIG is pretty much > constant per chip but multiple chips might have the same PIPE_CONFIG). > > > > > Cheers, > > Daniel > > _______________________________________________ > > dri-devel mailing list > > dri-devel(a)lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel

1 0

[Bug 107781] amdgpu hangs on resume on Lenovo A475
by bugzilla-daemon＠freedesktop.org 04 Sep '18

04 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=107781 --- Comment #7 from Michel Dänzer <michel(a)daenzer.net> --- (In reply to Alex Findler from comment #6) > I'll use these instructions. Which remote and baseline should I choose? The linux-4.17.y or linux-4.18.y branch from linux-stable.git . -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 107819] DRM radeon GPU fault detected (gem object lookup failed)
by bugzilla-daemon＠freedesktop.org 04 Sep '18

04 Sep '18

https://bugs.freedesktop.org/show_bug.cgi?id=107819 Bug ID: 107819 Summary: DRM radeon GPU fault detected (gem object lookup failed) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: egdfree(a)opensuse.org After plug two monitor i see this errors in dmesg (first monitor connected in HDMI, second in DisplayPort): kernel: [drm:radeon_cs_parser_relocs [radeon]] *ERROR* gem object lookup failed 0xa kernel: [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to parse relocation -2! kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x0ec35014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105B76 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03050014 kernel: VM fault (0x04, vmid 1) at page 1071990, write from CB (80) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x0e835014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105B57 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1071959, write from CB (16) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x0ee36014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105C3E kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03020014 kernel: VM fault (0x04, vmid 1) at page 1072190, write from CB (32) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x0ec36014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105CC0 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1072320, write from CB (16) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x0ee35014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105D36 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03060014 kernel: VM fault (0x04, vmid 1) at page 1072438, write from CB (96) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x0e836014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105D9C kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03050014 kernel: VM fault (0x04, vmid 1) at page 1072540, write from CB (80) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x0ea35014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105E12 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1072658, write from CB (16) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x07435014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105B38 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1071928, write from CB (16) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x07035014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105BA3 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03010014 kernel: VM fault (0x04, vmid 1) at page 1072035, write from CB (16) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x07035014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105C26 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03060014 kernel: VM fault (0x04, vmid 1) at page 1072166, write from CB (96) kernel: radeon 0000:01:00.0: GPU fault detected: 146 0x07236014 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00105C23 kernel: radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x03020014 installed: kernel-default-4.18.5-1.6.x86_64 libdrm_radeon1-32bit-2.4.93-1.1.x86_64 libdrm_amdgpu1-2.4.93-1.1.x86_64 libdrm_nouveau2-2.4.93-1.1.x86_64 libva-drm2-2.2.0-1.1.x86_64 libdrm_nouveau2-32bit-2.4.93-1.1.x86_64 libdrm2-2.4.93-1.1.x86_64 libdrm_intel1-32bit-2.4.93-1.1.x86_64 libdrm_intel1-2.4.93-1.1.x86_64 libdrm_radeon1-2.4.93-1.1.x86_64 libdrm2-32bit-2.4.93-1.1.x86_64 libdrm_amdgpu1-32bit-2.4.93-1.1.x86_64 libdrm-devel-2.4.93-1.1.x86_64 Mesa-libGLESv2-2-18.1.6-207.1.x86_64 Mesa-dri-32bit-18.1.6-205.1.x86_64 libOSMesa8-18.1.6-207.1.x86_64 Mesa-libva-18.1.6-207.1.x86_64 Mesa-libEGL1-18.1.6-207.1.x86_64 Mesa-gallium-18.1.6-207.1.x86_64 Mesa-libEGL-devel-18.1.6-207.1.x86_64 Mesa-libEGL1-32bit-18.1.6-207.1.x86_64 Mesa-gallium-32bit-18.1.6-205.1.x86_64 Mesa-libGL1-18.1.6-207.1.x86_64 Mesa-libglapi0-18.1.6-207.1.x86_64 Mesa-libd3d-32bit-18.1.6-205.1.x86_64 Mesa-dri-18.1.6-207.1.x86_64 Mesa-libglapi0-32bit-18.1.6-207.1.x86_64 Mesa-libGL-devel-18.1.6-207.1.x86_64 Mesa-demo-x-8.4.0-1.3.x86_64 Mesa-libd3d-18.1.6-207.1.x86_64 Mesa-32bit-18.1.6-207.1.x86_64 libOSMesa8-32bit-18.1.6-207.1.x86_64 Mesa-libGL1-32bit-18.1.6-207.1.x86_64 Mesa-18.1.6-207.1.x86_64 xorg-x11-server-1.20.1-1.1.x86_64 hardware: Radeon HD7770 -- You are receiving this mail because: You are the assignee for the bug.

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2018