[Bug 119631] RadeonSI get a huge performance dip with used with the nine state tracker
https://bugzilla.kernel.org/show_bug.cgi?id=119631 Vedran MiletiÄ changed: What|Removed |Added CC||vedran at miletic.net --- Comment #1 from Vedran MiletiÄ --- Compared to 4.6? Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390
https://bugs.freedesktop.org/show_bug.cgi?id=95247 --- Comment #5 from Sandeep --- Created attachment 124318 --> https://bugs.freedesktop.org/attachment.cgi?id=124318&action=edit Dmesg log - Linux 4.6 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160604/058d7ed6/attachment.html>
[Bug 96278] [amdgpu][tonga]Kernel Hung when starting X while detecting outputs
https://bugs.freedesktop.org/show_bug.cgi?id=96278 JohnDoe changed: What|Removed |Added Summary|Kernel Hung when starting X |[amdgpu][tonga]Kernel Hung |while detecting outputs |when starting X while ||detecting outputs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160604/aabc5f77/attachment.html>
[Bug 88458] The monitor turns off when playing starcraft 2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=88458 --- Comment #8 from Jaakko Niemi --- Definately maybe. I run: apitrace trace wine .wine/drive_c...path to sc.exe With few minutes running the game I get small file called "wine-preloader.trace", which is 270k, so I'm not sure if this is right. These days the game invokes in any case the battle.net.exe application from which game can be started. I'll do some more digging on this, but if anyone knows how to do this right (wine with modern blizzard games..), please let me know. Also let me know if the small trace file is interesting. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160604/02faf171/attachment-0001.html>
[Bug 96327] Assertion failure in radeon_drm_cs.c (Shadow of Mordor)
https://bugs.freedesktop.org/show_bug.cgi?id=96327 Jan Ziak <0xe2.0x9a.0x9b at gmail.com> changed: What|Removed |Added Assignee|dri-devel at lists.freedesktop |0xe2.0x9a.0x9b at gmail.com |.org| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160604/ac5c1404/attachment.html>
[Bug 119631] New: RadeonSI get a huge performance dip with used with the nine state tracker
https://bugzilla.kernel.org/show_bug.cgi?id=119631 Bug ID: 119631 Summary: RadeonSI get a huge performance dip with used with the nine state tracker Product: Drivers Version: 2.5 Kernel Version: 4.7-rc1 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: b747xx at gmail.com Regression: No Hi, I have a Radeon 7970HD and I use the Gallium Nine state tracker to play a specific game (EVE-Online). I did notice that the performance take a big dip when used with the kernel 4.7-next and -rc1. I did know about a regretion affecting some opengl game, that might and might not be related. Using the kernel 4.7, I lose about 1/3 to 2/3 of the fps depending of the situation. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] reservation: sprinkle some WARN_ON()s
On Thu, Apr 07, 2016 at 08:52:56PM -0400, Rob Clark wrote:
> A bit overkill since, for example, the rcu_dereference_protected() in
> reservation_object_get_list() will WARN. But this is much less subtle
> for folks reading the code.
>
> v2: use reservation_object_held() instead of ww_mutex_is_locked()
>
> Signed-off-by: Rob Clark
Doesn't seem to build here:
In file included from ./arch/arm/include/asm/bug.h:59:0,
from include/linux/bug.h:4,
from include/linux/thread_info.h:11,
from include/asm-generic/current.h:4,
from arch/arm/include/generated/asm/current.h:1,
from include/linux/mutex.h:13,
from include/linux/ww_mutex.h:17,
from include/linux/reservation.h:42,
from drivers/dma-buf/reservation.c:35:
drivers/dma-buf/reservation.c: In function
âreservation_object_reserve_sharedâ:
include/linux/reservation.h:82:38: error: implicit declaration of function
âlockdep_is_heldâ [-Werror=implicit-function-declaration]
#define reservation_object_held(obj) lockdep_is_held(&(obj)->lock.base)
^
include/asm-generic/bug.h:92:25: note: in definition of macro âWARN_ONâ
int __ret_warn_on = !!(condition);\
^
drivers/dma-buf/reservation.c:74:11: note: in expansion of macro
âreservation_object_heldâ
WARN_ON(!reservation_object_held(obj));
Sounds like we should include some headers from reservation.h.
-Daniel
> ---
> drivers/dma-buf/reservation.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
> index c0bd572..439af82 100644
> --- a/drivers/dma-buf/reservation.c
> +++ b/drivers/dma-buf/reservation.c
> @@ -52,6 +52,8 @@ int reservation_object_reserve_shared(struct
> reservation_object *obj)
> struct reservation_object_list *fobj, *old;
> u32 max;
>
> + WARN_ON(!reservation_object_held(obj));
> +
> old = reservation_object_get_list(obj);
>
> if (old && old->shared_max) {
> @@ -189,6 +191,8 @@ void reservation_object_add_shared_fence(struct
> reservation_object *obj,
> {
> struct reservation_object_list *old, *fobj = obj->staged;
>
> + WARN_ON(!reservation_object_held(obj));
> +
> old = reservation_object_get_list(obj);
> obj->staged = NULL;
>
> @@ -207,6 +211,8 @@ void reservation_object_add_excl_fence(struct
> reservation_object *obj,
> struct reservation_object_list *old;
> u32 i = 0;
>
> + WARN_ON(!reservation_object_held(obj));
> +
> old = reservation_object_get_list(obj);
> if (old)
> i = old->shared_count;
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 0/4] dma-buf/reservation doc updates
On Fri, Apr 01, 2016 at 08:50:32PM +0530, Sumit Semwal wrote: > Hi Rob, > > On 1 April 2016 at 19:37, Alex Deucher wrote: > > On Thu, Mar 31, 2016 at 4:26 PM, Rob Clark wrote: > >> Some dma-buf headerdoc fixes (turns out dma-buf.h wasn't getting pulled > >> into doc build), add reservation headerdoc, and fixup a bit the section > >> in device-drivers.tmpl. > >> > Thanks for catching these! I'll queue them up into my for-next in the next > week. Since they failed to show up in 4.7 I've pulled them into drm-misc now. Well except for patch 4, that one conflicts. And given that we'll have an ongoing docbook->sphinx conversion probably better to redo after that again. -Daniel > >> Rob Clark (4): > >> reservation: sprinkle some WARN_ON()s > >> dma-buf: headerdoc fixes > >> reservation: add headerdoc comments > >> doc: update/fixup dma-buf related DocBook > > > > For the series: > > Reviewed-by: Alex Deucher > > > >> > >> Documentation/DocBook/device-drivers.tmpl | 36 -- > >> drivers/dma-buf/reservation.c | 78 > >> +-- > >> include/linux/dma-buf.h | 13 -- > >> include/linux/reservation.h | 53 + > >> 4 files changed, 169 insertions(+), 11 deletions(-) > >> > >> -- > >> 2.5.5 > >> > >> ___ > >> dri-devel mailing list > >> dri-devel at lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel > > BR, > Sumit. > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH v2] drm/imx: use bus_flags for pixel clock polarity
On 2016-05-17 08:23, Philipp Zabel wrote:
> This patch allows panels to set pixel clock and data enable pin polarity
> other than the default of driving data at the falling pixel clock edge
> and active high display enable.
>
> Signed-off-by: Philipp Zabel
> ---
> Changes since v1:
> - Invert polarity - driving pixel data on the falling edge and sampling
>it at the rising edge is the default.
> - Rename imx_drm_set_bus_format_pins to imx_drm_set_bus_config as now,
>additionally to bus format and pins, it also sets polarities.
Looks good to me!
Reviewed-by: Stefan Agner
--
Stefan
> ---
> drivers/gpu/drm/imx/imx-drm-core.c | 13 -
> drivers/gpu/drm/imx/imx-drm.h | 7 ---
> drivers/gpu/drm/imx/imx-tve.c | 6 --
> drivers/gpu/drm/imx/ipuv3-crtc.c | 10 +++---
> drivers/gpu/drm/imx/parallel-display.c | 4 ++--
> 5 files changed, 25 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/imx/imx-drm-core.c
> b/drivers/gpu/drm/imx/imx-drm-core.c
> index e26dcde..1da77fd 100644
> --- a/drivers/gpu/drm/imx/imx-drm-core.c
> +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> @@ -96,8 +96,8 @@ static struct imx_drm_crtc *imx_drm_find_crtc(struct
> drm_crtc *crtc)
> return NULL;
> }
>
> -int imx_drm_set_bus_format_pins(struct drm_encoder *encoder, u32 bus_format,
> - int hsync_pin, int vsync_pin)
> +int imx_drm_set_bus_config(struct drm_encoder *encoder, u32 bus_format,
> + int hsync_pin, int vsync_pin, u32 bus_flags)
> {
> struct imx_drm_crtc_helper_funcs *helper;
> struct imx_drm_crtc *imx_crtc;
> @@ -109,14 +109,17 @@ int imx_drm_set_bus_format_pins(struct
> drm_encoder *encoder, u32 bus_format,
> helper = &imx_crtc->imx_drm_helper_funcs;
> if (helper->set_interface_pix_fmt)
> return helper->set_interface_pix_fmt(encoder->crtc,
> - bus_format, hsync_pin, vsync_pin);
> + bus_format, hsync_pin, vsync_pin,
> + bus_flags);
> return 0;
> }
> -EXPORT_SYMBOL_GPL(imx_drm_set_bus_format_pins);
> +EXPORT_SYMBOL_GPL(imx_drm_set_bus_config);
>
> int imx_drm_set_bus_format(struct drm_encoder *encoder, u32 bus_format)
> {
> - return imx_drm_set_bus_format_pins(encoder, bus_format, 2, 3);
> + return imx_drm_set_bus_config(encoder, bus_format, 2, 3,
> + DRM_BUS_FLAG_DE_HIGH |
> + DRM_BUS_FLAG_PIXDATA_NEGEDGE);
> }
> EXPORT_SYMBOL_GPL(imx_drm_set_bus_format);
>
> diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
> index b0241b9..74320a1 100644
> --- a/drivers/gpu/drm/imx/imx-drm.h
> +++ b/drivers/gpu/drm/imx/imx-drm.h
> @@ -19,7 +19,8 @@ struct imx_drm_crtc_helper_funcs {
> int (*enable_vblank)(struct drm_crtc *crtc);
> void (*disable_vblank)(struct drm_crtc *crtc);
> int (*set_interface_pix_fmt)(struct drm_crtc *crtc,
> - u32 bus_format, int hsync_pin, int vsync_pin);
> + u32 bus_format, int hsync_pin, int vsync_pin,
> + u32 bus_flags);
> const struct drm_crtc_helper_funcs *crtc_helper_funcs;
> const struct drm_crtc_funcs *crtc_funcs;
> };
> @@ -41,8 +42,8 @@ void imx_drm_mode_config_init(struct drm_device *drm);
>
> struct drm_gem_cma_object *imx_drm_fb_get_obj(struct drm_framebuffer *fb);
>
> -int imx_drm_set_bus_format_pins(struct drm_encoder *encoder,
> - u32 bus_format, int hsync_pin, int vsync_pin);
> +int imx_drm_set_bus_config(struct drm_encoder *encoder, u32 bus_format,
> + int hsync_pin, int vsync_pin, u32 bus_flags);
> int imx_drm_set_bus_format(struct drm_encoder *encoder,
> u32 bus_format);
>
> diff --git a/drivers/gpu/drm/imx/imx-tve.c b/drivers/gpu/drm/imx/imx-tve.c
> index ae7a9fb..baf7881 100644
> --- a/drivers/gpu/drm/imx/imx-tve.c
> +++ b/drivers/gpu/drm/imx/imx-tve.c
> @@ -294,8 +294,10 @@ static void imx_tve_encoder_prepare(struct
> drm_encoder *encoder)
>
> switch (tve->mode) {
> case TVE_MODE_VGA:
> - imx_drm_set_bus_format_pins(encoder, MEDIA_BUS_FMT_GBR888_1X24,
> - tve->hsync_pin, tve->vsync_pin);
> + imx_drm_set_bus_config(encoder, MEDIA_BUS_FMT_GBR888_1X24,
> +tve->hsync_pin, tve->vsync_pin,
> +DRM_BUS_FLAG_DE_HIGH |
> +DRM_BUS_FLAG_PIXDATA_NEGEDGE);
> break;
> case TVE_MODE_TVOUT:
> imx_drm_set_bus_format(encoder, MEDIA_BUS_FMT_YUV8_1X24);
> diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c
> b/drivers/gpu/drm/imx/ipuv3-crtc.c
> index dee8e8b..438e6c4 100644
> --- a/drivers/gpu/drm/imx/ipuv3-crtc.c
> +++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
> @@ -66,6 +66,7 @@ struct ipu_crtc {
> struct ipu
drm/vc4: NULL pointer dereference after failed to allocate buffer
Stefan Wahren writes: > Hi, > > i tried to boot 4.7.0-rc1-next-20160602 with bcm2835_defconfig on a Raspberry > Pi > B. > > Unfortunately it crashes with a NULL pointer dereference and many oops > following: > ... > [2.209373] vc4-drm soc:gpu: bound 20902000.hdmi (ops vc4_hdmi_ops) > [2.228303] vc4-drm soc:gpu: bound 20206000.pixelvalve (ops vc4_crtc_ops) > [2.247681] vc4-drm soc:gpu: bound 20207000.pixelvalve (ops vc4_crtc_ops) > [2.270300] vc4-drm soc:gpu: bound 20807000.pixelvalve (ops vc4_crtc_ops) > [2.288902] vc4-drm soc:gpu: bound 2040.hvs (ops vc4_hvs_ops) > [2.307006] vc4-drm soc:gpu: bound 20c0.v3d (ops vc4_v3d_ops) > [2.325069] fb: switching to vc4drmfb from simple > [2.341322] Console: switching to colour dummy device 80x30 > [2.350955] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > [2.357821] [drm] No driver support for vblank timestamp query. > [2.368495] mmc0: new SDHC card at address 1234 > [2.374284] mmcblk0: mmc0:1234 SA32G 29.3 GiB > [2.381213] mmcblk0: p1 p2 > [2.398018] vc4-drm soc:gpu: failed to allocate buffer with size 9216000 > [2.404912] Unable to handle kernel NULL pointer dereference at virtual > address > [2.413070] pgd = c0004000 > [2.415856] [] *pgd= > [2.419501] Internal error: Oops: 8005 [#1] ARM > [2.424425] CPU: 0 PID: 6 Comm: kworker/u2:0 Not tainted > 4.7.0-rc1-next-20160602+ #2 > [2.432214] Hardware name: BCM2835 > [2.435677] Workqueue: deferwq deferred_probe_work_func > [2.440948] task: cb8957c0 ti: cb8b2000 task.ti: cb8b2000 > [2.446378] PC is at 0x0 > [2.448953] LR is at drm_gem_cma_create+0xf0/0x108 Figure out where in drm_gem_cma_create() you are? -next kernels have been working for me on Pi 2s and 3s, and jumping to a NULL seems surprising for that function. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160604/10ec0f2c/attachment.sig>
[PATCH 1/4] drm/fb-helper: Support deferred setup
On Fri, Jun 03, 2016 at 06:11:16PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> FB helper code falls back to a 1024x768 mode if no outputs are connected
> or don't report back any modes upon initialization. This can be annoying
> because outputs that are added to FB helper later on can't be used with
> FB helper if they don't support a matching mode.
>
> The fallback is in place because VGA connectors can happen to report an
> unknown connection status even when they are in fact connected.
>
> Some drivers have custom solutions in place to defer FB helper setup
> until at least one output is connected. But the logic behind these
> solutions is always the same and there is nothing driver-specific about
> it, so a better alterative is to fix the FB helper core and add support
> for all drivers automatically.
>
> This patch adds support for deferred FB helper setup. It checks all the
> connectors for their connection status, and if all of them report to be
> disconnected marks the FB helper as needing deferred setup. Whet setup
> is deferred, the FB helper core will automatically retry setup after a
> hotplug event, and it will keep trying until it succeeds.
This might have been an alternative solution to the driver dependencies
I was experiencing with GPU switching on the MacBook Pro: The apple-gmux
module needs to be loaded on pre-retinas to switch DDC, and on retinas
the DRM driver for the active GPU needs to have set up the eDP output
so that the inactive GPU can use the pre-calibrated v-swing, pre-emph etc.
I tried something similar to this patch here first, falling back to
1024x786 if the dependencies weren't met, and then tearing down and
reinitializing the fbdev once all prerequisites were fulfilled.
This approach turned out to be too fragile so I settled on -EPROBE_DEFER,
which had the additional advantage of needing much less code.
I'm not sure if a hotplug signal is generated at all on older machines
with a plain vanilla VGA output. If that is not the case, this patch
here will cause a change of behaviour.
It also doesn't solve the issue that a display is unplugged and replaced
with a larger display. The fb resolution will stay the same. Ideally we
should tear down the fbdev if the last display using it is unplugged and
recreate it once something is plugged in again.
Best regards,
Lukas
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/drm_fb_helper.c | 36
> include/drm/drm_fb_helper.h | 21 +
> 2 files changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 7c2eb75db60f..4f334f9cab28 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -442,6 +442,9 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct
> drm_fb_helper *fb_helper)
> if (!drm_fbdev_emulation)
> return -ENODEV;
>
> + if (fb_helper->deferred_setup)
> + return 0;
> +
> drm_modeset_lock_all(dev);
> ret = restore_fbdev_mode(fb_helper);
>
> @@ -1398,6 +1401,23 @@ unlock:
> }
> EXPORT_SYMBOL(drm_fb_helper_pan_display);
>
> +static bool drm_fb_helper_maybe_connected(struct drm_fb_helper *helper)
> +{
> + bool connected = false;
> + unsigned int i;
> +
> + for (i = 0; i < helper->connector_count; i++) {
> + struct drm_fb_helper_connector *fb = helper->connector_info[i];
> +
> + if (fb->connector->status != connector_status_disconnected) {
> + connected = true;
> + break;
> + }
> + }
> +
> + return connected;
> +}
> +
> /*
> * Allocates the backing storage and sets up the fbdev info structure through
> * the ->fb_probe callback and then registers the fbdev and sets up the panic
> @@ -1499,6 +1519,17 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
> sizes.fb_height = min_t(u32, desired_mode->vdisplay +
> y, sizes.fb_height);
> }
>
> + /*
> + * If everything's disconnected, there's no use in attempting to set
> + * up fbdev.
> + */
> + if (!drm_fb_helper_maybe_connected(fb_helper)) {
> + DRM_INFO("No outputs connected, deferring setup\n");
> + fb_helper->preferred_bpp = preferred_bpp;
> + fb_helper->deferred_setup = true;
> + return 0;
> + }
> +
> if (crtc_count == 0 || sizes.fb_width == -1 || sizes.fb_height == -1) {
> /* hmm everyone went away - assume VGA cable just fell out
> and will come back later. */
> @@ -1539,6 +1570,7 @@ static int drm_fb_helper_single_fb_probe(struct
> drm_fb_helper *fb_helper,
>
> list_add(&fb_helper->kernel_fb_list, &kernel_fb_helper_list);
>
> + fb_helper->deferred_setup = false;
> return 0;
> }
>
> @@ -2237,6 +2269,10 @@ int drm_fb_helper_hotplug_event(struct drm_fb_
[PATCH] drm/fsl-dcu: use flat regmap cache
On Sat, Jun 4, 2016 at 3:51 AM, Stefan Agner wrote: > On 2016-06-03 16:00, Daniel Vetter wrote: >> On Fri, Jun 03, 2016 at 03:43:19PM -0700, Stefan Agner wrote: >>> Using flat regmap cache instead of RB-tree to avoid the following >>> lockdep warning on driver load: >>> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755 >>> lockdep_trace_alloc+0x15c/0x160() >>> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) >>> >>> The RB-tree regmap cache needs to allocate new space on first >>> writes. However, allocations in an atomic context (e.g. when a >>> spinlock is held) are not allowed. The function regmap_write >>> calls map->lock, which acquires a spinlock in the fast_io case. >>> Since the FSL DCU driver uses MMIO, the regmap bus of type >>> regmap_mmio is being used which has fast_io set to true. >>> >>> Use flat regmap cache and specify max register to be large >>> enouth to cover all registers available in LS1021a and Vybrids >>> register space. >>> >>> Signed-off-by: Stefan Agner >>> Cc: Mark Brown >>> Cc: stable at vger.kernel.org >>> --- >>> While regmap cache is used for suspend/resume only (which is >>> broken in its current state) Mark noted that using the RB regmap >>> cache can also cause issues during initialization of the driver. >>> This patch migrates to flat regmap cache (which we can also use >>> to fix the issue in stable kernels), and yet another patchset >>> moves to the atomic suspend/resume helpers (which will not go >>> into stable...) >> >> While talking suspend/resume, I highly recommend >> drm_atomic_helper_suspend and drm_atomic_helper_resume. In my experience >> dumb safe/restore of registers for restoring modeset state leads to tears. >> -Daniel > > Since you commented to the patchset implementing exactly that I assume > you have seen it. Yup, that was pretty awesome coincidence ;-) > I still would like to have this patch applied to fix the regmap cache > warning also for older kernels. Sure, this was just a quick comment on your remark that there's still trouble left with suspend/resume. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] reservation: sprinkle some WARN_ON()s
On Sat, Jun 4, 2016 at 8:52 AM, Daniel Vetter wrote:
> On Thu, Apr 07, 2016 at 08:52:56PM -0400, Rob Clark wrote:
>> A bit overkill since, for example, the rcu_dereference_protected() in
>> reservation_object_get_list() will WARN. But this is much less subtle
>> for folks reading the code.
>>
>> v2: use reservation_object_held() instead of ww_mutex_is_locked()
>>
>> Signed-off-by: Rob Clark
>
> Doesn't seem to build here:
>
>
> In file included from ./arch/arm/include/asm/bug.h:59:0,
> from include/linux/bug.h:4,
> from include/linux/thread_info.h:11,
> from include/asm-generic/current.h:4,
> from arch/arm/include/generated/asm/current.h:1,
> from include/linux/mutex.h:13,
> from include/linux/ww_mutex.h:17,
> from include/linux/reservation.h:42,
> from drivers/dma-buf/reservation.c:35:
> drivers/dma-buf/reservation.c: In function
> âreservation_object_reserve_sharedâ:
> include/linux/reservation.h:82:38: error: implicit declaration of function
> âlockdep_is_heldâ [-Werror=implicit-function-declaration]
> #define reservation_object_held(obj) lockdep_is_held(&(obj)->lock.base)
> ^
> include/asm-generic/bug.h:92:25: note: in definition of macro âWARN_ONâ
> int __ret_warn_on = !!(condition);\
> ^
> drivers/dma-buf/reservation.c:74:11: note: in expansion of macro
> âreservation_object_heldâ
> WARN_ON(!reservation_object_held(obj));
>
> Sounds like we should include some headers from reservation.h.
Sumit hit something similar.. not sure if he figured out the problem.
But seemed to only work if lockdep was enabled, iirc? It is probably
true that I didn't try building without lockdep.. although I don't
remember kbuild robot complaining. I'm a bit confused since
reservation_object_held() was used before.
Hmm, on second thought, without lockdep, rcu_lockdep_assert() macro is
a no-op, so the use of reservation_object_held() goes away.. :-/
Maybe we should just go back to earlier version of the patch which
used mutex_is_locked() instead?
BR,
-R
> -Daniel
>
>> ---
>> drivers/dma-buf/reservation.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
>> index c0bd572..439af82 100644
>> --- a/drivers/dma-buf/reservation.c
>> +++ b/drivers/dma-buf/reservation.c
>> @@ -52,6 +52,8 @@ int reservation_object_reserve_shared(struct
>> reservation_object *obj)
>> struct reservation_object_list *fobj, *old;
>> u32 max;
>>
>> + WARN_ON(!reservation_object_held(obj));
>> +
>> old = reservation_object_get_list(obj);
>>
>> if (old && old->shared_max) {
>> @@ -189,6 +191,8 @@ void reservation_object_add_shared_fence(struct
>> reservation_object *obj,
>> {
>> struct reservation_object_list *old, *fobj = obj->staged;
>>
>> + WARN_ON(!reservation_object_held(obj));
>> +
>> old = reservation_object_get_list(obj);
>> obj->staged = NULL;
>>
>> @@ -207,6 +211,8 @@ void reservation_object_add_excl_fence(struct
>> reservation_object *obj,
>> struct reservation_object_list *old;
>> u32 i = 0;
>>
>> + WARN_ON(!reservation_object_held(obj));
>> +
>> old = reservation_object_get_list(obj);
>> if (old)
>> i = old->shared_count;
>> --
>> 2.5.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
[Bug 95527] [radeonsi][CIK][VDPAU] Unable to use VDPAU locks up X
https://bugs.freedesktop.org/show_bug.cgi?id=95527 Shawn Starr changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #5 from Shawn Starr --- This appears fixed with latest mesa git master and agd5f's drm-next-wip-4.8 branch, either way, vlc is not hanging anymore, nor libreoffice. With that, closing this bug. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160604/7e27e4ed/attachment-0001.html>
[PATCH v2] drm: Add Grain Media GM12U320 kms driver
On Fri, Jun 03, 2016 at 07:58:57PM +0200, Hans de Goede wrote:
> Hi,
>
> Thanks for the review!
>
> On 03-06-16 19:27, Thierry Reding wrote:
> > On Fri, Jun 03, 2016 at 03:06:32PM +0200, Hans de Goede wrote:
> > > Grain-media GM12U320 based devices are mini video projectors using USB for
> > > both power and video data transport.
> > >
> > > This commit adds a kms driver for these devices, including prime support.
> > >
> > > This driver is based on the existing udl kms driver, and the gm12u320
> > > fb driver by Viacheslav Nurmekhamitov .
> > >
> > > Signed-off-by: Hans de Goede
> > > ---
> > > Changes in v2:
> > > -Rebase on 4.7-rc1
> > > -Sync with udl, bring in any fixes done to udl since v1
> >
> > This sounds a little nightmarish in the long term. From a cursory look
> > this duplicates a bunch of code that's present in UDL, where the main
> > differences are EDID handling and data transfer. I wonder if we can't
> > find a better way of reusing code than duplicating it.
>
> I was planning on eventually moving the shared code to some kms-usb helper
> lib, I was thinking it would be good to have more then one user first,
> but if people prefer me first factoring out some code from udl into
> a lib I can do that instead.
Yeah I think waiting for more usb drivers is probably better. I don't want
to resurrect all the drm_bus mistakes once more, we're still working to
get rid of them all.
The other bit: Can I haz this in atomic, plz?
And when you look at atomic, it would probably be worth it to check out
Noralf's drm_simple_display_pipe helpers. They're made exactly for dumb
devices like this one here. It would cut out a lof of code.
The one thing you might need on top of Noralf's patches is some
super-simple support for cursors. That should be easy to add though.
-Daniel
>
> > > diff --git a/drivers/gpu/drm/gm12u320/gm12u320_connector.c
> > > b/drivers/gpu/drm/gm12u320/gm12u320_connector.c
> > [...]
> > > +/*
> > > + * Note this assumes this driver is only ever used with the Acer C120,
> > > if we
> > > + * add support for other devices the vendor and model should be
> > > parameterized.
> > > + */
> > > +static struct edid gm12u320_edid = {
> > > + .header = { 0x00, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0x00 },
> > > + .mfg_id = { 0x04, 0x72 }, /* "ACR" */
> > > + .prod_code = { 0x20, 0xc1 }, /* C120h */
> > > + .mfg_week = 1,
> > > + .mfg_year = 1,
> > > + .version= 1,/* EDID 1.3 */
> > > + .revision = 3,/* EDID 1.3 */
> > > + .input = 0x80, /* Digital input */
> > > + .features = 0x02, /* Pref timing in DTD 1 */
> > > + .standard_timings = { { 1, 1 }, { 1, 1 }, { 1, 1 }, { 1, 1 },
> > > + { 1, 1 }, { 1, 1 }, { 1, 1 }, { 1, 1 } },
> > > + .detailed_timings = { {
> > > + .pixel_clock = 3383,
> > > + /* hactive = 852, hblank = 256 */
> > > + .data.pixel_data.hactive_lo = 0x54,
> > > + .data.pixel_data.hblank_lo = 0x00,
> > > + .data.pixel_data.hactive_hblank_hi = 0x31,
> > > + /* vactive = 480, vblank = 28 */
> > > + .data.pixel_data.vactive_lo = 0xe0,
> > > + .data.pixel_data.vblank_lo = 0x1c,
> > > + .data.pixel_data.vactive_vblank_hi = 0x10,
> > > + /* hsync offset 40 pw 128, vsync offset 1 pw 4 */
> > > + .data.pixel_data.hsync_offset_lo = 0x28,
> > > + .data.pixel_data.hsync_pulse_width_lo = 0x80,
> > > + .data.pixel_data.vsync_offset_pulse_width_lo = 0x14,
> > > + .data.pixel_data.hsync_vsync_offset_pulse_width_hi = 0x00,
> > > + /* Digital separate syncs, hsync+, vsync+ */
> > > + .data.pixel_data.misc = 0x1e,
> > > + }, {
> > > + .pixel_clock = 0,
> > > + .data.other_data.type = 0xfd, /* Monitor ranges */
> > > + .data.other_data.data.range.min_vfreq = 59,
> > > + .data.other_data.data.range.max_vfreq = 61,
> > > + .data.other_data.data.range.min_hfreq_khz = 29,
> > > + .data.other_data.data.range.max_hfreq_khz = 32,
> > > + .data.other_data.data.range.pixel_clock_mhz = 4, /* 40 MHz */
> > > + .data.other_data.data.range.flags = 0,
> > > + .data.other_data.data.range.formula.cvt = {
> > > + 0xa0, 0x20, 0x20, 0x20, 0x20, 0x20, 0x20 },
> > > + }, {
> > > + .pixel_clock = 0,
> > > + .data.other_data.type = 0xfc, /* Model string */
> > > + .data.other_data.data.str.str = {
> > > + 'C', '1', '2', '0', 'P', 'r', 'o', 'j', 'e', 'c',
> > > + 't', 'o', 'r' },
> > > + }, {
> > > + .pixel_clock = 0,
> > > + .data.other_data.type = 0xfe, /* Unspecified text / padding */
> > > + .data.other_data.data.str.str = {
> > > + '\n', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ',
> > > + ' ', ' ', ' ' },
> > > + } },
[PATCH v2 5/6] drm/fsl-dcu: implement suspend/resume using atomic helpers
On Fri, Jun 03, 2016 at 03:56:43PM -0700, Stefan Agner wrote:
> Use the drm_atomic_helper_suspend() and drm_atomic_helper_resume()
> helpers to implement subsystem-level suspend/resume. This replaces
> the (non-functional) regmap cache based suspend resume functionality.
>
> Signed-off-by: Stefan Agner
> ---
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 40
> ++-
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h | 1 +
> 2 files changed, 35 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index 06a4d01..2bc4fa2 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -22,6 +23,7 @@
> #include
>
> #include
> +#include
> #include
> #include
> #include
> @@ -42,10 +44,8 @@ static const struct regmap_config fsl_dcu_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> .val_bits = 32,
> - .cache_type = REGCACHE_FLAT,
>
> .volatile_reg = fsl_dcu_drm_is_volatile_reg,
> - .max_register = 0x11fc,
> };
>
> static int fsl_dcu_drm_irq_init(struct drm_device *dev)
> @@ -229,9 +229,25 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
> if (!fsl_dev)
> return 0;
>
> + disable_irq(fsl_dev->irq);
> drm_kms_helper_poll_disable(fsl_dev->drm);
> - regcache_cache_only(fsl_dev->regmap, true);
> - regcache_mark_dirty(fsl_dev->regmap);
> +
> + console_lock();
> + drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
> + console_unlock();
Hm, it would be nice to push that console_lock into the helper itself.
Plus maybe reuse the trick i915 uses to put the resume side into a work
item to avoid taking console_lock in a blocking way.
The reason for that is that in a normal suspend/resume operation
console_lock is highly contended due to all the prinkt noise flying
around. If someone disabled fbdev emulation (either in Kconfig or at
runtime) we really, really want to avoid taking it. And without fbdev
there's no need to call fb_set_suspend at all.
Signed up for that little bit of polish? Imo totally ok as a follow-up,
but would be real nice to have.
-Daniel
> +
> + fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
> + if (IS_ERR(fsl_dev->state)) {
> + console_lock();
> + drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
> + console_unlock();
> +
> + drm_kms_helper_poll_enable(fsl_dev->drm);
> + enable_irq(fsl_dev->irq);
> + return PTR_ERR(fsl_dev->state);
> + }
> +
> + clk_disable_unprepare(fsl_dev->pix_clk);
> clk_disable_unprepare(fsl_dev->clk);
>
> return 0;
> @@ -251,9 +267,21 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
> return ret;
> }
>
> + ret = clk_prepare_enable(fsl_dev->pix_clk);
> + if (ret < 0) {
> + dev_err(dev, "failed to enable pix clk\n");
> + return ret;
> + }
> +
> + fsl_dcu_drm_init_planes(fsl_dev->drm);
> + drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
> +
> + console_lock();
> + drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
> + console_unlock();
> +
> drm_kms_helper_poll_enable(fsl_dev->drm);
> - regcache_cache_only(fsl_dev->regmap, false);
> - regcache_sync(fsl_dev->regmap);
> + enable_irq(fsl_dev->irq);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> index b1bba3a..3b371fe7 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> @@ -194,6 +194,7 @@ struct fsl_dcu_drm_device {
> struct drm_encoder encoder;
> struct fsl_dcu_drm_connector connector;
> const struct fsl_dcu_soc_data *soc;
> + struct drm_atomic_state *state;
> };
>
> void fsl_dcu_fbdev_init(struct drm_device *dev);
> --
> 2.8.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH v2 1/6] drm/fb_cma_helper: add suspend helper
On Fri, Jun 03, 2016 at 03:56:39PM -0700, Stefan Agner wrote:
> Implement a suspend/resume helper for CMA users which calls
> drm_fb_helper_set_suspend.
>
> Suggested-by: Thierry Reding
> Signed-off-by: Stefan Agner
Acked-by: Daniel Vetter
... for merging through fsl-du tree. Just add a small note about it in
your pull request.
-Daniel
> ---
> drivers/gpu/drm/drm_fb_cma_helper.c | 15 +++
> include/drm/drm_fb_cma_helper.h | 1 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c
> index 172cafe..6948d82 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -582,3 +582,18 @@ void drm_fbdev_cma_hotplug_event(struct drm_fbdev_cma
> *fbdev_cma)
> drm_fb_helper_hotplug_event(&fbdev_cma->fb_helper);
> }
> EXPORT_SYMBOL_GPL(drm_fbdev_cma_hotplug_event);
> +
> +/**
> + * drm_fbdev_cma_set_suspend - wrapper around drm_fb_helper_set_suspend
> + * @fbdev_cma: The drm_fbdev_cma struct, may be NULL
> + * @state: desired state, zero to resume, non-zero to suspend
> + *
> + * Calls drm_fb_helper_set_suspend, which is a wrapper around
> + * fb_set_suspend implemented by fbdev core.
> + */
> +void drm_fbdev_cma_set_suspend(struct drm_fbdev_cma *fbdev_cma, int state)
> +{
> + if (fbdev_cma)
> + drm_fb_helper_set_suspend(&fbdev_cma->fb_helper, state);
> +}
> +EXPORT_SYMBOL(drm_fbdev_cma_set_suspend);
> diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
> index fd0dde9..f313211 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -23,6 +23,7 @@ void drm_fbdev_cma_fini(struct drm_fbdev_cma *fbdev_cma);
>
> void drm_fbdev_cma_restore_mode(struct drm_fbdev_cma *fbdev_cma);
> void drm_fbdev_cma_hotplug_event(struct drm_fbdev_cma *fbdev_cma);
> +void drm_fbdev_cma_set_suspend(struct drm_fbdev_cma *fbdev_cma, int state);
> int drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size *sizes,
> const struct drm_framebuffer_funcs *funcs);
> --
> 2.8.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH] drm/fsl-dcu: use flat regmap cache
On Fri, Jun 03, 2016 at 03:43:19PM -0700, Stefan Agner wrote:
> Using flat regmap cache instead of RB-tree to avoid the following
> lockdep warning on driver load:
> WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755
> lockdep_trace_alloc+0x15c/0x160()
> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>
> The RB-tree regmap cache needs to allocate new space on first
> writes. However, allocations in an atomic context (e.g. when a
> spinlock is held) are not allowed. The function regmap_write
> calls map->lock, which acquires a spinlock in the fast_io case.
> Since the FSL DCU driver uses MMIO, the regmap bus of type
> regmap_mmio is being used which has fast_io set to true.
>
> Use flat regmap cache and specify max register to be large
> enouth to cover all registers available in LS1021a and Vybrids
> register space.
>
> Signed-off-by: Stefan Agner
> Cc: Mark Brown
> Cc: stable at vger.kernel.org
> ---
> While regmap cache is used for suspend/resume only (which is
> broken in its current state) Mark noted that using the RB regmap
> cache can also cause issues during initialization of the driver.
> This patch migrates to flat regmap cache (which we can also use
> to fix the issue in stable kernels), and yet another patchset
> moves to the atomic suspend/resume helpers (which will not go
> into stable...)
While talking suspend/resume, I highly recommend
drm_atomic_helper_suspend and drm_atomic_helper_resume. In my experience
dumb safe/restore of registers for restoring modeset state leads to tears.
-Daniel
>
> Dave, I saw that you just sent out the pull for rc2, will send
> a pull request for rc3 early next week...
>
> --
> Stefan
>
> drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> index 0ec1ad9..dc723f7 100644
> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> @@ -42,9 +42,10 @@ static const struct regmap_config fsl_dcu_regmap_config = {
> .reg_bits = 32,
> .reg_stride = 4,
> .val_bits = 32,
> - .cache_type = REGCACHE_RBTREE,
> + .cache_type = REGCACHE_FLAT,
>
> .volatile_reg = fsl_dcu_drm_is_volatile_reg,
> + .max_register = 0x11fc,
> };
>
> static int fsl_dcu_drm_irq_init(struct drm_device *dev)
> --
> 2.8.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
