[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 Bug ID: 111481 Summary: AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: popovic.ma...@protonmail.com I've tried my AMD Radeon RX 5700 XT on both ubuntu (llvm 9 / mesa 19.3 - Oibaf PPA) and Manjaro (llvm 10 git / mesa-git). On both I've been using Gnome shell and in both cases I had frequent lockups and freezes. Once my GPU disconnected to Monitor and remained so until I rebooted, other times desktop would just freeze and crash the whole system. Software tried: LLVM 10 git / MESA 19.3 - git on Manjaro LLVM 9 / MESA 19.3 git from Oibaf PPA Kernels tried: Manjaro 5.3 RC4, Ubuntu 5.3 RC5 generic, Ubuntu drm-tip 5.3 daily Error log: avg 24 22:53:58 Marko-PC kernel: [drm:amdgpu_dm_commit_planes.constprop.0 [amdgpu]] ERROR Waiting for fences timed out or interrupted! avg 24 22:53:58 Marko-PC kernel: [drm:amdgpu_job_timedout [amdgpu]] ERROR ring gfx_0.0.0 timeout, signaled seq=94235, emitted seq=94237 avg 24 22:53:58 Marko-PC kernel: [drm:amdgpu_job_timedout [amdgpu]] ERROR Process information: process citra-qt pid 27356 thread citra-qt:cs0 pid 27366 Happened on all setups, bug was pretty much the same, lockups weren't extremely frequent but frequent enough that they were very noticable (5-6 freezes per day on average) Faulty hardware is probably out of options since I never had a hiccup or anything even close to crash or freeze on my Windows desktop. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Give dma-fence-array distinct lockclasses
Hi Chris, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.3-rc5 next-20190823] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/dma-buf-Give-dma-fence-array-distinct-lockclasses/20190825-045722 reproduce: make htmldocs If you fix the issue, kindly add following tag Reported-by: kbuild test robot All warnings (new ones prefixed by >>): Warning: The Sphinx 'sphinx_rtd_theme' HTML theme was not found. Make sure you have the theme installed to produce pretty HTML output. Falling back to the default theme. WARNING: dot(1) not found, for better output quality install graphviz from http://www.graphviz.org WARNING: convert(1) not found, for SVG to PDF conversion install ImageMagick (https://www.imagemagick.org) include/linux/w1.h:272: warning: Function parameter or member 'of_match_table' not described in 'w1_family' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'quotactl' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'quota_on' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_free_mnt_opts' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_eat_lsm_opts' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_kern_mount' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_show_options' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'sb_add_mnt_opt' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'd_instantiate' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'getprocattr' not described in 'security_list_options' include/linux/lsm_hooks.h:1811: warning: Function parameter or member 'setprocattr' not described in 'security_list_options' lib/genalloc.c:1: warning: 'gen_pool_add_virt' not found lib/genalloc.c:1: warning: 'gen_pool_alloc' not found lib/genalloc.c:1: warning: 'gen_pool_free' not found lib/genalloc.c:1: warning: 'gen_pool_alloc_algo' not found include/linux/i2c.h:337: warning: Function parameter or member 'init_irq' not described in 'i2c_client' include/linux/spi/spi.h:190: warning: Function parameter or member 'driver_override' not described in 'spi_device' drivers/usb/typec/bus.c:1: warning: 'typec_altmode_unregister_driver' not found drivers/usb/typec/bus.c:1: warning: 'typec_altmode_register_driver' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_register_notifier' not found drivers/usb/typec/class.c:1: warning: 'typec_altmode_unregister_notifier' not found fs/direct-io.c:258: warning: Excess function parameter 'offset' description in 'dio_complete' fs/libfs.c:496: warning: Excess function parameter 'available' description in 'simple_write_end' fs/posix_acl.c:647: warning: Function parameter or member 'inode' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'mode_p' not described in 'posix_acl_update_mode' fs/posix_acl.c:647: warning: Function parameter or member 'acl' not described in 'posix_acl_update_mode' include/linux/regulator/machine.h:196: warning: Function parameter or member 'max_uV_step' not described in 'regulation_constraints' include/linux/regulator/driver.h:223: warning: Function parameter or member 'resume' not described in 'regulator_ops' include/linux/input/sparse-keymap.h:43: warning: Function parameter or member 'sw' not described in 'key_entry' include/linux/skbuff.h:893: warning: Function parameter or member 'dev_scratch' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'list' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'ip_defrag_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'skb_mstamp_ns' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__cloned_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'head_frag' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member '__pkt_type_offset' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or member 'encapsulation' not described in 'sk_buff' include/linux/skbuff.h:893: warning: Function parameter or
Re: [PATCH] dma-buf: Give dma-fence-array distinct lockclasses
Quoting Koenig, Christian (2019-08-24 20:04:43) > Am 24.08.19 um 15:58 schrieb Chris Wilson: > > In order to allow dma-fence-array as a generic container for fences, we > > need to allow for it to contain other dma-fence-arrays. By giving each > > dma-fence-array construction their own lockclass, we allow different > > types of dma-fence-array to nest, but still do not allow on class of > > dma-fence-array to contain itself (even though they have distinct > > locks). > > > > In practice, this means that each subsystem gets its own dma-fence-array > > class and we can freely use dma-fence-arrays as containers within the > > dmabuf core without angering lockdep. > > I've considered this for as well. E.g. to use the dma_fence_array > implementation instead of coming up with the dma_fence_chain container. > > But as it turned out when userspace can control nesting, it is trivial > to chain enough dma_fence_arrays together to cause an in kernel stack > overflow. Which in turn creates a really nice attack vector. > > So as long as userspace has control over dma_fence_array nesting this is > a clear NAK and actually extremely dangerous. You are proposing to use recursive dma_fence_array containers for dma_resv... > It actually took me quite a while to get the dma_fence_chain container > recursion less to avoid stuff like this. Sure, we've been avoiding recursion for years. -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma-buf: Give dma-fence-array distinct lockclasses
Am 24.08.19 um 15:58 schrieb Chris Wilson:
> In order to allow dma-fence-array as a generic container for fences, we
> need to allow for it to contain other dma-fence-arrays. By giving each
> dma-fence-array construction their own lockclass, we allow different
> types of dma-fence-array to nest, but still do not allow on class of
> dma-fence-array to contain itself (even though they have distinct
> locks).
>
> In practice, this means that each subsystem gets its own dma-fence-array
> class and we can freely use dma-fence-arrays as containers within the
> dmabuf core without angering lockdep.
I've considered this for as well. E.g. to use the dma_fence_array
implementation instead of coming up with the dma_fence_chain container.
But as it turned out when userspace can control nesting, it is trivial
to chain enough dma_fence_arrays together to cause an in kernel stack
overflow. Which in turn creates a really nice attack vector.
So as long as userspace has control over dma_fence_array nesting this is
a clear NAK and actually extremely dangerous.
It actually took me quite a while to get the dma_fence_chain container
recursion less to avoid stuff like this.
Regards,
Christian.
>
> Signed-off-by: Chris Wilson
> Cc: Christian König
> Cc: Daniel Vetter
> ---
> drivers/dma-buf/dma-fence-array.c | 13 -
> include/linux/dma-fence-array.h | 16
> 2 files changed, 20 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-fence-array.c
> b/drivers/dma-buf/dma-fence-array.c
> index d3fbd950be94..d9bcdbb66d46 100644
> --- a/drivers/dma-buf/dma-fence-array.c
> +++ b/drivers/dma-buf/dma-fence-array.c
> @@ -147,10 +147,11 @@ EXPORT_SYMBOL(dma_fence_array_ops);
>* If @signal_on_any is true the fence array signals if any fence in the
> array
>* signals, otherwise it signals when all fences in the array signal.
>*/
> -struct dma_fence_array *dma_fence_array_create(int num_fences,
> -struct dma_fence **fences,
> -u64 context, unsigned seqno,
> -bool signal_on_any)
> +struct dma_fence_array *__dma_fence_array_create(int num_fences,
> + struct dma_fence **fences,
> + u64 context, unsigned seqno,
> + bool signal_on_any,
> + struct lock_class_key *key)
> {
> struct dma_fence_array *array;
> size_t size = sizeof(*array);
> @@ -162,6 +163,8 @@ struct dma_fence_array *dma_fence_array_create(int
> num_fences,
> return NULL;
>
> spin_lock_init(>lock);
> + lockdep_set_class(>lock, key);
> +
> dma_fence_init(>base, _fence_array_ops, >lock,
> context, seqno);
> init_irq_work(>work, irq_dma_fence_array_work);
> @@ -174,7 +177,7 @@ struct dma_fence_array *dma_fence_array_create(int
> num_fences,
>
> return array;
> }
> -EXPORT_SYMBOL(dma_fence_array_create);
> +EXPORT_SYMBOL(__dma_fence_array_create);
>
> /**
>* dma_fence_match_context - Check if all fences are from the given context
> diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
> index 303dd712220f..1395f9428cdb 100644
> --- a/include/linux/dma-fence-array.h
> +++ b/include/linux/dma-fence-array.h
> @@ -74,10 +74,18 @@ to_dma_fence_array(struct dma_fence *fence)
> return container_of(fence, struct dma_fence_array, base);
> }
>
> -struct dma_fence_array *dma_fence_array_create(int num_fences,
> -struct dma_fence **fences,
> -u64 context, unsigned seqno,
> -bool signal_on_any);
> +#define dma_fence_array_create(num, fences, context, seqno, any) ({ \
> + static struct lock_class_key __key; \
> + \
> + __dma_fence_array_create((num), (fences), (context), (seqno), (any), \
> + &__key); \
> +})
> +
> +struct dma_fence_array *__dma_fence_array_create(int num_fences,
> + struct dma_fence **fences,
> + u64 context, unsigned seqno,
> + bool signal_on_any,
> + struct lock_class_key *key);
>
> bool dma_fence_match_context(struct dma_fence *fence, u64 context);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for 5.3-rc6 (the second coming)
The pull request you sent on Sat, 24 Aug 2019 15:22:55 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-08-24 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/bc67b17eb91ea6a2b6d943bb64cde8d1438a11ec Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] video: hyperv: hyperv_fb: Support deferred IO for Hyper-V frame buffer driver
From: Wei Hu Sent: Wednesday, August 21, 2019 4:59 AM
>
> > From: Michael Kelley
> > Sent: Monday, August 19, 2019 6:41 AM
> > To: Wei Hu ; rdun...@infradead.org; shc_w...@mail.ru;
>
> > > - msg.dirt.rect[0].x1 = 0;
> > > - msg.dirt.rect[0].y1 = 0;
> > > - msg.dirt.rect[0].x2 = info->var.xres;
> > > - msg.dirt.rect[0].y2 = info->var.yres;
> > > + msg.dirt.rect[0].x1 = (x1 < 0 || x1 > x2) ? 0 : x1;
> > > + msg.dirt.rect[0].y1 = (y2 < 0 || y1 > y2) ? 0 : y1;
> >
> > This should be:
> >
> > msg.dirt.rect[0].y1 = (y1 < 0 || y1 > y2) ? 0 : y1;
> >
> > Also, throughout the code, I don't think there are any places where
> > x or y coordinate values are ever negative. INT_MAX or 0 is used as the
> > sentinel value indicating "not set". So can all the tests for less than 0
> > now be eliminated, both in this function and in other functions?
> >
> > > + msg.dirt.rect[0].x2 =
> > > + (x2 < x1 || x2 > info->var.xres) ? info->var.xres : x2;
> > > + msg.dirt.rect[0].y2 =
> > > + (y2 < y1 || y2 > info->var.yres) ? info->var.yres : y2;
> >
> > How exactly is the dirty rectangle specified to Hyper-V? Suppose the frame
> > buffer resolution is 100x200. If you want to specify the entire rectangle,
> > the
> > first coordinate is (0, 0). But what is the second coordinate? Should it
> > be
> > (99, 199) or (100, 200)? The above code (and original code) implies it
> > should specified as (100, 200), which is actually a point outside the
> > maximum resolution, which is counter-intuitive and makes me wonder
> > if the code is correct.
> >
> [Wei Hu]
> The current code treat the entire framebuffer rectangle as (0,0) ->
> (var.xres, var.yres).
> Every time it sends refresh request, these are two points sent to host and
> host
> seems accept it. See the above (x1, y1) and (x2, y2) in the deleted lines.
>
> So in your example the second coordinate is (100, 200).
OK, agreed. I ran some experiments and confirmed that this is indeed the
Hyper-V behavior.
>
>
> > > +/* Deferred IO callback */
> > > +static void synthvid_deferred_io(struct fb_info *p,
> > > + struct list_head *pagelist)
> > > +{
> > > + struct hvfb_par *par = p->par;
> > > + struct page *page;
> > > + unsigned long start, end;
> > > + int y1, y2, miny, maxy;
> > > + unsigned long flags;
> > > +
> > > + miny = INT_MAX;
> > > + maxy = 0;
> > > +
> > > + list_for_each_entry(page, pagelist, lru) {
> > > + start = page->index << PAGE_SHIFT;
> > > + end = start + PAGE_SIZE - 1;
> > > + y1 = start / p->fix.line_length;
> > > + y2 = end / p->fix.line_length;
> >
> > The above division rounds down because any remainder is discarded. I
> > wondered whether rounding down is correct, which got me to thinking
> > about how the dirty rectangle is specified. Is y2 the index of the last
> > dirty row? If so, that's not consistent with the code in synthvid_update(),
> > which might choose var.yres as y2, and that's the index of a row outside
> > of the frame buffer.
> >
> [Wei Hu]
> In this place we try to figure out and merge all the faulted pages into one
> big dirty rectangle. A page in memory represents one or multiple lines in
> frame buffer. For example, one faulted page could represent all the linear
> pixels from (x, y) to (x-1, y+1). In this case we just form the dirty
> rectangle
> as (0, y) -> (var.xres, y+1). Also keep in mind we need to merge multiple
> pages. That's why in the end the dirty rectangle is (0, miny) -> (var.xres,
> maxy).
Let me give an example of where I think the new code doesn't work. Suppose
the frame buffer resolution is 1024x768. With 4 bytes per pixel, each row
is 4096 bytes, or exactly one page. So each page contains exactly one row of
pixels. For simplicity in my example, let's look at the case when this function
is called with only one dirty page. The calculation of y1 will identify the
row
that is dirty. The calculation of y2 will identify the same row. So y1 will
equal y2, and miny will equal maxy. Then when synthvid_update() is called,
Hyper-V will interpret the parameters as no rows needing to be updated. In
a more complex case where the pagelist contains multiple dirty pages, maxy
also ends up one less than it needs to be.
I think passing 'maxy + 1' instead of 'maxy' to synthvid_update() will solve
the problem. It certainly warrants a comment that the calculation of maxy
is "inclusive", while synthvid_update() expects its parameters to be "exclusive"
per Hyper-V's expectations.
There's also another interesting situation. Suppose the resolution and page
size
is such that a page contains multiple rows. If the last page of the frame
buffer
is dirty, this routine could calculate a y2 value identifying a "phantom" row
that is off the end of the frame buffer -- i.e., that is bigger than yres. You
have synthvid_send() handling that case by clamping the y2 value to yres, but
it might be worth a comment here acknowledging the
Re: [PATCH v15 00/18] kunit: introduce KUnit, the Linux kernel unit testing framework
On 8/23/19 7:34 PM, Brendan Higgins wrote: ## TL;DR This revision addresses comments from Shuah by fixing a couple checkpatch warnings and fixing some comment readability issues. No API or major structual changes have been made since v13. ## Background This patch set proposes KUnit, a lightweight unit testing and mocking framework for the Linux kernel. Unlike Autotest and kselftest, KUnit is a true unit testing framework; it does not require installing the kernel on a test machine or in a VM (however, KUnit still allows you to run tests on test machines or in VMs if you want[1]) and does not require tests to be written in userspace running on a host kernel. Additionally, KUnit is fast: From invocation to completion KUnit can run several dozen tests in about a second. Currently, the entire KUnit test suite for KUnit runs in under a second from the initial invocation (build time excluded). KUnit is heavily inspired by JUnit, Python's unittest.mock, and Googletest/Googlemock for C++. KUnit provides facilities for defining unit test cases, grouping related test cases into test suites, providing common infrastructure for running tests, mocking, spying, and much more. ### What's so special about unit testing? A unit test is supposed to test a single unit of code in isolation, hence the name. There should be no dependencies outside the control of the test; this means no external dependencies, which makes tests orders of magnitudes faster. Likewise, since there are no external dependencies, there are no hoops to jump through to run the tests. Additionally, this makes unit tests deterministic: a failing unit test always indicates a problem. Finally, because unit tests necessarily have finer granularity, they are able to test all code paths easily solving the classic problem of difficulty in exercising error handling code. ### Is KUnit trying to replace other testing frameworks for the kernel? No. Most existing tests for the Linux kernel are end-to-end tests, which have their place. A well tested system has lots of unit tests, a reasonable number of integration tests, and some end-to-end tests. KUnit is just trying to address the unit test space which is currently not being addressed. ### More information on KUnit There is a bunch of documentation near the end of this patch set that describes how to use KUnit and best practices for writing unit tests. For convenience I am hosting the compiled docs here[2]. Additionally for convenience, I have applied these patches to a branch[3]. The repo may be cloned with: git clone https://kunit.googlesource.com/linux This patchset is on the kunit/rfc/v5.3/v15 branch. ## Changes Since Last Version - Moved comment from inline in macro to kernel-doc to address checkpatch warning. - Demoted BUG() to WARN_ON. - Formatted some kernel-doc comments to make them more readible. [1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kunit-on-non-uml-architectures [2] https://google.github.io/kunit-docs/third_party/kernel/docs/ [3] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.3/v15 Hi Brendan, Thanks for doing this work. Thanks for accommodating my request to improve the document/comment blocks in patch 01 and removing BUG() from patch 09. The comment block reads well now. Applied the series to linux-kselftest next for 5.4-rc1. thanks, -- Shuah
[Bug 111077] link_shader and deserialize_glsl_program suddenly consume huge amount of RAM
https://bugs.freedesktop.org/show_bug.cgi?id=111077 Matt Turner changed: What|Removed |Added CC||matts...@gmail.com --- Comment #18 from Matt Turner --- Cc'ing myself in case more help is needed bisecting. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] fbdev: fbmem: allow overriding the number of bootup logos
On Fri, Aug 23, 2019 at 08:47:47AM +, Peter Rosin wrote: > +++ b/drivers/video/fbdev/core/fbcon.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -56,6 +56,9 @@ EXPORT_SYMBOL(num_registered_fb); > bool fb_center_logo __read_mostly; > EXPORT_SYMBOL(fb_center_logo); > > +unsigned int fb_logo_count __read_mostly; > +EXPORT_SYMBOL(fb_logo_count); Why does this symbol need to be exported? As I read the Makefile, fbcon and fbmem are combined into the same module, so while the symbol needs to be non-static, it doesn't need to be exported to other modules.
Re: DRM_MODE_CONNECTOR_PANEL? [Was: drm/panel: Add and fill drm_panel type field]
Hi Sam, On Sat, Aug 24, 2019 at 11:54:21AM +0200, Sam Ravnborg wrote: > On Fri, Aug 23, 2019 at 10:32:44PM +0300, Laurent Pinchart wrote: > > Add a type field to the drm_panel structure to report the panel type, > > using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS, > > eDP, DSI and DPI). This will be used to initialise the corresponding > > connector type. > > As discussed on irc before applying this we should evaluate the > idea to introduce DRM_MODE_CONNECTOR_PANEL Thank you for bringing it up. > Today we have: > DRM_MODE_CONNECTOR_DPI > DRM_MODE_CONNECTOR_DBI > DRM_MODE_CONNECTOR_SPI > DRM_MODE_CONNECTOR_LVDS > > The question if what benefit ig gives to distingush between the > different ways panels are connected. > > For example for VGA and HDMI there is a physical connector involved so > here it make good sense. > But why should userspace care if the panel is connected via DPI or LVDS? > > The more generic DRM_MODE_CONNECTOR_PANEL would be equally descriptive. > > We will also start to see new drivers where there will be support > for more than one type of connector interface. > > Like for example ili9322: > - 8-bit serial RGB interface > - 24-bit parallel RGB interface > - 8-bit ITU-R BT.601 interface > - 8-bit ITU-R BT.656 interface > > Adding DRM_MODE_CONNECTOR_PANEL may create an xkcd 927 situation. > But we should then deprecate _DPI, _DBI, _SPI, _LVDS. _DBI doesn't exist, but we also have _eDP. The discussions originated from the fact that a number of drivers incorrectly report their connector type for panels today (including reporting DRM_MODE_CONNECTOR_Unknown), and they can't be fixed without a risk or breaking userspace, especially as the connector type is also used to name the connector (it would at least break command line mode setting as reported by Nicolas Ferre). It also makes it difficult for a driver to exhibit the right behaviour on new systems (that don't need to care about backward compatibility) without breaking the already supported systems. There were also recent discussions about adding a _DBI connector type, which will increase this mess. I pointed out in a few IRC discussions that I think the different connector types for panels were a mistake, and that we should have gone for DRM_MODE_CONNECTOR_PANEL in the first place. It's of course too late to fix this, but going forward, instead of introducing a _DBI connector type, I think we'd be much better off with _PANEL. > > Update all panel drivers accordingly. The panel-simple driver only > > specifies the type for the known to be LVDS panels, while all other > > panels are left as unknown and will be converted on a case-by-case > > basis as they all need to be carefully reviewed. > > > > Signed-off-by: Laurent Pinchart > > --- > > Changes since v1: > > > > - Rename the type field to connector_type > > - Pass the type to the drm_panel_init() function > > - Keep connector type as unknown for non-LVDS panels in panel-simple > > - Flag the toshiba_lt089ac29000 panel as LVDS as reported by Boris > > --- > > drivers/gpu/drm/drm_panel.c | 5 +++- > > drivers/gpu/drm/panel/panel-arm-versatile.c | 3 ++- > > .../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 ++- > > drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 ++- > > drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 ++- > > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 3 ++- > > .../gpu/drm/panel/panel-jdi-lt070me05000.c| 3 ++- > > .../drm/panel/panel-kingdisplay-kd097d04.c| 2 +- > > drivers/gpu/drm/panel/panel-lg-lb035q02.c | 3 ++- > > drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 ++- > > drivers/gpu/drm/panel/panel-lvds.c| 3 ++- > > drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 3 ++- > > drivers/gpu/drm/panel/panel-novatek-nt39016.c | 3 ++- > > .../drm/panel/panel-olimex-lcd-olinuxino.c| 3 ++- > > .../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 ++- > > .../drm/panel/panel-osd-osd101t2587-53ts.c| 2 +- > > .../drm/panel/panel-panasonic-vvx10f034n00.c | 2 +- > > .../drm/panel/panel-raspberrypi-touchscreen.c | 3 ++- > > drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 ++- > > drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 ++- > > .../drm/panel/panel-rocktech-jh057n00900.c| 3 ++- > > drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 ++- > > drivers/gpu/drm/panel/panel-samsung-ld9040.c | 3 ++- > > drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 3 ++- > > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 3 ++- > > .../gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 ++- > > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 3 ++- > > drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 3 ++- > > drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 3 ++- > > .../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 3 ++- > > .../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 3 ++- > > .../gpu/drm/panel/panel-sharp-ls043t1le01.c
[PATCH] dma-buf: Give dma-fence-array distinct lockclasses
In order to allow dma-fence-array as a generic container for fences, we
need to allow for it to contain other dma-fence-arrays. By giving each
dma-fence-array construction their own lockclass, we allow different
types of dma-fence-array to nest, but still do not allow on class of
dma-fence-array to contain itself (even though they have distinct
locks).
In practice, this means that each subsystem gets its own dma-fence-array
class and we can freely use dma-fence-arrays as containers within the
dmabuf core without angering lockdep.
Signed-off-by: Chris Wilson
Cc: Christian König
Cc: Daniel Vetter
---
drivers/dma-buf/dma-fence-array.c | 13 -
include/linux/dma-fence-array.h | 16
2 files changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/dma-fence-array.c
b/drivers/dma-buf/dma-fence-array.c
index d3fbd950be94..d9bcdbb66d46 100644
--- a/drivers/dma-buf/dma-fence-array.c
+++ b/drivers/dma-buf/dma-fence-array.c
@@ -147,10 +147,11 @@ EXPORT_SYMBOL(dma_fence_array_ops);
* If @signal_on_any is true the fence array signals if any fence in the array
* signals, otherwise it signals when all fences in the array signal.
*/
-struct dma_fence_array *dma_fence_array_create(int num_fences,
- struct dma_fence **fences,
- u64 context, unsigned seqno,
- bool signal_on_any)
+struct dma_fence_array *__dma_fence_array_create(int num_fences,
+struct dma_fence **fences,
+u64 context, unsigned seqno,
+bool signal_on_any,
+struct lock_class_key *key)
{
struct dma_fence_array *array;
size_t size = sizeof(*array);
@@ -162,6 +163,8 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
return NULL;
spin_lock_init(>lock);
+ lockdep_set_class(>lock, key);
+
dma_fence_init(>base, _fence_array_ops, >lock,
context, seqno);
init_irq_work(>work, irq_dma_fence_array_work);
@@ -174,7 +177,7 @@ struct dma_fence_array *dma_fence_array_create(int
num_fences,
return array;
}
-EXPORT_SYMBOL(dma_fence_array_create);
+EXPORT_SYMBOL(__dma_fence_array_create);
/**
* dma_fence_match_context - Check if all fences are from the given context
diff --git a/include/linux/dma-fence-array.h b/include/linux/dma-fence-array.h
index 303dd712220f..1395f9428cdb 100644
--- a/include/linux/dma-fence-array.h
+++ b/include/linux/dma-fence-array.h
@@ -74,10 +74,18 @@ to_dma_fence_array(struct dma_fence *fence)
return container_of(fence, struct dma_fence_array, base);
}
-struct dma_fence_array *dma_fence_array_create(int num_fences,
- struct dma_fence **fences,
- u64 context, unsigned seqno,
- bool signal_on_any);
+#define dma_fence_array_create(num, fences, context, seqno, any) ({ \
+ static struct lock_class_key __key; \
+ \
+ __dma_fence_array_create((num), (fences), (context), (seqno), (any), \
+&__key); \
+})
+
+struct dma_fence_array *__dma_fence_array_create(int num_fences,
+struct dma_fence **fences,
+u64 context, unsigned seqno,
+bool signal_on_any,
+struct lock_class_key *key);
bool dma_fence_match_context(struct dma_fence *fence, u64 context);
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] dma-buf: Extend selftests to exercise dma-fence-array
A preliminary set of tests to exercise the basic dma-fence API on top of
struct dma_fence_array.
Signed-off-by: Chris Wilson
---
drivers/dma-buf/Makefile | 3 +-
drivers/dma-buf/selftests.h | 1 +
drivers/dma-buf/st-dma-fence-array.c | 392 +++
3 files changed, 395 insertions(+), 1 deletion(-)
create mode 100644 drivers/dma-buf/st-dma-fence-array.c
diff --git a/drivers/dma-buf/Makefile b/drivers/dma-buf/Makefile
index 03479da06422..822fb65b14e4 100644
--- a/drivers/dma-buf/Makefile
+++ b/drivers/dma-buf/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_UDMABUF) += udmabuf.o
dmabuf_selftests-y := \
selftest.o \
- st-dma-fence.o
+ st-dma-fence.o \
+ st-dma-fence-array.o
obj-$(CONFIG_DMABUF_SELFTESTS) += dmabuf_selftests.o
diff --git a/drivers/dma-buf/selftests.h b/drivers/dma-buf/selftests.h
index 5320386f02e5..12241b2c03f2 100644
--- a/drivers/dma-buf/selftests.h
+++ b/drivers/dma-buf/selftests.h
@@ -11,3 +11,4 @@
*/
selftest(sanitycheck, __sanitycheck__) /* keep first (igt selfcheck) */
selftest(dma_fence, dma_fence)
+selftest(dma_fence_array, dma_fence_array)
diff --git a/drivers/dma-buf/st-dma-fence-array.c
b/drivers/dma-buf/st-dma-fence-array.c
new file mode 100644
index ..685a564a2826
--- /dev/null
+++ b/drivers/dma-buf/st-dma-fence-array.c
@@ -0,0 +1,392 @@
+/* SPDX-License-Identifier: MIT */
+
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "selftest.h"
+
+static struct kmem_cache *slab_fences;
+
+static struct mock_fence {
+ struct dma_fence base;
+ struct spinlock lock;
+} *to_mock_fence(struct dma_fence *f) {
+ return container_of(f, struct mock_fence, base);
+}
+
+static const char *mock_name(struct dma_fence *f)
+{
+ return "mock";
+}
+
+static void mock_fence_release(struct dma_fence *f)
+{
+ kmem_cache_free(slab_fences, to_mock_fence(f));
+}
+
+static const struct dma_fence_ops mock_ops = {
+ .get_driver_name = mock_name,
+ .get_timeline_name = mock_name,
+ .release = mock_fence_release,
+};
+
+static struct dma_fence *mock_fence(void *arg)
+{
+ struct mock_fence *f;
+
+ f = kmem_cache_alloc(slab_fences, GFP_KERNEL);
+ if (!f)
+ return NULL;
+
+ spin_lock_init(>lock);
+ dma_fence_init(>base, _ops, >lock, 0, 0);
+
+ return >base;
+}
+
+static struct dma_fence *stub_fence(void *arg)
+{
+ return dma_fence_get_stub();
+}
+
+static struct dma_fence *same_fence(void *arg)
+{
+ return dma_fence_get(arg);
+}
+
+static int empty(void *arg)
+{
+ struct dma_fence_array *arr;
+ int err = 0;
+
+ arr = dma_fence_array_create(0, NULL, 0, 0, false);
+ if (!arr)
+ return -ENOMEM;
+
+ if (!dma_fence_is_signaled(>base)) {
+ pr_err("Empty dma-fence-array is not signaled!\n");
+ err = -EINVAL;
+ }
+
+ dma_fence_put(>base);
+ return err;
+}
+
+static void free_fences(int count, struct dma_fence **fences)
+{
+ while (count--)
+ dma_fence_put(fences[count]);
+ kfree(fences);
+}
+
+static struct dma_fence **
+create_fences(int count, struct dma_fence *(*ctor)(void *arg), void *arg)
+{
+ struct dma_fence **fences;
+ int i;
+
+ fences = kmalloc_array(count, sizeof(*fences), GFP_KERNEL);
+ if (!fences)
+ return NULL;
+
+ for (i = 0; i < count; i++) {
+ fences[i] = ctor(arg);
+ if (!fences[i]) {
+ free_fences(i, fences);
+ return NULL;
+ }
+ }
+
+ return fences;
+}
+
+static int stub(void *arg)
+{
+ struct dma_fence_array *arr;
+ struct dma_fence **fences;
+ int err = 0;
+
+ fences = create_fences(1, stub_fence, NULL);
+ if (!fences)
+ return -ENOMEM;
+
+ arr = dma_fence_array_create(1, fences, 0, 0, false);
+ if (!arr) {
+ free_fences(1, fences);
+ return -ENOMEM;
+ }
+
+ dma_fence_enable_sw_signaling(>base);
+
+ if (!dma_fence_is_signaled(>base)) {
+ pr_err("dma-fence-array(stub) is not signaled!\n");
+ err = -EINVAL;
+ }
+
+ dma_fence_put(>base);
+ return err;
+}
+
+static int single(void *arg)
+{
+ struct dma_fence_array *arr;
+ struct dma_fence **fences;
+ int err = 0;
+
+ fences = create_fences(1, mock_fence, NULL);
+ if (!fences)
+ return -ENOMEM;
+
+ arr = dma_fence_array_create(1, fences, 0, 0, false);
+ if (!arr) {
+ free_fences(1, fences);
+ return -ENOMEM;
+ }
+
+ dma_fence_enable_sw_signaling(>base);
+
+ if (dma_fence_is_signaled(>base)) {
+ pr_err("dma-fence-array(single) is signaled upon
Re: [PATCH 08/10] dma-buf/resv: replace shared fence with new fences container
Quoting Christian König (2019-08-21 13:31:45)
> @@ -528,20 +352,9 @@ void dma_resv_prune_fences(struct dma_resv *obj)
> dma_fence_put(fence);
> }
>
> - list = dma_resv_get_list(obj);
> - if (!list)
> - return;
> -
> - for (i = 0; i < list->shared_count; ++i) {
> - fence = rcu_dereference_protected(list->shared[i],
> - dma_resv_held(obj));
> -
> - if (!dma_fence_is_signaled(fence))
> - continue;
> -
> - RCU_INIT_POINTER(list->shared[i], dma_fence_get_stub());
> - dma_fence_put(fence);
> - }
> + fence = dma_resv_fences_deref(obj, >readers);
> + if (dma_fence_is_signaled(fence))
> + dma_resv_fences_set(obj, >readers, NULL);
Something to note is that a dma-fence-array is not automatically
signaled and dma_fence_is_signaled() does not check the array.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111479] too much clutter
https://bugs.freedesktop.org/show_bug.cgi?id=111479 Andre Klapper changed: What|Removed |Added Component|General |Two Product|DRI |Spam Status|ASSIGNED|RESOLVED Group||spam Version|XOrg git|unspecified Resolution|--- |INVALID --- Comment #1 from Andre Klapper --- Go away and test somewhere else. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM_MODE_CONNECTOR_PANEL? [Was: drm/panel: Add and fill drm_panel type field]
Hi Laurent et all. On Fri, Aug 23, 2019 at 10:32:44PM +0300, Laurent Pinchart wrote: > Add a type field to the drm_panel structure to report the panel type, > using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS, > eDP, DSI and DPI). This will be used to initialise the corresponding > connector type. As discussed on irc before applying this we should evaluate the idea to introduce DRM_MODE_CONNECTOR_PANEL Today we have: DRM_MODE_CONNECTOR_DPI DRM_MODE_CONNECTOR_DBI DRM_MODE_CONNECTOR_SPI DRM_MODE_CONNECTOR_LVDS The question if what benefit ig gives to distingush between the different ways panels are connected. For example for VGA and HDMI there is a physical connector involved so here it make good sense. But why should userspace care if the panel is connected via DPI or LVDS? The more generic DRM_MODE_CONNECTOR_PANEL would be equally descriptive. We will also start to see new drivers where there will be support for more than one type of connector interface. Like for example ili9322: - 8-bit serial RGB interface - 24-bit parallel RGB interface - 8-bit ITU-R BT.601 interface - 8-bit ITU-R BT.656 interface Adding DRM_MODE_CONNECTOR_PANEL may create an xkcd 927 situation. But we should then deprecate _DPI, _DBI, _SPI, _LVDS. Sam > > Update all panel drivers accordingly. The panel-simple driver only > specifies the type for the known to be LVDS panels, while all other > panels are left as unknown and will be converted on a case-by-case > basis as they all need to be carefully reviewed. > > Signed-off-by: Laurent Pinchart > --- > Changes since v1: > > - Rename the type field to connector_type > - Pass the type to the drm_panel_init() function > - Keep connector type as unknown for non-LVDS panels in panel-simple > - Flag the toshiba_lt089ac29000 panel as LVDS as reported by Boris > --- > drivers/gpu/drm/drm_panel.c | 5 +++- > drivers/gpu/drm/panel/panel-arm-versatile.c | 3 ++- > .../drm/panel/panel-feiyang-fy07024di26a30d.c | 3 ++- > drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 3 ++- > drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 3 ++- > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 3 ++- > .../gpu/drm/panel/panel-jdi-lt070me05000.c| 3 ++- > .../drm/panel/panel-kingdisplay-kd097d04.c| 2 +- > drivers/gpu/drm/panel/panel-lg-lb035q02.c | 3 ++- > drivers/gpu/drm/panel/panel-lg-lg4573.c | 3 ++- > drivers/gpu/drm/panel/panel-lvds.c| 3 ++- > drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 3 ++- > drivers/gpu/drm/panel/panel-novatek-nt39016.c | 3 ++- > .../drm/panel/panel-olimex-lcd-olinuxino.c| 3 ++- > .../gpu/drm/panel/panel-orisetech-otm8009a.c | 3 ++- > .../drm/panel/panel-osd-osd101t2587-53ts.c| 2 +- > .../drm/panel/panel-panasonic-vvx10f034n00.c | 2 +- > .../drm/panel/panel-raspberrypi-touchscreen.c | 3 ++- > drivers/gpu/drm/panel/panel-raydium-rm67191.c | 3 ++- > drivers/gpu/drm/panel/panel-raydium-rm68200.c | 3 ++- > .../drm/panel/panel-rocktech-jh057n00900.c| 3 ++- > drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 3 ++- > drivers/gpu/drm/panel/panel-samsung-ld9040.c | 3 ++- > drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 3 ++- > drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 3 ++- > .../gpu/drm/panel/panel-samsung-s6e63j0x03.c | 3 ++- > drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 3 ++- > drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 3 ++- > drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 3 ++- > .../gpu/drm/panel/panel-sharp-lq101r1sx01.c | 3 ++- > .../gpu/drm/panel/panel-sharp-ls037v7dw01.c | 3 ++- > .../gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +- > drivers/gpu/drm/panel/panel-simple.c | 26 ++- > drivers/gpu/drm/panel/panel-sitronix-st7701.c | 3 ++- > .../gpu/drm/panel/panel-sitronix-st7789v.c| 3 ++- > drivers/gpu/drm/panel/panel-sony-acx565akm.c | 3 ++- > drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 3 ++- > drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 3 ++- > drivers/gpu/drm/panel/panel-tpo-tpg110.c | 3 ++- > drivers/gpu/drm/panel/panel-truly-nt35597.c | 3 ++- > include/drm/drm_panel.h | 12 - > 41 files changed, 112 insertions(+), 41 deletions(-) > > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c > index ba2fad4c9648..ed7985c0535a 100644 > --- a/drivers/gpu/drm/drm_panel.c > +++ b/drivers/gpu/drm/drm_panel.c > @@ -46,16 +46,19 @@ static LIST_HEAD(panel_list); > * @panel: DRM panel > * @dev: parent device of the panel > * @funcs: panel operations > + * @connector_type: the connector type (DRM_MODE_CONNECTOR_*) corresponding > to > + * the panel interface > * > * Initialize the panel structure for subsequent registration with > * drm_panel_add(). > */ > void drm_panel_init(struct drm_panel *panel, struct device *dev, > - const struct drm_panel_funcs
[Bug 204683] New: amdgpu: ring sdma0 timeout
https://bugzilla.kernel.org/show_bug.cgi?id=204683 Bug ID: 204683 Summary: amdgpu: ring sdma0 timeout Product: Drivers Version: 2.5 Kernel Version: 5.3.0-rc5 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: m...@familie-heinz.name Regression: No Hi, when playing some games I randomly (sometimes after 5 minutes, sometimes after 2 hours) get a blank screen, sometimes audio still works, sometimes the whole system locks up. I've seen this with Rise of the Tomb Raider and 7 Days to Die so far. I finally managed to sync the log files to disk to get an error, before whole thing locked up: Aug 24 11:13:33 egalite kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=368056, emitted seq=368057 Aug 24 11:13:33 egalite kernel: [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] *ERROR* [CRTC:47:crtc-0] flip_done timed out Aug 24 11:13:33 egalite kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process 7DaysToDie.x86_ pid 8108 thread 7DaysToDie:cs0 Aug 24 11:13:33 egalite kernel: amdgpu :0c:00.0: GPU reset begin! Aug 24 11:13:33 egalite kernel: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, but soft recovered Only a hard reset made me recover from that. This is with a self-built kernel 5.3.0-rc5. Also happens with 5.2.1. Mesa: 19.1.4-1 GPU: Vega 56 Best Matthias -- 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/4] drm/panel: Initialise panel dev and funcs through drm_panel_init()
On Fri, Aug 23, 2019 at 10:32:43PM +0300, Laurent Pinchart wrote:
> Instead of requiring all drivers to set the dev and funcs fields of
> drm_panel manually after calling drm_panel_init(), pass the data as
> arguments to the function. This simplifies the panel drivers, and will
> help future refactoring when adding new arguments to drm_panel_init().
>
> The panel drivers have been updated with the following Coccinelle
> semantic patch, with manual inspection to verify that no call to
> drm_panel_init() with a single argument still exists.
>
> @@
> expression panel;
> expression device;
> identifier ops;
> @@
> drm_panel_init(
> + , device,
> );
> ...
> (
> -panel.dev = device;
> -panel.funcs =
> |
> -panel.funcs =
> -panel.dev = device;
> )
>
> Suggested-by: Sam Ravnborg
> Signed-off-by: Laurent Pinchart
Thanks, applied to drm-misc-next.
Nice use of Coccinelle.
Sam
> ---
> drivers/gpu/drm/drm_panel.c | 11 ---
> drivers/gpu/drm/panel/panel-arm-versatile.c | 4 +---
> drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 4 +---
> drivers/gpu/drm/panel/panel-ilitek-ili9322.c | 4 +---
> drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 4 +---
> drivers/gpu/drm/panel/panel-innolux-p079zca.c | 4 +---
> drivers/gpu/drm/panel/panel-jdi-lt070me05000.c| 4 +---
> drivers/gpu/drm/panel/panel-kingdisplay-kd097d04.c| 5 ++---
> drivers/gpu/drm/panel/panel-lg-lb035q02.c | 4 +---
> drivers/gpu/drm/panel/panel-lg-lg4573.c | 4 +---
> drivers/gpu/drm/panel/panel-lvds.c| 4 +---
> drivers/gpu/drm/panel/panel-nec-nl8048hl11.c | 4 +---
> drivers/gpu/drm/panel/panel-novatek-nt39016.c | 4 +---
> drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.c| 4 +---
> drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 4 +---
> drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c| 5 ++---
> drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c | 5 ++---
> drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 4 +---
> drivers/gpu/drm/panel/panel-raydium-rm67191.c | 4 +---
> drivers/gpu/drm/panel/panel-raydium-rm68200.c | 4 +---
> drivers/gpu/drm/panel/panel-rocktech-jh057n00900.c| 4 +---
> drivers/gpu/drm/panel/panel-ronbo-rb070d30.c | 4 +---
> drivers/gpu/drm/panel/panel-samsung-ld9040.c | 4 +---
> drivers/gpu/drm/panel/panel-samsung-s6d16d0.c | 4 +---
> drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c | 4 +---
> drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 4 +---
> drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 4 +---
> drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c | 4 +---
> drivers/gpu/drm/panel/panel-seiko-43wvf1g.c | 4 +---
> drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 4 +---
> drivers/gpu/drm/panel/panel-sharp-ls037v7dw01.c | 4 +---
> drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 5 ++---
> drivers/gpu/drm/panel/panel-simple.c | 4 +---
> drivers/gpu/drm/panel/panel-sitronix-st7701.c | 4 +---
> drivers/gpu/drm/panel/panel-sitronix-st7789v.c| 4 +---
> drivers/gpu/drm/panel/panel-sony-acx565akm.c | 4 +---
> drivers/gpu/drm/panel/panel-tpo-td028ttec1.c | 4 +---
> drivers/gpu/drm/panel/panel-tpo-td043mtea1.c | 4 +---
> drivers/gpu/drm/panel/panel-tpo-tpg110.c | 4 +---
> drivers/gpu/drm/panel/panel-truly-nt35597.c | 4 +---
> include/drm/drm_panel.h | 3 ++-
> 41 files changed, 53 insertions(+), 121 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> index 6b0bf42039cf..ba2fad4c9648 100644
> --- a/drivers/gpu/drm/drm_panel.c
> +++ b/drivers/gpu/drm/drm_panel.c
> @@ -44,13 +44,18 @@ static LIST_HEAD(panel_list);
> /**
> * drm_panel_init - initialize a panel
> * @panel: DRM panel
> + * @dev: parent device of the panel
> + * @funcs: panel operations
> *
> - * Sets up internal fields of the panel so that it can subsequently be added
> - * to the registry.
> + * Initialize the panel structure for subsequent registration with
> + * drm_panel_add().
> */
> -void drm_panel_init(struct drm_panel *panel)
> +void drm_panel_init(struct drm_panel *panel, struct device *dev,
> + const struct drm_panel_funcs *funcs)
> {
> INIT_LIST_HEAD(>list);
> + panel->dev = dev;
> + panel->funcs = funcs;
> }
> EXPORT_SYMBOL(drm_panel_init);
>
> diff --git a/drivers/gpu/drm/panel/panel-arm-versatile.c
> b/drivers/gpu/drm/panel/panel-arm-versatile.c
> index 5f72c922a04b..a4333ed0f20c 100644
> --- a/drivers/gpu/drm/panel/panel-arm-versatile.c
> +++ b/drivers/gpu/drm/panel/panel-arm-versatile.c
> @@ -350,9 +350,7 @@ static int versatile_panel_probe(struct platform_device
> *pdev)
>
Re: [PATCH v2 1/4] drm/panel: Add missing drm_panel_init() in panel drivers
On Fri, Aug 23, 2019 at 10:32:42PM +0300, Laurent Pinchart wrote: > Panels must be initialised with drm_panel_init(). Add the missing > function call in the panel-raspberrypi-touchscreen.c and > panel-sitronix-st7789v.c drivers. > > Signed-off-by: Laurent Pinchart Thanks, good to have this done in the right way. This does not solve any know bugs visible to users. At least there are no reports I know off. So for now only applied to drm-misc-next. Sam > --- > drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c | 1 + > drivers/gpu/drm/panel/panel-sitronix-st7789v.c| 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c > b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c > index b5b14aa059ea..2aa89eaecf6f 100644 > --- a/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c > +++ b/drivers/gpu/drm/panel/panel-raspberrypi-touchscreen.c > @@ -426,6 +426,7 @@ static int rpi_touchscreen_probe(struct i2c_client *i2c, > return PTR_ERR(ts->dsi); > } > > + drm_panel_init(>base); > ts->base.dev = dev; > ts->base.funcs = _touchscreen_funcs; > > diff --git a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c > b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c > index 5e3e92ea9ea6..3b2612ae931e 100644 > --- a/drivers/gpu/drm/panel/panel-sitronix-st7789v.c > +++ b/drivers/gpu/drm/panel/panel-sitronix-st7789v.c > @@ -381,6 +381,7 @@ static int st7789v_probe(struct spi_device *spi) > spi_set_drvdata(spi, ctx); > ctx->spi = spi; > > + drm_panel_init(>panel); > ctx->panel.dev = >dev; > ctx->panel.funcs = _drm_funcs; > > -- > Regards, > > Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: next/master build: 218 builds: 4 failed, 214 passed, 10 errors, 786 warnings (next-20190823)
Hi Dave, On Sat, 24 Aug 2019 15:06:07 +1000 Dave Airlie wrote: > > I'll add the include anyways and send to Linus, Thanks. -- Cheers, Stephen Rothwell pgpY5ky1k5YC6.pgp Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
