[PATCH 0/4] Detect and remove trace_printk
trace_printk is meant as a debugging tool, and should not be compiled into production code without specific debug Kconfig options enabled or source code changes. Patches 1 to 3 remove/disable trace_printk that should not be enabled by default. Patch 4 adds a config option that can be used to detect such trace_printk at compile time (instead of printing a nasty warning at runtime). Nicolas Boichat (4): usb: cdns3: gadget: Replace trace_printk by dev_dbg media: atomisp: Replace trace_printk by pr_info media: camss: vfe: Use trace_printk for debugging only kernel/trace: Add TRACING_ALLOW_PRINTK config option drivers/gpu/drm/i915/Kconfig.debug | 4 ++-- .../media/platform/qcom/camss/camss-vfe-4-1.c | 2 ++ .../media/platform/qcom/camss/camss-vfe-4-7.c | 2 ++ drivers/staging/media/atomisp/pci/hmm/hmm.c | 10 +- drivers/usb/cdns3/gadget.c | 2 +- fs/f2fs/Kconfig | 1 + include/linux/kernel.h | 17 - kernel/trace/Kconfig| 10 ++ samples/Kconfig | 2 ++ 9 files changed, 41 insertions(+), 9 deletions(-) -- 2.27.0.212.ge8ba1cc988-goog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] usb: cdns3: gadget: Replace trace_printk by dev_dbg
trace_printk should not be used in production code, replace it
call with dev_dbg.
Signed-off-by: Nicolas Boichat
---
Unclear why a trace_printk was used in the first place, it's
possible that some rate-limiting is necessary here.
drivers/usb/cdns3/gadget.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/cdns3/gadget.c b/drivers/usb/cdns3/gadget.c
index 5e24c2e57c0d8c8..c303ab7c62d1651 100644
--- a/drivers/usb/cdns3/gadget.c
+++ b/drivers/usb/cdns3/gadget.c
@@ -421,7 +421,7 @@ static int cdns3_start_all_request(struct cdns3_device
*priv_dev,
if ((priv_req->flags & REQUEST_INTERNAL) ||
(priv_ep->flags & EP_TDLCHK_EN) ||
priv_ep->use_streams) {
- trace_printk("Blocking external request\n");
+ dev_dbg(priv_dev->dev, "Blocking external request\n");
return ret;
}
}
--
2.27.0.212.ge8ba1cc988-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/4] kernel/trace: Add TRACING_ALLOW_PRINTK config option
trace_printk is meant as a debugging tool, and should not be
compiled into production code without specific debug Kconfig
options enabled, or source code changes, as indicated by the
warning that shows up on boot if any trace_printk is called:
** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE **
** **
** trace_printk() being used. Allocating extra memory. **
** **
** This means that this is a DEBUG kernel and it is **
** unsafe for production use. **
If this option is set to n, the kernel will generate a
build-time error if trace_printk is used.
Note that the code to handle trace_printk is still present,
so this does not prevent people from compiling out-of-tree
kernel modules with the option set to =y, or BPF programs.
Signed-off-by: Nicolas Boichat
---
Changes since v1:
- Use static_assert instead of __static_assert (Jason Gunthorpe)
- Fix issues that can be detected by this patch (running some
randconfig in a loop, kernel test robot, or manual inspection),
by:
- Making some debug config options that use trace_printk depend
on the new config option.
- Adding 3 patches before this one.
There is a question from Alexei whether the warning is warranted,
and it's possibly too strongly worded, but the fact is, we do
not want trace_printk to be sprinkled in kernel code by default,
unless a very specific Kconfig command is enabled (or preprocessor
macro).
There's at least 3 reasons that I can come up with:
1. trace_printk introduces some overhead.
2. If the kernel keeps adding always-enabled trace_printk, it will
be much harder for developers to make use of trace_printk for
debugging.
3. People may assume that trace_printk is for debugging only, and
may accidentally output sensitive data (theoritical at this
stage).
drivers/gpu/drm/i915/Kconfig.debug | 4 ++--
fs/f2fs/Kconfig| 1 +
include/linux/kernel.h | 17 -
kernel/trace/Kconfig | 10 ++
samples/Kconfig| 2 ++
5 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/Kconfig.debug
b/drivers/gpu/drm/i915/Kconfig.debug
index 1cb28c20807c59d..fa30f9bdc82311f 100644
--- a/drivers/gpu/drm/i915/Kconfig.debug
+++ b/drivers/gpu/drm/i915/Kconfig.debug
@@ -84,7 +84,7 @@ config DRM_I915_ERRLOG_GEM
config DRM_I915_TRACE_GEM
bool "Insert extra ftrace output from the GEM internals"
depends on DRM_I915_DEBUG_GEM
- select TRACING
+ depends on TRACING_ALLOW_PRINTK
default n
help
Enable additional and verbose debugging output that will spam
@@ -98,7 +98,7 @@ config DRM_I915_TRACE_GEM
config DRM_I915_TRACE_GTT
bool "Insert extra ftrace output from the GTT internals"
depends on DRM_I915_DEBUG_GEM
- select TRACING
+ depends on TRACING_ALLOW_PRINTK
default n
help
Enable additional and verbose debugging output that will spam
diff --git a/fs/f2fs/Kconfig b/fs/f2fs/Kconfig
index d13c5c6a978769b..d161d96cc1b7418 100644
--- a/fs/f2fs/Kconfig
+++ b/fs/f2fs/Kconfig
@@ -80,6 +80,7 @@ config F2FS_IO_TRACE
bool "F2FS IO tracer"
depends on F2FS_FS
depends on FUNCTION_TRACER
+ depends on TRACING_ALLOW_PRINTK
help
F2FS IO trace is based on a function trace, which gathers process
information and block IO patterns in the filesystem level.
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 196607aaf653082..8abce95b0c95a0e 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -721,10 +721,15 @@ do {
\
#define trace_printk(fmt, ...) \
do { \
char ___STR[] = __stringify((__VA_ARGS__)); \
+ \
+ static_assert( \
+ IS_ENABLED(CONFIG_TRACING_ALLOW_PRINTK),\
+ "trace_printk called, please enable
CONFIG_TRACING_ALLOW_PRINTK."); \
+ \
if (sizeof(___STR) > 3) \
do_trace_printk(fmt, ##__VA_ARGS__);\
else\
- trace_puts(fmt);\
+ do_trace_puts(fmt); \
} while (0)
#define do_trace_printk(fmt, args...) \
@@ -773,6 +778,13 @@ int __trace_printk(unsigned long ip, const char *fmt, ...);
*/
#define trace_puts(str) ({ \
+ static_assert( \
+ IS_ENABLED(CONFIG_
[PATCH 3/4] media: camss: vfe: Use trace_printk for debugging only
trace_printk should not be used in production code. Since
tracing interrupts is presumably latency sensitive, pr_dbg is
not appropriate, so guard the call with a preprocessor symbol
that can be defined for debugging purpose.
Signed-off-by: Nicolas Boichat
---
drivers/media/platform/qcom/camss/camss-vfe-4-1.c | 2 ++
drivers/media/platform/qcom/camss/camss-vfe-4-7.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
index 174a36be6f5d866..0c57171fae4f9e9 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
@@ -936,8 +936,10 @@ static irqreturn_t vfe_isr(int irq, void *dev)
vfe->ops->isr_read(vfe, &value0, &value1);
+#ifdef CAMSS_VFE_TRACE_IRQ
trace_printk("VFE: status0 = 0x%08x, status1 = 0x%08x\n",
value0, value1);
+#endif
if (value0 & VFE_0_IRQ_STATUS_0_RESET_ACK)
vfe->isr_ops.reset_ack(vfe);
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
index 0dca8bf9281e774..307675925e5c779 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
@@ -1058,8 +1058,10 @@ static irqreturn_t vfe_isr(int irq, void *dev)
vfe->ops->isr_read(vfe, &value0, &value1);
+#ifdef CAMSS_VFE_TRACE_IRQ
trace_printk("VFE: status0 = 0x%08x, status1 = 0x%08x\n",
value0, value1);
+#endif
if (value0 & VFE_0_IRQ_STATUS_0_RESET_ACK)
vfe->isr_ops.reset_ack(vfe);
--
2.27.0.212.ge8ba1cc988-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] media: atomisp: Replace trace_printk by pr_info
trace_printk should not be used in production code, replace it
call with pr_info.
Signed-off-by: Nicolas Boichat
---
drivers/staging/media/atomisp/pci/hmm/hmm.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/media/atomisp/pci/hmm/hmm.c
b/drivers/staging/media/atomisp/pci/hmm/hmm.c
index 42fef17798622f1..2bd39b4939f16d2 100644
--- a/drivers/staging/media/atomisp/pci/hmm/hmm.c
+++ b/drivers/staging/media/atomisp/pci/hmm/hmm.c
@@ -735,11 +735,11 @@ ia_css_ptr hmm_host_vaddr_to_hrt_vaddr(const void *ptr)
void hmm_show_mem_stat(const char *func, const int line)
{
- trace_printk("tol_cnt=%d usr_size=%d res_size=%d res_cnt=%d sys_size=%d
dyc_thr=%d dyc_size=%d.\n",
-hmm_mem_stat.tol_cnt,
-hmm_mem_stat.usr_size, hmm_mem_stat.res_size,
-hmm_mem_stat.res_cnt, hmm_mem_stat.sys_size,
-hmm_mem_stat.dyc_thr, hmm_mem_stat.dyc_size);
+ pr_info("tol_cnt=%d usr_size=%d res_size=%d res_cnt=%d sys_size=%d
dyc_thr=%d dyc_size=%d.\n",
+ hmm_mem_stat.tol_cnt,
+ hmm_mem_stat.usr_size, hmm_mem_stat.res_size,
+ hmm_mem_stat.res_cnt, hmm_mem_stat.sys_size,
+ hmm_mem_stat.dyc_thr, hmm_mem_stat.dyc_size);
}
void hmm_init_mem_stat(int res_pgnr, int dyc_en, int dyc_pgnr)
--
2.27.0.212.ge8ba1cc988-goog
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #28 from Duncan (1i5t5.dun...@cox.net) --- (In reply to rtmasura+kernel from comment #27) > and another crash, chrome's good at causing them (watching youtube). Used -s > "" for the setting which I think should set it to 'auto', and what I assumed > was default. I've changed that to -s "off" to see if that helps. You just added those updates as I was typing a comment pointing out that chrome/chromium in your bug; bugzilla warned of a mid-air collision! Chrom(e|ium) has new vulkan accel code and very likely exercises some of the same relatively new amdgpu kernel code kwin does, so both of them triggering the bug wouldn't surprise me at all. As it happens I switched back to firefox during the 5.6 kernel cycle, so haven't seen chromium's interaction with the (kernel 5.7) bug myself, but once I saw it in that trace I said to myself I bet that's his trigger! FWIW I advanced a couple more bisect steps pretty quickly as it was triggering as I tried to complete system updates (which on gentoo of course means building the packages), but then I hit an apparently good kernel, and uptime says 3 days now, something I've not seen in awhile! Only thing is, I finished those updates and they were pretty calm the next couple days, so I've not been stressing the system to the same extent, either. Given the problems I got myself into the first bisect run, I'm going to run on this kernel a bit longer before I do that bisect good to advance a step. If it reaches a week and I've done either a good system update or a some heavy 4k@60 youtube on firefox, I'll call it good, but I'm not ready to yet. The good news is, in a couple more bisect steps I'll be down to some practical number of remaining commits to report the range here, and if they have the time, a dev with a practiced eye should be able to narrow it down by say 3/4 (two steps ahead of my bisect), leaving something actually practical to examine closer. After that it'll be past the point of my bisect being the only bottleneck, if it's big enough to get dev priority time, of course. If not, I'll just have to keep plugging away at the bisect... -- 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] fbtft-bus.c:
Hi K, Thank you for the patch! Yet something to improve: [auto build test ERROR on staging/staging-testing] [also build test ERROR on v5.8-rc2 next-20200626] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c/20200627-125213 base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git 92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027 config: m68k-randconfig-r016-20200624 (attached as .config) compiler: m68k-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): 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 COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=m68k If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): In file included from include/linux/build_bug.h:5, from include/linux/bits.h:23, from include/linux/gpio/consumer.h:5, from drivers/staging/fbtft/fbtft-bus.c:4: include/linux/scatterlist.h: In function 'sg_set_buf': arch/m68k/include/asm/page_mm.h:169:49: warning: ordered comparison of pointer with null pointer [-Wextra] 169 | #define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET && (void *)(kaddr) < high_memory) | ^~ include/linux/compiler.h:78:42: note: in definition of macro 'unlikely' 78 | # define unlikely(x) __builtin_expect(!!(x), 0) | ^ include/linux/scatterlist.h:143:2: note: in expansion of macro 'BUG_ON' 143 | BUG_ON(!virt_addr_valid(buf)); | ^~ include/linux/scatterlist.h:143:10: note: in expansion of macro 'virt_addr_valid' 143 | BUG_ON(!virt_addr_valid(buf)); | ^~~ drivers/staging/fbtft/fbtft-bus.c: At top level: >> drivers/staging/fbtft/fbtft-bus.c:65:53: error: macro >> "define_fbtft_write_reg" requires 4 arguments, but only 3 given 65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8) | ^ drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" defined here 14 | #define define_fbtft_write_reg(func, buffer_type, data_type, modifier)\ | >> drivers/staging/fbtft/fbtft-bus.c:65:23: error: expected ';' before 'void' 65 | define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8) | ^ | ; drivers/staging/fbtft/fbtft-bus.c:67:57: error: macro "define_fbtft_write_reg" requires 4 arguments, but only 3 given 67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16) | ^ drivers/staging/fbtft/fbtft-bus.c:14: note: macro "define_fbtft_write_reg" defined here 14 | #define define_fbtft_write_reg(func, buffer_type, data_type, modifier)\ | drivers/staging/fbtft/fbtft-bus.c:67:23: error: expected ';' before 'void' 67 | define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16) | ^ | ; 68 | 69 | void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...) | vim +/define_fbtft_write_reg +65 drivers/staging/fbtft/fbtft-bus.c 64 > 65 define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8) 66 define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16) 67 define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16) 68 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] fbtft-bus.c:
Hi K,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.8-rc2 next-20200626]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c/20200627-125213
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: i386-randconfig-a005-20200624 (attached as .config)
compiler: gcc-7 (Ubuntu 7.5.0-6ubuntu2) 7.5.0
reproduce (this is a W=1 build):
# save the attached .config to linux build tree
make W=1 ARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All error/warnings (new ones prefixed by >>):
drivers/staging/fbtft/fbtft-bus.c:65:53: error: macro
"define_fbtft_write_reg" requires 4 arguments, but only 3 given
define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
^
>> drivers/staging/fbtft/fbtft-bus.c:15:1: error: expected '=', ',', ';', 'asm'
>> or '__attribute__' before 'void'
void func(struct fbtft_par *par, int len, ...)
\
^
>> drivers/staging/fbtft/fbtft-bus.c:66:1: note: in expansion of macro
>> 'define_fbtft_write_reg'
define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
^~
drivers/staging/fbtft/fbtft-bus.c:67:57: error: macro
"define_fbtft_write_reg" requires 4 arguments, but only 3 given
define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
^
drivers/staging/fbtft/fbtft-bus.c:69:1: error: expected '=', ',', ';', 'asm'
or '__attribute__' before 'void'
void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
^~~~
vim +15 drivers/staging/fbtft/fbtft-bus.c
c296d5f9957c03 Thomas Petazzoni 2014-12-31 7
c296d5f9957c03 Thomas Petazzoni 2014-12-31 8
/*
c296d5f9957c03 Thomas Petazzoni 2014-12-31 9 *
c296d5f9957c03 Thomas Petazzoni 2014-12-31 10 * void (*write_reg)(struct
fbtft_par *par, int len, ...);
c296d5f9957c03 Thomas Petazzoni 2014-12-31 11 *
c296d5f9957c03 Thomas Petazzoni 2014-12-31 12
*/
c296d5f9957c03 Thomas Petazzoni 2014-12-31 13
8d8825b420ffb3 Alfonso Lima Astor 2017-10-17 14 #define
define_fbtft_write_reg(func, buffer_type, data_type, modifier)\
c296d5f9957c03 Thomas Petazzoni 2014-12-31 @15 void func(struct fbtft_par
*par, int len, ...)\
c296d5f9957c03 Thomas Petazzoni 2014-12-31 16 {
\
c296d5f9957c03 Thomas Petazzoni 2014-12-31 17va_list args;
\
c296d5f9957c03 Thomas Petazzoni 2014-12-31 18int i, ret;
\
c296d5f9957c03 Thomas Petazzoni 2014-12-31 19int offset = 0;
\
8d8825b420ffb3 Alfonso Lima Astor 2017-10-17 20buffer_type *buf =
(buffer_type *)par->buf; \
c296d5f9957c03 Thomas Petazzoni 2014-12-31 21
\
c296d5f9957c03 Thomas Petazzoni 2014-12-31 22if (unlikely(par->debug
& DEBUG_WRITE_REGISTER)) {\
c296d5f9957c03 Thomas Petazzoni 2014-12-31 23va_start(args,
len); \
c296d5f9957c03 Thomas Petazzoni 2014-12-31 24for (i = 0; i <
len; i++) { \
cc1c0eea8527bd Renato Soma2018-04-17 25buf[i]
= modifier((data_type)va_arg(args, \
cc1c0eea8527bd Renato Soma2018-04-17 26
unsigned int)); \
c296d5f9957c03 Thomas Petazzoni 2014-12-31 27}
\
c296d5f9957c03 Thomas Petazzoni 2014-12-31 28va_end(args);
\
cc1c0eea8527bd Renato Soma2018-04-17 29
fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par, \
cc1c0eea8527bd Renato Soma2018-04-17 30
par->info->device, b
Re: [PATCH v4] drm/doc: device hot-unplug for userspace
Den 22.06.2020 16.05, skrev Pekka Paalanen: > From: Pekka Paalanen > > Set up the expectations on how hot-unplugging a DRM device should look like to > userspace. > > Written by Daniel Vetter's request and largely based on his comments in IRC > and > from https://lists.freedesktop.org/archives/dri-devel/2020-May/265484.html . > > A related Wayland protocol change proposal is at > https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/35 > > Signed-off-by: Pekka Paalanen > Reviewed-by: Daniel Vetter > Cc: Andrey Grodzovsky > Cc: Dave Airlie > Cc: Sean Paul > Cc: Simon Ser > Cc: Noralf Trønnes > Cc: Ben Skeggs > Cc: Christian König > Cc: Harry Wentland > Cc: Karol Herbst > > --- > > Harry and Christian, could one of you ack this on behalf of AMD > drivers? > > Ben or Karol, could you ack on behalf of Nouveau? > > Noralf, would this work for the tiny drivers etc.? > Looks good to me: Acked-by: Noralf Trønnes > This is only about laying out plans for the future, not about what > drivers do today. We'd just like to be sure the goals are reasonable and > everyone is aware of the idea. > > Thanks, > pq ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Host1x/TegraDRM UAPI (drm_tegra_channel_map)
26.06.2020 10:34, Thierry Reding пишет:
> On Fri, Jun 26, 2020 at 01:47:46AM +0300, Dmitry Osipenko wrote:
>> 23.06.2020 15:09, Mikko Perttunen пишет:
>>> ### DRM_TEGRA_CHANNEL_MAP
>>>
>>> Make memory accessible by the engine while executing work on the channel.
>>>
>>> ```
>>> #define DRM_TEGRA_CHANNEL_MAP_READWRITE (1<<0)
>>>
>>> struct drm_tegra_channel_map {
>>> /*
>>> * [in] ID of the channel for which to map memory to.
>>> */
>>> __u32 channel_id;
>>> /*
>>> * [in] GEM handle of the memory to map.
>>> */
>>> __u32 handle;
>>>
>>> /*
>>> * [in] Offset in GEM handle of the memory area to map.
>>> *
>>> * Must be aligned by 4K.
>>> */
>>> __u64 offset;
>>
>> Could you please give a use-case example for this partial mapping?
>>
>> I vaguely recalling that maybe it was me who suggested this in the past..
>>
>> I kinda see that this could be useful for a case where userspace
>> allocates a large chunk of memory and then performs sub-allocations in
>> the userspace driver. But do we have a real-world example for this right
>> now?
>
> I think the main point about this IOCTL was to make mapping/unmapping
> more efficient and avoid relocations for situations where we know it is
> safe to do so.
>
> The fact that this can be used to create partial mappings is mostly just
> an added bonus, in my opinion. Doing this doesn't create much complexity
> but in turn gives us a lot more flexibility.
>
> A couple of places where I think this could be useful are OpenGL and
> Vulkan, both of which support buffer suballocation. This has a couple of
> advantages on modern GPUs where sometimes you want to use very large
> allocation granularity, etc.
>
> Now, I don't think that we'll see much of that in Tegra DRM directly,
> although grate could certainly make use of this, I suspect. However, I
> think for interoperation of dGPU and Tegra DRM (with VIC for post-
> processing, or hopefully some of the other hardware acceleration
> engines at some point), this might come in handy.
>
> There are other possible use-cases within just Tegra DRM as well. We may
> want to only partially map planar buffers for video post-processing, for
> example. Or map each plane separately.
>
>> Please see more below.
>>
>>> /*
>>> * [in] Length of memory area to map in bytes.
>>> *
>>> * Must be aligned by 4K.
>>> */
>>> __u64 length;
>>>
>>> /*
>>> * [out] IOVA of mapped memory. Userspace can use this IOVA
>>> * directly to refer to the memory to skip using relocations.
>>> * Only available if hardware memory isolation is enabled.
>>> *
>>> * Will be set to 0x___ if unavailable.
>>> */
>>> __u64 iova;
>>>
>>> /*
>>> * [out] ID corresponding to the mapped memory to be used for
>>> * relocations or unmapping.
>>> */
>>> __u32 mapping_id;
>>> /*
>>> * [in] Flags.
>>> */
>>> __u32 flags;
>>>
>>> __u32 reserved[6];
>>> };
>>
>> It looks to me that we actually need a bit different thing here.
>>
>> This MAP IOCTL maps a portion of a GEM and then returns the mapping_id.
>> And I think we need something more flexible that will allow us to use
>> GEM handles for the relocation IDs, which should fit nicely with the
>> DMA-reservations.
>>
>> What about an IOCTL that wraps GEM into another GEM? We could wrap a
>> portion of GEM_A into a GEM_B, and then map the GEM_B using the MAP IOCTL.
>>
>> It could be something like this:
>>
>> ### DRM_TEGRA_BO_WRAP
>>
>> struct drm_tegra_wrap_bo {
>> __u32 bo_handle_wrapped; // out
>> __u32 bo_handle; // in
>> __u64 offset;
>> __u64 length;
>> };
>>
>> ### DRM_TEGRA_CHANNEL_MAP
>>
>> struct drm_tegra_channel_map {
>> __u32 channels_mask;
>> __u32 mapping_id;
>> __u32 bo_handle;
>> __u32 flags;
>> __u64 iova;
>> };
>>
>> ===
>>
>> This allows multiple mapping_ids to have the same backing GEM, so the
>> mapping_id could be resolved into a BO during of job's submission for
>> the DMA-reservations handling.
>
> That's pretty much what we have already above, isn't it? Just because we
> call the field "mapping_id" doesn't mean that in the background we can't
> create a GEM object and return it's handle as "mapping_id".
>
> One advantage of Mikko's proposal is that we have a single IOCTL rather
> than two to create the mapping, making it a bit more lightweight.
Thinking a bit more about it, I now changed my mind.
There is no need to perform implicit fencing on each suballocation,
instead explicit fencing should be used for the suballocations.
So, we will need to add the relocation flags for the direction and
explicit (or implicit) fencing per-relocation. The direction will tell
how fence should be at
Re: Warning triggered in drm_dp_delayed_destroy_work workqueue
On Fri, Jun 26, 2020 at 05:06:00PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 26, 2020 at 03:40:20PM +0200, Daniel Vetter wrote:
> > Adding Lyude, she's been revamping all the lifetime refcouting in the
> > dp code last few kernel releases. At a glance I don't even have an
> > idea what's going wrong here ...
>
> Already fixed by Imre I believe.
>
> 7d11507605a7 ("drm/dp_mst: Fix the DDC I2C device unregistration of an MST
> port")
>
Ah! It does seems to be the same issue indeed! Thanks a lot for pointing
me at this commit. Hopefully this fix can be included in 5.8. Not that
I'm seeing this WARNING frequently, but frequent enough to annoy me :-)
Cheers,
--
Luis
> > -Daniel
> >
> > On Thu, Jun 25, 2020 at 12:22 PM Luis Henriques wrote:
> > >
> > > Hi!
> > >
> > > I've been seeing this warning occasionally, not sure if it has been
> > > reported yet. It's not a regression as I remember seeing it in, at least,
> > > 5.7.
> > >
> > > Anyway, here it is:
> > >
> > > [ cut here ]
> > > sysfs group 'power' not found for kobject 'i2c-7'
> > > WARNING: CPU: 1 PID: 17996 at fs/sysfs/group.c:279
> > > sysfs_remove_group+0x74/0x80
> > > Modules linked in: ccm(E) dell_rbtn(E) iwlmvm(E) mei_wdt(E) mac80211(E)
> > > libarc4(E) uvcvideo(E) dell_laptop(E) videobuf2_vmalloc(E) intel_rapl_>
> > > soundcore(E) intel_soc_dts_iosf(E) rng_core(E) battery(E) acpi_pad(E)
> > > sparse_keymap(E) acpi_thermal_rel(E) intel_pch_thermal(E) int3402_therm>
> > > sysfillrect(E) intel_lpss(E) sysimgblt(E) fb_sys_fops(E) idma64(E)
> > > scsi_mod(E) virt_dma(E) mfd_core(E) drm(E) fan(E) thermal(E) i2c_hid(E)
> > > hi>
> > > CPU: 1 PID: 17996 Comm: kworker/1:1 Tainted: GE
> > > 5.8.0-rc2+ #36
> > > Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.14.2 05/25/2020
> > > Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper]
> > > RIP: 0010:sysfs_remove_group+0x74/0x80
> > > Code: ff 5b 48 89 ef 5d 41 5c e9 79 bc ff ff 48 89 ef e8 01 b8 ff ff eb
> > > cc 49 8b 14 24 48 8b 33 48 c7 c7 90 ac 8b 93 e8 de b1 d4 ff <0f> 0b 5b>
> > > RSP: :b12d40c13c38 EFLAGS: 00010282
> > > RAX: RBX: 936e6a60 RCX: 0027
> > > RDX: 0027 RSI: 0086 RDI: 8e37de097b68
> > > RBP: R08: 8e37de097b60 R09: 93fb4624
> > > R10: 0904 R11: 0001002c R12: 8e37d3081c18
> > > R13: 8e375f1450a8 R14: R15: 8e375f145410
> > > FS: () GS:8e37de08()
> > > knlGS:
> > > CS: 0010 DS: ES: CR0: 80050033
> > > CR2: CR3: 0004ab20a001 CR4: 003606e0
> > > DR0: DR1: DR2:
> > > DR3: DR6: fffe0ff0 DR7: 0400
> > > Call Trace:
> > > device_del+0x97/0x3f0
> > > cdev_device_del+0x15/0x30
> > > put_i2c_dev+0x7b/0x90 [i2c_dev]
> > > i2cdev_detach_adapter+0x33/0x60 [i2c_dev]
> > > notifier_call_chain+0x47/0x70
> > > blocking_notifier_call_chain+0x3d/0x60
> > > device_del+0x8f/0x3f0
> > > device_unregister+0x16/0x60
> > > i2c_del_adapter+0x247/0x300
> > > drm_dp_port_set_pdt+0x90/0x2c0 [drm_kms_helper]
> > > drm_dp_delayed_destroy_work+0x2be/0x340 [drm_kms_helper]
> > > process_one_work+0x1ae/0x370
> > > worker_thread+0x50/0x3a0
> > > ? process_one_work+0x370/0x370
> > > kthread+0x11b/0x140
> > > ? kthread_associate_blkcg+0x90/0x90
> > > ret_from_fork+0x22/0x30
> > > ---[ end trace 16486ad3c2627482 ]---
> > > [ cut here ]
> > >
> > > Cheers,
> > > --
> > > Luis
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/connector: fix minor typos in comments
Some of these comments are part of the Linux GPU Driver Developer's
Guide.
Fix some minor typo in the comments and remove a repeated 'the'.
Signed-off-by: Antonio Borneo
---
drivers/gpu/drm/drm_connector.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index d877ddc6dc57..cb62fb8e594e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -38,7 +38,7 @@
* DOC: overview
*
* In DRM connectors are the general abstraction for display sinks, and include
- * als fixed panels or anything else that can display pixels in some form. As
+ * also fixed panels or anything else that can display pixels in some form. As
* opposed to all other KMS objects representing hardware (like CRTC, encoder
or
* plane abstractions) connectors can be hotplugged and unplugged at runtime.
* Hence they are reference-counted using drm_connector_get() and
@@ -129,7 +129,7 @@ EXPORT_SYMBOL(drm_get_connector_type_name);
/**
* drm_connector_get_cmdline_mode - reads the user's cmdline mode
- * @connector: connector to quwery
+ * @connector: connector to query
*
* The kernel supports per-connector configuration of its consoles through
* use of the video= parameter. This function parses that option and
@@ -991,7 +991,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] = {
* DP MST sinks), or high-res integrated panels (like dual-link DSI) which
* are not gen-locked. Note that for tiled panels which are genlocked, like
* dual-link LVDS or dual-link DSI, the driver should try to not expose the
- * tiling and virtualize both &drm_crtc and &drm_plane if needed. Drivers
+ * tiling and virtualise both &drm_crtc and &drm_plane if needed. Drivers
* should update this value using drm_connector_set_tile_property().
* Userspace cannot change this property.
* link-status:
@@ -1131,7 +1131,7 @@ static const struct drm_prop_enum_list dp_colorspaces[] =
{
*
* It will even need to do colorspace conversion and get all layers
* to one common colorspace for blending. It can use either GL, Media
- * or display engine to get this done based on the capabilties of the
+ * or display engine to get this done based on the capabilities of the
* associated hardware.
*
* Driver expects metadata to be put in &struct hdr_output_metadata
@@ -1614,7 +1614,7 @@ EXPORT_SYMBOL(drm_mode_create_scaling_mode_property);
* variable refresh rate capability for a connector.
*
* Returns:
- * Zero on success, negative errono on failure.
+ * Zero on success, negative errno on failure.
*/
int drm_connector_attach_vrr_capable_property(
struct drm_connector *connector)
@@ -1759,7 +1759,7 @@ EXPORT_SYMBOL(drm_mode_create_aspect_ratio_property);
* HDMI connectors.
*
* Returns:
- * Zero on success, negative errono on failure.
+ * Zero on success, negative errno on failure.
*/
int drm_mode_create_hdmi_colorspace_property(struct drm_connector *connector)
{
@@ -1788,7 +1788,7 @@ EXPORT_SYMBOL(drm_mode_create_hdmi_colorspace_property);
* DP connectors.
*
* Returns:
- * Zero on success, negative errono on failure.
+ * Zero on success, negative errno on failure.
*/
int drm_mode_create_dp_colorspace_property(struct drm_connector *connector)
{
@@ -1840,7 +1840,7 @@ EXPORT_SYMBOL(drm_mode_create_content_type_property);
* drm_mode_create_suggested_offset_properties - create suggests offset
properties
* @dev: DRM device
*
- * Create the the suggested x/y offset property for connectors.
+ * Create the suggested x/y offset property for connectors.
*/
int drm_mode_create_suggested_offset_properties(struct drm_device *dev)
{
@@ -1963,7 +1963,7 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
size = EDID_LENGTH * (1 + edid->extensions);
/* Set the display info, using edid if available, otherwise
-* reseting the values to defaults. This duplicates the work
+* resetting the values to defaults. This duplicates the work
* done in drm_add_edid_modes, but that function is not
* consistently called before this one in all drivers and the
* computation is cheap enough that it seems better to
@@ -2076,7 +2076,7 @@ void drm_connector_set_vrr_capable_property(
EXPORT_SYMBOL(drm_connector_set_vrr_capable_property);
/**
- * drm_connector_set_panel_orientation - sets the connecter's panel_orientation
+ * drm_connector_set_panel_orientation - sets the connector's panel_orientation
* @connector: connector for which to set the panel-orientation property.
* @panel_orientation: drm_panel_orientation value to set
*
@@ -2131,7 +2131,7 @@ EXPORT_SYMBOL(drm_connector_set_panel_orientation);
/**
* drm_connector_set_panel_orientation_with_quirk -
- * set the connecter's panel_orientation after checking for quirks
+ * set t
Re: [RFC] Host1x/TegraDRM UAPI
26.06.2020 16:38, Daniel Vetter пишет: > On Fri, Jun 26, 2020 at 01:40:40PM +0200, Thierry Reding wrote: >> On Fri, Jun 26, 2020 at 01:06:58PM +0200, Karol Herbst wrote: >>> On Tue, Jun 23, 2020 at 3:03 PM Mikko Perttunen wrote: # Host1x/TegraDRM UAPI proposal This is a proposal for a stable UAPI for Host1x and TegraDRM, to replace the current TegraDRM UAPI that is behind `STAGING` and quite obsolete in many ways. I haven't written any implementation yet -- I'll do that once there is some agreement on the high-level design. Current open items: * The syncpoint UAPI allows userspace to create sync_file FDs with arbitrary syncpoint fences. dma_fence code currently seems to assume all fences will be signaled, which would not necessarily be the case with this interface. * Previously present GEM IOCTLs (GEM_CREATE, GEM_MMAP) are not present. Not sure if they are still needed. >>> >>> Hi, as this wasn't addressed here (and sorry if I missed it): is there >>> an open source userspace making use of this UAPI? Because this is >>> something which needs to be seen before it can be included at all. >> >> There's a set of commits that implement an earlier draft here: >> >> https://github.com/thierryreding/linux/tree/for-5.6/drm-tegra-destage-abi >> >> and corresponding changes to libdrm to make use of that and implement >> tests using the various generations of VIC here: >> >> https://cgit.freedesktop.org/~tagr/drm/log/ >> >> Before actually jumping to an implementation we wanted to go over the >> design a bit more to avoid wasting a lot of work, like we've done in >> the past. Turns out it isn't easy to get everyone to agree on a good >> ABI. Who would've thought? =) >> >> I expect that once the discussion around the ABI settles Mikko will >> start on implementing this ABI in the kernel and we'll update the >> libdrm patches to make use of the new ABI as well. > > Do we have more than libdrm and tests for this, like something somewhat > functional? Since tegradrm landed years ago we've refined the criteria a > bit in this regard, latest version is explicit in that it needs to be > something that's functional (for end-users in some form), not just > infrastructure and tests. We have Opentegra [1] and VDPAU [2] userspace drivers for older Tegra SoCs that have been using the staging UAPI for years now. [1] https://github.com/grate-driver/xf86-video-opentegra [2] https://github.com/grate-driver/libvdpau-tegra The UAPI and the kernel driver updates are very needed for these drivers because of the missing UAPI synchronization features and performance problems of the kernel driver. So we already have some real-world userspace for the testing! It's not the first and not the second time we're discussing the Tegra DRM UAPI changes, but this time it feels like there is a good chance that it will finally materialize and I'm very happy about it :) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dt-bindings: display: vc4: dpi: Fix panel warning
The example used in the DPI binding before the conversion to YAML had a
simple-panel example that got carried over to the YAML binding.
However, that example doesn't match the simple-panel binding and results in
validation errors. Since it's only marginally helpful, let's remove that
part of the example entirely.
Fixes: 094536003e06 ("dt-bindings: display: Convert VC4 bindings to schemas")
Signed-off-by: Maxime Ripard
---
.../devicetree/bindings/display/brcm,bcm2835-dpi.yaml | 10 --
1 file changed, 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
index 58213c564e03..5c1024bbc1b3 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
+++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
@@ -45,16 +45,6 @@ examples:
- |
#include
-panel: panel {
-compatible = "ontat,yx700wv03", "simple-panel";
-
-port {
-panel_in: endpoint {
-remote-endpoint = <&dpi_out>;
-};
-};
-};
-
dpi: dpi@7e208000 {
compatible = "brcm,bcm2835-dpi";
reg = <0x7e208000 0x8c>;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dt-bindings: display: vc4: dpi: Fix panel warning
On Fri, Jun 26, 2020 at 02:11:31PM +0200, Maxime Ripard wrote:
> The example used in the DPI binding before the conversion to YAML had a
> simple-panel example that got carried over to the YAML binding.
>
> However, that example doesn't match the simple-panel binding and results in
> validation errors. Since it's only marginally helpful, let's remove that
> part of the example entirely.
>
> Fixes: 094536003e06 ("dt-bindings: display: Convert VC4 bindings to schemas")
> Signed-off-by: Maxime Ripard
Acked-by: Sam Ravnborg
> ---
> .../devicetree/bindings/display/brcm,bcm2835-dpi.yaml | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> index 58213c564e03..5c1024bbc1b3 100644
> --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-dpi.yaml
> @@ -45,16 +45,6 @@ examples:
>- |
> #include
>
> -panel: panel {
> -compatible = "ontat,yx700wv03", "simple-panel";
> -
> -port {
> -panel_in: endpoint {
> -remote-endpoint = <&dpi_out>;
> -};
> -};
> -};
> -
> dpi: dpi@7e208000 {
> compatible = "brcm,bcm2835-dpi";
> reg = <0x7e208000 0x8c>;
> --
> 2.26.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/atomic_helper: add a flag for duplicating drm_private_obj state
From: Shawn Guo
The msm/mdp5 driver uses state of drm_private_obj as its global atomic
state, which keeps the assignment of hwpipe to plane. With
drm_private_obj missing from duplicate state call in context of atomic
suspend/resume helpers, mdp5 suspend works with no problem only for the
very first time. Any subsequent suspend will hit the following warning,
because hwpipe assignment doesn't get duplicated for suspend state.
$ echo mem > /sys/power/state
[ 38.44] PM: suspend entry (deep)
[ 38.85] PM: Syncing filesystems ... done.
[ 38.114630] Freezing user space processes ... (elapsed 0.001 seconds) done.
[ 38.115912] OOM killer disabled.
[ 38.115914] Freezing remaining freezable tasks ... (elapsed 0.001 seconds)
done.
[ 38.122170] [ cut here ]
[ 38.122212] WARNING: CPU: 0 PID: 1747 at
drivers/gpu/drm/msm/disp/mdp5/mdp5_pipe.c:145 mdp5_pipe_release+0x90/0xc0
[ 38.122215] Modules linked in:
[ 38.12] CPU: 0 PID: 1747 Comm: sh Not tainted
4.19.107-00515-g9d5e4d7a33ed-dirty #323
[ 38.14] Hardware name: Square, Inc. T2 Devkit (DT)
[ 38.18] pstate: 4005 (nZcv daif -PAN -UAO)
[ 38.122230] pc : mdp5_pipe_release+0x90/0xc0
[ 38.122233] lr : mdp5_pipe_release+0x90/0xc0
[ 38.122235] sp : 0d13b7f0
[ 38.122236] x29: 0d13b7f0 x28:
[ 38.122240] x27: 0002 x26: 800079adce00
[ 38.122243] x25: 800079405200 x24:
[ 38.122246] x23: 80007a78cc08 x22: 80007b1cc018
[ 38.122249] x21: 80007b1cc000 x20: 80007b317080
[ 38.122252] x19: 80007a78ce80 x18: 0002
[ 38.122255] x17: x16:
[ 38.122258] x15: fff0 x14: 08c3fb48
[ 38.122261] x13: 08cdac4a x12: 08c3f000
[ 38.122264] x11: x10: 08cda000
[ 38.122267] x9 : x8 : 08ce4a40
[ 38.122269] x7 : x6 : 39ea41a9
[ 38.122272] x5 : x4 :
[ 38.122275] x3 : x2 : c7580c109cae4500
[ 38.122278] x1 : x0 : 0024
[ 38.122281] Call trace:
[ 38.122285] mdp5_pipe_release+0x90/0xc0
[ 38.122288] mdp5_plane_atomic_check+0x2c0/0x448
[ 38.122294] drm_atomic_helper_check_planes+0xd0/0x208
[ 38.122298] drm_atomic_helper_check+0x38/0xa8
[ 38.122302] drm_atomic_check_only+0x3e8/0x630
[ 38.122305] drm_atomic_commit+0x18/0x58
[ 38.122309] __drm_atomic_helper_disable_all.isra.12+0x15c/0x1a8
[ 38.122312] drm_atomic_helper_suspend+0x80/0xf0
[ 38.122316] msm_pm_suspend+0x4c/0x70
[ 38.122320] dpm_run_callback.isra.6+0x20/0x68
[ 38.122323] __device_suspend+0x110/0x308
[ 38.122326] dpm_suspend+0x100/0x1f0
[ 38.122329] dpm_suspend_start+0x64/0x70
[ 38.122334] suspend_devices_and_enter+0x110/0x500
[ 38.122336] pm_suspend+0x268/0x2c0
[ 38.122339] state_store+0x88/0x110
[ 38.122345] kobj_attr_store+0x14/0x28
[ 38.122352] sysfs_kf_write+0x3c/0x50
[ 38.122355] kernfs_fop_write+0x118/0x1e0
[ 38.122360] __vfs_write+0x30/0x168
[ 38.122363] vfs_write+0xa4/0x1a8
[ 38.122366] ksys_write+0x64/0xe8
[ 38.122368] __arm64_sys_write+0x18/0x20
[ 38.122374] el0_svc_common+0x6c/0x178
[ 38.122377] el0_svc_compat_handler+0x1c/0x28
[ 38.122381] el0_svc_compat+0x8/0x18
[ 38.122383] ---[ end trace 24145b7d8545345b ]---
[ 38.491552] Disabling non-boot CPUs ...
Let's add a flag for duplicating the state of drm_private_obj and set
the flag from msm/mdp5 driver, so that the problem can be fixed while
other drivers using drm_private_obj stay unaffected.
Signed-off-by: Shawn Guo
---
Changes for v2:
- Add a flag to duplicate the state of drm_private_obj conditionally,
so that other drivers using drm_private_obj stay unaffected.
drivers/gpu/drm/drm_atomic_helper.c | 22 ++
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 7 +++
include/drm/drm_atomic.h | 11 +++
3 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 85d163f16801..4bf041730b9e 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -3140,6 +3140,7 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
struct drm_atomic_state *state;
struct drm_connector *conn;
struct drm_connector_list_iter conn_iter;
+ struct drm_private_obj *priv_obj;
struct drm_plane *plane;
struct drm_crtc *crtc;
int err = 0;
@@ -3184,6 +3185,19 @@ drm_atomic_helper_duplicate_state(struct drm_device *dev,
}
drm_connector_list_iter_end(&conn_iter);
+ drm_for_each_privobj(priv_obj, dev) {
+ struct drm_private_state *priv_state;
+
+ if (!priv_obj->needs_duplicate_state)
+ continue;
+
+ priv_state = drm_
[Bug 207673] amdgpu/radeon: crash due to over temperature
https://bugzilla.kernel.org/show_bug.cgi?id=207673 --- Comment #5 from phileimer (p...@jpmr.org) --- Created attachment 289897 --> https://bugzilla.kernel.org/attachment.cgi?id=289897&action=edit amdgpu: kernel log when over temperature crash -- 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 v6 2/4] driver core: add deferring probe reason to devices_deferred property
On 26/06/2020 13:01, Andrzej Hajda wrote:
/sys/kernel/debug/devices_deferred property contains list of deferred devices.
This list does not contain reason why the driver deferred probe, the patch
improves it.
The natural place to set the reason is probe_err function introduced recently,
ie. if probe_err will be called with -EPROBE_DEFER instead of printk the message
will be attached to deferred device and printed when user read devices_deferred
property.
Signed-off-by: Andrzej Hajda
Reviewed-by: Mark Brown
Reviewed-by: Javier Martinez Canillas
Reviewed-by: Andy Shevchenko
---
drivers/base/base.h | 3 +++
drivers/base/core.c | 8 ++--
drivers/base/dd.c | 23 ++-
3 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index 95c22c0f9036..6954fccab3d7 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -93,6 +93,7 @@ struct device_private {
struct klist_node knode_class;
struct list_head deferred_probe;
struct device_driver *async_driver;
+ char *deferred_probe_reason;
struct device *device;
u8 dead:1;
};
@@ -134,6 +135,8 @@ extern void device_release_driver_internal(struct device
*dev,
extern void driver_detach(struct device_driver *drv);
extern int driver_probe_device(struct device_driver *drv, struct device *dev);
extern void driver_deferred_probe_del(struct device *dev);
+extern void device_set_deferred_probe_reson(const struct device *dev,
+ struct va_format *vaf);
static inline int driver_match_device(struct device_driver *drv,
struct device *dev)
{
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 3a827c82933f..fee047f03681 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -3963,6 +3963,8 @@ define_dev_printk_level(_dev_info, KERN_INFO);
* This helper implements common pattern present in probe functions for error
* checking: print debug or error message depending if the error value is
* -EPROBE_DEFER and propagate error upwards.
+ * In case of -EPROBE_DEFER it sets also defer probe reason, which can be
+ * checked later by reading devices_deferred debugfs attribute.
* It replaces code sequence:
*if (err != -EPROBE_DEFER)
*dev_err(dev, ...);
@@ -3984,10 +3986,12 @@ int dev_err_probe(const struct device *dev, int err,
const char *fmt, ...)
vaf.fmt = fmt;
vaf.va = &args;
- if (err != -EPROBE_DEFER)
+ if (err != -EPROBE_DEFER) {
dev_err(dev, "error %d: %pV", err, &vaf);
- else
+ } else {
+ device_set_deferred_probe_reson(dev, &vaf);
dev_dbg(dev, "error %d: %pV", err, &vaf);
+ }
va_end(args);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 9a1d940342ac..dd5683b61f74 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -136,6 +137,8 @@ void driver_deferred_probe_del(struct device *dev)
if (!list_empty(&dev->p->deferred_probe)) {
dev_dbg(dev, "Removed from deferred list\n");
list_del_init(&dev->p->deferred_probe);
+ kfree(dev->p->deferred_probe_reason);
+ dev->p->deferred_probe_reason = NULL;
}
mutex_unlock(&deferred_probe_mutex);
}
@@ -211,6 +214,23 @@ void device_unblock_probing(void)
driver_deferred_probe_trigger();
}
+/**
+ * device_set_deferred_probe_reson() - Set defer probe reason message for
device
+ * @dev: the pointer to the struct device
+ * @vaf: the pointer to va_format structure with message
+ */
+void device_set_deferred_probe_reson(const struct device *dev, struct
va_format *vaf)
+{
+ const char *drv = dev_driver_string(dev);
+
+ mutex_lock(&deferred_probe_mutex);
+
+ kfree(dev->p->deferred_probe_reason);
+ dev->p->deferred_probe_reason = kasprintf(GFP_KERNEL, "%s: %pV", drv,
vaf);
+
+ mutex_unlock(&deferred_probe_mutex);
+}
+
/*
* deferred_devs_show() - Show the devices in the deferred probe pending list.
*/
@@ -221,7 +241,8 @@ static int deferred_devs_show(struct seq_file *s, void
*data)
mutex_lock(&deferred_probe_mutex);
list_for_each_entry(curr, &deferred_probe_pending_list, deferred_probe)
- seq_printf(s, "%s\n", dev_name(curr->device));
+ seq_printf(s, "%s\t%s", dev_name(curr->device),
+ curr->device->p->deferred_probe_reason ?: "\n");
mutex_unlock(&deferred_probe_mutex);
Sry, may be i missing smth, but shouldn't it be optional
(CONFIG_DEBUG_FS is probably too generic).
--
Best regards,
grygorii
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-de
Re: [PATCH 1/2] dt-bindings: serial: add generic DT binding for announcing RTS/CTS lines
On Wed, May 20, 2020 at 03:39:31PM +0200, Erwan Le Ray wrote: > Add support of generic DT binding for annoucing RTS/CTS lines. The initial > binding 'st,hw-flow-control' is not needed anymore since generic binding > is available, but is kept for backward compatibility. > > Signed-off-by: Erwan Le Ray > > diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml > b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml > index 75b8521eb7cb..06d5f251ec88 100644 > --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml > +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml > @@ -35,9 +35,11 @@ properties: > description: label associated with this uart > >st,hw-flow-ctrl: > -description: enable hardware flow control > +description: enable hardware flow control (deprecated) > $ref: /schemas/types.yaml#/definitions/flag > > + uart-has-rtscts: true > + >dmas: > minItems: 1 > maxItems: 2 > -- > 2.17.1 > Did this get ignored by the DT maintainers? :( ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v9 6/7] drm/msm: Set the global virtual address range from the IOMMU domain
On Fri, Jun 26, 2020 at 1:01 PM Jordan Crouse wrote:
>
> Use the aperture settings from the IOMMU domain to set up the virtual
> address range for the GPU. This allows us to transparently deal with
> IOMMU side features (like split pagetables).
>
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 13 +++--
> drivers/gpu/drm/msm/msm_iommu.c | 7 +++
> 2 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> index 5db06b590943..3e717c1ebb7f 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
> @@ -192,9 +192,18 @@ adreno_iommu_create_address_space(struct msm_gpu *gpu,
> struct iommu_domain *iommu = iommu_domain_alloc(&platform_bus_type);
> struct msm_mmu *mmu = msm_iommu_new(&pdev->dev, iommu);
> struct msm_gem_address_space *aspace;
> + u64 start, size;
>
> - aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M,
> - 0x - SZ_16M);
> + /*
> +* Use the aperture start or SZ_16M, whichever is greater. This will
> +* ensure that we align with the allocated pagetable range while still
> +* allowing room in the lower 32 bits for GMEM and whatnot
> +*/
> + start = max_t(u64, SZ_16M, iommu->geometry.aperture_start);
> + size = iommu->geometry.aperture_end - start + 1;
> +
> + aspace = msm_gem_address_space_create(mmu, "gpu",
> + start & GENMASK(48, 0), size);
hmm, I kinda think this isn't going to play well for the 32b gpus
(pre-a5xx).. possibly we should add address space size to 'struct
adreno_info'?
Or I guess it is always going to be the same for all devices within a
generation? So it could just be passed in to adreno_gpu_init()
Hopefully that makes things smoother if we someday had more than 48bits..
BR,
-R
>
> if (IS_ERR(aspace) && !IS_ERR(mmu))
> mmu->funcs->destroy(mmu);
> diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
> index 3a381a9674c9..1b6635504069 100644
> --- a/drivers/gpu/drm/msm/msm_iommu.c
> +++ b/drivers/gpu/drm/msm/msm_iommu.c
> @@ -36,6 +36,10 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t
> iova,
> struct msm_iommu *iommu = to_msm_iommu(mmu);
> size_t ret;
>
> + /* The arm-smmu driver expects the addresses to be sign extended */
> + if (iova & BIT_ULL(48))
> + iova |= GENMASK_ULL(63, 49);
> +
> ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
> WARN_ON(!ret);
>
> @@ -46,6 +50,9 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t
> iova, size_t len)
> {
> struct msm_iommu *iommu = to_msm_iommu(mmu);
>
> + if (iova & BIT_ULL(48))
> + iova |= GENMASK_ULL(63, 49);
> +
> iommu_unmap(iommu->domain, iova, len);
>
> return 0;
> --
> 2.17.1
>
> ___
> Freedreno mailing list
> freedr...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/freedreno
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v8 2/9] drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_off()
This got me confused for a bit while looking over this code: I had been planning on adding some blocking function calls into this function, but seeing the irqsave/irqrestore variants of spin_(un)lock() didn't make it very clear whether or not that would actually be safe. So I went ahead and reviewed every single driver in the kernel that uses this function, and they all fall into three categories: * Driver probe code * ->atomic_disable() callbacks * Legacy modesetting callbacks All of these will be guaranteed to have IRQs enabled, which means it's perfectly safe to block here. Just to make things a little less confusing to others in the future, let's switch over to spin_lock_irq()/spin_unlock_irq() to make that fact a little more obvious. Signed-off-by: Lyude Paul Reviewed-by: Daniel Vetter Cc: Ville Syrjälä --- drivers/gpu/drm/drm_vblank.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index ce5c1e1d29963..e895f5331fdb4 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -1283,13 +1283,12 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc) struct drm_pending_vblank_event *e, *t; ktime_t now; - unsigned long irqflags; u64 seq; if (drm_WARN_ON(dev, pipe >= dev->num_crtcs)) return; - spin_lock_irqsave(&dev->event_lock, irqflags); + spin_lock_irq(&dev->event_lock); spin_lock(&dev->vbl_lock); drm_dbg_vbl(dev, "crtc %d, vblank enabled %d, inmodeset %d\n", @@ -1325,7 +1324,7 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc) drm_vblank_put(dev, pipe); send_vblank_event(dev, e, seq, now); } - spin_unlock_irqrestore(&dev->event_lock, irqflags); + spin_unlock_irq(&dev->event_lock); /* Will be reset by the modeset helpers when re-enabling the crtc by * calling drm_calc_timestamping_constants(). */ -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v8 1/9] drm/vblank: Register drmm cleanup action once per drm_vblank_crtc
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to initialize one of them.
Changes since v3:
* Use drmm_add_action_or_reset() - Daniel Vetter
Cc: Ville Syrjälä
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Reviewed-by: Daniel Vetter
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_vblank.c | 23 ++-
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 85e5f2db16085..ce5c1e1d29963 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -492,16 +492,12 @@ static void vblank_disable_fn(struct timer_list *t)
static void drm_vblank_init_release(struct drm_device *dev, void *ptr)
{
- unsigned int pipe;
-
- for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
- struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
+ struct drm_vblank_crtc *vblank = ptr;
- drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
- drm_core_check_feature(dev, DRIVER_MODESET));
+ drm_WARN_ON(dev, READ_ONCE(vblank->enabled) &&
+ drm_core_check_feature(dev, DRIVER_MODESET));
- del_timer_sync(&vblank->disable_timer);
- }
+ del_timer_sync(&vblank->disable_timer);
}
/**
@@ -511,7 +507,7 @@ static void drm_vblank_init_release(struct drm_device *dev,
void *ptr)
*
* This function initializes vblank support for @num_crtcs display pipelines.
* Cleanup is handled automatically through a cleanup function added with
- * drmm_add_action().
+ * drmm_add_action_or_reset().
*
* Returns:
* Zero on success or a negative error code on failure.
@@ -530,10 +526,6 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
num_crtcs)
dev->num_crtcs = num_crtcs;
- ret = drmm_add_action(dev, drm_vblank_init_release, NULL);
- if (ret)
- return ret;
-
for (i = 0; i < num_crtcs; i++) {
struct drm_vblank_crtc *vblank = &dev->vblank[i];
@@ -542,6 +534,11 @@ int drm_vblank_init(struct drm_device *dev, unsigned int
num_crtcs)
init_waitqueue_head(&vblank->queue);
timer_setup(&vblank->disable_timer, vblank_disable_fn, 0);
seqlock_init(&vblank->seqlock);
+
+ ret = drmm_add_action_or_reset(dev, drm_vblank_init_release,
+ vblank);
+ if (ret)
+ return ret;
}
return 0;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v8 6/9] drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason we'll need this is for CRC support.
See: on nvidia hardware, each CRC entry in the CRC notifier dma context
has a "tag". This tag corresponds to the nth update on a specific
EVO/NvDisplay channel, which itself is referred to as the "controlling
channel". For gf119+ this can be the core channel, ovly channel, or base
channel. Since we don't expose CRC entry tags to userspace, we simply
ignore this feature and always use the core channel as the controlling
channel. Simple.
Things get a little bit more complicated on gv100+ though. GV100+ only
lets us set the controlling channel to a specific wndw channel, and that
wndw must be owned by the head that we're grabbing CRCs when we enable
CRC generation. Thus, we always need to make sure that each atomic head
state has at least one wndw that is mapped to the head, which will be
used as the controlling channel.
Note that since we don't have flexible wndw mappings yet, we don't
expect to run into any scenarios yet where we'd have a head with no
mapped wndws. When we do add support for flexible wndw mappings however,
we'll need to make sure that we handle reprogramming CRC capture if our
controlling wndw is moved to another head (and potentially reject the
new head state entirely if we can't find another available wndw to
replace it).
With that being said, nouveau currently tracks wndw visibility on heads.
It does not keep track of the actual ownership mappings, which are
(currently) statically programmed. To fix this, we introduce another
bitmask into nv50_head_atom.wndw to keep track of ownership separately
from visibility. We then introduce a nv50_head callback to handle
populating the wndw ownership map, and call it during the atomic check
phase when core->assign_windows is set to true.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/atom.h | 1 +
drivers/gpu/drm/nouveau/dispnv50/disp.c | 16
drivers/gpu/drm/nouveau/dispnv50/head.h | 2 ++
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 10 ++
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 ++
5 files changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/atom.h
b/drivers/gpu/drm/nouveau/dispnv50/atom.h
index 24f7700768dab..62faaf60f47a5 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/atom.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/atom.h
@@ -18,6 +18,7 @@ struct nv50_head_atom {
struct {
u32 mask;
+ u32 owned;
u32 olut;
} wndw;
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index d472942102f50..368069a5b181a 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2287,12 +2287,28 @@ static int
nv50_disp_atomic_check(struct drm_device *dev, struct drm_atomic_state *state)
{
struct nv50_atom *atom = nv50_atom(state);
+ struct nv50_core *core = nv50_disp(dev)->core;
struct drm_connector_state *old_connector_state, *new_connector_state;
struct drm_connector *connector;
struct drm_crtc_state *new_crtc_state;
struct drm_crtc *crtc;
+ struct nv50_head *head;
+ struct nv50_head_atom *asyh;
int ret, i;
+ if (core->assign_windows && core->func->head->static_wndw_map) {
+ drm_for_each_crtc(crtc, dev) {
+ new_crtc_state = drm_atomic_get_crtc_state(state,
+ crtc);
+ if (IS_ERR(new_crtc_state))
+ return PTR_ERR(new_crtc_state);
+
+ head = nv50_head(crtc);
+ asyh = nv50_head_atom(new_crtc_state);
+ core->func->head->static_wndw_map(head, asyh);
+ }
+ }
+
/* We need to handle colour management on a per-plane basis. */
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
if (new_crtc_state->color_mgmt_changed) {
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.h
b/drivers/gpu/drm/nouveau/dispnv50/head.h
index c32b27cdaefc9..c05bbba9e247c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.h
@@ -40,6 +40,7 @@ struct nv50_head_func {
void (*dither)(struct nv50_head *, struct nv50_head_atom *);
void (*procamp)(struct nv50_head *, struct nv50_head_atom *);
void (*or)(struct nv50_head *, struct nv50_head_atom *);
+ void (*static_wndw_map)(struct nv50_head *, struct nv50_head_atom *);
};
extern const struct nv50_head_func head507d;
@@ -86,6 +87,7 @@ int headc37d_curs_format(str
[RFC v8 4/9] drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's depth in the atomic state hasn't been modified.
Normally this wouldn't matter, since we don't modify OR state outside of
modesets, but since the CRC capture region is implemented as part of the
OR state in hardware we'll want to make sure all commits modifying OR
state are idempotent so as to avoid changing the depth unexpectedly.
So, fix this by simply not writing the reduced depth value we come up
with to the atomic state.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 11 +++
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 11 +++
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
index 4a9a32b89f746..9ef3c603fc43e 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
@@ -27,17 +27,20 @@ static void
headc37d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
{
struct nv50_dmac *core = &nv50_disp(head->base.base.dev)->core->chan;
+ u8 depth;
u32 *push;
+
if ((push = evo_wait(core, 2))) {
/*XXX: This is a dirty hack until OR depth handling is
* improved later for deep colour etc.
*/
switch (asyh->or.depth) {
- case 6: asyh->or.depth = 5; break;
- case 5: asyh->or.depth = 4; break;
- case 2: asyh->or.depth = 1; break;
- case 0: asyh->or.depth = 4; break;
+ case 6: depth = 5; break;
+ case 5: depth = 4; break;
+ case 2: depth = 1; break;
+ case 0: depth = 4; break;
default:
+ depth = asyh->or.depth;
WARN_ON(1);
break;
}
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index 859131a8bc3c8..97141eb8e75ab 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -27,17 +27,20 @@ static void
headc57d_or(struct nv50_head *head, struct nv50_head_atom *asyh)
{
struct nv50_dmac *core = &nv50_disp(head->base.base.dev)->core->chan;
+ u8 depth;
u32 *push;
+
if ((push = evo_wait(core, 2))) {
/*XXX: This is a dirty hack until OR depth handling is
* improved later for deep colour etc.
*/
switch (asyh->or.depth) {
- case 6: asyh->or.depth = 5; break;
- case 5: asyh->or.depth = 4; break;
- case 2: asyh->or.depth = 1; break;
- case 0: asyh->or.depth = 4; break;
+ case 6: depth = 5; break;
+ case 5: depth = 4; break;
+ case 2: depth = 1; break;
+ case 0: depth = 4; break;
default:
+ depth = asyh->or.depth;
WARN_ON(1);
break;
}
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v8 3/9] drm/vblank: Add vblank works
Add some kind of vblank workers. The interface is similar to regular delayed works, and is mostly based off kthread_work. It allows for scheduling delayed works that execute once a particular vblank sequence has passed. It also allows for accurate flushing of scheduled vblank works - in that flushing waits for both the vblank sequence and job execution to complete, or for the work to get cancelled - whichever comes first. Whatever hardware programming we do in the work must be fast (must at least complete during the vblank or scanout period, sometimes during the first few scanlines of the vblank). As such we use a high-priority per-CRTC thread to accomplish this. Changes since v7: * Stuff drm_vblank_internal.h and drm_vblank_work_internal.h contents into drm_internal.h * Get rid of unnecessary spinlock in drm_crtc_vblank_on() * Remove !vblank->worker check * Grab vbl_lock in drm_vblank_work_schedule() * Mention self-rearming work items in drm_vblank_work_schedule() kdocs * Return 1 from drm_vblank_work_schedule() if the work was scheduled successfully, 0 or error code otherwise * Use drm_dbg_core() instead of DRM_DEV_ERROR() in drm_vblank_work_schedule() * Remove vblank->worker checks in drm_vblank_destroy_worker() and drm_vblank_flush_worker() Changes since v6: * Get rid of ->pending and seqcounts, and implement flushing through simpler means - danvet * Get rid of work_lock, just use drm_device->event_lock * Move drm_vblank_work item cleanup into drm_crtc_vblank_off() so that we ensure that all vblank work has finished before disabling vblanks * Add checks into drm_crtc_vblank_reset() so we yell if it gets called while there's vblank workers active * Grab event_lock in both drm_crtc_vblank_on()/drm_crtc_vblank_off(), the main reason for this is so that other threads calling drm_vblank_work_schedule() are blocked from attempting to schedule while we're in the middle of enabling/disabling vblanks. * Move drm_handle_vblank_works() call below drm_handle_vblank_events() * Simplify drm_vblank_work_cancel_sync() * Fix drm_vblank_work_cancel_sync() documentation * Move wake_up_all() calls out of spinlock where we can. The only one I left was the call to wake_up_all() in drm_vblank_handle_works() as this seemed like it made more sense just living in that function (which is all technically under lock) * Move drm_vblank_work related functions into their own source files * Add drm_vblank_internal.h so we can export some functions we don't want drivers using, but that we do need to use in drm_vblank_work.c * Add a bunch of documentation Changes since v4: * Get rid of kthread interfaces we tried adding and move all of the locking into drm_vblank.c. For implementing drm_vblank_work_flush(), we now use a wait_queue and sequence counters in order to differentiate between multiple work item executions. * Get rid of drm_vblank_work_cancel() - this would have been pretty difficult to actually reimplement and it occurred to me that neither nouveau or i915 are even planning to use this function. Since there's also no async cancel function for most of the work interfaces in the kernel, it seems a bit unnecessary anyway. * Get rid of to_drm_vblank_work() since we now are also able to just pass the struct drm_vblank_work to work item callbacks anyway Changes since v3: * Use our own spinlocks, don't integrate so tightly with kthread_works Changes since v2: * Use kthread_workers instead of reinventing the wheel. Cc: Tejun Heo Cc: dri-devel@lists.freedesktop.org Cc: nouv...@lists.freedesktop.org Reviewed-by: Daniel Vetter Co-developed-by: Ville Syrjälä Signed-off-by: Lyude Paul --- Documentation/gpu/drm-kms.rst | 15 ++ drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_internal.h| 27 +++ drivers/gpu/drm/drm_vblank.c | 44 +++-- drivers/gpu/drm/drm_vblank_work.c | 267 ++ include/drm/drm_vblank.h | 20 +++ include/drm/drm_vblank_work.h | 71 7 files changed, 430 insertions(+), 16 deletions(-) create mode 100644 drivers/gpu/drm/drm_vblank_work.c create mode 100644 include/drm/drm_vblank_work.h diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 975cfeb8a3532..3c5ae4f6dfd23 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -543,3 +543,18 @@ Vertical Blanking and Interrupt Handling Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_vblank.c :export: + +Vertical Blank Work +=== + +.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c + :doc: vblank works + +Vertical Blank Work Functions Reference +--- + +.. kernel-doc:: include/drm/drm_vblank_work.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_vblank_work.c + :export: diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 2c0e5a7e59536..02ee5faf1a925 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gp
[RFC v8 7/9] drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 18 --
drivers/gpu/drm/nouveau/dispnv50/disp.h | 14 ++
2 files changed, 14 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 368069a5b181a..090882794f7d6 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -57,24 +57,6 @@
#include
-/**
- * Atomic state
- */
-
-struct nv50_outp_atom {
- struct list_head head;
-
- struct drm_encoder *encoder;
- bool flush_disable;
-
- union nv50_outp_atom_mask {
- struct {
- bool ctrl:1;
- };
- u8 mask;
- } set, clr;
-};
-
/**
* EVO channel
*/
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.h
b/drivers/gpu/drm/nouveau/dispnv50/disp.h
index 696e70a6b98b6..c7b72fa850995 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.h
@@ -71,6 +71,20 @@ struct nv50_dmac {
struct mutex lock;
};
+struct nv50_outp_atom {
+ struct list_head head;
+
+ struct drm_encoder *encoder;
+ bool flush_disable;
+
+ union nv50_outp_atom_mask {
+ struct {
+ bool ctrl:1;
+ };
+ u8 mask;
+ } set, clr;
+};
+
int nv50_dmac_create(struct nvif_device *device, struct nvif_object *disp,
const s32 *oclass, u8 head, void *data, u32 size,
u64 syncbuf, struct nv50_dmac *dmac);
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v8 0/9] drm/nouveau: Introduce CRC support for gf119+
Nvidia released some documentation on how CRC support works on their GPUs, hooray! So: this patch series implements said CRC support in nouveau, along with adding some special debugfs interfaces for some relevant igt-gpu-tools tests (already on the ML). First - we add some new functionality to kthread_work in the kernel, and then use this to add a new feature to DRM that Ville Syrjälä came up with: vblank workers. Basically, this is just a generic DRM interface that allows for scheduling high-priority workers that start on a given vblank interrupt. Note that while we're currently only using this in nouveau, Intel has plans to use this for i915 as well (hence why they came up with it!). And finally: in order to implement the last feature, we expose some new functions in the kernel's kthread_worker infrastructure so that we can de-complicate our implementation of this. Anyway-welcome to the future! :) Major changes since v7: * Drop /harm/armh/ patch * Address danvet's comments * Drop "drm/nouveau/kms/nv50-: Unroll error cleanup in nv50_head_create()" Major changes since v6: * Move vblank_work related functions into their own files * Write documentation * Simplify work flushing and cancellation by getting rid of seqcounts and ->pending Major changes since v4: * Remove the interfaces we tried adding to kthread_worker and use a wait queue + seqcount in order to implement flushing vblank workers. * Rebase Major changes since v3: * Style fixes on nouveau patches from checkpatch, no functional changes * Don't integrate so tightly with kthread_work (and use our own lock), instead introduce some new functions for doing simple async flushing and cancelling. I think this interface looks a lot more acceptable then what I was previously trying. * Apply some changes requested by danvet Major changes since v2: * Use kthread_worker instead of kthreadd for vblank workers * Don't check debugfs return values Lyude Paul (9): drm/vblank: Register drmm cleanup action once per drm_vblank_crtc drm/vblank: Use spin_(un)lock_irq() in drm_crtc_vblank_off() drm/vblank: Add vblank works drm/nouveau/kms/nv140-: Don't modify depth in state during atomic commit drm/nouveau/kms/nv50-: Fix disabling dithering drm/nouveau/kms/nv140-: Track wndw mappings in nv50_head_atom drm/nouveau/kms/nv50-: Expose nv50_outp_atom in disp.h drm/nouveau/kms/nv50-: Move hard-coded object handles into header drm/nouveau/kms/nvd9-: Add CRC support Documentation/gpu/drm-kms.rst | 15 + drivers/gpu/drm/Makefile| 2 +- drivers/gpu/drm/drm_internal.h | 27 + drivers/gpu/drm/drm_vblank.c| 72 +- drivers/gpu/drm/drm_vblank_work.c | 267 drivers/gpu/drm/nouveau/dispnv04/crtc.c | 25 +- drivers/gpu/drm/nouveau/dispnv50/Kbuild | 4 + drivers/gpu/drm/nouveau/dispnv50/atom.h | 21 + drivers/gpu/drm/nouveau/dispnv50/core.h | 4 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/crc.c | 714 drivers/gpu/drm/nouveau/dispnv50/crc.h | 125 drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 139 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 153 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 58 +- drivers/gpu/drm/nouveau/dispnv50/disp.h | 24 + drivers/gpu/drm/nouveau/dispnv50/handles.h | 16 + drivers/gpu/drm/nouveau/dispnv50/head.c | 98 ++- drivers/gpu/drm/nouveau/dispnv50/head.h | 12 +- drivers/gpu/drm/nouveau/dispnv50/head907d.c | 14 +- drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 27 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 20 +- drivers/gpu/drm/nouveau/dispnv50/wndw.c | 3 +- drivers/gpu/drm/nouveau/nouveau_display.c | 60 +- include/drm/drm_vblank.h| 20 + include/drm/drm_vblank_work.h | 71 ++ 29 files changed, 1861 insertions(+), 142 deletions(-) create mode 100644 drivers/gpu/drm/drm_vblank_work.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc.h create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crc907d.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h create mode 100644 include/drm/drm_vblank_work.h -- 2.26.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v8 5/9] drm/nouveau/kms/nv50-: Fix disabling dithering
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/head.c
b/drivers/gpu/drm/nouveau/dispnv50/head.c
index 8f6455697ba72..ed6819519f6d8 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/head.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/head.c
@@ -84,18 +84,20 @@ nv50_head_atomic_check_dither(struct nv50_head_atom *armh,
{
u32 mode = 0x00;
- if (asyc->dither.mode == DITHERING_MODE_AUTO) {
- if (asyh->base.depth > asyh->or.bpc * 3)
- mode = DITHERING_MODE_DYNAMIC2X2;
- } else {
- mode = asyc->dither.mode;
- }
+ if (asyc->dither.mode) {
+ if (asyc->dither.mode == DITHERING_MODE_AUTO) {
+ if (asyh->base.depth > asyh->or.bpc * 3)
+ mode = DITHERING_MODE_DYNAMIC2X2;
+ } else {
+ mode = asyc->dither.mode;
+ }
- if (asyc->dither.depth == DITHERING_DEPTH_AUTO) {
- if (asyh->or.bpc >= 8)
- mode |= DITHERING_DEPTH_8BPC;
- } else {
- mode |= asyc->dither.depth;
+ if (asyc->dither.depth == DITHERING_DEPTH_AUTO) {
+ if (asyh->or.bpc >= 8)
+ mode |= DITHERING_DEPTH_8BPC;
+ } else {
+ mode |= asyc->dither.depth;
+ }
}
asyh->dither.enable = mode;
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC v8 9/9] drm/nouveau/kms/nvd9-: Add CRC support
This introduces support for CRC readback on gf119+, using the documentation generously provided to us by Nvidia: https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed through a single set of "outp" sources: outp-active/auto for a CRC of the scanout region, outp-complete for a CRC of both the scanout and blanking/sync region combined, and outp-inactive for a CRC of only the blanking/sync region. For each source, nouveau selects the appropriate tap point based on the output path in use. We also expose an "rg" source, which allows for capturing CRCs of the scanout raster before it's encoded into a video signal in the output path. This tap point is referred to as the raster generator. Note that while there's some other neat features that can be used with CRC capture on nvidia hardware, like capturing from two CRC sources simultaneously, I couldn't see any usecase for them and did not implement them. Nvidia only allows for accessing CRCs through a shared DMA region that we program through the core EVO/NvDisplay channel which is referred to as the notifier context. The notifier context is limited to either 255 (for Fermi-Pascal) or 2047 (Volta+) entries to store CRCs in, and unfortunately the hardware simply drops CRCs and reports an overflow once all available entries in the notifier context are filled. Since the DRM CRC API and igt-gpu-tools don't expect there to be a limit on how many CRCs can be captured, we work around this in nouveau by allocating two separate notifier contexts for each head instead of one. We schedule a vblank worker ahead of time so that once we start getting close to filling up all of the available entries in the notifier context, we can swap the currently used notifier context out with another pre-prepared notifier context in a manner similar to page flipping. Unfortunately, the hardware only allows us to this by flushing two separate updates on the core channel: one to release the current notifier context handle, and one to program the next notifier context's handle. When the hardware processes the first update, the CRC for the current frame is lost. However, the second update can be flushed immediately without waiting for the first to complete so that CRC generation resumes on the next frame. According to Nvidia's hardware engineers, there isn't any cleaner way of flipping notifier contexts that would avoid this. Since using vblank workers to swap out the notifier context will ensure we can usually flush both updates to hardware within the timespan of a single frame, we can also ensure that there will only be exactly one frame lost between the first and second update being executed by the hardware. This gives us the guarantee that we're always correctly matching each CRC entry with it's respective frame even after a context flip. And since IGT will retrieve the CRC entry for a frame by waiting until it receives a CRC for any subsequent frames, this doesn't cause an issue with any tests and is much simpler than trying to change the current DRM API to accommodate. In order to facilitate testing of correct handling of this limitation, we also expose a debugfs interface to manually control the threshold for when we start trying to flip the notifier context. We will use this in igt to trigger a context flip for testing purposes without needing to wait for the notifier to completely fill up. This threshold is reset to the default value set by nouveau after each capture, and is exposed in a separate folder within each CRTC's debugfs directory labelled "nv_crc". Changes since v1: * Forgot to finish saving crc.h before saving, whoops. This just adds some corrections to the empty function declarations that we use if CONFIG_DEBUG_FS isn't enabled. Changes since v2: * Don't check return code from debugfs_create_dir() or debugfs_create_file() - Greg K-H Changes since v3: (no functional changes) * Fix SPDX license identifiers (checkpatch) * s/uint32_t/u32/ (checkpatch) * Fix indenting in switch cases (checkpatch) Changes since v4: * Remove unneeded param changes with nv50_head_flush_clr/set * Rebase Changes since v5: * Remove set but unused variable (outp) in nv50_crc_atomic_check() - Kbuild bot Signed-off-by: Lyude Paul --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 25 +- drivers/gpu/drm/nouveau/dispnv50/Kbuild | 4 + drivers/gpu/drm/nouveau/dispnv50/atom.h | 20 + drivers/gpu/drm/nouveau/dispnv50/core.h | 4 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 3 + drivers/gpu/drm/nouveau/dispnv50/crc.c | 714 drivers/gpu/drm/nouveau/dispnv50/crc.h | 125 drivers/gpu/drm/nouveau/dispnv50/crc907d.c | 139 drivers/gpu/drm/nouveau/dispnv50/crcc37d.c | 153 + dr
[RFC v8 8/9] drm/nouveau/kms/nv50-: Move hard-coded object handles into header
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just go ahead and move any hard-coded
handles into a single header. This is just to keep things slightly
organized, and to make it a little bit easier if we need to add more
handles in the future.
This patch should contain no functional changes.
Changes since v3:
* Correct SPDX license identifier (checkpatch)
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c| 7 +--
drivers/gpu/drm/nouveau/dispnv50/handles.h | 15 +++
drivers/gpu/drm/nouveau/dispnv50/wndw.c| 3 ++-
3 files changed, 22 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/dispnv50/handles.h
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 090882794f7d6..bf7ba1e1c0f74 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -26,6 +26,7 @@
#include "core.h"
#include "head.h"
#include "wndw.h"
+#include "handles.h"
#include
#include
@@ -154,7 +155,8 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (!syncbuf)
return 0;
- ret = nvif_object_init(&dmac->base.user, 0xf000, NV_DMA_IN_MEMORY,
+ ret = nvif_object_init(&dmac->base.user, NV50_DISP_HANDLE_SYNCBUF,
+ NV_DMA_IN_MEMORY,
&(struct nv_dma_v0) {
.target = NV_DMA_V0_TARGET_VRAM,
.access = NV_DMA_V0_ACCESS_RDWR,
@@ -165,7 +167,8 @@ nv50_dmac_create(struct nvif_device *device, struct
nvif_object *disp,
if (ret)
return ret;
- ret = nvif_object_init(&dmac->base.user, 0xf001, NV_DMA_IN_MEMORY,
+ ret = nvif_object_init(&dmac->base.user, NV50_DISP_HANDLE_VRAM,
+ NV_DMA_IN_MEMORY,
&(struct nv_dma_v0) {
.target = NV_DMA_V0_TARGET_VRAM,
.access = NV_DMA_V0_ACCESS_RDWR,
diff --git a/drivers/gpu/drm/nouveau/dispnv50/handles.h
b/drivers/gpu/drm/nouveau/dispnv50/handles.h
new file mode 100644
index 0..d1beeb9a444db
--- /dev/null
+++ b/drivers/gpu/drm/nouveau/dispnv50/handles.h
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: MIT
+#ifndef __NV50_KMS_HANDLES_H__
+#define __NV50_KMS_HANDLES_H__
+
+/*
+ * Various hard-coded object handles that nouveau uses. These are made-up by
+ * nouveau developers, not Nvidia. The only significance of the handles chosen
+ * is that they must all be unique.
+ */
+#define NV50_DISP_HANDLE_SYNCBUF
0xf000
+#define NV50_DISP_HANDLE_VRAM
0xf001
+
+#define NV50_DISP_HANDLE_WNDW_CTX(kind)(0xfb00 |
kind)
+
+#endif /* !__NV50_KMS_HANDLES_H__ */
diff --git a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
index 720fe75de1859..293ccfdba17ef 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/wndw.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/wndw.c
@@ -21,6 +21,7 @@
*/
#include "wndw.h"
#include "wimm.h"
+#include "handles.h"
#include
#include
@@ -59,7 +60,7 @@ nv50_wndw_ctxdma_new(struct nv50_wndw *wndw, struct
drm_framebuffer *fb)
int ret;
nouveau_framebuffer_get_layout(fb, &unused, &kind);
- handle = 0xfb00 | kind;
+ handle = NV50_DISP_HANDLE_WNDW_CTX(kind);
list_for_each_entry(ctxdma, &wndw->ctxdma.list, head) {
if (ctxdma->object.handle == handle)
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/6] drm/msm/a6xx: Add support for per-instance pagetables
On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse wrote:
>
> Add support for using per-instance pagetables if all the dependencies are
> available.
>
> Signed-off-by: Jordan Crouse
> ---
>
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 +++
> drivers/gpu/drm/msm/msm_ringbuffer.h | 1 +
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index aa53f47b7e8b..95ed2ceac121 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -79,6 +79,34 @@ static void get_stats_counter(struct msm_ringbuffer *ring,
> u32 counter,
> OUT_RING(ring, upper_32_bits(iova));
> }
>
> +static void a6xx_set_pagetable(struct msm_gpu *gpu, struct msm_ringbuffer
> *ring,
> + struct msm_file_private *ctx)
> +{
> + phys_addr_t ttbr;
> + u32 asid;
> +
> + if (msm_iommu_pagetable_params(ctx->aspace->mmu, &ttbr, &asid))
> + return;
> +
> + /* Execute the table update */
> + OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 4);
> + OUT_RING(ring, lower_32_bits(ttbr));
> + OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> + /* CONTEXTIDR is currently unused */
> + OUT_RING(ring, 0);
> + /* CONTEXTBANK is currently unused */
> + OUT_RING(ring, 0);
> +
> + /*
> +* Write the new TTBR0 to the memstore. This is good for debugging.
> +*/
> + OUT_PKT7(ring, CP_MEM_WRITE, 4);
> + OUT_RING(ring, lower_32_bits(rbmemptr(ring, ttbr0)));
> + OUT_RING(ring, upper_32_bits(rbmemptr(ring, ttbr0)));
> + OUT_RING(ring, lower_32_bits(ttbr));
> + OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> +}
> +
> static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> struct msm_file_private *ctx)
> {
> @@ -89,6 +117,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> msm_gem_submit *submit,
> struct msm_ringbuffer *ring = submit->ring;
> unsigned int i;
>
> + a6xx_set_pagetable(gpu, ring, ctx);
> +
> get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
> rbmemptr_stats(ring, index, cpcycles_start));
>
> @@ -872,6 +902,18 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
> return (unsigned long)busy_time;
> }
>
> +struct msm_gem_address_space *a6xx_address_space_instance(struct msm_gpu
> *gpu)
> +{
> + struct msm_mmu *mmu;
> +
> + mmu = msm_iommu_pagetable_create(gpu->aspace->mmu);
> + if (IS_ERR(mmu))
> + return msm_gem_address_space_get(gpu->aspace);
> +
> + return msm_gem_address_space_create(mmu,
> + "gpu", 0x1ULL, 0x1ULL);
> +}
> +
> static const struct adreno_gpu_funcs funcs = {
> .base = {
> .get_param = adreno_get_param,
> @@ -895,6 +937,7 @@ static const struct adreno_gpu_funcs funcs = {
> .gpu_state_put = a6xx_gpu_state_put,
> #endif
> .create_address_space = adreno_iommu_create_address_space,
> + .address_space_instance = a6xx_address_space_instance,
Hmm, maybe instead of .address_space_instance, something like
.create_context_address_space?
Since like .create_address_space, it is creating an address space..
the difference is that it is a per context/process aspace..
BR,
-R
> },
> .get_timestamp = a6xx_get_timestamp,
> };
> diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h
> b/drivers/gpu/drm/msm/msm_ringbuffer.h
> index 7764373d0ed2..0987d6bf848c 100644
> --- a/drivers/gpu/drm/msm/msm_ringbuffer.h
> +++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
> @@ -31,6 +31,7 @@ struct msm_rbmemptrs {
> volatile uint32_t fence;
>
> volatile struct msm_gpu_submit_stats
> stats[MSM_GPU_SUBMIT_STATS_COUNT];
> + volatile u64 ttbr0;
> };
>
> struct msm_ringbuffer {
> --
> 2.17.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/27] Converter R-Car DU to the DRM bridge connector helper
Hi Liu, thanks for the notice. Laurent, I trust you will take a look and resolve this. Sam On Thu, Jun 25, 2020 at 04:48:01PM +0800, Liu Ying wrote: > Hi Sam, > > On Tue, 2020-06-23 at 20:55 +0200, Sam Ravnborg wrote: > > Hi Laurent. > > > > On Tue, May 26, 2020 at 04:14:38AM +0300, Laurent Pinchart wrote: > > > Hello, > > > > > > This patch series converts the R-Car DU driver to use the DRM > > > bridge > > > connector helper drm_bridge_connector_init(). > > > > > > The bulk of the series is conversion of the adv7511, simple-bridge, > > > rcar-lbds and dw-hdmi drivers to make connector creation optional > > > (through the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag). > > > > > > The series starts with the adv7511 driver, previously posted as > > > "[PATCH > > > 0/4] drm: bridge: adv7511: Enable usage with DRM bridge connector > > > helper" ([1]). Patches 01/27 to 04/27 incorporate all the received > > > review comments. > > > > > > The next three patches address the simple-bridge driver, previously > > > posted as "[PATCH 0/2] drm: bridge: simple-bridge: Enable usage > > > with DRM > > > bridge connector helper". Patch 05/27 is an additional fix that > > > stems > > > from the review, and patches 06/27 and 07/27 incorporate all the > > > received review comments. > > > > > > Patch 08/27 is a new patch that addresses the rcar-lvds driver. > > > Instead > > > of implementing direct support for DRM_BRIDGE_ATTACH_NO_CONNECTOR, > > > it > > > simply removes code that shouldn't have been in the driver in the > > > first > > > place by switching to the panel bridge helper. > > > > > > Patches 09/27 to 22/27 then address the dw-hdmi driver. That's a > > > more > > > sizeable rework, due to the fact that the driver implements a mid- > > > layer > > > for platform-specific glue, with the internal drm_connector being > > > used > > > throughout the whole code. There's no rocket science there, but > > > patch > > > 10/27 should be noted for adding a new argument to the > > > drm_bridge_funcs.mode_valid() function. Please see individual > > > patches > > > for details. > > > > > > Patch 23/27 adds support to the dw-hdmi driver to attach to a > > > downstream > > > bridge if one is specified in DT. As the DT port number > > > corresponding to > > > the video output differs between platforms that integrate the dw- > > > hdmi > > > (some of them even don't have a video output port, which should > > > probably > > > be fixed, but that's out of scope for this series), the port number > > > has > > > to be specified by the platform glue layer. Patch 24/27 does so for > > > the > > > R-Car dw-hdmi driver. > > > > > > Patch 25/27 is a drive-by fix for an error path issue in the rcar- > > > du > > > driver. Patch 26/27 finally makes use of the > > > drm_bridge_connector_init() > > > helper. > > > > > > Unfortunately, this breaks the VGA output on R-Car Gen3 platforms. > > > On > > > those platforms, the VGA DDC lines are not connected, and there is > > > no > > > mean for software to detect the VGA output connection status. When > > > the > > > simple-bridge driver creates a connector, it automatically adds > > > default > > > modes when no DDC is available. This behavious is also present int > > > the > > > DRM probe helper drm_helper_probe_single_connector_modes(), but > > > only > > > when the connector status is connector_status_connected. As the > > > driver > > > (rightfully) reports connector_status_unconnected, no modes are > > > added. > > > Patch 27/27 fixes this issue by extending addition of default modes > > > in > > > drm_helper_probe_single_connector_modes() when the output status is > > > unknown. An alternative approach would be to implement this > > > behaviour in > > > the bridge connector helper (drm_bridge_connector.c). > > > > > > All the modified drivers have been compile-tested, and the series > > > has > > > been tested on a Renesas R-Car Salvator-XS board with the VGA, HDMI > > > and > > > LVDS outputs. > > > > > > [1] > > > https://lore.kernel.org/dri-devel/20200409004610.12346-1-laurent.pinchart+rene...@ideasonboard.com/ > > > [2] > > > https://lore.kernel.org/dri-devel/20200409003636.11792-1-laurent.pinchart+rene...@ideasonboard.com/ > > > > As we briefly discussed on IRC the first 21 patches are now applied > > to > > drm-misc-next. > > I see patch '[22/27] drm: bridge: dw-hdmi: Make connector creation > optional' is applied to drm-misc-next. > That patch would introduce an uninitialized mutex accessing issue as I > mentioned in the patch[1]. And, the patch intends to fix the issue in > the first place. > > [1] https://patchwork.freedesktop.org/patch/370560/ > > > Regards, > Liu Ying > > > The rcar-du specific patches was left out and the last patch was > > likewise not applied in this round- mostly because it was the coming > > after several rcar-du patches and I was not sure if there was some > > dependencies to consider. > > > > With this set in we have more examples i
Re: [PATCH] drm: gma500: Drop surplus include
On Sat, Jun 27, 2020 at 12:01 AM Linus Walleij wrote: > > This file includes but does not use any > symbols from it, drop the include. Hi Linus, Seems the include should be moved to mdfld_dsi_output.c instead. Thanks Patrik > > Cc: Patrik Jakobsson > Signed-off-by: Linus Walleij > --- > drivers/gpu/drm/gma500/psb_intel_drv.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h > b/drivers/gpu/drm/gma500/psb_intel_drv.h > index fb601983cef0..9221d1f545b0 100644 > --- a/drivers/gpu/drm/gma500/psb_intel_drv.h > +++ b/drivers/gpu/drm/gma500/psb_intel_drv.h > @@ -13,7 +13,6 @@ > #include > #include > #include > -#include > #include "gma_display.h" > > /* > -- > 2.25.4 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 6/6] drm/msm/a6xx: Add support for per-instance pagetables
On Sat, Jun 27, 2020 at 12:56 PM Rob Clark wrote:
>
> On Fri, Jun 26, 2020 at 1:04 PM Jordan Crouse wrote:
> >
> > Add support for using per-instance pagetables if all the dependencies are
> > available.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> >
> > drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 43 +++
> > drivers/gpu/drm/msm/msm_ringbuffer.h | 1 +
> > 2 files changed, 44 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > index aa53f47b7e8b..95ed2ceac121 100644
> > --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> > @@ -79,6 +79,34 @@ static void get_stats_counter(struct msm_ringbuffer
> > *ring, u32 counter,
> > OUT_RING(ring, upper_32_bits(iova));
> > }
> >
> > +static void a6xx_set_pagetable(struct msm_gpu *gpu, struct msm_ringbuffer
> > *ring,
> > + struct msm_file_private *ctx)
> > +{
> > + phys_addr_t ttbr;
> > + u32 asid;
> > +
> > + if (msm_iommu_pagetable_params(ctx->aspace->mmu, &ttbr, &asid))
> > + return;
> > +
> > + /* Execute the table update */
> > + OUT_PKT7(ring, CP_SMMU_TABLE_UPDATE, 4);
> > + OUT_RING(ring, lower_32_bits(ttbr));
> > + OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> > + /* CONTEXTIDR is currently unused */
> > + OUT_RING(ring, 0);
> > + /* CONTEXTBANK is currently unused */
> > + OUT_RING(ring, 0);
> > +
> > + /*
> > +* Write the new TTBR0 to the memstore. This is good for debugging.
> > +*/
> > + OUT_PKT7(ring, CP_MEM_WRITE, 4);
> > + OUT_RING(ring, lower_32_bits(rbmemptr(ring, ttbr0)));
> > + OUT_RING(ring, upper_32_bits(rbmemptr(ring, ttbr0)));
> > + OUT_RING(ring, lower_32_bits(ttbr));
> > + OUT_RING(ring, (((u64) asid) << 48) | upper_32_bits(ttbr));
> > +}
> > +
> > static void a6xx_submit(struct msm_gpu *gpu, struct msm_gem_submit *submit,
> > struct msm_file_private *ctx)
> > {
> > @@ -89,6 +117,8 @@ static void a6xx_submit(struct msm_gpu *gpu, struct
> > msm_gem_submit *submit,
> > struct msm_ringbuffer *ring = submit->ring;
> > unsigned int i;
> >
> > + a6xx_set_pagetable(gpu, ring, ctx);
> > +
> > get_stats_counter(ring, REG_A6XX_RBBM_PERFCTR_CP_0_LO,
> > rbmemptr_stats(ring, index, cpcycles_start));
> >
> > @@ -872,6 +902,18 @@ static unsigned long a6xx_gpu_busy(struct msm_gpu *gpu)
> > return (unsigned long)busy_time;
> > }
> >
> > +struct msm_gem_address_space *a6xx_address_space_instance(struct msm_gpu
> > *gpu)
> > +{
> > + struct msm_mmu *mmu;
> > +
> > + mmu = msm_iommu_pagetable_create(gpu->aspace->mmu);
> > + if (IS_ERR(mmu))
> > + return msm_gem_address_space_get(gpu->aspace);
> > +
> > + return msm_gem_address_space_create(mmu,
> > + "gpu", 0x1ULL, 0x1ULL);
> > +}
> > +
> > static const struct adreno_gpu_funcs funcs = {
> > .base = {
> > .get_param = adreno_get_param,
> > @@ -895,6 +937,7 @@ static const struct adreno_gpu_funcs funcs = {
> > .gpu_state_put = a6xx_gpu_state_put,
> > #endif
> > .create_address_space = adreno_iommu_create_address_space,
> > + .address_space_instance = a6xx_address_space_instance,
>
> Hmm, maybe instead of .address_space_instance, something like
> .create_context_address_space?
>
> Since like .create_address_space, it is creating an address space..
> the difference is that it is a per context/process aspace..
>
or maybe just .create_pgtable and return the 'struct msm_mmu' (which
is itself starting to become less of a great name)..
The only other thing a6xx_address_space_instance() adds is knowing
where the split is between the kernel and user pgtables, and I suppose
that isn't a thing that would really be changing between gens?
BR,
-R
> BR,
> -R
>
> > },
> > .get_timestamp = a6xx_get_timestamp,
> > };
> > diff --git a/drivers/gpu/drm/msm/msm_ringbuffer.h
> > b/drivers/gpu/drm/msm/msm_ringbuffer.h
> > index 7764373d0ed2..0987d6bf848c 100644
> > --- a/drivers/gpu/drm/msm/msm_ringbuffer.h
> > +++ b/drivers/gpu/drm/msm/msm_ringbuffer.h
> > @@ -31,6 +31,7 @@ struct msm_rbmemptrs {
> > volatile uint32_t fence;
> >
> > volatile struct msm_gpu_submit_stats
> > stats[MSM_GPU_SUBMIT_STATS_COUNT];
> > + volatile u64 ttbr0;
> > };
> >
> > struct msm_ringbuffer {
> > --
> > 2.17.1
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 0/2] Improve descriptions of a few simple-panels
On Mon, Jun 22, 2020 at 01:27:40AM +0300, Dmitry Osipenko wrote: > Hello, > > This is a follow up to [1], which was already applied to drm-misc and then > Laurent Pinchart spotted some problems. This series addresses those problems. > > [1] > https://patchwork.ozlabs.org/project/linux-tegra/patch/20200617222703.17080-8-dig...@gmail.com/ > > Dmitry Osipenko (2): > drm/panel-simple: Correct EDT ET057090DHU connector type > drm/panel-simple: Add missing BUS descriptions for some panels Thanks for the quick fixes, both are now applied to drm-misc-next. Sam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/2] drm/panel-simple: Add missing BUS descriptions for some panels
Hi Dmitry,
Thank you for the patch.
On Mon, Jun 22, 2020 at 01:27:42AM +0300, Dmitry Osipenko wrote:
> This patch adds missing BUS fields to the display panel descriptions of
> the panels which are found on NVIDIA Tegra devices:
>
> 1. AUO B101AW03
> 2. Chunghwa CLAA070WP03XG
> 3. Chunghwa CLAA101WA01A
> 4. Chunghwa CLAA101WB01
> 5. Innolux N156BGE L21
> 6. Samsung LTN101NT05
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/panel/panel-simple.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 87edd2bdf09a..986df9937650 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -698,6 +698,8 @@ static const struct panel_desc auo_b101aw03 = {
> .width = 223,
> .height = 125,
> },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
Does DRM_BUS_FLAG_PIXDATA_DRIVE_* make sense for LVDS ?
The rest looks good, except the Samsung panel for which I haven't been
able to locate a datasheet.
Reviewed-by: Laurent Pinchart
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> @@ -1352,6 +1354,8 @@ static const struct panel_desc chunghwa_claa070wp03xg =
> {
> .width = 94,
> .height = 150,
> },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> @@ -1375,6 +1379,8 @@ static const struct panel_desc chunghwa_claa101wa01a = {
> .width = 220,
> .height = 120,
> },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> @@ -1398,6 +1404,8 @@ static const struct panel_desc chunghwa_claa101wb01 = {
> .width = 223,
> .height = 125,
> },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> @@ -2071,6 +2079,8 @@ static const struct panel_desc innolux_n156bge_l21 = {
> .width = 344,
> .height = 193,
> },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
> @@ -3018,6 +3028,8 @@ static const struct panel_desc samsung_ltn101nt05 = {
> .width = 223,
> .height = 125,
> },
> + .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG,
> + .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE,
> .connector_type = DRM_MODE_CONNECTOR_LVDS,
> };
>
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: gma500: Drop surplus include
On Sat, Jun 27, 2020 at 10:07 PM Patrik Jakobsson wrote: > On Sat, Jun 27, 2020 at 12:01 AM Linus Walleij > wrote: > > > > This file includes but does not use any > > symbols from it, drop the include. > > Hi Linus, > Seems the include should be moved to mdfld_dsi_output.c instead. Yeah we are in include file hell :/ I'll figure it out. Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 zzyx...@gmail.com changed: What|Removed |Added CC||zzyx...@gmail.com --- Comment #29 from zzyx...@gmail.com --- Just hit this on Archlinux with linux-5.7.6 on a Vega 64. So far I've had three crashes mostly occuring within the first few minutes of uptime. I'm not running kwin or chrome, just a light window manager (bspwm) and compton. During the first two, steam's fossilize was running which lead me to suspect it was triggered by an interaction with that. However the third crashed before I even managed to start steam, so either I'm just lucky or my system is good at triggering this. @Duncan I'm not sure if you want to muddle your bisect results with a different system configuration, but I'm happy to help test commits if that would be helpful. I've noticed the call traces reported in the kernel log are slightly different for each crash; I'm not sure if they're likely to be useful or not. Here's at least the one from my first crash: Jun 27 14:04:40 erebor kernel: general protection fault, probably for non-canonical address 0x5dda9795528973db: [#1] PREEMPT SMP NOPTI Jun 27 14:04:40 erebor kernel: CPU: 14 PID: 193610 Comm: kworker/u32:14 Tainted: G OE 5.7.6-arch1-1 #1 Jun 27 14:04:40 erebor kernel: Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./AB350 Pro4, BIOS P4.90 06/14/2018 Jun 27 14:04:40 erebor kernel: Workqueue: events_unbound commit_work [drm_kms_helper] Jun 27 14:04:40 erebor kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail+0x2aa/0x2310 [amdgpu] Jun 27 14:04:40 erebor kernel: Code: 4f 08 8b 81 e0 02 00 00 41 83 c5 01 44 39 e8 0f 87 46 ff ff ff 48 83 bd f0 fc ff ff 00 0f 84 03 01 00 00 48 8b bd f0 fc ff ff <80> bf b0 01 00 00 01 0f 86 ac 00 00> Jun 27 14:04:40 erebor kernel: RSP: 0018:bcec0a4afaf8 EFLAGS: 00010206 Jun 27 14:04:40 erebor kernel: RAX: 0006 RBX: 9b71dbaed000 RCX: 9b7472e4b800 Jun 27 14:04:40 erebor kernel: RDX: 9b72504ea400 RSI: c13181e0 RDI: 5dda9795528973db Jun 27 14:04:40 erebor kernel: RBP: bcec0a4afe60 R08: 0001 R09: 0001 Jun 27 14:04:40 erebor kernel: R10: 0082 R11: 000730e2 R12: Jun 27 14:04:40 erebor kernel: R13: 0006 R14: 9b71dbaed800 R15: 9b71a8fdb580 Jun 27 14:04:40 erebor kernel: FS: () GS:9b747ef8() knlGS: Jun 27 14:04:40 erebor kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 27 14:04:40 erebor kernel: CR2: 56460ce164b0 CR3: 000341c86000 CR4: 003406e0 Jun 27 14:04:40 erebor kernel: Call Trace: Jun 27 14:04:40 erebor kernel: ? __erst_read+0x160/0x1d0 Jun 27 14:04:40 erebor kernel: ? __switch_to_asm+0x34/0x70 Jun 27 14:04:40 erebor kernel: ? __switch_to_asm+0x40/0x70 Jun 27 14:04:40 erebor kernel: ? __switch_to_asm+0x34/0x70 Jun 27 14:04:40 erebor kernel: ? __switch_to_asm+0x40/0x70 Jun 27 14:04:40 erebor kernel: ? rescuer_thread+0x3f0/0x3f0 Jun 27 14:04:40 erebor kernel: commit_tail+0x94/0x130 [drm_kms_helper] Jun 27 14:04:40 erebor kernel: process_one_work+0x1da/0x3d0 Jun 27 14:04:40 erebor kernel: ? rescuer_thread+0x3f0/0x3f0 Jun 27 14:04:40 erebor kernel: worker_thread+0x4d/0x3e0 Jun 27 14:04:40 erebor kernel: ? rescuer_thread+0x3f0/0x3f0 Jun 27 14:04:40 erebor kernel: kthread+0x13e/0x160 Jun 27 14:04:40 erebor kernel: ? __kthread_bind_mask+0x60/0x60 Jun 27 14:04:40 erebor kernel: ret_from_fork+0x22/0x40 Jun 27 14:04:40 erebor kernel: Modules linked in: snd_seq_midi snd_seq_dummy snd_seq_midi_event snd_hrtimer snd_seq fuse ccm 8021q garp mrp stp llc snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_seq_de> Jun 27 14:04:40 erebor kernel: blake2b_generic libcrc32c crc32c_generic xor uas usb_storage raid6_pq crc32c_intel xhci_pci xhci_hcd Jun 27 14:04:40 erebor kernel: ---[ end trace cb5c0d96dd991657 ]--- Jun 27 14:04:40 erebor kernel: RIP: 0010:amdgpu_dm_atomic_commit_tail+0x2aa/0x2310 [amdgpu] Jun 27 14:04:40 erebor kernel: Code: 4f 08 8b 81 e0 02 00 00 41 83 c5 01 44 39 e8 0f 87 46 ff ff ff 48 83 bd f0 fc ff ff 00 0f 84 03 01 00 00 48 8b bd f0 fc ff ff <80> bf b0 01 00 00 01 0f 86 ac 00 00> Jun 27 14:04:40 erebor kernel: RSP: 0018:bcec0a4afaf8 EFLAGS: 00010206 Jun 27 14:04:40 erebor kernel: RAX: 0006 RBX: 9b71dbaed000 RCX: 9b7472e4b800 Jun 27 14:04:40 erebor kernel: RDX: 9b72504ea400 RSI: c13181e0 RDI: 5dda9795528973db Jun 27 14:04:40 erebor kernel: RBP: bcec0a4afe60 R08: 0001 R09: 0001 Jun 27 14:04:40 erebor kernel: R10: 0082 R11: 000730e2 R12: Jun 27 14:04:40 erebor kernel: R13: 0006 R14: 9b71dbaed800 R15: 9b71a8fdb580 Jun 27 14:04:40 erebor kernel: FS: () GS:9b747ef8() knl
[PATCH] drm: gma500: Convert to GPIO descriptors
Finalize he conversion of GMA500 to use only GPIO descriptors.
The GPIO look-up-table is associated with the device directly
in the GMA500 Medfield chip driver since no explicit platform
type device (such as in x86/platform/intel-mid) exists: the
GMA500 probes directly from the PCI device. Apparently GPIOs
88 and 34 are used on all of these so just go ahead and
register those for resetting the DSI pipes.
Cc: Patrik Jakobsson
Signed-off-by: Linus Walleij
---
drivers/gpu/drm/gma500/mdfld_device.c | 20 +
drivers/gpu/drm/gma500/mdfld_dsi_dpi.c| 2 +-
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 51 ---
drivers/gpu/drm/gma500/mdfld_dsi_output.h | 2 +-
drivers/gpu/drm/gma500/mdfld_output.h | 2 +-
drivers/gpu/drm/gma500/psb_intel_drv.h| 1 -
6 files changed, 49 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_device.c
b/drivers/gpu/drm/gma500/mdfld_device.c
index b718efccdcf2..be9cf6b1e3b3 100644
--- a/drivers/gpu/drm/gma500/mdfld_device.c
+++ b/drivers/gpu/drm/gma500/mdfld_device.c
@@ -6,6 +6,7 @@
**/
#include
+#include
#include
@@ -505,12 +506,31 @@ static const struct psb_offset mdfld_regmap[3] = {
},
};
+/*
+ * The GPIO lines for resetting DSI pipe 0 and 2 are available in the
+ * PCI device :00:0c.0 on the Medfield.
+ */
+static struct gpiod_lookup_table mdfld_dsi_pipe_gpio_table = {
+ .table = {
+ GPIO_LOOKUP(":00:0c.0", 128, "dsi-pipe0-reset",
+ GPIO_ACTIVE_HIGH),
+ GPIO_LOOKUP(":00:0c.0", 34, "dsi-pipe2-reset",
+ GPIO_ACTIVE_HIGH),
+ { },
+ },
+};
+
static int mdfld_chip_setup(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
if (pci_enable_msi(dev->pdev))
dev_warn(dev->dev, "Enabling MSI failed!\n");
dev_priv->regmap = mdfld_regmap;
+
+ /* Associate the GPIO lines with the DRM device */
+ mdfld_dsi_pipe_gpio_table.dev_id = dev_name(dev->dev);
+ gpiod_add_lookup_table(&mdfld_dsi_pipe_gpio_table);
+
return mid_chip_setup(dev);
}
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
index c976a9dd9240..ae1223f631a7 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_dpi.c
@@ -955,7 +955,7 @@ struct mdfld_dsi_encoder *mdfld_dsi_dpi_init(struct
drm_device *dev,
/* panel hard-reset */
if (p_funcs->reset) {
- ret = p_funcs->reset(pipe);
+ ret = p_funcs->reset(dev, pipe);
if (ret) {
DRM_ERROR("Panel %d hard-reset failed\n", pipe);
return NULL;
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index f350ac1ead18..c9478261964a 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
@@ -432,42 +433,42 @@ static int mdfld_dsi_get_default_config(struct drm_device
*dev,
return 0;
}
-int mdfld_dsi_panel_reset(int pipe)
+int mdfld_dsi_panel_reset(struct drm_device *ddev, int pipe)
{
- unsigned gpio;
- int ret = 0;
-
+ struct device *dev = ddev->dev;
+ struct gpio_desc *gpiod;
+
+ /*
+* Raise the GPIO reset line for the corresponding pipe to HIGH,
+* this is probably because it is active low so this takes the
+* respective pipe out of reset. (We have no code to put it back
+* into reset in this driver.)
+*/
switch (pipe) {
case 0:
- gpio = 128;
+ gpiod = gpiod_get(dev, "dsi-pipe0-reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(gpiod))
+ return PTR_ERR(gpiod);
break;
case 2:
- gpio = 34;
+ gpiod = gpiod_get(dev, "dsi-pipe2-reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(gpiod))
+ return PTR_ERR(gpiod);
break;
default:
- DRM_ERROR("Invalid output\n");
+ DRM_DEV_ERROR(dev, "Invalid output pipe\n");
return -EINVAL;
}
+ gpiod_put(gpiod);
- ret = gpio_request(gpio, "gfx");
- if (ret) {
- DRM_ERROR("gpio_rqueset failed\n");
- return ret;
- }
-
- ret = gpio_direction_output(gpio, 1);
- if (ret) {
- DRM_ERROR("gpio_direction_output failed\n");
- goto gpio_error;
- }
+ /* Always read the pipe0 GPIO line, FIXME: explain why! */
+ gpiod = gpiod_get(dev, "dsi-pipe0-reset", GPIOD_ASIS);
+ if (IS_ERR(gpiod))
+
Re: [PATCH] fbtft-bus.c: Removing that prohibited space before ')'
Hi K,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v5.8-rc2 next-20200626]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/B-K-Karthik/fbtft-bus-c-Removing-that-prohibited-space-before/20200627-125315
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
92cd1b5d65f5c67147c7da39a3c2ad7e6ff81027
config: x86_64-randconfig-r015-20200628 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
a43b99a1e38e2beffb68a6db93f216f511e7fd41)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/staging/fbtft/fbtft-bus.c:65:53: error: too few arguments provided
>> to function-like macro invocation
define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
^
drivers/staging/fbtft/fbtft-bus.c:14:9: note: macro 'define_fbtft_write_reg'
defined here
#define define_fbtft_write_reg(func, buffer_type, data_type, modifier)
\
^
>> drivers/staging/fbtft/fbtft-bus.c:65:1: error: unknown type name
>> 'define_fbtft_write_reg'
define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
^
drivers/staging/fbtft/fbtft-bus.c:67:57: error: too few arguments provided
to function-like macro invocation
define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
^
drivers/staging/fbtft/fbtft-bus.c:14:9: note: macro 'define_fbtft_write_reg'
defined here
#define define_fbtft_write_reg(func, buffer_type, data_type, modifier)
\
^
drivers/staging/fbtft/fbtft-bus.c:67:1: error: unknown type name
'define_fbtft_write_reg'
define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
^
>> drivers/staging/fbtft/fbtft-bus.c:86:3: error: non-void function
>> 'fbtft_write_reg8_bus9' should return a value [-Wreturn-type]
return;
^
drivers/staging/fbtft/fbtft-bus.c:109:3: error: non-void function
'fbtft_write_reg8_bus9' should return a value [-Wreturn-type]
return;
^
6 errors generated.
vim +65 drivers/staging/fbtft/fbtft-bus.c
64
> 65 define_fbtft_write_reg(fbtft_write_reg8_bus8, u8, u8)
66 define_fbtft_write_reg(fbtft_write_reg16_bus8, __be16, u16, cpu_to_be16)
> 67 define_fbtft_write_reg(fbtft_write_reg16_bus16, u16, u16)
68
69 void fbtft_write_reg8_bus9(struct fbtft_par *par, int len, ...)
70 {
71 va_list args;
72 int i, ret;
73 int pad = 0;
74 u16 *buf = (u16 *)par->buf;
75
76 if (unlikely(par->debug & DEBUG_WRITE_REGISTER)) {
77 va_start(args, len);
78 for (i = 0; i < len; i++)
79 *(((u8 *)buf) + i) = (u8)va_arg(args, unsigned
int);
80 va_end(args);
81 fbtft_par_dbg_hex(DEBUG_WRITE_REGISTER, par,
82par->info->device, u8, buf, len, "%s:
",
83__func__);
84 }
85 if (len <= 0)
> 86 return;
87
88 if (par->spi && (par->spi->bits_per_word == 8)) {
89 /* we're emulating 9-bit, pad start of buffer with
no-ops
90 * (assuming here that zero is a no-op)
91 */
92 pad = (len % 4) ? 4 - (len % 4) : 0;
93 for (i = 0; i < pad; i++)
94 *buf++ = 0x000;
95 }
96
97 va_start(args, len);
98 *buf++ = (u8)va_arg(args, unsigned int);
99 i = len - 1;
100 while (i--) {
101 *buf = (u8)va_arg(args, unsigned int);
102 *buf++ |= 0x100; /* dc=1 */
103 }
104 va_end(args);
105 ret = par->fbtftops.write(par, par->buf, (len + pad) *
sizeof(u16));
106 if (ret < 0) {
107
[Bug 207383] [Regression] 5.7 amdgpu/polaris11 gpf: amdgpu_atomic_commit_tail
https://bugzilla.kernel.org/show_bug.cgi?id=207383 --- Comment #30 from mn...@protonmail.com --- I've been looking at this bug for a while now and I'll try to share what I've found about it. In some conditions, when amdgpu_dm_atomic_commit_tail calls dm_atomic_get_new_state, dm_atomic_get_new_state returns a struct dm_atomic_state* with an garbage context pointer. I've also found that this bug exclusively occurs when commit_work is on the workqueue. After forcing drm_atomic_helper_commit to run all of the commits without adding to the workqueue and running the OS, the issue seems to have disappeared. The system was stable for at least 1.5 hours before I manually shut it down (meanwhile it has usually crashed within 30-45 minutes). Perhaps there's some sort of race condition occurring after commit_work is queued? -- 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 v2 2/2] virtio: virtio_has_iommu_quirk -> virtio_has_dma_quirk
On 2020/6/25 上午7:21, Michael S. Tsirkin wrote:
Now that the corresponding feature bit has been renamed,
rename the quirk too - it's about special ways to
do DMA, not necessarily about the IOMMU.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_object.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++--
drivers/virtio/virtio_ring.c| 2 +-
include/linux/virtio_config.h | 4 ++--
tools/virtio/linux/virtio_config.h | 4 ++--
5 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c
b/drivers/gpu/drm/virtio/virtgpu_object.c
index 6ccbd01cd888..e8799ab0c753 100644
--- a/drivers/gpu/drm/virtio/virtgpu_object.c
+++ b/drivers/gpu/drm/virtio/virtgpu_object.c
@@ -141,7 +141,7 @@ static int virtio_gpu_object_shmem_init(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_mem_entry **ents,
unsigned int *nents)
{
- bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
+ bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
struct scatterlist *sg;
int si, ret;
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/virtgpu_vq.c
index 9e663a5d9952..53af60d484a4 100644
--- a/drivers/gpu/drm/virtio/virtgpu_vq.c
+++ b/drivers/gpu/drm/virtio/virtgpu_vq.c
@@ -599,7 +599,7 @@ void virtio_gpu_cmd_transfer_to_host_2d(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]);
struct virtio_gpu_transfer_to_host_2d *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
- bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
+ bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
if (use_dma_api)
@@ -1015,7 +1015,7 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct
virtio_gpu_device *vgdev,
struct virtio_gpu_object *bo = gem_to_virtio_gpu_obj(objs->objs[0]);
struct virtio_gpu_transfer_host_3d *cmd_p;
struct virtio_gpu_vbuffer *vbuf;
- bool use_dma_api = !virtio_has_iommu_quirk(vgdev->vdev);
+ bool use_dma_api = !virtio_has_dma_quirk(vgdev->vdev);
struct virtio_gpu_object_shmem *shmem = to_virtio_gpu_shmem(bo);
if (use_dma_api)
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index a1a5c2a91426..34253cb69cb8 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -240,7 +240,7 @@ static inline bool virtqueue_use_indirect(struct virtqueue
*_vq,
static bool vring_use_dma_api(struct virtio_device *vdev)
{
- if (!virtio_has_iommu_quirk(vdev))
+ if (!virtio_has_dma_quirk(vdev))
return true;
/* Otherwise, we are left to guess. */
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index f2cc2a0df174..3b4eae5ac5e3 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -162,10 +162,10 @@ static inline bool virtio_has_feature(const struct
virtio_device *vdev,
}
/**
- * virtio_has_iommu_quirk - determine whether this device has the iommu quirk
+ * virtio_has_dma_quirk - determine whether this device has the DMA quirk
* @vdev: the device
*/
-static inline bool virtio_has_iommu_quirk(const struct virtio_device *vdev)
+static inline bool virtio_has_dma_quirk(const struct virtio_device *vdev)
{
/*
* Note the reverse polarity of the quirk feature (compared to most
diff --git a/tools/virtio/linux/virtio_config.h
b/tools/virtio/linux/virtio_config.h
index f99ae42668e0..f2640e505c4e 100644
--- a/tools/virtio/linux/virtio_config.h
+++ b/tools/virtio/linux/virtio_config.h
@@ -42,10 +42,10 @@ static inline void __virtio_clear_bit(struct virtio_device
*vdev,
(__virtio_test_bit((dev), feature))
/**
- * virtio_has_iommu_quirk - determine whether this device has the iommu quirk
+ * virtio_has_dma_quirk - determine whether this device has the DMA quirk
* @vdev: the device
*/
-static inline bool virtio_has_iommu_quirk(const struct virtio_device *vdev)
+static inline bool virtio_has_dma_quirk(const struct virtio_device *vdev)
{
/*
* Note the reverse polarity of the quirk feature (compared to most
Acked-by: Jason Wang
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
