[PATCH] drm: Fix deadlock retry loop in page_flip_ioctl
I failed to properly onion-wrap the unwind code: We acquire the vblank
reference before we start with the wait-wound locking dance, hence we
must make sure we retry before we drop the reference. Oops.
Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl")
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Reported-by: Tommi Rantala
Cc: Tommi Rantala
Cc: Michel Dänzer
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index fedd4d60d9cd..24c8a611b98a 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -948,6 +948,11 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
out:
+ if (ret == -EDEADLK) {
+ drm_modeset_backoff(&ctx);
+ goto retry;
+ }
+
if (ret && crtc->funcs->page_flip_target)
drm_crtc_vblank_put(crtc);
if (fb)
@@ -956,11 +961,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
drm_framebuffer_put(crtc->primary->old_fb);
crtc->primary->old_fb = NULL;
- if (ret == -EDEADLK) {
- drm_modeset_backoff(&ctx);
- goto retry;
- }
-
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)
On Thu, May 18, 2017 at 07:43:51PM +0300, Tommi Rantala wrote: > 2017-05-11 5:51 GMT+03:00 Michel Dänzer : > > On 11/05/17 04:33 AM, Tommi Rantala wrote: > >> Complete kernel log: > >> http://termbin.com/dzy5 > >> > >> [ 249.952546] [ cut here ] > >> [ 249.952593] WARNING: CPU: 5 PID: 0 at > >> /home/ttrantal/git/linux/drivers/gpu/drm/drm_irq.c:1195 > >> drm_vblank_put+0xc4/0x120 [drm] > >> [ 249.952596] Modules linked in: fuse tun bridge stp llc af_packet > >> pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu hid_generic > >> uhci_hcd radeon 3c59x mii tg3 ehci_pci ehci_hcd i2c_algo_bit > >> drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm > >> agpgart unix autofs4 > >> [ 249.952675] CPU: 5 PID: 0 Comm: swapper/5 Tainted: GW > >> 4.11.0+ #4 > >> [ 249.952678] Hardware name: Hewlett-Packard HP xw6600 > >> Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012 > >> [ 249.952681] task: 88080aea task.stack: c900031b > >> [ 249.952695] RIP: 0010:drm_vblank_put+0xc4/0x120 [drm] > >> [ 249.952698] RSP: 0018:88080f003d70 EFLAGS: 00010046 > >> [ 249.952703] RAX: RBX: 880801d53000 RCX: > >> > >> [ 249.952706] RDX: RSI: RDI: > >> 88080a4ac000 > >> [ 249.952709] RBP: 88080f003d88 R08: 0001 R09: > >> 0003 > >> [ 249.952711] R10: 88080f003d08 R11: 001da540 R12: > >> 88080a4ac000 > >> [ 249.952714] R13: R14: 0086 R15: > >> 8808019a > >> [ 249.952717] FS: () GS:88080f00() > >> knlGS: > >> [ 249.952720] CS: 0010 DS: ES: CR0: 80050033 > >> [ 249.952723] CR2: 7f8bcc3a5810 CR3: 000808789000 CR4: > >> 06e0 > >> [ 249.952726] Call Trace: > >> [ 249.952731] > >> [ 249.952746] drm_crtc_vblank_put+0x1b/0x30 [drm] > >> [ 249.952813] radeon_crtc_handle_flip+0xdc/0x140 [radeon] > >> [ 249.952843] si_irq_process+0x610/0x1e90 [radeon] > >> [ 249.952872] radeon_driver_irq_handler_kms+0x39/0xc0 [radeon] > >> [ 249.952881] __handle_irq_event_percpu+0x60/0x580 > >> [ 249.952887] handle_irq_event_percpu+0x20/0x90 > >> [ 249.952892] handle_irq_event+0x46/0xb0 > >> [ 249.952897] handle_edge_irq+0x13d/0x370 > >> [ 249.952903] handle_irq+0x66/0x210 > >> [ 249.952908] ? __local_bh_enable+0x34/0x50 > >> [ 249.952914] do_IRQ+0x7e/0x1b0 > >> [ 249.952920] common_interrupt+0x95/0x95 > > > > Weird, not sure how this could happen. Can you bisect? > > Hi, > > Bisection points to this (also manually applied commit 9739e74646 > while testing, got kernel oops otherwise): > > commit 29dc0d1de18239cf3ef8bab578b8321ed340d81c > Author: Daniel Vetter > Date: Wed Mar 22 22:50:49 2017 +0100 > > drm: Roll out acquire context for the page_flip ioctl > > Again just prep work. > > Reviewed-by: Harry Wentland > Signed-off-by: Daniel Vetter > Link: > http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-11-daniel.vet...@ffwll.ch > > > I'm also seeing some more warnings in this version: Yeah I think the locking stuff we've fixed, at least if you don't see it in 4.12 it should be all good. And I think I spotted the bug you've bisected to, patch is on dri-devel, pls test. Thanks for the bug report. -Daniel > > > May 18 19:21:55 xw6600 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp14s0: > link becomes ready > May 18 19:21:57 xw6600 kernel: [ cut here ] > May 18 19:21:57 xw6600 kernel: WARNING: CPU: 5 PID: 4607 at > /home/ttrantal/git/linux/drivers/gpu/drm/drm_modeset_lock.c:193 > drm_modeset_lock_crtc+0xe5/0x100 [drm] > May 18 19:21:57 xw6600 kernel: Modules linked in: tun bridge stp llc > af_packet pl2303 usbserial shpchp acpi_cpufreq binfmt_misc amdgpu > hid_generic uhci_hcd radeon 3c59x mii i2c_algo_bit drm_kms_helper tg3 > syscopyarea sysfillrect sysimgblt > May 18 19:21:57 xw6600 kernel: CPU: 5 PID: 4607 Comm: gnome-shell Not > tainted 4.11.0-rc3-00944-g29dc0d1-dirty #30 > May 18 19:21:57 xw6600 kernel: Hardware name: Hewlett-Packard HP > xw6600 Workstation/0A9Ch, BIOS 786F4 v01.46 09/20/2012 > May 18 19:21:57 xw6600 kernel: Call Trace: > May 18 19:21:57 xw6600 kernel: dump_stack+0x69/0x9b > May 18 19:21:57 xw6600 kernel: __warn+0xff/0x140 > May 18 19:21:57 xw6600 kernel: warn_slowpath_null+0x18/0x20 > May 18 19:21:57 xw6600 kernel: drm_modeset_lock_crtc+0xe5/0x100 [drm] > May 18 19:21:57 xw6600 kernel: drm_mode_cursor_common+0xbd/0x200 [drm] > May 18 19:21:57 xw6600 kernel: drm_mode_cursor_ioctl+0x3c/0x40 [drm] > May 18 19:21:57 xw6600 kernel: drm_ioctl+0x3ea/0x870 [drm] > May 18 19:21:57 xw6600 kernel: ? drm_mode_setplane+0x1a0/0x1a0 [drm] > May 18 19:21:57 xw6600 kernel: ? trace_hardirqs_on_caller+0x1ad/0x2c0 > May 18 19:21:57 xw6600 kernel: ? trace_hardirqs_on+0xd/0x10 > May 18 19:21:57 xw6600 kernel: radeon_drm_ioctl+0x6e/0
Re: [PATCH v3 12/16] drm/stm: remove unneeded -Iinclude/drm compiler flag
On Thu, May 18, 2017 at 01:29:49PM +0900, Masahiro Yamada wrote: > With the include directives under include/drm/ fixed, this flag is > no longer needed. > > Signed-off-by: Masahiro Yamada Ok, this and patch 1 applied, pls double-check I've done the right thing and it's all good now (well, once linux-next has rebuild with the 2 patches merged, which should be in 1-2 days at most). Thanks, Daniel > --- > > Changes in v3: None > > drivers/gpu/drm/stm/Makefile | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/stm/Makefile b/drivers/gpu/drm/stm/Makefile > index e114d45..a09ecf4 100644 > --- a/drivers/gpu/drm/stm/Makefile > +++ b/drivers/gpu/drm/stm/Makefile > @@ -1,5 +1,3 @@ > -ccflags-y := -Iinclude/drm > - > stm-drm-y := \ > drv.o \ > ltdc.o > -- > 2.7.4 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
Re: [PATCH] drm/amd: include instead of "linux/delay.h"
On Thu, May 18, 2017 at 08:47:34AM +0200, Christian König wrote:
> Am 18.05.2017 um 06:43 schrieb Masahiro Yamada:
> > Use <...> notation to include headers located in include/linux.
> > While we are here, tweak the includes order a bit to sort them
> > alphabetically.
> >
> > Signed-off-by: Masahiro Yamada
>
> Reviewed-by: Christian König
I think I'll leave this one for Alex, but I guess I can pick it up into
drm-misc too if that's simpler ... All the other include patches are in
there already.
-Daniel
>
> > ---
> >
> > drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++--
> > drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c | 2 +-
> > drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
> > drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++--
> > drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 8 +---
> > drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 5 +++--
> > 6 files changed, 16 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> > index ff4ae3d..963a9e0 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
> > @@ -22,10 +22,10 @@
> >*/
> > #include "pp_debug.h"
> > -#include "linux/delay.h"
> > -#include
> > +#include
> > #include
> > #include
> > +#include
> > #include
> > #include "cgs_common.h"
> > #include "power_state.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> > index f5e8fda..f6b4dd9 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
> > @@ -21,8 +21,8 @@
> >*
> >*/
> > +#include
> > #include
> > -#include "linux/delay.h"
> > #include "hwmgr.h"
> > #include "amd_acpi.h"
> > #include "pp_acpi.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> > index 8f663ab..581374d 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> > @@ -21,11 +21,11 @@
> >*
> >*/
> > #include "pp_debug.h"
> > +#include
> > +#include
> > #include
> > #include
> > -#include
> > #include
> > -#include "linux/delay.h"
> > #include "pp_acpi.h"
> > #include "ppatomctrl.h"
> > #include "atombios.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > index 8394955..f4ab81b 100644
> > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
> > @@ -20,10 +20,11 @@
> >* OTHER DEALINGS IN THE SOFTWARE.
> >*
> >*/
> > +
> > +#include
> > +#include
> > #include
> > #include
> > -#include
> > -#include "linux/delay.h"
> > #include "hwmgr.h"
> > #include "amd_powerplay.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > index 1f6744a..39c7091 100644
> > --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > @@ -20,11 +20,13 @@
> >* OTHER DEALINGS IN THE SOFTWARE.
> >*
> >*/
> > -#include
> > +
> > +#include
> > +#include
> > #include
> > #include
> > -#include
> > -#include "linux/delay.h"
> > +#include
> > +
> > #include "cgs_common.h"
> > #include "smu/smu_8_0_d.h"
> > #include "smu/smu_8_0_sh_mask.h"
> > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
> > b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
> > index c0d7576..2e954a4 100644
> > --- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
> > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
> > @@ -20,15 +20,16 @@
> >* OTHER DEALINGS IN THE SOFTWARE.
> >*
> >*/
> > -#include
> > +
> > +#include
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include "pp_instance.h"
> > #include "smumgr.h"
> > #include "cgs_common.h"
> > -#include "linux/delay.h"
> > MODULE_FIRMWARE("amdgpu/topaz_smc.bin");
> > MODULE_FIRMWARE("amdgpu/topaz_k_smc.bin");
>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
Re: [PATCH 1/2] drm/atomic: Consitfy mode parameter to drm_atomic_set_mode_for_crtc()
On Thu, May 18, 2017 at 10:38:36PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> drm_atomic_set_mode_for_crtc() doesn't modify the passed mode, so let's
> make it const.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic.c | 2 +-
> include/drm/drm_atomic.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index cdec19a86af3..21cb78202c90 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -328,7 +328,7 @@ static s32 __user *get_out_fence_for_crtc(struct
> drm_atomic_state *state,
> * Zero on success, error code on failure. Cannot return -EDEADLK.
> */
> int drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
> - struct drm_display_mode *mode)
> + const struct drm_display_mode *mode)
> {
> struct drm_mode_modeinfo umode;
>
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 8645dcdef031..0196f264a418 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -520,7 +520,7 @@ __drm_atomic_get_current_plane_state(struct
> drm_atomic_state *state,
>
> int __must_check
> drm_atomic_set_mode_for_crtc(struct drm_crtc_state *state,
> - struct drm_display_mode *mode);
> + const struct drm_display_mode *mode);
> int __must_check
> drm_atomic_set_mode_prop_for_crtc(struct drm_crtc_state *state,
> struct drm_property_blob *blob);
> --
> 2.10.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Constify load detect mode
On Thu, May 18, 2017 at 10:38:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Make the mode used for load detection const, and adjust all relevant
> functions to accept a const mode.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 12 ++--
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 8217ed0e7132..6c08a7d6a0de 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9538,7 +9538,7 @@ static void i9xx_disable_cursor(struct intel_plane
> *plane,
>
>
> /* VESA 640x480x72Hz mode to set on the pipe */
> -static struct drm_display_mode load_detect_mode = {
> +static const struct drm_display_mode load_detect_mode = {
> DRM_MODE("640x480", DRM_MODE_TYPE_DEFAULT, 31500, 640, 664,
>704, 832, 0, 480, 489, 491, 520, 0, DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC),
> };
> @@ -9573,7 +9573,7 @@ intel_framebuffer_pitch_for_width(int width, int bpp)
> }
>
> static u32
> -intel_framebuffer_size_for_mode(struct drm_display_mode *mode, int bpp)
> +intel_framebuffer_size_for_mode(const struct drm_display_mode *mode, int bpp)
> {
> u32 pitch = intel_framebuffer_pitch_for_width(mode->hdisplay, bpp);
> return PAGE_ALIGN(pitch * mode->vdisplay);
> @@ -9581,7 +9581,7 @@ intel_framebuffer_size_for_mode(struct drm_display_mode
> *mode, int bpp)
>
> static struct drm_framebuffer *
> intel_framebuffer_create_for_mode(struct drm_device *dev,
> - struct drm_display_mode *mode,
> + const struct drm_display_mode *mode,
> int depth, int bpp)
> {
> struct drm_framebuffer *fb;
> @@ -9608,7 +9608,7 @@ intel_framebuffer_create_for_mode(struct drm_device
> *dev,
>
> static struct drm_framebuffer *
> mode_fits_in_fbdev(struct drm_device *dev,
> -struct drm_display_mode *mode)
> +const struct drm_display_mode *mode)
> {
> #ifdef CONFIG_DRM_FBDEV_EMULATION
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -9641,7 +9641,7 @@ mode_fits_in_fbdev(struct drm_device *dev,
>
> static int intel_modeset_setup_plane_state(struct drm_atomic_state *state,
> struct drm_crtc *crtc,
> -struct drm_display_mode *mode,
> +const struct drm_display_mode *mode,
> struct drm_framebuffer *fb,
> int x, int y)
> {
> @@ -9675,7 +9675,7 @@ static int intel_modeset_setup_plane_state(struct
> drm_atomic_state *state,
> }
>
> int intel_get_load_detect_pipe(struct drm_connector *connector,
> -struct drm_display_mode *mode,
> +const struct drm_display_mode *mode,
> struct intel_load_detect_pipe *old,
> struct drm_modeset_acquire_ctx *ctx)
> {
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index bd500977b3fc..d2aa92fa7ec4 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1398,7 +1398,7 @@ void vlv_wait_port_ready(struct drm_i915_private
> *dev_priv,
>struct intel_digital_port *dport,
>unsigned int expected_mask);
> int intel_get_load_detect_pipe(struct drm_connector *connector,
> -struct drm_display_mode *mode,
> +const struct drm_display_mode *mode,
> struct intel_load_detect_pipe *old,
> struct drm_modeset_acquire_ctx *ctx);
> void intel_release_load_detect_pipe(struct drm_connector *connector,
> --
> 2.10.2
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
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
Re: [PATCH v4 1/2] drm/blend: Fix comment typ-o
On Fri, May 19, 2017 at 04:50:16PM -0400, Robert Foss wrote: > Fix DRM_REFELCT_Y -> DRM_REFLECT_Y. > > Signed-off-by: Robert Foss Applied, thanks. -Daniel > --- > drivers/gpu/drm/drm_blend.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > index a0d0d6843288..dee67ef6c670 100644 > --- a/drivers/gpu/drm/drm_blend.c > +++ b/drivers/gpu/drm/drm_blend.c > @@ -129,7 +129,7 @@ > * "rotate-270" > * DRM_REFLECT_X: > * "reflect-x" > - * DRM_REFELCT_Y: > + * DRM_REFLECT_Y: > * "reflect-y" > * > * Rotation is the specified amount in degrees in counter clockwise > direction, > -- > 2.11.0.453.g787f75f05 > -- 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
[Bug 100949] Power management problem on CIK/SI hybrid laptop
https://bugs.freedesktop.org/show_bug.cgi?id=100949 --- Comment #3 from Michel Dänzer --- I'm seeing the same *ERROR* lines on suspend/resume on one of my laptops, and the laptop panel stays black. Does that match your problem, or what did you mean by "broke the handling of power management"? -- 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 -next] drm/vgem: Fix return value check in vgem_init()
On Sun, May 21, 2017 at 01:09:05PM +0100, Chris Wilson wrote:
> On Sun, May 21, 2017 at 01:19:39AM +, Wei Yongjun wrote:
> > From: Wei Yongjun
> >
> > In case of error, the function platform_device_register_simple() returns
> > ERR_PTR() and never returns NULL. The NULL test in the return value
> > check should be replaced with IS_ERR().
> >
> > Fixes: 315f0242aa2b ("drm/vgem: Convert to a struct drm_device subclass")
>
> This is wrong, the bug was introduced in
> af33a9190d02 ("drm/vgem: Enable dmabuf import interfaces")
> not that it matters since it is the same tag.
Fixed.
> > Signed-off-by: Wei Yongjun
>
> Checked it is an ERR_PTR return on failure, so
> Reviewed-by: Chris Wilson
Applied, thanks for patch&review.
-Daniel
--
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
Re: [PATCH v4 2/2] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI
On Fri, May 19, 2017 at 04:50:17PM -0400, Robert Foss wrote:
> Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI
> as a convenience.
>
> Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
> through the atomic API, but realizing that userspace is likely to take
> shortcuts and assume that the enum values are what is sent over the
> wire.
>
> As a result these defines are provided purely as a convenience to
> userspace applications.
>
> Signed-off-by: Robert Foss
> Reviewed-by: Emil Velikov
> Reviewed-by: Sinclair Yeh
> Acked-by: Liviu Dudau
> ---
> Changes since v3:
> - Switched away from past tense in comments
> - Add define name change to previously mis-spelled DRM_REFLECT_X comment
> - Improved the comment for the DRM_MODE_REFLECT_ comment
>
> Changes since v2:
> - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_
> - Fix compilation errors
> - Changed comment formatting
> - Deduplicated comment lines
> - Clarified DRM_MODE_PROP_REFLECT_ comment
>
> Changes since v1:
> - Moved defines from drm.h to drm_mode.h
> - Changed define prefix from DRM_ to DRM_MODE_PROP_
> - Updated uses of the defines to the new prefix
> - Removed include from drm_rect.c
> - Stopped using the BIT() macro
I know everyone else is different, but I like to keep these in the commit
message (even better when they're annotated with the names of reviewers
who made the suggestion). So added it to the commit.
Anyway applied, thanks.
-Daniel
>
> drivers/gpu/drm/arm/malidp_drv.h| 2 +-
> drivers/gpu/drm/arm/malidp_planes.c | 18 -
> drivers/gpu/drm/armada/armada_overlay.c | 2 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 +-
> drivers/gpu/drm/drm_atomic.c| 2 +-
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/gpu/drm/drm_blend.c | 45 +++---
> drivers/gpu/drm/drm_fb_helper.c | 4 +-
> drivers/gpu/drm/drm_plane_helper.c | 2 +-
> drivers/gpu/drm/drm_rect.c | 36 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 14 +++
> drivers/gpu/drm/i915/intel_atomic_plane.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c| 50
> -
> drivers/gpu/drm/i915/intel_fbc.c| 2 +-
> drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
> drivers/gpu/drm/i915/intel_sprite.c | 20 +-
> drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 30 +++
> drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 4 +-
> drivers/gpu/drm/omapdrm/omap_fb.c | 18 -
> drivers/gpu/drm/omapdrm/omap_plane.c| 16
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
> include/drm/drm_blend.h | 21 +--
> include/uapi/drm/drm_mode.h | 49 +++-
> 25 files changed, 202 insertions(+), 171 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h
> b/drivers/gpu/drm/arm/malidp_drv.h
> index 040311ffcaec..2e2033140efc 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -65,6 +65,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
> int malidp_crtc_init(struct drm_device *drm);
>
> /* often used combination of rotational bits */
> -#define MALIDP_ROTATED_MASK (DRM_ROTATE_90 | DRM_ROTATE_270)
> +#define MALIDP_ROTATED_MASK (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270)
>
> #endif /* __MALIDP_DRV_H__ */
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 814fda23cead..063a8d2b0be3 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -80,7 +80,7 @@ static void malidp_plane_reset(struct drm_plane *plane)
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> if (state) {
> state->base.plane = plane;
> - state->base.rotation = DRM_ROTATE_0;
> + state->base.rotation = DRM_MODE_ROTATE_0;
> plane->state = &state->base;
> }
> }
> @@ -221,7 +221,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
> return ret;
>
> /* packed RGB888 / BGR888 can't be rotated or flipped */
> - if (state->rotation != DRM_ROTATE_0 &&
> + if (state->rotation != DRM_MODE_ROTATE_0 &&
> (fb->format->format == DRM_FORMAT_RGB888 ||
>fb->format->format == DRM_FORMAT_BGR888))
> return -EINVAL;
> @@ -315,12 +315,12 @@ static void malidp_de_plane_update(struct drm_plane
> *plane,
> val &= ~LAYER_ROT_MASK;
>
> /* setup the rotation and axis flip bits */
> - if (plane->state->rotation & DRM_ROTATE_MASK)
> - va
Re: [PATCH v4 03/10] drm: Use new mode_valid() helpers in connector probe helper
On Fri, May 19, 2017 at 01:52:12AM +0100, Jose Abreu wrote:
> This changes the connector probe helper function to use the new
> encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
> helper callbacks to validate the modes.
>
> The new callbacks are optional so the behaviour remains the same
> if they are not implemented. If they are, then the code loops
> through all the connector's encodersXbridgesXcrtcs and calls the
> callback.
>
> If at least a valid encoderXbridgeXcrtc combination is found which
> accepts the mode then the function returns MODE_OK.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
> Cc: Laurent Pinchart
You've lost the per-patch changelog here, which is pretty easy to
accidentally do if you keep it below the ---. That's one of the reasons
why in drm we prefer the per-patch changelog to be part of the commit
itself.
Anyway I have no opinion on the bikshed discussion itself (it's a static
inline helper ffs, it doesn't really matter), and that bikeshed is the
last open I could distill from the previous submissions:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_probe_helper.c | 67
> +++---
> 1 file changed, 63 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index f01abdc..00e6832 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -83,6 +83,61 @@
> return MODE_OK;
> }
>
> +static enum drm_mode_status
> +drm_mode_validate_pipeline(struct drm_display_mode *mode,
> + struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + uint32_t *ids = connector->encoder_ids;
> + enum drm_mode_status ret = MODE_OK;
> + unsigned int i;
> +
> + /* Step 1: Validate against connector */
> + ret = drm_connector_mode_valid(connector, mode);
> + if (ret != MODE_OK)
> + return ret;
> +
> + /* Step 2: Validate against encoders and crtcs */
> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
> + struct drm_crtc *crtc;
> +
> + if (!encoder)
> + continue;
> +
> + ret = drm_encoder_mode_valid(encoder, mode);
> + if (ret != MODE_OK) {
> + /* No point in continuing for crtc check as this encoder
> + * will not accept the mode anyway. If all encoders
> + * reject the mode then, at exit, ret will not be
> + * MODE_OK. */
> + continue;
> + }
> +
> + ret = drm_bridge_mode_valid(encoder->bridge, mode);
> + if (ret != MODE_OK) {
> + /* There is also no point in continuing for crtc check
> + * here. */
> + continue;
> + }
> +
> + drm_for_each_crtc(crtc, dev) {
> + if (!drm_encoder_crtc_ok(encoder, crtc))
> + continue;
> +
> + ret = drm_crtc_mode_valid(crtc, mode);
> + if (ret == MODE_OK) {
> + /* If we get to this point there is at least
> + * one combination of encoder+crtc that works
> + * for this mode. Lets return now. */
> + return ret;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
> {
> struct drm_cmdline_mode *cmdline_mode;
> @@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
> *- drm_mode_validate_flag() checks the modes against basic connector
> * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
> *- the optional &drm_connector_helper_funcs.mode_valid helper can
> perform
> - * driver and/or hardware specific checks
> + * driver and/or sink specific checks
> + *- the optional &drm_crtc_helper_funcs.mode_valid,
> + * &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid
> + * helpers can perform driver and/or source specific checks which are
> also
> + * enforced by the modeset/atomic helpers
> *
> * 5. Any mode whose status is not OK is pruned from the connector's modes
> list,
> *accompanied by a debug message indicating the reason for the mode's
> @@ -466,9 +525,9 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> if (mode->status == MODE_OK)
> mode->status = drm_mode_validate_flag(mode, mode_flags);
>
> -
Re: [PATCH] drm/amd: include instead of "linux/delay.h"
Am 22.05.2017 um 09:39 schrieb Daniel Vetter:
On Thu, May 18, 2017 at 08:47:34AM +0200, Christian König wrote:
Am 18.05.2017 um 06:43 schrieb Masahiro Yamada:
Use <...> notation to include headers located in include/linux.
While we are here, tweak the includes order a bit to sort them
alphabetically.
Signed-off-by: Masahiro Yamada
Reviewed-by: Christian König
I think I'll leave this one for Alex, but I guess I can pick it up into
drm-misc too if that's simpler ... All the other include patches are in
there already.
Please pick that up for drm-misc. Alex is on vacation this week and I
already have all hands full replacing him.
Christian.
-Daniel
---
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++--
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 8 +---
drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 5 +++--
6 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ff4ae3d..963a9e0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -22,10 +22,10 @@
*/
#include "pp_debug.h"
-#include "linux/delay.h"
-#include
+#include
#include
#include
+#include
#include
#include "cgs_common.h"
#include "power_state.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
index f5e8fda..f6b4dd9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
@@ -21,8 +21,8 @@
*
*/
+#include
#include
-#include "linux/delay.h"
#include "hwmgr.h"
#include "amd_acpi.h"
#include "pp_acpi.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 8f663ab..581374d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -21,11 +21,11 @@
*
*/
#include "pp_debug.h"
+#include
+#include
#include
#include
-#include
#include
-#include "linux/delay.h"
#include "pp_acpi.h"
#include "ppatomctrl.h"
#include "atombios.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 8394955..f4ab81b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -20,10 +20,11 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
+
+#include
+#include
#include
#include
-#include
-#include "linux/delay.h"
#include "hwmgr.h"
#include "amd_powerplay.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
index 1f6744a..39c7091 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
@@ -20,11 +20,13 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
-#include
+
+#include
+#include
#include
#include
-#include
-#include "linux/delay.h"
+#include
+
#include "cgs_common.h"
#include "smu/smu_8_0_d.h"
#include "smu/smu_8_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
index c0d7576..2e954a4 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
@@ -20,15 +20,16 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
-#include
+
+#include
#include
#include
#include
+#include
#include
#include "pp_instance.h"
#include "smumgr.h"
#include "cgs_common.h"
-#include "linux/delay.h"
MODULE_FIRMWARE("amdgpu/topaz_smc.bin");
MODULE_FIRMWARE("amdgpu/topaz_k_smc.bin");
___
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
Re: [PATCH v4 00/10] Introduce new mode validation callbacks
On Fri, May 19, 2017 at 01:52:09AM +0100, Jose Abreu wrote:
> This series is a follow up from the discussion at [1]. We start by
> introducing crtc->mode_valid(), encoder->mode_valid() and
> bridge->mode_valid() callbacks which will be used in followup
> patches and also by cleaning the documentation a little bit. This
> patch is available at [2] and the series depends on it.
>
> We proceed by introducing new helpers to call this new callbacks
> at 1/10.
>
> At 2/10 a helper function is introduced that calls all mode_valid()
> from a set of bridges.
>
> Next, at 3/10 we modify the connector probe helper so that only modes
> which are supported by a given bridge+encoder+crtc combination are
> probbed.
>
> At 4/10 we call all the mode_valid() callbacks for a given pipeline,
> except the connector->mode_valid one, so that the mode is validated.
> This is done before calling mode_fixup().
>
> Finally, from 5/10 to 10/10 we use the new callbacks in drivers that
> can implement it.
>
> [1] https://patchwork.kernel.org/patch/9702233/
> [2] https://lists.freedesktop.org/archives/dri-devel/2017-May/141761.html
>
> Jose Abreu (10):
> drm: Add drm_{crtc/encoder/connector}_mode_valid()
> drm: Introduce drm_bridge_mode_valid()
> drm: Use new mode_valid() helpers in connector probe helper
> drm: Use mode_valid() in atomic modeset
> drm: arc: Use crtc->mode_valid() callback
> drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback
> drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback
> drm/arm: malidp: Use crtc->mode_valid() callback
> drm/atmel-hlcdc: Use crtc->mode_valid() callback
> drm: vc4: Use crtc->mode_valid() and encoder->mode_valid() callbacks
Looks all real nice, I think a bit more time to get acks/reviews/tested-by
for the driver conversions and I'll go and vacuum this all up.
Thanks a lot for doing this.
-Daniel
>
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> Cc: Andrzej Hajda
> Cc: Archit Taneja
> Cc: Laurent Pinchart
>
> drivers/gpu/drm/arc/arcpgu_crtc.c | 29 ---
> drivers/gpu/drm/arm/malidp_crtc.c | 11 ++-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 9 +--
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 13 ++-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 40 +++---
> drivers/gpu/drm/drm_atomic_helper.c| 76 +-
> drivers/gpu/drm/drm_bridge.c | 33
> drivers/gpu/drm/drm_crtc_helper_internal.h | 13 +++
> drivers/gpu/drm/drm_probe_helper.c | 105
> -
> drivers/gpu/drm/imx/dw_hdmi-imx.c | 4 +-
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 2 +-
> drivers/gpu/drm/vc4/vc4_crtc.c | 13 ++-
> drivers/gpu/drm/vc4/vc4_dpi.c | 13 ++-
> include/drm/bridge/dw_hdmi.h | 2 +-
> include/drm/drm_bridge.h | 2 +
> 16 files changed, 280 insertions(+), 87 deletions(-)
>
> --
> 1.9.1
>
>
--
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
Re: (radeon?) WARNING: drivers/gpu/drm/drm_irq.c:1195 drm_vblank_put (v4.11-12441-g56868a4)
2017-05-22 10:32 GMT+03:00 Daniel Vetter : > Yeah I think the locking stuff we've fixed, at least if you don't see it > in 4.12 it should be all good. And I think I spotted the bug you've > bisected to, patch is on dri-devel, pls test. Thanks! I'll test it later today. -Tommi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd: include instead of "linux/delay.h"
On Mon, May 22, 2017 at 09:55:46AM +0200, Christian König wrote: > Am 22.05.2017 um 09:39 schrieb Daniel Vetter: > > On Thu, May 18, 2017 at 08:47:34AM +0200, Christian König wrote: > > > Am 18.05.2017 um 06:43 schrieb Masahiro Yamada: > > > > Use <...> notation to include headers located in include/linux. > > > > While we are here, tweak the includes order a bit to sort them > > > > alphabetically. > > > > > > > > Signed-off-by: Masahiro Yamada > > > Reviewed-by: Christian König > > I think I'll leave this one for Alex, but I guess I can pick it up into > > drm-misc too if that's simpler ... All the other include patches are in > > there already. > > Please pick that up for drm-misc. Alex is on vacation this week and I > already have all hands full replacing him. Done. Aside: Switching to commit rights is a nice way to make maintainer vacations real smooth :-) I wanted to chat with Alex about that anyway, I guess I'll ping him when he's back. Cheers, Daniel > > Christian. > > > -Daniel > > > > --- > > > > > > > >drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++-- > > > >drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c | 2 +- > > > >drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++-- > > > >drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++-- > > > >drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 8 +--- > > > >drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 5 +++-- > > > >6 files changed, 16 insertions(+), 12 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c > > > > b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c > > > > index ff4ae3d..963a9e0 100644 > > > > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c > > > > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c > > > > @@ -22,10 +22,10 @@ > > > > */ > > > >#include "pp_debug.h" > > > > -#include "linux/delay.h" > > > > -#include > > > > +#include > > > >#include > > > >#include > > > > +#include > > > >#include > > > >#include "cgs_common.h" > > > >#include "power_state.h" > > > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c > > > > b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c > > > > index f5e8fda..f6b4dd9 100644 > > > > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c > > > > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c > > > > @@ -21,8 +21,8 @@ > > > > * > > > > */ > > > > +#include > > > >#include > > > > -#include "linux/delay.h" > > > >#include "hwmgr.h" > > > >#include "amd_acpi.h" > > > >#include "pp_acpi.h" > > > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > > > > b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > > > > index 8f663ab..581374d 100644 > > > > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > > > > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c > > > > @@ -21,11 +21,11 @@ > > > > * > > > > */ > > > >#include "pp_debug.h" > > > > +#include > > > > +#include > > > >#include > > > >#include > > > > -#include > > > >#include > > > > -#include "linux/delay.h" > > > >#include "pp_acpi.h" > > > >#include "ppatomctrl.h" > > > >#include "atombios.h" > > > > diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c > > > > b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c > > > > index 8394955..f4ab81b 100644 > > > > --- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c > > > > +++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c > > > > @@ -20,10 +20,11 @@ > > > > * OTHER DEALINGS IN THE SOFTWARE. > > > > * > > > > */ > > > > + > > > > +#include > > > > +#include > > > >#include > > > >#include > > > > -#include > > > > -#include "linux/delay.h" > > > >#include "hwmgr.h" > > > >#include "amd_powerplay.h" > > > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c > > > > b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c > > > > index 1f6744a..39c7091 100644 > > > > --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c > > > > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c > > > > @@ -20,11 +20,13 @@ > > > > * OTHER DEALINGS IN THE SOFTWARE. > > > > * > > > > */ > > > > -#include > > > > + > > > > +#include > > > > +#include > > > >#include > > > >#include > > > > -#include > > > > -#include "linux/delay.h" > > > > +#include > > > > + > > > >#include "cgs_common.h" > > > >#include "smu/smu_8_0_d.h" > > > >#include "smu/smu_8_0_sh_mask.h" > > > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c > > > > b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c > > > > index c0d7576..2e954a4 100644 > > > > --- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c > > > > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c > > > > @@ -20,15 +20,16 @@ > > > > * OTHER DEALINGS IN THE SOFTWARE. > > > > * > > > > */ > > > > -#include > > > > + > > > > +#in
Re: [PATCH] drm/amd: include instead of "linux/delay.h"
Am 22.05.2017 um 10:06 schrieb Daniel Vetter:
On Mon, May 22, 2017 at 09:55:46AM +0200, Christian König wrote:
Am 22.05.2017 um 09:39 schrieb Daniel Vetter:
On Thu, May 18, 2017 at 08:47:34AM +0200, Christian König wrote:
Am 18.05.2017 um 06:43 schrieb Masahiro Yamada:
Use <...> notation to include headers located in include/linux.
While we are here, tweak the includes order a bit to sort them
alphabetically.
Signed-off-by: Masahiro Yamada
Reviewed-by: Christian König
I think I'll leave this one for Alex, but I guess I can pick it up into
drm-misc too if that's simpler ... All the other include patches are in
there already.
Please pick that up for drm-misc. Alex is on vacation this week and I
already have all hands full replacing him.
Done. Aside: Switching to commit rights is a nice way to make maintainer
vacations real smooth :-) I wanted to chat with Alex about that anyway, I
guess I'll ping him when he's back.
Completely agree. One lesson learned from the past week is that Alex
needs to stop using his personal repository on fdo.
We were asked a couple of times if I couldn't update a branch there from
different directions, which we obviously can't do.
Christian.
Cheers, Daniel
Christian.
-Daniel
---
drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c| 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c | 2 +-
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c | 5 +++--
drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 8 +---
drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c | 5 +++--
6 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
index ff4ae3d..963a9e0 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/hwmgr.c
@@ -22,10 +22,10 @@
*/
#include "pp_debug.h"
-#include "linux/delay.h"
-#include
+#include
#include
#include
+#include
#include
#include "cgs_common.h"
#include "power_state.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
index f5e8fda..f6b4dd9 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/pp_acpi.c
@@ -21,8 +21,8 @@
*
*/
+#include
#include
-#include "linux/delay.h"
#include "hwmgr.h"
#include "amd_acpi.h"
#include "pp_acpi.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index 8f663ab..581374d 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -21,11 +21,11 @@
*
*/
#include "pp_debug.h"
+#include
+#include
#include
#include
-#include
#include
-#include "linux/delay.h"
#include "pp_acpi.h"
#include "ppatomctrl.h"
#include "atombios.h"
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
index 8394955..f4ab81b 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c
@@ -20,10 +20,11 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
+
+#include
+#include
#include
#include
-#include
-#include "linux/delay.h"
#include "hwmgr.h"
#include "amd_powerplay.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
index 1f6744a..39c7091 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
@@ -20,11 +20,13 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
-#include
+
+#include
+#include
#include
#include
-#include
-#include "linux/delay.h"
+#include
+
#include "cgs_common.h"
#include "smu/smu_8_0_d.h"
#include "smu/smu_8_0_sh_mask.h"
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
index c0d7576..2e954a4 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/smumgr.c
@@ -20,15 +20,16 @@
* OTHER DEALINGS IN THE SOFTWARE.
*
*/
-#include
+
+#include
#include
#include
#include
+#include
#include
#include "pp_instance.h"
#include "smumgr.h"
#include "cgs_common.h"
-#include "linux/delay.h"
MODULE_FIRMWARE("amdgpu/topaz_smc.bin");
MODULE_FIRMWARE("amdgpu/topaz_k_smc.bin");
___
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
__
Re: drm: Primary display is recognized as secondary display
On Sat, May 20, 2017 at 10:02:32PM +0900, Hisao Tanabe wrote: > DELL 27-inch display is connected to ThinkPad 250 via DisplayPort cable, > and DELL 27-inch display is used as primary display. > > After upgrade kernel from 4.10 to 4.11, the DELL 27-inch display is now > recognized as a secondary display. What's primary and secondary? Do you mean X's RandR PrimaryOutput, or the layout, both of which are provided by userspace. I suspect what you mean is that the connectors were relabelled, so the output from before/after xrandr might help to clarify that. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100400] Game Valhalla Hills crash on startup
https://bugs.freedesktop.org/show_bug.cgi?id=100400 --- Comment #11 from Samuel Pitoiset --- Hi there, The crash at startup can no longer be reproduced. I have just tested with Mesa (4eb0411ed72) and LLVM (9031fd91990). Though, it still crashes with Mesa 17.1.0 and LLVM 4.0.0. Can you upgrade LLVM and confirm, please? -- 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
[Bug 100949] Power management problem on CIK/SI hybrid laptop
https://bugs.freedesktop.org/show_bug.cgi?id=100949 --- Comment #4 from Luya Tshimbalanga --- > I'm seeing the same *ERROR* lines on suspend/resume on one of my laptops, and > the laptop panel stays black. Does that match your problem, or what did you > mean by "broke the handling of power management"? For the former, that matches the problem I encountered. About the line "broke the handling of power management", I noticed more fan noise than usual but it may be something else. It will be nice to optimize that power management if possible. -- 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
[Bug 100802] [regression] mostly blank graphics on Faeria
https://bugs.freedesktop.org/show_bug.cgi?id=100802 --- Comment #6 from Samuel Pitoiset --- Same here, the trace replays fine with Mesa/LLVM from today on RX480. -- 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
[Bug 100949] Power management problem on CIK/SI hybrid laptop
https://bugs.freedesktop.org/show_bug.cgi?id=100949 --- Comment #5 from Michel Dänzer --- And you're saying suspend/resume broke around May 2nd for you? Do you happen to remember a commit before that where it worked for you? -- 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
[Bug 99859] Glamor Crashes on big endian Hardware
https://bugs.freedesktop.org/show_bug.cgi?id=99859 --- Comment #20 from intermedi...@hotmail.com --- Thanks for the reply Michel, i hope will be fixed because all actual gpu are using SI and this made Linux unusable on BE host if a new machine (like is mine) . -- 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] drm: Fix deadlock retry loop in page_flip_ioctl
On 22/05/17 04:31 PM, Daniel Vetter wrote:
> I failed to properly onion-wrap the unwind code: We acquire the vblank
> reference before we start with the wait-wound locking dance, hence we
> must make sure we retry before we drop the reference. Oops.
>
> Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl")
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Reported-by: Tommi Rantala
> Cc: Tommi Rantala
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index fedd4d60d9cd..24c8a611b98a 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -948,6 +948,11 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> }
>
> out:
> + if (ret == -EDEADLK) {
> + drm_modeset_backoff(&ctx);
> + goto retry;
> + }
> +
> if (ret && crtc->funcs->page_flip_target)
> drm_crtc_vblank_put(crtc);
> if (fb)
> @@ -956,11 +961,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> drm_framebuffer_put(crtc->primary->old_fb);
> crtc->primary->old_fb = NULL;
>
> - if (ret == -EDEADLK) {
> - drm_modeset_backoff(&ctx);
> - goto retry;
> - }
I suspect the drm_framebuffer_put(fb) call still needs to happen before
the retry?
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI
On Mon, May 22, 2017 at 09:51:22AM +0200, Daniel Vetter wrote:
> On Fri, May 19, 2017 at 04:50:17PM -0400, Robert Foss wrote:
> > Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI
> > as a convenience.
> >
> > Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
> > through the atomic API, but realizing that userspace is likely to take
> > shortcuts and assume that the enum values are what is sent over the
> > wire.
> >
> > As a result these defines are provided purely as a convenience to
> > userspace applications.
> >
> > Signed-off-by: Robert Foss
> > Reviewed-by: Emil Velikov
> > Reviewed-by: Sinclair Yeh
> > Acked-by: Liviu Dudau
> > ---
> > Changes since v3:
> > - Switched away from past tense in comments
> > - Add define name change to previously mis-spelled DRM_REFLECT_X comment
> > - Improved the comment for the DRM_MODE_REFLECT_ comment
> >
> > Changes since v2:
> > - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_
> > - Fix compilation errors
> > - Changed comment formatting
> > - Deduplicated comment lines
> > - Clarified DRM_MODE_PROP_REFLECT_ comment
> >
> > Changes since v1:
> > - Moved defines from drm.h to drm_mode.h
> > - Changed define prefix from DRM_ to DRM_MODE_PROP_
> > - Updated uses of the defines to the new prefix
> > - Removed include from drm_rect.c
> > - Stopped using the BIT() macro
>
> I know everyone else is different, but I like to keep these in the commit
> message (even better when they're annotated with the names of reviewers
> who made the suggestion). So added it to the commit.
>
> Anyway applied, thanks.
Ok, this turns into a mess because drm-intel isn't in sync and oh the fun.
But I guess I'll survive :-)
-Daniel
> -Daniel
>
> >
> > drivers/gpu/drm/arm/malidp_drv.h| 2 +-
> > drivers/gpu/drm/arm/malidp_planes.c | 18 -
> > drivers/gpu/drm/armada/armada_overlay.c | 2 +-
> > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 +-
> > drivers/gpu/drm/drm_atomic.c| 2 +-
> > drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> > drivers/gpu/drm/drm_blend.c | 45 +++---
> > drivers/gpu/drm/drm_fb_helper.c | 4 +-
> > drivers/gpu/drm/drm_plane_helper.c | 2 +-
> > drivers/gpu/drm/drm_rect.c | 36 +-
> > drivers/gpu/drm/i915/i915_debugfs.c | 14 +++
> > drivers/gpu/drm/i915/intel_atomic_plane.c | 6 +--
> > drivers/gpu/drm/i915/intel_display.c| 50
> > -
> > drivers/gpu/drm/i915/intel_fbc.c| 2 +-
> > drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
> > drivers/gpu/drm/i915/intel_sprite.c | 20 +-
> > drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
> > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 30 +++
> > drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
> > drivers/gpu/drm/omapdrm/omap_drv.c | 4 +-
> > drivers/gpu/drm/omapdrm/omap_fb.c | 18 -
> > drivers/gpu/drm/omapdrm/omap_plane.c| 16
> > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
> > include/drm/drm_blend.h | 21 +--
> > include/uapi/drm/drm_mode.h | 49
> > +++-
> > 25 files changed, 202 insertions(+), 171 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.h
> > b/drivers/gpu/drm/arm/malidp_drv.h
> > index 040311ffcaec..2e2033140efc 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.h
> > +++ b/drivers/gpu/drm/arm/malidp_drv.h
> > @@ -65,6 +65,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
> > int malidp_crtc_init(struct drm_device *drm);
> >
> > /* often used combination of rotational bits */
> > -#define MALIDP_ROTATED_MASK(DRM_ROTATE_90 | DRM_ROTATE_270)
> > +#define MALIDP_ROTATED_MASK(DRM_MODE_ROTATE_90 |
> > DRM_MODE_ROTATE_270)
> >
> > #endif /* __MALIDP_DRV_H__ */
> > diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> > b/drivers/gpu/drm/arm/malidp_planes.c
> > index 814fda23cead..063a8d2b0be3 100644
> > --- a/drivers/gpu/drm/arm/malidp_planes.c
> > +++ b/drivers/gpu/drm/arm/malidp_planes.c
> > @@ -80,7 +80,7 @@ static void malidp_plane_reset(struct drm_plane *plane)
> > state = kzalloc(sizeof(*state), GFP_KERNEL);
> > if (state) {
> > state->base.plane = plane;
> > - state->base.rotation = DRM_ROTATE_0;
> > + state->base.rotation = DRM_MODE_ROTATE_0;
> > plane->state = &state->base;
> > }
> > }
> > @@ -221,7 +221,7 @@ static int malidp_de_plane_check(struct drm_plane
> > *plane,
> > return ret;
> >
> > /* packed RGB888 / BGR888 can't be rotated or flipped */
> > - if (state->rotation != DRM_ROTATE_0 &&
> > + if (state->rotation != DRM_MODE_ROTATE_0 &
Re: [PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name
On Tue, May 16, 2017 at 12:10:42PM +0100, Chris Wilson wrote:
> Constructing the name takes the majority of the time for allocating a
> sync_file to wrap a fence, and the name is very rarely used (only via
> the sync_file status user interface). To reduce the impact on the common
> path (that of creating sync_file to pass around), defer the construction
> of the name until it is first used.
>
> v2: Update kerneldoc (kbuild test robot)
> v3: sync_debug.c was peeking at the name
> v4: Comment upon the potential race between two users of
> sync_file_get_name() and claim that such a race is below the level of
> notice. However, to prevent any future nuisance, use a global spinlock
> to serialize the assignment of the name.
> v5: Completely avoid the read/write race by only storing the name passed
> in from the user inside sync_file->user_name and passing in a buffer to
> dynamically construct the name otherwise.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> Cc: Daniel Vetter
> Cc: David Herrmann
Any thoughts on this one? It should completely avoid the race, with
the presumption that unless the user sets a name when merging the best
response is to show the fence name.
It may be interesting to actually show both; the encoded
sync_file->fence name and the user's identifier.
-Chris
> ---
> drivers/dma-buf/sync_debug.c | 4 +++-
> drivers/dma-buf/sync_file.c | 39 ---
> include/linux/sync_file.h| 5 +++--
> 3 files changed, 38 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> index 4b1731ee7458..59a3b2f8ee91 100644
> --- a/drivers/dma-buf/sync_debug.c
> +++ b/drivers/dma-buf/sync_debug.c
> @@ -132,9 +132,11 @@ static void sync_print_obj(struct seq_file *s, struct
> sync_timeline *obj)
> static void sync_print_sync_file(struct seq_file *s,
> struct sync_file *sync_file)
> {
> + char buf[128];
> int i;
>
> - seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
> + seq_printf(s, "[%p] %s: %s\n", sync_file,
> +sync_file_get_name(sync_file, buf, sizeof(buf)),
> sync_status_str(dma_fence_get_status(sync_file->fence)));
>
> if (dma_fence_is_array(sync_file->fence)) {
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index c9eb4997cfcc..d7e219d2669d 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -80,11 +80,6 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
>
> sync_file->fence = dma_fence_get(fence);
>
> - snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
> - fence->ops->get_driver_name(fence),
> - fence->ops->get_timeline_name(fence), fence->context,
> - fence->seqno);
> -
> return sync_file;
> }
> EXPORT_SYMBOL(sync_file_create);
> @@ -129,6 +124,36 @@ struct dma_fence *sync_file_get_fence(int fd)
> }
> EXPORT_SYMBOL(sync_file_get_fence);
>
> +/**
> + * sync_file_get_name - get the name of the sync_file
> + * @sync_file: sync_file to get the fence from
> + * @buf: destination buffer to copy sync_file name into
> + * @len: available size of destination buffer.
> + *
> + * Each sync_file may have a name assigned either by the user (when merging
> + * sync_files together) or created from the fence it contains. In the latter
> + * case construction of the name is deferred until use, and so requires
> + * sync_file_get_name().
> + *
> + * Returns: a string representing the name.
> + */
> +char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
> +{
> + if (sync_file->user_name[0]) {
> + strlcpy(buf, sync_file->user_name, len);
> + } else {
> + struct dma_fence *fence = sync_file->fence;
> +
> + snprintf(buf, len, "%s-%s%llu-%d",
> + fence->ops->get_driver_name(fence),
> + fence->ops->get_timeline_name(fence),
> + fence->context,
> + fence->seqno);
> + }
> +
> + return buf;
> +}
> +
> static int sync_file_set_fence(struct sync_file *sync_file,
> struct dma_fence **fences, int num_fences)
> {
> @@ -266,7 +291,7 @@ static struct sync_file *sync_file_merge(const char
> *name, struct sync_file *a,
> goto err;
> }
>
> - strlcpy(sync_file->name, name, sizeof(sync_file->name));
> + strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
> return sync_file;
>
> err:
> @@ -419,7 +444,7 @@ static long sync_file_ioctl_fence_info(struct sync_file
> *sync_file,
> }
>
> no_fences:
> - strlcpy(info.name, sync_file->name, sizeof(info.name));
> + sync_file_get_name(sync_file, info.name, sizeof(info.name));
> info.status = dma_fence_is_signaled(sync_file->
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #13 from Jean Delvare (jdelv...@suse.de) --- Assuming you mean "in comment #1", well no, they do not work for me. Have you tested? I naively trusted you, and as a result agreed not to get the problematic commit reverted upstream, and now users are hitting a regression when upgrading to kernel v4.11. This isn't good. Now we need to figure out whether it is actually fixed upstream or not. No more assumptions. And if it fixed, knowing which commit did fix it would let us push the fix to the 4.11 stable tree. However I am not going to waste time bisecting it. If nobody knows how it was fixed, I will push the same revert to 4.11 that was pushed to 4.10, and be done with it. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #14 from flora@amd.com --- I don't know why it fails on your side, at least it works with my test PC. anyway, you could revert it if this troubles you. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101029] notebook does not work when not booted using nomodeset AMD APU
https://bugs.freedesktop.org/show_bug.cgi?id=101029 --- Comment #25 from Julien Isorce --- Does the patch mentioned in comment 24 only allow '__queue_flush' to complete faster at boot time ? Or should we expect some performance gain after boot ? -- 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 1/3] drm/omap: Support for HDMI hot plug detection
On 15/05/17 12:03, Peter Ujfalusi wrote:
> The HPD signal can be used for detecting HDMI cable plug and unplug event
> without the need for polling the status of the line.
> This will speed up detecting such event because we do not need to wait for
> the next poll event to notice the state change.
>
> Signed-off-by: Peter Ujfalusi
> ---
> drivers/gpu/drm/omapdrm/dss/omapdss.h| 17 +
> drivers/gpu/drm/omapdrm/omap_connector.c | 32
> +++-
> drivers/gpu/drm/omapdrm/omap_drv.c | 29 +
> 3 files changed, 77 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> index b19dae1fd6c5..1f01669eb610 100644
> --- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
> +++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
>
> #define DISPC_IRQ_FRAMEDONE (1 << 0)
> #define DISPC_IRQ_VSYNC (1 << 1)
> @@ -555,6 +556,14 @@ struct omapdss_hdmi_ops {
> int (*read_edid)(struct omap_dss_device *dssdev, u8 *buf, int len);
> bool (*detect)(struct omap_dss_device *dssdev);
>
> + int (*register_hpd_cb)(struct omap_dss_device *dssdev,
> +void (*cb)(void *cb_data,
> + enum drm_connector_status status),
> +void *cb_data);
> + void (*unregister_hpd_cb)(struct omap_dss_device *dssdev);
> + void (*enable_hpd)(struct omap_dss_device *dssdev);
> + void (*disable_hpd)(struct omap_dss_device *dssdev);
> +
> int (*set_hdmi_mode)(struct omap_dss_device *dssdev, bool hdmi_mode);
> int (*set_infoframe)(struct omap_dss_device *dssdev,
> const struct hdmi_avi_infoframe *avi);
> @@ -761,6 +770,14 @@ struct omap_dss_driver {
> int (*read_edid)(struct omap_dss_device *dssdev, u8 *buf, int len);
> bool (*detect)(struct omap_dss_device *dssdev);
>
> + int (*register_hpd_cb)(struct omap_dss_device *dssdev,
> +void (*cb)(void *cb_data,
> + enum drm_connector_status status),
> +void *cb_data);
> + void (*unregister_hpd_cb)(struct omap_dss_device *dssdev);
> + void (*enable_hpd)(struct omap_dss_device *dssdev);
> + void (*disable_hpd)(struct omap_dss_device *dssdev);
> +
> int (*set_hdmi_mode)(struct omap_dss_device *dssdev, bool hdmi_mode);
> int (*set_hdmi_infoframe)(struct omap_dss_device *dssdev,
> const struct hdmi_avi_infoframe *avi);
> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
> b/drivers/gpu/drm/omapdrm/omap_connector.c
> index c24b6b783e9a..5219e340ed9d 100644
> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> @@ -35,6 +35,18 @@ struct omap_connector {
> bool hdmi_mode;
> };
>
> +static void omap_connector_hpd_cb(void *cb_data,
> + enum drm_connector_status status)
> +{
> + struct omap_connector *omap_connector = cb_data;
> + struct drm_connector *connector = &omap_connector->base;
> +
> + if (connector->status != status) {
> + connector->status = status;
> + drm_kms_helper_hotplug_event(omap_connector->base.dev);
> + }
> +}
I'm not sure if this is racy or not... drm_kms_helper_hotplug_event()
should be called without locks held, but is it safe to touch
connector->status without any locks?
> +
> bool omap_connector_get_hdmi_mode(struct drm_connector *connector)
> {
> struct omap_connector *omap_connector = to_omap_connector(connector);
> @@ -75,6 +87,10 @@ static void omap_connector_destroy(struct drm_connector
> *connector)
> struct omap_dss_device *dssdev = omap_connector->dssdev;
>
> DBG("%s", omap_connector->dssdev->name);
> + if (connector->polled == DRM_CONNECTOR_POLL_HPD &&
> + dssdev->driver->unregister_hpd_cb) {
> + dssdev->driver->unregister_hpd_cb(dssdev);
> + }
> drm_connector_unregister(connector);
> drm_connector_cleanup(connector);
> kfree(omap_connector);
> @@ -216,6 +232,7 @@ struct drm_connector *omap_connector_init(struct
> drm_device *dev,
> {
> struct drm_connector *connector = NULL;
> struct omap_connector *omap_connector;
> + bool hpd_supported = false;
>
> DBG("%s", dssdev->name);
>
> @@ -233,7 +250,20 @@ struct drm_connector *omap_connector_init(struct
> drm_device *dev,
> connector_type);
> drm_connector_helper_add(connector, &omap_connector_helper_funcs);
>
> - if (dssdev->driver->detect)
> + if (dssdev->driver->register_hpd_cb) {
> + int ret = dssdev->driver->register_hpd_cb(dssdev,
> + omap_connector_hpd_cb,
> +
Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device
Hi Kieran,
On Monday 22 May 2017 13:16:11 Kieran Bingham wrote:
> On 17/05/17 00:20, Laurent Pinchart wrote:
> > For planes handled by a VSP instance, map the framebuffer memory through
> > the VSP to ensure proper IOMMU handling.
> >
> > Signed-off-by: Laurent Pinchart
> >
>
> Looks good except for a small unsigned int comparison causing an infinite
> loop on fail case.
>
> With the loop fixed:
>
> Reviewed-by: Kieran Bingham
>
> > ---
> >
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 74 +++---
> > drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +
> > 2 files changed, 70 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index b0ff304ce3dc..1b874cfd40f3
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
[snip]
> > @@ -187,6 +186,67 @@ static void rcar_du_vsp_plane_setup(struct
> > rcar_du_vsp_plane *plane)
> > vsp1_du_atomic_update(plane->vsp->vsp, plane->index, &cfg);
> > }
> >
> > +static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
> > + struct drm_plane_state *state)
> > +{
> > + struct rcar_du_vsp_plane_state *rstate =
to_rcar_vsp_plane_state(state);
> > + struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
> > + struct rcar_du_device *rcdu = vsp->dev;
> > + unsigned int i;
>
> Unsigned here..
>
> > + int ret;
> > +
> > + if (!state->fb)
> > + return 0;
> > +
> > + for (i = 0; i < rstate->format->planes; ++i) {
> > + struct drm_gem_cma_object *gem =
> > + drm_fb_cma_get_gem_obj(state->fb, i);
> > + struct sg_table *sgt = &rstate->sg_tables[i];
> > +
> > + ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr, gem->paddr,
> > + gem->base.size);
> > + if (ret)
> > + goto fail;
> > +
> > + ret = vsp1_du_map_sg(vsp->vsp, sgt);
> > + if (!ret) {
> > + sg_free_table(sgt);
> > + ret = -ENOMEM;
> > + goto fail;
> > + }
> > + }
> > +
> > + return 0;
> > +
> > +fail:
> > + for (i--; i >= 0; i--) {
>
> Means that this loop will never exit; i will always be >= 0;
>
> I'd propose just making signed for this usage.
>
> I've checked the i values for the breakouts - so they are good, and we need
> to use i == 0 to unmap the last table.
>
> > + struct sg_table *sgt = &rstate->sg_tables[i];
How about keep i unsigned and using
for (; i > 0; i--) {
struct sg_table *sgt = &rstate->sg_tables[i-1];
...
}
If you want to fix while applying, you can pick your favourite version.
> > +
> > + vsp1_du_unmap_sg(vsp->vsp, sgt);
> > + sg_free_table(sgt);
> > + }
> > +
> > + return ret;
> > +}
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 2/3] dt-bindings: display: Add STM32 DSI host driver
On Fri, May 19, 2017 at 11:25 AM, Philippe CORNU wrote: > > > On 05/18/2017 11:42 PM, Rob Herring wrote: >> On Fri, May 12, 2017 at 04:56:28PM +0200, Philippe CORNU wrote: >>> This patch adds documentation of device tree bindings for the STM32 >>> DSI host driver based on the Synopsys DW MIPI DSI driver from Rockchip. >>> >>> Signed-off-by: Philippe CORNU >>> --- >>> .../devicetree/bindings/display/st,stm32-ltdc.txt | 92 >>> +- >>> 1 file changed, 90 insertions(+), 2 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt >>> b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt >>> index 8e14769..a61381b 100644 >>> --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt >>> +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt >>> @@ -1,7 +1,6 @@ >>> * STMicroelectronics STM32 lcd-tft display controller >>> >>> - ltdc: lcd-tft display controller host >>> - must be a sub-node of st-display-subsystem >> >> Why is this removed? The "must" refers to the location, not whether >> present or not if that's what you were trying to change. >> > Dear Rob, > Many thanks for your comments. > > There is no need anymore to have a st-display-subsystem parent node in > the device tree for the ltdc, that is why I removed this "must" information. Okay, that's good because I'm not a fan of them. That seems like an unrelated change though. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device
On Mon, May 22, 2017 at 2:52 PM, Kieran Bingham
wrote:
> My only distaste there is having to then add the [i-1] index to the sg_tables.
>
> I have just experimented with:
>
> fail:
> for (; i-- != 0;) {
> struct sg_table *sgt = &rstate->sg_tables[i];
> ...
> }
>
> This performs the correct loops, with the correct indexes, but does the
> decrement in the condition offend coding styles ?
>
> If that's disliked even more I'll just apply your suggestion.
You can still use "i-- > 0", which looks a little bit better IMHO.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device
Hello Geert and Kieran,
On Monday 22 May 2017 15:00:27 Geert Uytterhoeven wrote:
> On Mon, May 22, 2017 at 2:52 PM, Kieran Bingham wrote:
> > My only distaste there is having to then add the [i-1] index to the
> > sg_tables.
> >
> > I have just experimented with:
> >
> > fail:
> > for (; i-- != 0;) {
> > struct sg_table *sgt = &rstate->sg_tables[i];
> > ...
> > }
> >
> > This performs the correct loops, with the correct indexes, but does the
> > decrement in the condition offend coding styles ?
> >
> > If that's disliked even more I'll just apply your suggestion.
>
> You can still use "i-- > 0", which looks a little bit better IMHO.
I'm fine with that option too.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 0/3] Cleanup evergreen/si IRQ handling code
On Sat, 2017-05-20 at 13:39 +0200, Christian König wrote: > Am 20.05.2017 um 01:48 schrieb Lyude: > > This is the first part of me going through and cleaning up the IRQ > > handling > > code for radeon, since after taking a look at it the other day > > while trying to > > debug something I realized basically all of the code was copy > > pasted > > everywhere, and quite difficult to actually read through. > > > > Will come up with something for r600 and cik once I've got the > > chipsets on hand > > to test with. > > > > Lyude (3): > > drm/radeon: Cleanup display interrupt handling for evergreen, si > > drm/radeon: Cleanup HDMI audio interrupt handling for evergreen > > drm/radeon: Cleanup pageflipping IRQ handling for evergreen, si > > I don't have time to do a line by line review, but what I saw looked > very good to me. > > So the whole seres is Acked-by: Christian König .com>. > > BTW: You don't want to take a look at the other hw generations as > well? Oh don't worry, I'm already planning on that! The next chance I have available I'll be going my coworker's GPUs so I can get the hardware I need to test refactors I write of the rest of the hw gen's IRQ handling code. :) > > Regards, > Christian. > > > > > drivers/gpu/drm/radeon/evergreen.c | 943 ++- > > - > > drivers/gpu/drm/radeon/radeon.h | 27 +- > > drivers/gpu/drm/radeon/radeon_irq_kms.c | 35 ++ > > drivers/gpu/drm/radeon/si.c | 655 + > > - > > 4 files changed, 344 insertions(+), 1316 deletions(-) > > > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
Hi Marek, On Fri, May 5, 2017 at 3:01 PM, Fabio Estevam wrote: > According to the eLCDIF initialization steps listed in the MX6SX > Reference Manual the eLCDIF block reset is mandatory. > > Without performing the eLCDIF reset the display shows garbage content > when the kernel boots. > > In earlier tests this issue has not been observed because the bootloader > was previously showing a splash screen and the bootloader display driver > does properly implement the eLCDIF reset. > > Add the eLCDIF reset to the driver, so that it can operate correctly > independently of the bootloader. > > Tested on a imx6sx-sdb board. > > Cc: > Signed-off-by: Fabio Estevam > --- > Changes since v2: > > - Remove unneeded udelay(1) - Marek Any comments about v3? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99784] AMD 7470m When VGA plugged into laptop, only one monitor working at a time
https://bugs.freedesktop.org/show_bug.cgi?id=99784 --- Comment #15 from lazane...@gmail.com --- Created attachment 131434 --> https://bugs.freedesktop.org/attachment.cgi?id=131434&action=edit Kernel oops at drm module (4.12.rc2 kernel) Just tested 4.12.rc2 kernel, and had another kernel oops in drm related functions (at line 909 in attachment). -- 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] drm/radeon: Fix oops upon driver load on PowerXpress laptops
On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote:
> On Thu, May 18 2017, Lukas Wunner wrote:
[snip]
> > Reported-by: Nicolai Stange
> > Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with
> > vga_switcheroo")
> > Signed-off-by: Lukas Wunner
> > ---
> >
> > Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
> > needs to be fixed, so sending out with a proper commit message now.
> > The bug was only introduced to radeon, not amdgpu.
>
> Tested-by: Nicolai Stange
>
> Thanks for the quick fix!
>
> > @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
> > land before -rc3 because Sean Paul has already sent out the -rc2 pull.
> > I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
> > take it yourself? Whichever you prefer. Thanks & sorry for the breakage!
I've learned this morning that Alex is on vacation. I've pushed
the patch to drm-misc-fixes so that the issue is fixed in 4.12-rc3.
@Sean Paul: I've fast-forwarded to 4.12-rc2 before pushing, please
shout if I've done anything wrong. First time I'm doing this.
Thanks,
Lukas
> >
> > drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> > b/drivers/gpu/drm/radeon/radeon_kms.c
> > index 6a68d440bc44..d0ad03674250 100644
> > --- a/drivers/gpu/drm/radeon/radeon_kms.c
> > +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> > @@ -116,7 +116,7 @@ int radeon_driver_load_kms(struct drm_device *dev,
> > unsigned long flags)
> > if ((radeon_runtime_pm != 0) &&
> > radeon_has_atpx() &&
> > ((flags & RADEON_IS_IGP) == 0) &&
> > - !pci_is_thunderbolt_attached(rdev->pdev))
> > + !pci_is_thunderbolt_attached(dev->pdev))
> > flags |= RADEON_IS_PX;
> >
> > /* radeon_device_init should report only fatal error
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix deadlock retry loop in page_flip_ioctl
I failed to properly onion-wrap the unwind code: We acquire the vblank
reference before we start with the wait-wound locking dance, hence we
must make sure we retry before we drop the reference. Oops.
v2: The vblank_put must be after the frambuffer_put (Michel). I suck at
unwrapping code that doesn't use separate labels for each stage, but
checks each pointer first ... While re-reading everything I also
realized that we must clean up the fb refcounts, and specifically
plane->old_fb before we drop the locks, either in the final unlocking,
or in the w/w retry path. Hence the correct fix is to drop the
vblank_put to the very bottom.
Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl")
Cc: Harry Wentland
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sean Paul
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Reported-by: Tommi Rantala
Cc: Tommi Rantala
Cc: Michel Dänzer
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index fedd4d60d9cd..5dc8c4350602 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -948,8 +948,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
out:
- if (ret && crtc->funcs->page_flip_target)
- drm_crtc_vblank_put(crtc);
if (fb)
drm_framebuffer_put(fb);
if (crtc->primary->old_fb)
@@ -964,5 +962,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
+ if (ret && crtc->funcs->page_flip_target)
+ drm_crtc_vblank_put(crtc);
+
return ret;
}
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon
https://bugs.freedesktop.org/show_bug.cgi?id=97882 --- Comment #3 from Maxim Sheviakov --- Same here. Using Arch x86_64 with linux-ck 4.11.2 and mesa 17.1.0. AMDGPU's performance is about 60~70% of radeon's on MSI R7 370 Armor 2X. -- 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
[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon
https://bugs.freedesktop.org/show_bug.cgi?id=97882 --- Comment #4 from Maxim Sheviakov --- Created attachment 131435 --> https://bugs.freedesktop.org/attachment.cgi?id=131435&action=edit dmesg | egrep 'drm|amdgpu' -- 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
[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #47 from Eike --- This problem also occurs on certain graphics & monitor driver combinations on Windows and is according to the linked thread a firmware problem of the Asus MG279Q. This almost only happens with GCN2 AMD cards. There seems to exist a fix for this since a few weeks, which can only be applied by Asus' service centers. So if you have this monitor and experience these problems, try RMAing the monitor. I am currently waiting for my replacement monitor. I will tell you if it worked, when it gets here. Thread archive: https://rog.asus.com/forum/archive/index.php/t-87817.html The active thread is linked at the top of the archive. Also, please give feedback to the ASUS display team in the linked thread if RMA did or didn't work out for you. -- 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
[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #48 from Jonas --- I have an Asus MG278Q, which is the TN model, and the issue is not the same as explained in the thread you have linked. Under Archlinux what happens above 60Hz is a crazy flickering of almost all screen, which can be triggered by having many windows open, or simply a terminal compiling a kernel (which refreshes very fast). Under Windows I don't have this problem at all, in fact in linux it is possible to workaround it by setting a "high" power mode, but it is not very convenient because of temperatures and power draw. -- 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
[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon
https://bugs.freedesktop.org/show_bug.cgi?id=97882 --- Comment #5 from Maxim Sheviakov --- Created attachment 131436 --> https://bugs.freedesktop.org/attachment.cgi?id=131436&action=edit dmesg | egrep 'drm|radeon' -- 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
[PATCH] drm/pl111: add ARM_AMBA dependency
The driver is written in a way to enable compile-testing without
CONFIG_ARM_AMBA,
but it just causes needless warnings:
drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined but
not used [-Werror=unused-variable]
drivers/gpu/drm/pl111/pl111_drv.c:81:12: error: 'pl111_modeset_init' defined
but not used [-Werror=unused-function]
This removes the #ifdef instead, and adds a dependency on ARM_AMBA to
only let us build the driver when the base support is enabled.
Unfortunately, this requires removing one redundant 'select ARM_AMBA'
line from mach-s3c64xx to avoid a circular dependency.
It might be good to allow manually enabling ARM_AMBA when COMPILE_TEST
is turned on, but that should be a separate patch and may cause other
build regressions.
Fixes: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111")
Signed-off-by: Arnd Bergmann
---
arch/arm/mach-s3c64xx/Kconfig | 1 -
drivers/gpu/drm/pl111/Kconfig | 1 +
drivers/gpu/drm/pl111/pl111_drv.c | 2 --
3 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
index 459214fa20b4..5ee5ad74a3d6 100644
--- a/arch/arm/mach-s3c64xx/Kconfig
+++ b/arch/arm/mach-s3c64xx/Kconfig
@@ -40,7 +40,6 @@ config CPU_S3C6410
config S3C64XX_PL080
def_bool DMADEVICES
- select ARM_AMBA
select AMBA_PL08X
config S3C64XX_SETUP_SDHCI
diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index 309f4fd52de7..e2f393fcc4bf 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -2,6 +2,7 @@ config DRM_PL111
tristate "DRM Support for PL111 CLCD Controller"
depends on DRM
depends on ARM || ARM64 || COMPILE_TEST
+ depends on ARM_AMBA
depends on COMMON_CLK
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c
b/drivers/gpu/drm/pl111/pl111_drv.c
index 97095b1aa961..dce382f97f8c 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -179,7 +179,6 @@ static struct drm_driver pl111_drm_driver = {
#endif
};
-#ifdef CONFIG_ARM_AMBA
static int pl111_amba_probe(struct amba_device *amba_dev,
const struct amba_id *id)
{
@@ -262,7 +261,6 @@ static struct amba_driver pl111_amba_driver = {
};
module_amba_driver(pl111_amba_driver);
-#endif /* CONFIG_ARM_AMBA */
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_AUTHOR("ARM Ltd.");
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 97882] [amdgpu SI] amdgpu on SI devices is much slower then radeon
https://bugs.freedesktop.org/show_bug.cgi?id=97882 --- Comment #6 from Trevor Davenport --- >From phoronix's data this appears to not happen on Tahiti chips. The 270x and 370 are always slower on amdgpu compared to radeon. See http://www.phoronix.com/scan.php?page=article&item=linux-411-gcn10&num=2 -- 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 v4 00/10] Introduce new mode validation callbacks
On Mon, May 22, 2017 at 09:56:00AM +0200, Daniel Vetter wrote:
> On Fri, May 19, 2017 at 01:52:09AM +0100, Jose Abreu wrote:
> > This series is a follow up from the discussion at [1]. We start by
> > introducing crtc->mode_valid(), encoder->mode_valid() and
> > bridge->mode_valid() callbacks which will be used in followup
> > patches and also by cleaning the documentation a little bit. This
> > patch is available at [2] and the series depends on it.
> >
> > We proceed by introducing new helpers to call this new callbacks
> > at 1/10.
> >
> > At 2/10 a helper function is introduced that calls all mode_valid()
> > from a set of bridges.
> >
> > Next, at 3/10 we modify the connector probe helper so that only modes
> > which are supported by a given bridge+encoder+crtc combination are
> > probbed.
> >
> > At 4/10 we call all the mode_valid() callbacks for a given pipeline,
> > except the connector->mode_valid one, so that the mode is validated.
> > This is done before calling mode_fixup().
> >
> > Finally, from 5/10 to 10/10 we use the new callbacks in drivers that
> > can implement it.
> >
> > [1] https://patchwork.kernel.org/patch/9702233/
> > [2] https://lists.freedesktop.org/archives/dri-devel/2017-May/141761.html
> >
> > Jose Abreu (10):
> > drm: Add drm_{crtc/encoder/connector}_mode_valid()
> > drm: Introduce drm_bridge_mode_valid()
> > drm: Use new mode_valid() helpers in connector probe helper
> > drm: Use mode_valid() in atomic modeset
> > drm: arc: Use crtc->mode_valid() callback
> > drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback
> > drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback
> > drm/arm: malidp: Use crtc->mode_valid() callback
> > drm/atmel-hlcdc: Use crtc->mode_valid() callback
> > drm: vc4: Use crtc->mode_valid() and encoder->mode_valid() callbacks
>
> Looks all real nice, I think a bit more time to get acks/reviews/tested-by
> for the driver conversions and I'll go and vacuum this all up.
On that: You didn't cc driver maintainers on the driver conversion patches
(not all are bridge drivers maintainer by Archit&co), without that they
might miss it. Please remember to do that (you might need to resend to get
their attention), scripts/get_maintainers.pl helps with that.
Thanks, Daniel
--
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
[Bug 100949] Power management problem on CIK/SI hybrid laptop
https://bugs.freedesktop.org/show_bug.cgi?id=100949 --- Comment #6 from Luya Tshimbalanga --- Last commit that worked prior to the breakage was on 20170410. I just updated to the recent 20170511 which seems partially resolving the issue but the error message below still remains. [22328.935171] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* displayport link status failed [22328.935217] [drm:amdgpu_atombios_dp_link_train [amdgpu]] *ERROR* clock recovery failed -- 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 libdrm] Android's major/minor/makedev live in
On 20 May 2017 at 19:24, enh wrote: > Bug: https://github.com/android-ndk/ndk/issues/398 > --- > Android.common.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Android.common.mk b/Android.common.mk > index 35c0f02c..b45ca10f 100644 > --- a/Android.common.mk > +++ b/Android.common.mk > @@ -1,5 +1,6 @@ > # XXX: Consider moving these to config.h analogous to autoconf. > LOCAL_CFLAGS += \ > + -DMAJOR_IN_SYSMACROS=1 \ > -DHAVE_VISIBILITY=1 \ > -DHAVE_LIBDRM_ATOMIC_PRIMITIVES=1 > > -- Thanks Elliott. Couple of tips for the future: Please set your name - $git config --global user.name "Elliott Hughes". If using git send-email is not possible, ensure that your client does not mangle with the patch. Rob, Mauro Gents can you check if this patch plays well on your setups. I don't want to break things on your end. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 2/2] drm: Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ to UAPI
On Fri, May 19, 2017 at 04:50:17PM -0400, Robert Foss wrote:
> Add DRM_MODE_ROTATE_ and DRM_MODE_REFLECT_ defines to the UAPI
> as a convenience.
>
> Ideally the DRM_ROTATE_ and DRM_REFLECT_ property ids are looked up
> through the atomic API, but realizing that userspace is likely to take
> shortcuts and assume that the enum values are what is sent over the
> wire.
>
> As a result these defines are provided purely as a convenience to
> userspace applications.
>
> Signed-off-by: Robert Foss
> Reviewed-by: Emil Velikov
> Reviewed-by: Sinclair Yeh
> Acked-by: Liviu Dudau
> ---
> Changes since v3:
> - Switched away from past tense in comments
> - Add define name change to previously mis-spelled DRM_REFLECT_X comment
> - Improved the comment for the DRM_MODE_REFLECT_ comment
>
> Changes since v2:
> - Changed define prefix from DRM_MODE_PROP_ to DRM_MODE_
> - Fix compilation errors
> - Changed comment formatting
> - Deduplicated comment lines
> - Clarified DRM_MODE_PROP_REFLECT_ comment
>
> Changes since v1:
> - Moved defines from drm.h to drm_mode.h
> - Changed define prefix from DRM_ to DRM_MODE_PROP_
> - Updated uses of the defines to the new prefix
> - Removed include from drm_rect.c
> - Stopped using the BIT() macro
>
> drivers/gpu/drm/arm/malidp_drv.h| 2 +-
> drivers/gpu/drm/arm/malidp_planes.c | 18 -
> drivers/gpu/drm/armada/armada_overlay.c | 2 +-
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 20 +-
> drivers/gpu/drm/drm_atomic.c| 2 +-
> drivers/gpu/drm/drm_atomic_helper.c | 2 +-
> drivers/gpu/drm/drm_blend.c | 45 +++---
> drivers/gpu/drm/drm_fb_helper.c | 4 +-
> drivers/gpu/drm/drm_plane_helper.c | 2 +-
> drivers/gpu/drm/drm_rect.c | 36 +-
> drivers/gpu/drm/i915/i915_debugfs.c | 14 +++
> drivers/gpu/drm/i915/intel_atomic_plane.c | 6 +--
> drivers/gpu/drm/i915/intel_display.c| 50
> -
> drivers/gpu/drm/i915/intel_fbc.c| 2 +-
> drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
> drivers/gpu/drm/i915/intel_sprite.c | 20 +-
> drivers/gpu/drm/imx/ipuv3-plane.c | 2 +-
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 30 +++
> drivers/gpu/drm/nouveau/nv50_display.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_drv.c | 4 +-
> drivers/gpu/drm/omapdrm/omap_fb.c | 18 -
> drivers/gpu/drm/omapdrm/omap_plane.c| 16
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +-
> include/drm/drm_blend.h | 21 +--
> include/uapi/drm/drm_mode.h | 49 +++-
> 25 files changed, 202 insertions(+), 171 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.h
> b/drivers/gpu/drm/arm/malidp_drv.h
> index 040311ffcaec..2e2033140efc 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.h
> +++ b/drivers/gpu/drm/arm/malidp_drv.h
> @@ -65,6 +65,6 @@ void malidp_de_planes_destroy(struct drm_device *drm);
> int malidp_crtc_init(struct drm_device *drm);
>
> /* often used combination of rotational bits */
> -#define MALIDP_ROTATED_MASK (DRM_ROTATE_90 | DRM_ROTATE_270)
> +#define MALIDP_ROTATED_MASK (DRM_MODE_ROTATE_90 | DRM_MODE_ROTATE_270)
>
> #endif /* __MALIDP_DRV_H__ */
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index 814fda23cead..063a8d2b0be3 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -80,7 +80,7 @@ static void malidp_plane_reset(struct drm_plane *plane)
> state = kzalloc(sizeof(*state), GFP_KERNEL);
> if (state) {
> state->base.plane = plane;
> - state->base.rotation = DRM_ROTATE_0;
> + state->base.rotation = DRM_MODE_ROTATE_0;
> plane->state = &state->base;
> }
> }
> @@ -221,7 +221,7 @@ static int malidp_de_plane_check(struct drm_plane *plane,
> return ret;
>
> /* packed RGB888 / BGR888 can't be rotated or flipped */
> - if (state->rotation != DRM_ROTATE_0 &&
> + if (state->rotation != DRM_MODE_ROTATE_0 &&
> (fb->format->format == DRM_FORMAT_RGB888 ||
>fb->format->format == DRM_FORMAT_BGR888))
> return -EINVAL;
> @@ -315,12 +315,12 @@ static void malidp_de_plane_update(struct drm_plane
> *plane,
> val &= ~LAYER_ROT_MASK;
>
> /* setup the rotation and axis flip bits */
> - if (plane->state->rotation & DRM_ROTATE_MASK)
> - val |= ilog2(plane->state->rotation & DRM_ROTATE_MASK) <<
> + if (plane->state->rotation & DRM_MODE_ROTATE_MASK)
> + val |= ilog2(plane->state->rotation & DRM_MODE_ROTATE_MASK) <<
> LAYER_ROT_OFFSET;
[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate
https://bugs.freedesktop.org/show_bug.cgi?id=93826 --- Comment #49 from Rodhos --- My monitor is Samsung SyncMaster 2032BW. It happens after Ubuntu changing the default drivers. -- 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] drm/pl111: add ARM_AMBA dependency
Arnd Bergmann writes: > The driver is written in a way to enable compile-testing without > CONFIG_ARM_AMBA, > but it just causes needless warnings: > > drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined > but not used [-Werror=unused-variable] > drivers/gpu/drm/pl111/pl111_drv.c:81:12: error: 'pl111_modeset_init' defined > but not used [-Werror=unused-function] > > This removes the #ifdef instead, and adds a dependency on ARM_AMBA to > only let us build the driver when the base support is enabled. > > Unfortunately, this requires removing one redundant 'select ARM_AMBA' > line from mach-s3c64xx to avoid a circular dependency. > > It might be good to allow manually enabling ARM_AMBA when COMPILE_TEST > is turned on, but that should be a separate patch and may cause other > build regressions. If I understand the Kconfig, you're effectively disabling the build on COMPILE_TEST && !ARM. I'd rather that we just fix up the warnings, so that people can keep build-testing DRM drivers: https://patchwork.kernel.org/patch/9737857/ signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 101145] Wine game needs GLSL override for fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=101145 Bug ID: 101145 Summary: Wine game needs GLSL override for fullscreen Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: wy...@openmailbox.org QA Contact: dri-devel@lists.freedesktop.org Created attachment 131437 --> https://bugs.freedesktop.org/attachment.cgi?id=131437&action=edit bug I have wine game that corrupts monitor after entering fullscreen. Windowed uses GDI but fullscreen is DirectX. Overriding GL versions help as workaround. MESA_GLSL_VERSION_OVERRIDE=110 (MUST be 110) MESA_GL_VERSION_OVERRIDE=3.0 (must be <= 3.0) This happens with softpipe and llvmpipe too and without override they show black screen and output: fixme:d3d:wined3d_guess_card No card selector available for card vendor (using GL_RENDERER "Gallium 0.4 on softpipe"). Game enters fullscreen with something like IDirectDraw2::SetCooperativeLevel -> IDirectDraw2::SetVideoMode. Original bug: bugs.winehq.org/show_bug.cgi?id=41283. Graphics: Card: Advanced Micro Devices [AMD/ATI] Tonga PRO [Radeon R9 285/380] Display Server: X.Org 1.19.3 driver: amdgpu Resolution: 1920x1080@60.00hz, 1920x1080@60.00hz GLX Renderer: Gallium 0.4 on AMD TONGA (DRM 3.15.0 / 4.12.0-rc1-g2ea659a9ef48, LLVM 5.0.0) GLX Version: 3.0 Mesa 17.2.0-devel (git-1586768e74) -- 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
[Bug 101145] Wine game needs GLSL override for fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=101145 --- Comment #1 from wyrex --- Created attachment 131438 --> https://bugs.freedesktop.org/attachment.cgi?id=131438&action=edit without override -- 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
[Bug 101145] Wine game needs GLSL override for fullscreen
https://bugs.freedesktop.org/show_bug.cgi?id=101145 --- Comment #2 from wyrex --- Created attachment 131439 --> https://bugs.freedesktop.org/attachment.cgi?id=131439&action=edit log with override -- 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 v3] drm: mxsfb_crtc: Reset the eLCDIF controller
Hi Marek, On Mon, May 22, 2017 at 11:20 AM, Marek Vasut wrote: > IMO it's OK. > > Reviewed-by: Marek Vasut Thanks for the feedback. Do you plan to send Dave a pull request so that this one can reach 4.12-rc? Thanks ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Fix deadlock retry loop in page_flip_ioctl
2017-05-22 16:59 GMT+03:00 Daniel Vetter :
> I failed to properly onion-wrap the unwind code: We acquire the vblank
> reference before we start with the wait-wound locking dance, hence we
> must make sure we retry before we drop the reference. Oops.
>
> v2: The vblank_put must be after the frambuffer_put (Michel). I suck at
> unwrapping code that doesn't use separate labels for each stage, but
> checks each pointer first ... While re-reading everything I also
> realized that we must clean up the fb refcounts, and specifically
> plane->old_fb before we drop the locks, either in the final unlocking,
> or in the w/w retry path. Hence the correct fix is to drop the
> vblank_put to the very bottom.
>
> Fixes: 29dc0d1de182 ("drm: Roll out acquire context for the page_flip ioctl")
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: David Airlie
> Cc: dri-devel@lists.freedesktop.org
> Reported-by: Tommi Rantala
> Cc: Tommi Rantala
> Cc: Michel Dänzer
> Signed-off-by: Daniel Vetter
Thanks, confirmed that this fixes the warning that I was seeing!
Tested-by: Tommi Rantala
> ---
> drivers/gpu/drm/drm_plane.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index fedd4d60d9cd..5dc8c4350602 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -948,8 +948,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> }
>
> out:
> - if (ret && crtc->funcs->page_flip_target)
> - drm_crtc_vblank_put(crtc);
> if (fb)
> drm_framebuffer_put(fb);
> if (crtc->primary->old_fb)
> @@ -964,5 +962,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
> drm_modeset_drop_locks(&ctx);
> drm_modeset_acquire_fini(&ctx);
>
> + if (ret && crtc->funcs->page_flip_target)
> + drm_crtc_vblank_put(crtc);
> +
> return ret;
> }
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 195743] Screen flicker and instability on hdmi monitors with AMDGPU, EDID problems
https://bugzilla.kernel.org/show_bug.cgi?id=195743 keziolio...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from keziolio...@gmail.com --- That was probably an hardware issue, closing -- 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] drm/radeon: Fix oops upon driver load on PowerXpress laptops
On Thu, May 18, 2017 at 09:33:44PM +0200, Lukas Wunner wrote:
> Nicolai Stange reports the following oops which is caused by
> dereferencing rdev->pdev before it's subsequently set by
> radeon_device_init(). Fix it.
>
> BUG: unable to handle kernel NULL pointer dereference at 07cb
> IP: radeon_driver_load_kms+0xeb/0x230 [radeon]
> PGD 0
> P4D 0
>
> Oops: [#1] SMP
> Modules linked in: amdkfd amd_iommu_v2 i915(+) radeon(+) i2c_algo_bit
> drm_kms_helper ttm e1000e drm sdhci_pci sdhci_acpi ptp sdhci crc32c_intel
> serio_raw mmc_core pps_core video i2c_hid hid_plantronics
> CPU: 4 PID: 389 Comm: systemd-udevd Not tainted 4.12.0-rc1-next-20170515+ #1
> Hardware name: Dell Inc. Latitude E6540/0725FP, BIOS A10 06/26/2014
> task: 97d62c8f task.stack: b96f01478000
> RIP: 0010:radeon_driver_load_kms+0xeb/0x230 [radeon]
> RSP: 0018:b96f0147b9d0 EFLAGS: 00010246
> RAX: RBX: 97d620085000 RCX: 00610037
> RDX: RSI: 002b RDI:
> RBP: b96f0147b9e8 R08: 0002 R09: b96f0147b924
> R10: R11: 97d62edd2ec0 R12: 97d628d5c000
> R13: 00610037 R14: c0698280 R15:
> FS: 7f496363d8c0() GS:97d62eb0() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 07cb CR3: 00022c14c000 CR4: 001406e0
> Call Trace:
>drm_dev_register+0x146/0x1d0 [drm]
>drm_get_pci_dev+0x9a/0x180 [drm]
>radeon_pci_probe+0xb8/0xe0 [radeon]
>local_pci_probe+0x45/0xa0
>pci_device_probe+0x14f/0x1a0
>driver_probe_device+0x29c/0x450
>__driver_attach+0xdf/0xf0
>? driver_probe_device+0x450/0x450
>bus_for_each_dev+0x6c/0xc0
>driver_attach+0x1e/0x20
>bus_add_driver+0x170/0x270
>driver_register+0x60/0xe0
>? 0xc0508000
>__pci_register_driver+0x4c/0x50
>drm_pci_init+0xeb/0x100 [drm]
>? vga_switcheroo_register_handler+0x6a/0x90
>? 0xc0508000
>radeon_init+0x98/0xb6 [radeon]
>do_one_initcall+0x52/0x1a0
>? __vunmap+0x81/0xb0
>? kmem_cache_alloc_trace+0x159/0x1b0
>? do_init_module+0x27/0x1f8
>do_init_module+0x5f/0x1f8
>load_module+0x27ce/0x2be0
>SYSC_finit_module+0xdf/0x110
>? SYSC_finit_module+0xdf/0x110
>SyS_finit_module+0xe/0x10
>do_syscall_64+0x67/0x150
>entry_SYSCALL64_slow_path+0x25/0x25
> RIP: 0033:0x7f4962295679
> RSP: 002b:7ffdd8c4f878 EFLAGS: 0246 ORIG_RAX: 0139
> RAX: ffda RBX: 55c014ed8200 RCX: 7f4962295679
> RDX: RSI: 7f4962dd19c5 RDI: 0010
> RBP: 7f4962dd19c5 R08: R09: 7ffdd8c4f990
> R10: 0010 R11: 0246 R12:
> R13: 55c014ed81a0 R14: 0002 R15: 55c0149d1fca
> Code: 5d 5d c3 8b 05 a7 05 14 00 49 81 cd 00 00 08 00 85 c0 74 a3 e8 e7 c0
> 0e 00 84 c0 74 9a 41 f7 c5 00 00 02 00 75 91 49 8b 44 24 10 <0f> b6 90 cb 07
> 00 00 f6 c2 20 74 1e e9 7b ff ff ff 48 8b 40 38
> RIP: radeon_driver_load_kms+0xeb/0x230 [radeon] RSP: b96f0147b9d0
> CR2: 07cb
> ---[ end trace 89cc4ba7e569c65c ]---
>
> Reported-by: Nicolai Stange
> Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with
> vga_switcheroo")
> Signed-off-by: Lukas Wunner
> ---
>
> Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
> needs to be fixed, so sending out with a proper commit message now.
> The bug was only introduced to radeon, not amdgpu.
>
> @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
> land before -rc3 because Sean Paul has already sent out the -rc2 pull.
> I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
> take it yourself? Whichever you prefer. Thanks & sorry for the breakage!
Just noticed that this has landed already in drm-misc-fixes, without any
r-b or at least an ack from radeon driver folks. That's breaking the
drm-misc rules, we need at least an ack for small drivers (which radeon
really isn't) and a full reviewed-by tag on everything else.
Patch doesn't look wrong, so not much harm, but please follow the ground
rules and especially don't ever push your own patches without any peer
feedback.
Thanks, Daniel
>
> drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index 6a68d440bc44..d0ad03674250 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -116,7 +116,7 @@ int radeon_driver_load_kms(struct drm_device *dev,
> unsigned long flags)
> if ((radeon_runtime_pm != 0) &&
> radeon_has_atpx() &&
> ((flags & RADEON_IS_IGP) == 0) &&
> - !pci_is_thunderbolt_attached(rdev->pdev))
> +
Re: [PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name
On Tue, May 16, 2017 at 12:10:42PM +0100, Chris Wilson wrote:
> Constructing the name takes the majority of the time for allocating a
> sync_file to wrap a fence, and the name is very rarely used (only via
> the sync_file status user interface). To reduce the impact on the common
> path (that of creating sync_file to pass around), defer the construction
> of the name until it is first used.
>
> v2: Update kerneldoc (kbuild test robot)
> v3: sync_debug.c was peeking at the name
> v4: Comment upon the potential race between two users of
> sync_file_get_name() and claim that such a race is below the level of
> notice. However, to prevent any future nuisance, use a global spinlock
> to serialize the assignment of the name.
> v5: Completely avoid the read/write race by only storing the name passed
> in from the user inside sync_file->user_name and passing in a buffer to
> dynamically construct the name otherwise.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Gustavo Padovan
> Cc: Daniel Vetter
> Cc: David Herrmann
> ---
> drivers/dma-buf/sync_debug.c | 4 +++-
> drivers/dma-buf/sync_file.c | 39 ---
> include/linux/sync_file.h| 5 +++--
> 3 files changed, 38 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> index 4b1731ee7458..59a3b2f8ee91 100644
> --- a/drivers/dma-buf/sync_debug.c
> +++ b/drivers/dma-buf/sync_debug.c
> @@ -132,9 +132,11 @@ static void sync_print_obj(struct seq_file *s, struct
> sync_timeline *obj)
> static void sync_print_sync_file(struct seq_file *s,
> struct sync_file *sync_file)
> {
> + char buf[128];
> int i;
>
> - seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
> + seq_printf(s, "[%p] %s: %s\n", sync_file,
> +sync_file_get_name(sync_file, buf, sizeof(buf)),
> sync_status_str(dma_fence_get_status(sync_file->fence)));
>
> if (dma_fence_is_array(sync_file->fence)) {
> diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
> index c9eb4997cfcc..d7e219d2669d 100644
> --- a/drivers/dma-buf/sync_file.c
> +++ b/drivers/dma-buf/sync_file.c
> @@ -80,11 +80,6 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
>
> sync_file->fence = dma_fence_get(fence);
>
> - snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
> - fence->ops->get_driver_name(fence),
> - fence->ops->get_timeline_name(fence), fence->context,
> - fence->seqno);
> -
> return sync_file;
> }
> EXPORT_SYMBOL(sync_file_create);
> @@ -129,6 +124,36 @@ struct dma_fence *sync_file_get_fence(int fd)
> }
> EXPORT_SYMBOL(sync_file_get_fence);
>
> +/**
> + * sync_file_get_name - get the name of the sync_file
> + * @sync_file: sync_file to get the fence from
> + * @buf: destination buffer to copy sync_file name into
> + * @len: available size of destination buffer.
> + *
> + * Each sync_file may have a name assigned either by the user (when merging
> + * sync_files together) or created from the fence it contains. In the latter
> + * case construction of the name is deferred until use, and so requires
> + * sync_file_get_name().
> + *
> + * Returns: a string representing the name.
> + */
> +char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
> +{
> + if (sync_file->user_name[0]) {
> + strlcpy(buf, sync_file->user_name, len);
> + } else {
> + struct dma_fence *fence = sync_file->fence;
> +
> + snprintf(buf, len, "%s-%s%llu-%d",
> + fence->ops->get_driver_name(fence),
> + fence->ops->get_timeline_name(fence),
> + fence->context,
> + fence->seqno);
> + }
> +
> + return buf;
> +}
> +
> static int sync_file_set_fence(struct sync_file *sync_file,
> struct dma_fence **fences, int num_fences)
> {
> @@ -266,7 +291,7 @@ static struct sync_file *sync_file_merge(const char
> *name, struct sync_file *a,
> goto err;
> }
>
> - strlcpy(sync_file->name, name, sizeof(sync_file->name));
> + strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
> return sync_file;
>
> err:
> @@ -419,7 +444,7 @@ static long sync_file_ioctl_fence_info(struct sync_file
> *sync_file,
> }
>
> no_fences:
> - strlcpy(info.name, sync_file->name, sizeof(info.name));
> + sync_file_get_name(sync_file, info.name, sizeof(info.name));
> info.status = dma_fence_is_signaled(sync_file->fence);
> info.num_fences = num_fences;
>
> diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
> index d37beefdfbd5..5226d62ae91b 100644
> --- a/include/linux/sync_file.h
> +++ b/include/linux/sync_file.h
> @@ -23,7 +23,7 @@
> /**
> * struct sync_file - sync file
Re: [PATCH] drm/radeon: Fix oops upon driver load on PowerXpress laptops
On Mon, May 22, 2017 at 04:04:07PM +0200, Lukas Wunner wrote:
> On Sun, May 21, 2017 at 09:31:09AM +0200, Nicolai Stange wrote:
> > On Thu, May 18 2017, Lukas Wunner wrote:
> [snip]
> > > Reported-by: Nicolai Stange
> > > Fixes: 7ffb0ce31cf9 ("drm/radeon: Don't register Thunderbolt eGPU with
> > > vga_switcheroo")
> > > Signed-off-by: Lukas Wunner
> > > ---
> > >
> > > Awaiting a Tested-by: from Nicolai, but it's clear this is a bug and
> > > needs to be fixed, so sending out with a proper commit message now.
> > > The bug was only introduced to radeon, not amdgpu.
> >
> > Tested-by: Nicolai Stange
> >
> > Thanks for the quick fix!
> >
> > > @Alex Deucher: I could push this to drm-misc-fixes but then it wouldn't
> > > land before -rc3 because Sean Paul has already sent out the -rc2 pull.
> > > I notice you haven't sent out a pull for -rc2 yet, so maybe you want to
> > > take it yourself? Whichever you prefer. Thanks & sorry for the breakage!
>
> I've learned this morning that Alex is on vacation. I've pushed
> the patch to drm-misc-fixes so that the issue is fixed in 4.12-rc3.
>
> @Sean Paul: I've fast-forwarded to 4.12-rc2 before pushing, please
> shout if I've done anything wrong. First time I'm doing this.
No shouting, but a heads-up on IRC is probably warranted for both pushing a
patch without R-b and fast-forwarding one of the branches.
Sean
>
> Thanks,
>
> Lukas
>
> > >
> > > drivers/gpu/drm/radeon/radeon_kms.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
> > > b/drivers/gpu/drm/radeon/radeon_kms.c
> > > index 6a68d440bc44..d0ad03674250 100644
> > > --- a/drivers/gpu/drm/radeon/radeon_kms.c
> > > +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> > > @@ -116,7 +116,7 @@ int radeon_driver_load_kms(struct drm_device *dev,
> > > unsigned long flags)
> > > if ((radeon_runtime_pm != 0) &&
> > > radeon_has_atpx() &&
> > > ((flags & RADEON_IS_IGP) == 0) &&
> > > - !pci_is_thunderbolt_attached(rdev->pdev))
> > > + !pci_is_thunderbolt_attached(dev->pdev))
> > > flags |= RADEON_IS_PX;
> > >
> > > /* radeon_device_init should report only fatal error
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] gpu: drm: gma500: remove two more dead variable
The dead code removal left two unused variables:
drivers/gpu/drm/gma500/mdfld_tpo_vid.c: In function 'tpo_vid_get_config_mode':
drivers/gpu/drm/gma500/mdfld_tpo_vid.c:34:31: error: unused variable 'ti'
[-Werror=unused-variable]
This removes them as well.
Fixes: 94d7fb4982d2 ("gpu: drm: gma500: remove dead code")
Signed-off-by: Arnd Bergmann
---
drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
index d40628e6810d..a9420bf9a419 100644
--- a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
+++ b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
@@ -30,8 +30,6 @@
static struct drm_display_mode *tpo_vid_get_config_mode(struct drm_device *dev)
{
struct drm_display_mode *mode;
- struct drm_psb_private *dev_priv = dev->dev_private;
- struct oaktrail_timing_info *ti = &dev_priv->gct_data.DTD;
mode = kzalloc(sizeof(*mode), GFP_KERNEL);
if (!mode)
--
2.9.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.
Laurent Pinchart writes: > Hi Eric, > > On Tuesday 16 May 2017 11:46:36 Eric Anholt wrote: > > [snip] > >> In terms of physical connections: >> >>[15-pin "DSI" connector on 2835] >> >> | I2C | DSI >>/ \SPI | >> [TS] [Atmel]--[TC358762] >>\| >> \PWM| >> \ | DPI >> [some backlight]--[some unknown panel] >> >> The binding I'm trying to create is to expose what's necessary for a >> driver that talks I2C to the Atmel, which then controls the PWM and does >> the command sequence over SPI to the Toshiba that sets up its end of the >> DSI link. > > According to the documentation I've been able to find, the TC358762 has an > SPI > master port through which it can output the commands DCS received from the > DSI > port, and an I2C slave port through which it can be configured by an external > device. If the connection between the microcontroller and the TC358762 is > indeed SPI and not I2C, I assume it's used by the microcontroller to receive > the DCS commands and perform control of the backlight (and possibly other > components) accordingly. By the way, is there any place where I can find a > leaked version of the non-public panel schematics ? ;-) Not that I know of. I don't know that you can control the backlight over DCS, given that I have no docs. We only send commands from Atmel to TC, not the other way around. > As far as I can tell from your patch series, you don't need to send any > command to the TC358762 over DSI. In that case I would model the panel in DT > as an I2C device, as all control goes through the I2C bus. The DSI video data > connection should then be modelled using the OF graph DT bindings. The result > will be a black box panel with a custom black box panel driver, using a > single > DT node. There's no need for a separate bridge instance. That's the cleanest > option I can come up with so far, and I agree that splitting TC358762 support > into a standalone bridge driver makes no sense in this case. I agree, it's just that when I submitted to drm-panel I was told that it didn't make sense as a single driver, so I went to all of this work instead. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/4] dt-bindings: Document the Raspberry Pi Touchscreen nodes.
Laurent Pinchart writes: > Hi Archit, > > On Friday 19 May 2017 14:24:36 Archit Taneja wrote: >> On 05/18/2017 08:25 PM, Laurent Pinchart wrote: >> > On Thursday 18 May 2017 13:56:19 Archit Taneja wrote: >> >> On 05/17/2017 12:16 AM, Eric Anholt wrote: >> > >> > [snip] >> > >> >>> In terms of physical connections: >> >>>[15-pin "DSI" connector on 2835] >> >>> | I2C | DSI >> >>>/ \SPI | >> >>> [TS] [Atmel]--[TC358762] >> >>>\| >> >>> \PWM| >> >>> \ | DPI >> >>> >> >>> [some backlight]--[some unknown panel] >> >>> >> >>> The binding I'm trying to create is to expose what's necessary for a >> >>> driver that talks I2C to the Atmel, which then controls the PWM and does >> >>> the command sequence over SPI to the Toshiba that sets up its end of the >> >>> DSI link. >> >> >> >> The bridge (Atmel + TC358762 combination) here looks like it's primarily >> >> an i2c device (i.e, the control bus is i2c). Therefore, the drm-bridge >> >> driver here should be an i2c driver instead of a mipi_dsi_driver. >> > >> > Glad to see we agree, that's what I've proposed in a separate answer :-) >> > I'd go one step further though, there should be no DRM bridge, just a DRM >> > panel. >> >> If the PCB containing the controller chips and the panel are part of a >> single casing, and the set up won't work with another panel, then yeah, I >> agree. If the bridge chips are on a separate adapter board, and there is a >> possibility to connect other panels, then maybe a separate DRM bridge and a >> DRM panel might be a safer bet. > > I thought it was a single black box, but upon closer inspection there's a > separate PCB with the Microcontroller and TC358762. > > Eric, do you know if it's possible to exchange the panel for another one (and > not just an model with identical features from another vendor, but another > panel with a different mode for instance) without reprogramming the > microcontroller, or is the bridge board tied to the panel model ? Not without finding some other panel with equivalent non-standard connectors / doing your own soldering, at a minimum. And we don't know what kind of programming the microcontroller does, since it's a black box. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH RESEND] drm: mxsfb_crtc: Reset the eLCDIF controller
From: Fabio Estevam
According to the eLCDIF initialization steps listed in the MX6SX
Reference Manual the eLCDIF block reset is mandatory.
Without performing the eLCDIF reset the display shows garbage content
when the kernel boots.
In earlier tests this issue has not been observed because the bootloader
was previously showing a splash screen and the bootloader display driver
does properly implement the eLCDIF reset.
Add the eLCDIF reset to the driver, so that it can operate correctly
independently of the bootloader.
Tested on a imx6sx-sdb board.
Cc: #4.11.x
Signed-off-by: Fabio Estevam
Reviewed-by: Marek Vasut
---
Daniel,
Marek suggested that this goes via drm-misc.
Thanks
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 42 ++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 1144e0c..0abe776 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -35,6 +35,13 @@
#include "mxsfb_drv.h"
#include "mxsfb_regs.h"
+#define MXS_SET_ADDR 0x4
+#define MXS_CLR_ADDR 0x8
+#define MODULE_CLKGATE BIT(30)
+#define MODULE_SFTRST BIT(31)
+/* 1 second delay should be plenty of time for block reset */
+#define RESET_TIMEOUT 100
+
static u32 set_hsync_pulse_width(struct mxsfb_drm_private *mxsfb, u32 val)
{
return (val & mxsfb->devdata->hs_wdth_mask) <<
@@ -159,6 +166,36 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
+/*
+ * Clear the bit and poll it cleared. This is usually called with
+ * a reset address and mask being either SFTRST(bit 31) or CLKGATE
+ * (bit 30).
+ */
+static int clear_poll_bit(void __iomem *addr, u32 mask)
+{
+ u32 reg;
+
+ writel(mask, addr + MXS_CLR_ADDR);
+ return readl_poll_timeout(addr, reg, !(reg & mask), 0, RESET_TIMEOUT);
+}
+
+static int mxsfb_reset_block(void __iomem *reset_addr)
+{
+ int ret;
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ writel(MODULE_CLKGATE, reset_addr + MXS_CLR_ADDR);
+
+ ret = clear_poll_bit(reset_addr, MODULE_SFTRST);
+ if (ret)
+ return ret;
+
+ return clear_poll_bit(reset_addr, MODULE_CLKGATE);
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
@@ -173,6 +210,11 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
*/
mxsfb_enable_axi_clk(mxsfb);
+ /* Mandatory eLCDIF reset as per the Reference Manual */
+ err = mxsfb_reset_block(mxsfb->base);
+ if (err)
+ return;
+
/* Clear the FIFOs */
writel(CTRL1_FIFO_CLEAR, mxsfb->base + LCDC_CTRL1 + REG_SET);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 194761] amdgpu driver breaks on Oland (SI)
https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #15 from Jean Delvare (jdelv...@suse.de) --- And it's not just me, see: https://bugzilla.opensuse.org/show_bug.cgi?id=1039806 -- 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] drm/pl111: add ARM_AMBA dependency
On Mon, May 22, 2017 at 6:32 PM, Krzysztof Kozlowski wrote:
> On Mon, May 22, 2017 at 05:20:08PM +0200, Arnd Bergmann wrote:
>> The driver is written in a way to enable compile-testing without
>> CONFIG_ARM_AMBA,
>> but it just causes needless warnings:
>>
>> drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined
>> but not used [-Werror=unused-variable]
>> drivers/gpu/drm/pl111/pl111_drv.c:81:12: error: 'pl111_modeset_init' defined
>> but not used [-Werror=unused-function]
>>
>> This removes the #ifdef instead, and adds a dependency on ARM_AMBA to
>> only let us build the driver when the base support is enabled.
>>
>> Unfortunately, this requires removing one redundant 'select ARM_AMBA'
>> line from mach-s3c64xx to avoid a circular dependency.
>>
>> It might be good to allow manually enabling ARM_AMBA when COMPILE_TEST
>> is turned on, but that should be a separate patch and may cause other
>> build regressions.
>>
>> Fixes: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111")
>> Signed-off-by: Arnd Bergmann
>> ---
>> arch/arm/mach-s3c64xx/Kconfig | 1 -
>> drivers/gpu/drm/pl111/Kconfig | 1 +
>> drivers/gpu/drm/pl111/pl111_drv.c | 2 --
>> 3 files changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
>> index 459214fa20b4..5ee5ad74a3d6 100644
>> --- a/arch/arm/mach-s3c64xx/Kconfig
>> +++ b/arch/arm/mach-s3c64xx/Kconfig
>> @@ -40,7 +40,6 @@ config CPU_S3C6410
>>
>> config S3C64XX_PL080
>> def_bool DMADEVICES
>> - select ARM_AMBA
>
> I must admit that I miss how pl111 DRM driver create circular dependency
> with S3C64XX_PL080 (or AMBA_PL08X?). Maybe it is unrelated change and
> should be a separate patch?
When I add 'depends on ARM_AMBA' for pl111, I get this dependency loop:
drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:63: symbol FB_DDC is selected by FB_CYBER2000_DDC
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:381: symbol FB_CYBER2000_DDC depends on FB_CYBER2000
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:369: symbol FB_CYBER2000 depends on FB
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:72: symbol DRM_KMS_FB_HELPER is selected by
DRM_KMS_CMA_HELPER
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/Kconfig:137: symbol DRM_KMS_CMA_HELPER is selected by DRM_PL111
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/gpu/drm/pl111/Kconfig:1: symbol DRM_PL111 depends on ARM_AMBA
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/amba/Kconfig:1: symbol ARM_AMBA is selected by S3C64XX_PL080
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
arch/arm/mach-s3c64xx/Kconfig:42: symbol S3C64XX_PL080 default value
contains DMADEVICES
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
drivers/dma/Kconfig:5: symbol DMADEVICES is selected by SND_SOC_SH4_SIU
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:29: symbol SND_SOC_SH4_SIU is selected by SND_SIU_MIGOR
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
sound/soc/sh/Kconfig:59: symbol SND_SIU_MIGOR depends on I2C
We could break the loop at any of those places, but the
S3C64XX_PL080 symbol seemed the easiest way since the
'select' there is completely unnecessary and it directly relates
to the change I made in PL111.
Arnd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/pl111: add ARM_AMBA dependency
On Mon, May 22, 2017 at 6:23 PM, Eric Anholt wrote: > Arnd Bergmann writes: > >> The driver is written in a way to enable compile-testing without >> CONFIG_ARM_AMBA, >> but it just causes needless warnings: >> >> drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined >> but not used [-Werror=unused-variable] >> drivers/gpu/drm/pl111/pl111_drv.c:81:12: error: 'pl111_modeset_init' defined >> but not used [-Werror=unused-function] >> >> This removes the #ifdef instead, and adds a dependency on ARM_AMBA to >> only let us build the driver when the base support is enabled. >> >> Unfortunately, this requires removing one redundant 'select ARM_AMBA' >> line from mach-s3c64xx to avoid a circular dependency. >> >> It might be good to allow manually enabling ARM_AMBA when COMPILE_TEST >> is turned on, but that should be a separate patch and may cause other >> build regressions. > > If I understand the Kconfig, you're effectively disabling the build on > COMPILE_TEST && !ARM. I'd rather that we just fix up the warnings, so > that people can keep build-testing DRM drivers: > > https://patchwork.kernel.org/patch/9737857/ That works too. When I tried the same, I thought it was a little too silly to have a file that effectively compiles into nothing. My initial approach did two things differently though: - use __maybe_unused instead of __used, since - annotate pl111_amba_driver instead of pl111_drm_driver/pl111_modeset_init, and keep only module_amba_driver() in the #ifdef. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100437] IO_PAGE_FAULT is spammed in dmesg
https://bugs.freedesktop.org/show_bug.cgi?id=100437 --- Comment #9 from Greg Turner --- Just another datapoint on this... I have this disease with a (non-reference) Asus RX480 in an Asus Sabertooth Gen3 R2.0 (or something like that, I can never remember exactly what it's called). It does not fix itself when I reboot. If I turn off IOMMU entirely in the BIOS (not just the memory hole), then it goes away (along, of course, with my iommu functionality, which I'm not thrilled about). I can also boot and avoid the spam with iommu=pt or iommu=soft. I have also seen brief "flashing screen" artifacts in xorg, which get more frequent if I stress the system (doesn't need to be graphics related). Whether these correlate with the log spam, I'm not entirely sure. I think it may, but it might instead have been related to a firmware loading problem that I've since resolved... I'd have to try it again to be sure. Like the OP, when I get the log spam I also see this: May 22 14:23:21 moneypit kernel: amdgpu: [powerplay] [AVFS] Something is broken. See log! May 22 14:23:21 moneypit kernel: amdgpu: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table! -- 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] drm/pl111: add ARM_AMBA dependency
Arnd Bergmann writes: > On Mon, May 22, 2017 at 6:23 PM, Eric Anholt wrote: >> Arnd Bergmann writes: >> >>> The driver is written in a way to enable compile-testing without >>> CONFIG_ARM_AMBA, >>> but it just causes needless warnings: >>> >>> drivers/gpu/drm/pl111/pl111_drv.c:149:26: error: 'pl111_drm_driver' defined >>> but not used [-Werror=unused-variable] >>> drivers/gpu/drm/pl111/pl111_drv.c:81:12: error: 'pl111_modeset_init' >>> defined but not used [-Werror=unused-function] >>> >>> This removes the #ifdef instead, and adds a dependency on ARM_AMBA to >>> only let us build the driver when the base support is enabled. >>> >>> Unfortunately, this requires removing one redundant 'select ARM_AMBA' >>> line from mach-s3c64xx to avoid a circular dependency. >>> >>> It might be good to allow manually enabling ARM_AMBA when COMPILE_TEST >>> is turned on, but that should be a separate patch and may cause other >>> build regressions. >> >> If I understand the Kconfig, you're effectively disabling the build on >> COMPILE_TEST && !ARM. I'd rather that we just fix up the warnings, so >> that people can keep build-testing DRM drivers: >> >> https://patchwork.kernel.org/patch/9737857/ > > That works too. When I tried the same, I thought it was a little too silly to > have a file that effectively compiles into nothing. > > My initial approach did two things differently though: > > - use __maybe_unused instead of __used, since > > - annotate pl111_amba_driver instead of > pl111_drm_driver/pl111_modeset_init, and keep only > module_amba_driver() in the #ifdef. Oh, yeah, we've eliminated the amba_request_regions() that used to be why the probe had to be under the #ifdef, so your solution would get us better coverage and simpler code. If you could send that patch to dri-devel today, I'll get it applied. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/pl111: Fix return value check in pl111_amba_probe()
Wei Yongjun writes:
> From: Wei Yongjun
>
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
> Fixes: bed41005e617 ("drm/pl111: Initial drm/kms driver for pl111")
> Signed-off-by: Wei Yongjun
Reviewed and applied. Thanks!
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: nouveau: add null check before pointer dereference
On 05/23/2017 05:12 AM, Gustavo A. R. Silva wrote:
Add null check before dereferencing pointer asyc
I've taken the patch into my tree, thanks!
Ben.
Addresses-Coverity-ID: 1397932
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/nouveau/nv50_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index a766324..052a60a 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -2107,7 +2107,8 @@ nv50_head_atomic_check(struct drm_crtc *crtc, struct
drm_crtc_state *state)
asyc->set.dither = true;
}
} else {
- asyc->set.mask = ~0;
+ if (asyc)
+ asyc->set.mask = ~0;
asyh->set.mask = ~0;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: gma500: remove dead code
On Fri, May 19, 2017 at 2:28 PM, Patrik Jakobsson
wrote:
> On Fri, May 19, 2017 at 11:19 AM, Gustavo A. R. Silva
> wrote:
>> Local variable use_gct is assigned to a constant value and it is never
>> updated again. Remove this variable and the dead code it guards.
>>
>> Addresses-Coverity-ID: 145690
>> Signed-off-by: Gustavo A. R. Silva
>
> I believe the first version is already in drm-misc. Actually this
> entire file can be removed. It was never hooked up and since nobody
> every complained I feel confident we can remove it.
Sorry my bad, it is actually in use since it's hardcoded. I'll pick up
Arnd's fix (unless he takes it through some other tree).
Thanks
Patrik
> Cheers
> Patrik
>
>> ---
>> Changes in v2:
>> Remove variables ti and dev_priv, which was causing a compilation warning.
>>
>> I have improved my testing to avoid similar issues in the future.
>> This is how I tested it this time:
>>
>> $ make allmodconfig
>> $ make drivers/gpu/drm/gma500/mdfld_tpo_vid.o
>>
>>
>> drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 53
>> ++
>> 1 file changed, 9 insertions(+), 44 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
>> b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
>> index d8d4170..a9420bf 100644
>> --- a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
>> +++ b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
>> @@ -30,55 +30,20 @@
>> static struct drm_display_mode *tpo_vid_get_config_mode(struct drm_device
>> *dev)
>> {
>> struct drm_display_mode *mode;
>> - struct drm_psb_private *dev_priv = dev->dev_private;
>> - struct oaktrail_timing_info *ti = &dev_priv->gct_data.DTD;
>> - bool use_gct = false;
>>
>> mode = kzalloc(sizeof(*mode), GFP_KERNEL);
>> if (!mode)
>> return NULL;
>>
>> - if (use_gct) {
>> - mode->hdisplay = (ti->hactive_hi << 8) | ti->hactive_lo;
>> - mode->vdisplay = (ti->vactive_hi << 8) | ti->vactive_lo;
>> - mode->hsync_start = mode->hdisplay +
>> - ((ti->hsync_offset_hi << 8) |
>> - ti->hsync_offset_lo);
>> - mode->hsync_end = mode->hsync_start +
>> - ((ti->hsync_pulse_width_hi << 8) |
>> - ti->hsync_pulse_width_lo);
>> - mode->htotal = mode->hdisplay + ((ti->hblank_hi << 8) |
>> -
>> ti->hblank_lo);
>> - mode->vsync_start =
>> - mode->vdisplay + ((ti->vsync_offset_hi << 8) |
>> - ti->vsync_offset_lo);
>> - mode->vsync_end =
>> - mode->vsync_start + ((ti->vsync_pulse_width_hi << 8)
>> |
>> - ti->vsync_pulse_width_lo);
>> - mode->vtotal = mode->vdisplay +
>> - ((ti->vblank_hi << 8) | ti->vblank_lo);
>> - mode->clock = ti->pixel_clock * 10;
>> -
>> - dev_dbg(dev->dev, "hdisplay is %d\n", mode->hdisplay);
>> - dev_dbg(dev->dev, "vdisplay is %d\n", mode->vdisplay);
>> - dev_dbg(dev->dev, "HSS is %d\n", mode->hsync_start);
>> - dev_dbg(dev->dev, "HSE is %d\n", mode->hsync_end);
>> - dev_dbg(dev->dev, "htotal is %d\n", mode->htotal);
>> - dev_dbg(dev->dev, "VSS is %d\n", mode->vsync_start);
>> - dev_dbg(dev->dev, "VSE is %d\n", mode->vsync_end);
>> - dev_dbg(dev->dev, "vtotal is %d\n", mode->vtotal);
>> - dev_dbg(dev->dev, "clock is %d\n", mode->clock);
>> - } else {
>> - mode->hdisplay = 864;
>> - mode->vdisplay = 480;
>> - mode->hsync_start = 873;
>> - mode->hsync_end = 876;
>> - mode->htotal = 887;
>> - mode->vsync_start = 487;
>> - mode->vsync_end = 490;
>> - mode->vtotal = 499;
>> - mode->clock = 33264;
>> - }
>> + mode->hdisplay = 864;
>> + mode->vdisplay = 480;
>> + mode->hsync_start = 873;
>> + mode->hsync_end = 876;
>> + mode->htotal = 887;
>> + mode->vsync_start = 487;
>> + mode->vsync_end = 490;
>> + mode->vtotal = 499;
>> + mode->clock = 33264;
>>
>> drm_mode_set_name(mode);
>> drm_mode_set_crtcinfo(mode, 0);
>> --
>> 2.5.0
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: drm: gma500: remove two more dead variable
On Mon, May 22, 2017 at 10:30 PM, Arnd Bergmann wrote:
> The dead code removal left two unused variables:
>
> drivers/gpu/drm/gma500/mdfld_tpo_vid.c: In function 'tpo_vid_get_config_mode':
> drivers/gpu/drm/gma500/mdfld_tpo_vid.c:34:31: error: unused variable 'ti'
> [-Werror=unused-variable]
>
> This removes them as well.
>
> Fixes: 94d7fb4982d2 ("gpu: drm: gma500: remove dead code")
> Signed-off-by: Arnd Bergmann
Thanks, I'll take this through drm-misc
Signed-off-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/gma500/mdfld_tpo_vid.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
> b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
> index d40628e6810d..a9420bf9a419 100644
> --- a/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
> +++ b/drivers/gpu/drm/gma500/mdfld_tpo_vid.c
> @@ -30,8 +30,6 @@
> static struct drm_display_mode *tpo_vid_get_config_mode(struct drm_device
> *dev)
> {
> struct drm_display_mode *mode;
> - struct drm_psb_private *dev_priv = dev->dev_private;
> - struct oaktrail_timing_info *ti = &dev_priv->gct_data.DTD;
>
> mode = kzalloc(sizeof(*mode), GFP_KERNEL);
> if (!mode)
> --
> 2.9.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/22] drm/tegra: Check whether page belongs to BO in tegra_bo_kmap()
On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote:
> This fixes an OOPS in case of out-of-bounds accessing of a kmap'ed cmdbuf
> (non-IOMMU allocation) while patching the relocations in do_relocs().
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/gem.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
> index 424569b53e57..ca0d4439e97b 100644
> --- a/drivers/gpu/drm/tegra/gem.c
> +++ b/drivers/gpu/drm/tegra/gem.c
> @@ -74,6 +74,9 @@ static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned
> int page)
> {
> struct tegra_bo *obj = host1x_to_tegra_bo(bo);
>
> + if (page * PAGE_SIZE >= obj->gem.size)
> + return NULL;
> +
> if (obj->vaddr)
> return obj->vaddr + page * PAGE_SIZE;
> else if (obj->gem.import_attach)
> --
> 2.13.0
>
Reviewed-by: Erik Faye-Lund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/22] gpu: host1x: Correct host1x_job_pin() error handling
On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote:
> In case of relocations / waitchecks patching failure the jobs pins stay
> referenced till DRM file get closed, wasting memory. Add the missed
> unpinning.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/host1x/job.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index d9933828fe87..14f3f957ffab 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -592,22 +592,20 @@ int host1x_job_pin(struct host1x_job *job, struct
> device *dev)
>
> err = do_relocs(job, g->bo);
> if (err)
> - break;
> + goto out;
>
> err = do_waitchks(job, host, g->bo);
> if (err)
> - break;
> + goto out;
> }
>
> - if (IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL) && !err) {
> - err = copy_gathers(job, dev);
> - if (err) {
> - host1x_job_unpin(job);
> - return err;
> - }
> - }
> + if (!IS_ENABLED(CONFIG_TEGRA_HOST1X_FIREWALL))
> + goto out;
>
> + err = copy_gathers(job, dev);
> out:
> + if (err)
> + host1x_job_unpin(job);
> wmb();
>
> return err;
> --
> 2.13.0
>
One subtle undocumented change here, is that wmb() now gets called in
the copy_gathers()-error case (just like it already does for the other
error-cases). That's seems like an OK change, so:
Reviewed-by: Erik Faye-Lund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 19/21] drm/sun4i: Add compatible for the A10s pipeline
On Wed, May 17, 2017 at 09:40:48AM +0200, Maxime Ripard wrote: > The A10s has a slightly different display pipeline than the A13, with an > HDMI controller. > > Add a compatible for it. > > Signed-off-by: Maxime Ripard > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 1 + > drivers/gpu/drm/sun4i/sun4i_drv.c | 1 + > 2 files changed, 2 insertions(+) Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/22] gpu: host1x: Forbid relocation address shifting in the firewall
On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote: > Incorrectly shifted relocation address will cause a lower memory corruption > and likely a hang on a write or a read of an arbitrary data in case of IOMMU > absent. As of now there is no use for the address shifting (at least on > Tegra20) and adding a proper shifting / sizes validation is much more work. > Let's forbid it in the firewall till a proper validation is implemented. > > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/host1x/job.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c > index 190353944d23..1a1568e64ba8 100644 > --- a/drivers/gpu/host1x/job.c > +++ b/drivers/gpu/host1x/job.c > @@ -332,6 +332,10 @@ static bool check_reloc(struct host1x_reloc *reloc, > struct host1x_bo *cmdbuf, > if (reloc->cmdbuf.bo != cmdbuf || reloc->cmdbuf.offset != offset) > return false; > > + /* relocation shift value validation isn't implemented yet */ > + if (reloc->shift) > + return false; > + > return true; > } > > -- > 2.13.0 > Good call. Reviewed-by: Erik Faye-Lund ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/22] gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall
On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote:
> Several channels could be made to write the same unit concurrently via the
> SETCLASS opcode, trusting userspace is a bad idea. It should be possible to
> drop the per-client channel reservation and add a per-unit locking by
> inserting MLOCK's to the command stream to re-allow the SETCLASS opcode, but
> it will be much more work. Let's forbid the unit-unrelated class changes for
> now.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/drm.c | 1 +
> drivers/gpu/drm/tegra/drm.h | 1 +
> drivers/gpu/drm/tegra/gr2d.c | 12
> drivers/gpu/host1x/job.c | 24
> include/linux/host1x.h | 5 -
> 5 files changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> index cdb05d6efde4..17416e1c219a 100644
> --- a/drivers/gpu/drm/tegra/drm.c
> +++ b/drivers/gpu/drm/tegra/drm.c
> @@ -531,6 +531,7 @@ int tegra_drm_submit(struct tegra_drm_context *context,
> }
>
> job->is_addr_reg = context->client->ops->is_addr_reg;
> + job->is_valid_class = context->client->ops->is_valid_class;
> job->syncpt_incrs = syncpt.incrs;
> job->syncpt_id = syncpt.id;
> job->timeout = 1;
> diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> index 85aa2e3d9d4e..6d6da01282f3 100644
> --- a/drivers/gpu/drm/tegra/drm.h
> +++ b/drivers/gpu/drm/tegra/drm.h
> @@ -83,6 +83,7 @@ struct tegra_drm_client_ops {
> struct tegra_drm_context *context);
> void (*close_channel)(struct tegra_drm_context *context);
> int (*is_addr_reg)(struct device *dev, u32 class, u32 offset);
> + int (*is_valid_class)(u32 class);
> int (*submit)(struct tegra_drm_context *context,
> struct drm_tegra_submit *args, struct drm_device *drm,
> struct drm_file *file);
> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
> index 02cd3e37a6ec..782231c41a1a 100644
> --- a/drivers/gpu/drm/tegra/gr2d.c
> +++ b/drivers/gpu/drm/tegra/gr2d.c
> @@ -109,10 +109,22 @@ static int gr2d_is_addr_reg(struct device *dev, u32
> class, u32 offset)
> return 0;
> }
>
> +static int gr2d_is_valid_class(u32 class)
> +{
> + switch (class) {
> + case HOST1X_CLASS_GR2D:
> + case HOST1X_CLASS_GR2D_SB:
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> static const struct tegra_drm_client_ops gr2d_ops = {
> .open_channel = gr2d_open_channel,
> .close_channel = gr2d_close_channel,
> .is_addr_reg = gr2d_is_addr_reg,
> + .is_valid_class = gr2d_is_valid_class,
> .submit = tegra_drm_submit,
> };
>
> diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
> index cf335c5979e2..65e12219405a 100644
> --- a/drivers/gpu/host1x/job.c
> +++ b/drivers/gpu/host1x/job.c
> @@ -358,6 +358,9 @@ struct host1x_firewall {
>
> static int check_register(struct host1x_firewall *fw, unsigned long offset)
> {
> + if (!fw->job->is_addr_reg)
> + return 0;
> +
> if (fw->job->is_addr_reg(fw->dev, fw->class, offset)) {
> if (!fw->num_relocs)
> return -EINVAL;
> @@ -372,6 +375,19 @@ static int check_register(struct host1x_firewall *fw,
> unsigned long offset)
> return 0;
> }
>
> +static int check_class(struct host1x_firewall *fw, u32 class)
> +{
> + if (!fw->job->is_valid_class) {
> + if (fw->class != class)
> + return -EINVAL;
> + } else {
> + if (!fw->job->is_valid_class(fw->class))
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static int check_mask(struct host1x_firewall *fw)
> {
> u32 mask = fw->mask;
> @@ -445,11 +461,9 @@ static int validate(struct host1x_firewall *fw, struct
> host1x_job_gather *g)
> {
> u32 *cmdbuf_base = (u32 *)fw->job->gather_copy_mapped +
> (g->offset / sizeof(u32));
> + u32 job_class = fw->class;
> int err = 0;
>
> - if (!fw->job->is_addr_reg)
> - return 0;
> -
> fw->words = g->words;
> fw->cmdbuf = g->bo;
> fw->offset = 0;
> @@ -469,7 +483,9 @@ static int validate(struct host1x_firewall *fw, struct
> host1x_job_gather *g)
> fw->class = word >> 6 & 0x3ff;
> fw->mask = word & 0x3f;
> fw->reg = word >> 16 & 0xfff;
> - err = check_mask(fw);
> + err = check_class(fw, job_class);
> + if (!err)
> + err = check_mask(fw);
> if (err)
> goto out;
> break;
> diff --git a/include/linux/host1x.h b/include/linux/host1x.h
> index aa323e
Re: [PATCH 18/22] gpu: host1x: Remove unused 'struct host1x_cmdbuf'
On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote:
> The struct host1x_cmdbuf is unused, let's remove it.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/host1x/job.h | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/host1x/job.h b/drivers/gpu/host1x/job.h
> index 0debd93a1849..4bda51d503ec 100644
> --- a/drivers/gpu/host1x/job.h
> +++ b/drivers/gpu/host1x/job.h
> @@ -27,13 +27,6 @@ struct host1x_job_gather {
> bool handled;
> };
>
> -struct host1x_cmdbuf {
> - u32 handle;
> - u32 offset;
> - u32 words;
> - u32 pad;
> -};
> -
> struct host1x_job_unpin_data {
> struct host1x_bo *bo;
> struct sg_table *sgt;
> --
> 2.13.0
>
Reviewed-by: Erik Faye-Lund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 19/22] gpu: host1x: Remove unused host1x_cdma_stop() definition
On Tue, May 23, 2017 at 2:14 AM, Dmitry Osipenko wrote:
> There is no host1x_cdma_stop() in the code, let's remove its definition
> from the header file.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/host1x/cdma.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/host1x/cdma.h b/drivers/gpu/host1x/cdma.h
> index ec170a78f4e1..286d49386be9 100644
> --- a/drivers/gpu/host1x/cdma.h
> +++ b/drivers/gpu/host1x/cdma.h
> @@ -88,7 +88,6 @@ struct host1x_cdma {
>
> int host1x_cdma_init(struct host1x_cdma *cdma);
> int host1x_cdma_deinit(struct host1x_cdma *cdma);
> -void host1x_cdma_stop(struct host1x_cdma *cdma);
> int host1x_cdma_begin(struct host1x_cdma *cdma, struct host1x_job *job);
> void host1x_cdma_push(struct host1x_cdma *cdma, u32 op1, u32 op2);
> void host1x_cdma_end(struct host1x_cdma *cdma, struct host1x_job *job);
> --
> 2.13.0
>
Reviewed-by: Erik Faye-Lund
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/stm: ltdc: fix duplicated arguments
Fix COMPILE_TEST build issue detected with the rule: "duplicated argument to & or |" Signed-off-by: Philippe CORNU --- drivers/gpu/drm/stm/ltdc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index a40418c..700cc08 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -463,7 +463,7 @@ static void ltdc_crtc_mode_set_nofb(struct drm_crtc *crtc) clk_enable(ldev->pixel_clk); /* Configures the HS, VS, DE and PC polarities. */ - val = HSPOL_AL | HSPOL_AL | DEPOL_AL | PCPOL_IPC; + val = HSPOL_AL | VSPOL_AL | DEPOL_AL | PCPOL_IPC; if (vm.flags & DISPLAY_FLAGS_HSYNC_HIGH) val |= HSPOL_AH; -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/22] drm/tegra: Fix lockup on a use of staging API
Commit bdd2f9cd ("Don't leak kernel pointer to userspace") added a mutex
around staging IOCTL's, some of those mutexes are taken twice.
Fixes: bdd2f9cd10eb ("drm/tegra: Don't leak kernel pointer to userspace")
Signed-off-by: Dmitry Osipenko
Reviewed-by: Mikko Perttunen
---
drivers/gpu/drm/tegra/drm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 51c48a8e00ec..b49d32a89f40 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -451,18 +451,6 @@ int tegra_drm_submit(struct tegra_drm_context *context,
#ifdef CONFIG_DRM_TEGRA_STAGING
-static struct tegra_drm_context *
-tegra_drm_file_get_context(struct tegra_drm_file *file, u32 id)
-{
- struct tegra_drm_context *context;
-
- mutex_lock(&file->lock);
- context = idr_find(&file->contexts, id);
- mutex_unlock(&file->lock);
-
- return context;
-}
-
static int tegra_gem_create(struct drm_device *drm, void *data,
struct drm_file *file)
{
@@ -606,7 +594,7 @@ static int tegra_close_channel(struct drm_device *drm, void
*data,
mutex_lock(&fpriv->lock);
- context = tegra_drm_file_get_context(fpriv, args->context);
+ context = idr_find(&fpriv->contexts, args->context);
if (!context) {
err = -EINVAL;
goto unlock;
@@ -631,7 +619,7 @@ static int tegra_get_syncpt(struct drm_device *drm, void
*data,
mutex_lock(&fpriv->lock);
- context = tegra_drm_file_get_context(fpriv, args->context);
+ context = idr_find(&fpriv->contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;
@@ -660,7 +648,7 @@ static int tegra_submit(struct drm_device *drm, void *data,
mutex_lock(&fpriv->lock);
- context = tegra_drm_file_get_context(fpriv, args->context);
+ context = idr_find(&fpriv->contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;
@@ -685,7 +673,7 @@ static int tegra_get_syncpt_base(struct drm_device *drm,
void *data,
mutex_lock(&fpriv->lock);
- context = tegra_drm_file_get_context(fpriv, args->context);
+ context = idr_find(&fpriv->contexts, args->context);
if (!context) {
err = -ENODEV;
goto unlock;
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: Primary display is recognized as secondary display
On Mon, May 22, 2017 at 09:22:03AM +0100, Chris Wilson wrote: > On Sat, May 20, 2017 at 10:02:32PM +0900, Hisao Tanabe wrote: > > DELL 27-inch display is connected to ThinkPad 250 via DisplayPort cable, > > and DELL 27-inch display is used as primary display. > > > > After upgrade kernel from 4.10 to 4.11, the DELL 27-inch display is now > > recognized as a secondary display. > > What's primary and secondary? Do you mean X's RandR PrimaryOutput, or > the layout, both of which are provided by userspace. I suspect what you > mean is that the connectors were relabelled, so the output from > before/after xrandr might help to clarify that. I use Fedora 25 GNOME 3. == Kernel 4.11 1) The output of the xrandr command before changing the display setting is as follows. $ xrandr Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767 eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 280mm x 160mm 1920x1080 60.04*+ 1400x1050 59.98 1600x900 60.00 1280x1024 60.02 1280x960 60.00 1368x768 60.00 1280x720 60.00 1024x768 60.00 1024x576 60.00 960x540 60.00 800x600 60.3256.25 864x486 60.00 640x480 59.94 720x405 60.00 640x360 60.00 DP1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 600mm x 340mm 2560x1440 59.95*+ 1920x1200 59.88 1920x1080 60.0060.0050.0059.9424.0023.98 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.95 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 DP2 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) 2) Change display settings using 'gnome-control-center display'. - Set the DELL 27-inch display to primary (Primary means "Show the top bar and Activities Overview on this display"). - Set the Built-in display to secondary display (Secondary Display means "Join this display with another to create an extra workspace"). - Arrange Combined Displays. 3) The output of the xrandr command after changing the display setting is as follows. $ xrandr Screen 0: minimum 8 x 8, current 2560 x 2520, maximum 32767 x 32767 eDP1 connected 1920x1080+312+1440 (normal left inverted right x axis y axis) 280mm x 160mm 1920x1080 60.04*+ 1400x1050 59.98 1600x900 60.00 1280x1024 60.02 1280x960 60.00 1368x768 60.00 1280x720 60.00 1024x768 60.00 1024x576 60.00 960x540 60.00 800x600 60.3256.25 864x486 60.00 640x480 59.94 720x405 60.00 640x360 60.00 DP1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 600mm x 340mm 2560x1440 59.95*+ 1920x1200 59.88 1920x1080 60.0060.0050.0059.9424.0023.98 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.95 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 DP2 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) 4) The output of the xrandr command after reboot the machine is as follows. This is same output 1). The 2) setting is not saved. $ xrandr Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767 eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 280mm x 160mm 1920x1080 60.04*+ 1400x1050 59.98 1600x900 60.00 1280x1024 60.02 1280x960 60.00 1368x768 60.00 1280x720 60.00 1024x768 60.00 1024x576 60.00 960x540 60.00 800x600 60.3256.25 864x486 60.00 640x480 59.94 720x405 60.00 640x360 60.00 DP1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 600mm x 340mm 2560x1440 59.95*+ 1920x1200 59.88 1920x1080 60.0060.0050.0059.9424.0023.98 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.95 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1
Re: [linux-sunxi] Re: [RFC PATCH 07/11] drm: sun4i: add support for the TV encoder in H3 SoC
Hi, Dne sobota, 20. maj 2017 ob 03:37:53 CEST je Chen-Yu Tsai napisal(a): > On Sat, May 20, 2017 at 2:23 AM, Jernej Škrabec wrote: > > Hi, > > > > Dne petek, 19. maj 2017 ob 20:08:18 CEST je Icenowy Zheng napisal(a): > >> 于 2017年5月20日 GMT+08:00 上午2:03:30, Maxime Ripard > > > electrons.com> 写到: > >> >On Thu, May 18, 2017 at 12:43:50AM +0800, Icenowy Zheng wrote: > >> >> Allwinner H3 features a TV encoder similar to the one in earlier > >> > > >> >SoCs, > >> > > >> >> but with some different points about clocks: > >> >> - It has a mod clock and a bus clock. > >> >> - The mod clock must be at a fixed rate to generate signal. > >> > > >> >Why? > >> > >> It's experiment result by Jernej. > >> > >> The clock rates in BSP kernel is also specially designed > >> (PLL_DE at 432MHz) in order to be able to feed the TVE. > > > > My experiments and search through BSP code showed that TVE seems to have > > additional fixed predivider 8. So if you want to generate 27 MHz clock, > > unit has to be feed with 216 MHz. > > > > TVE has only one PLL source PLL_DE. And since 216 MHz is a bit low for > > DE2, > > BSP defaults to 432 MHz for PLL_DE and use divider 2 to generate 216 MHz. > > This clock is then divided by 8 internaly to get final 27 MHz. > > > > Please note that I don't have any hard evidence to support that, only > > experimental data. However, only that explanation make sense to me. > > > > BTW, BSP H3/H5 TV driver supports only PAL and NTSC which both use 27 MHz > > base clock. Further experiments are needed to check if there is any > > possibility to have other resolutions by manipulating clocks and give > > other proper settings. I plan to do that, but not in very near future. > > You only have composite video output, and those are the only 2 standard > resolutions that make any sense. Right, other resolutions are for VGA. Anyway, I did some more digging in A10 and R40 datasheets. I think that H3 TVE unit is something in between. R40 TVE has a setting to select "up sample". Possible settings are 27 MHz, 54 MHz, 108 MHz and 216 MHz. BSP driver on R40 has this setting enabled only for PAL and NTSC and it is always 216 MHz. I think that H3 may have this hardwired to 216 MHz and this would be the reason why 216 MHz is needed. Has anyone else any better explanation? Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/22] drm/tegra: Check syncpoint ID in the 'submit' IOCTL
In case of invalid syncpoint ID, the host1x_syncpt_get() returns NULL and
none of its users perform a check of the returned pointer later. Let's bail
out until it's too late.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/drm.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index eae0c1512ab0..cdb05d6efde4 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -393,6 +393,8 @@ int tegra_drm_submit(struct tegra_drm_context *context,
struct drm_tegra_waitchk __user *waitchks =
(void __user *)(uintptr_t)args->waitchks;
struct drm_tegra_syncpt syncpt;
+ struct host1x *host1x = dev_get_drvdata(drm->dev->parent);
+ struct host1x_syncpt *sp;
struct host1x_job *job;
int err;
@@ -521,6 +523,13 @@ int tegra_drm_submit(struct tegra_drm_context *context,
goto fail;
}
+ /* check whether syncpoint ID is valid */
+ sp = host1x_syncpt_get(host1x, syncpt.id);
+ if (!sp) {
+ err = -ENOENT;
+ goto fail;
+ }
+
job->is_addr_reg = context->client->ops->is_addr_reg;
job->syncpt_incrs = syncpt.incrs;
job->syncpt_id = syncpt.id;
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device
Hi Laurent,
Thankyou for the patch.
On 17/05/17 00:20, Laurent Pinchart wrote:
> For planes handled by a VSP instance, map the framebuffer memory through
> the VSP to ensure proper IOMMU handling.
>
> Signed-off-by: Laurent Pinchart
Looks good except for a small unsigned int comparison causing an infinite loop
on fail case.
With the loop fixed:
Reviewed-by: Kieran Bingham
> ---
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 74
> ---
> drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 2 +
> 2 files changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index b0ff304ce3dc..1b874cfd40f3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -19,7 +19,9 @@
> #include
> #include
>
> +#include
> #include
> +#include
> #include
>
> #include
> @@ -170,12 +172,9 @@ static void rcar_du_vsp_plane_setup(struct
> rcar_du_vsp_plane *plane)
> cfg.dst.width = state->state.crtc_w;
> cfg.dst.height = state->state.crtc_h;
>
> - for (i = 0; i < state->format->planes; ++i) {
> - struct drm_gem_cma_object *gem;
> -
> - gem = drm_fb_cma_get_gem_obj(fb, i);
> - cfg.mem[i] = gem->paddr + fb->offsets[i];
> - }
> + for (i = 0; i < state->format->planes; ++i)
> + cfg.mem[i] = sg_dma_address(state->sg_tables[i].sgl)
> ++ fb->offsets[i];
>
> for (i = 0; i < ARRAY_SIZE(formats_kms); ++i) {
> if (formats_kms[i] == state->format->fourcc) {
> @@ -187,6 +186,67 @@ static void rcar_du_vsp_plane_setup(struct
> rcar_du_vsp_plane *plane)
> vsp1_du_atomic_update(plane->vsp->vsp, plane->index, &cfg);
> }
>
> +static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
> + struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
> + struct rcar_du_device *rcdu = vsp->dev;
> + unsigned int i;
Unsigned here..
> + int ret;
> +
> + if (!state->fb)
> + return 0;
> +
> + for (i = 0; i < rstate->format->planes; ++i) {
> + struct drm_gem_cma_object *gem =
> + drm_fb_cma_get_gem_obj(state->fb, i);
> + struct sg_table *sgt = &rstate->sg_tables[i];
> +
> + ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr, gem->paddr,
> + gem->base.size);
> + if (ret)
> + goto fail;
> +
> + ret = vsp1_du_map_sg(vsp->vsp, sgt);
> + if (!ret) {
> + sg_free_table(sgt);
> + ret = -ENOMEM;
> + goto fail;
> + }
> + }
> +
> + return 0;
> +
> +fail:
> + for (i--; i >= 0; i--) {
Means that this loop will never exit; i will always be >= 0;
I'd propose just making signed for this usage.
I've checked the i values for the breakouts - so they are good, and we need to
use i == 0 to unmap the last table.
> + struct sg_table *sgt = &rstate->sg_tables[i];
> +
> + vsp1_du_unmap_sg(vsp->vsp, sgt);
> + sg_free_table(sgt);
> + }
> +
> + return ret;
> +}
> +
> +static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
> + struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
> + unsigned int i;
> +
> + if (!state->fb)
> + return;
> +
> + for (i = 0; i < rstate->format->planes; ++i) {
> + struct sg_table *sgt = &rstate->sg_tables[i];
> +
> + vsp1_du_unmap_sg(vsp->vsp, sgt);
> + sg_free_table(sgt);
> + }
> +}
> +
> static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
> struct drm_plane_state *state)
> {
> @@ -227,6 +287,8 @@ static void rcar_du_vsp_plane_atomic_update(struct
> drm_plane *plane,
> }
>
> static const struct drm_plane_helper_funcs rcar_du_vsp_plane_helper_funcs = {
> + .prepare_fb = rcar_du_vsp_plane_prepare_fb,
> + .cleanup_fb = rcar_du_vsp_plane_cleanup_fb,
> .atomic_check = rcar_du_vsp_plane_atomic_check,
> .atomic_update = rcar_du_vsp_plane_atomic_update,
> };
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> index f1d0f1824528..8861661590ff 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
> @@ -43,6 +43,7 @@ static inline struct rcar_du_vsp_plane
> *to_rcar_vsp_plane(struct drm_plane *p)
> * struct rcar_du_vsp_plane_state - Driver-specific plane state
> * @state: base DRM plane state
> *
Re: [PATCH v2 3/5] v4l: vsp1: Map the DL and video buffers through the proper bus master
Hi Laurent,
Thanks for the patch:
On 17/05/17 00:20, Laurent Pinchart wrote:
> From: Magnus Damm
>
> On Gen2 hardware the VSP1 is a bus master and accesses the display list
> and video buffers through DMA directly. On Gen3 hardware, however,
> memory accesses go through a separate IP core called FCP.
>
> The VSP1 driver unconditionally maps DMA buffers through the VSP device.
> While this doesn't cause any practical issue so far, DMA mappings will
> be incorrect as soon as we will enable IOMMU support for the FCP on Gen3
> platforms, resulting in IOMMU faults.
>
> Fix this by mapping all buffers through the FCP device if present, and
> through the VSP1 device as usual otherwise.
>
> Suggested-by: Magnus Damm
> [Cache the bus master device]
> Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/vsp1/vsp1.h | 1 +
> drivers/media/platform/vsp1/vsp1_dl.c| 4 ++--
> drivers/media/platform/vsp1/vsp1_drv.c | 9 +
> drivers/media/platform/vsp1/vsp1_video.c | 2 +-
> 4 files changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1.h
> b/drivers/media/platform/vsp1/vsp1.h
> index 85387a64179a..847963b6e9eb 100644
> --- a/drivers/media/platform/vsp1/vsp1.h
> +++ b/drivers/media/platform/vsp1/vsp1.h
> @@ -74,6 +74,7 @@ struct vsp1_device {
>
> void __iomem *mmio;
> struct rcar_fcp_device *fcp;
> + struct device *bus_master;
>
> struct vsp1_bru *bru;
> struct vsp1_clu *clu;
> diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
> b/drivers/media/platform/vsp1/vsp1_dl.c
> index 7d8f37772b56..445d1c31fff3 100644
> --- a/drivers/media/platform/vsp1/vsp1_dl.c
> +++ b/drivers/media/platform/vsp1/vsp1_dl.c
> @@ -137,7 +137,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
> dlb->vsp1 = vsp1;
> dlb->size = size;
>
> - dlb->entries = dma_alloc_wc(vsp1->dev, dlb->size, &dlb->dma,
> + dlb->entries = dma_alloc_wc(vsp1->bus_master, dlb->size, &dlb->dma,
> GFP_KERNEL);
> if (!dlb->entries)
> return -ENOMEM;
> @@ -150,7 +150,7 @@ static int vsp1_dl_body_init(struct vsp1_device *vsp1,
> */
> static void vsp1_dl_body_cleanup(struct vsp1_dl_body *dlb)
> {
> - dma_free_wc(dlb->vsp1->dev, dlb->size, dlb->entries, dlb->dma);
> + dma_free_wc(dlb->vsp1->bus_master, dlb->size, dlb->entries, dlb->dma);
> }
>
> /**
> diff --git a/drivers/media/platform/vsp1/vsp1_drv.c
> b/drivers/media/platform/vsp1/vsp1_drv.c
> index 048446af5ae7..95c26edead85 100644
> --- a/drivers/media/platform/vsp1/vsp1_drv.c
> +++ b/drivers/media/platform/vsp1/vsp1_drv.c
> @@ -764,6 +764,15 @@ static int vsp1_probe(struct platform_device *pdev)
> PTR_ERR(vsp1->fcp));
> return PTR_ERR(vsp1->fcp);
> }
> +
> + /*
> + * When the FCP is present, it handles all bus master accesses
> + * for the VSP and must thus be used in place of the VSP device
> + * to map DMA buffers.
> + */
> + vsp1->bus_master = rcar_fcp_get_device(vsp1->fcp);
> + } else {
> + vsp1->bus_master = vsp1->dev;
> }
>
> /* Configure device parameters based on the version register. */
> diff --git a/drivers/media/platform/vsp1/vsp1_video.c
> b/drivers/media/platform/vsp1/vsp1_video.c
> index eab3c3ea85d7..5af3486afe07 100644
> --- a/drivers/media/platform/vsp1/vsp1_video.c
> +++ b/drivers/media/platform/vsp1/vsp1_video.c
> @@ -1197,7 +1197,7 @@ struct vsp1_video *vsp1_video_create(struct vsp1_device
> *vsp1,
> video->queue.ops = &vsp1_video_queue_qops;
> video->queue.mem_ops = &vb2_dma_contig_memops;
> video->queue.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
> - video->queue.dev = video->vsp1->dev;
> + video->queue.dev = video->vsp1->bus_master;
> ret = vb2_queue_init(&video->queue);
> if (ret < 0) {
> dev_err(video->vsp1->dev, "failed to initialize vb2 queue\n");
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: mxsfb_crtc: Reset the eLCDIF controller
On 05/22/2017 03:55 PM, Fabio Estevam wrote: > Hi Marek, > > On Fri, May 5, 2017 at 3:01 PM, Fabio Estevam wrote: >> According to the eLCDIF initialization steps listed in the MX6SX >> Reference Manual the eLCDIF block reset is mandatory. >> >> Without performing the eLCDIF reset the display shows garbage content >> when the kernel boots. >> >> In earlier tests this issue has not been observed because the bootloader >> was previously showing a splash screen and the bootloader display driver >> does properly implement the eLCDIF reset. >> >> Add the eLCDIF reset to the driver, so that it can operate correctly >> independently of the bootloader. >> >> Tested on a imx6sx-sdb board. >> >> Cc: >> Signed-off-by: Fabio Estevam >> --- >> Changes since v2: >> >> - Remove unneeded udelay(1) - Marek > > Any comments about v3? > IMO it's OK. Reviewed-by: Marek Vasut -- Best regards, Marek Vasut ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm: rcar-du: Map memory through the VSP device
On 22/05/17 14:23, Laurent Pinchart wrote:
> Hello Geert and Kieran,
>
> On Monday 22 May 2017 15:00:27 Geert Uytterhoeven wrote:
>> On Mon, May 22, 2017 at 2:52 PM, Kieran Bingham wrote:
>>> My only distaste there is having to then add the [i-1] index to the
>>> sg_tables.
>>>
>>> I have just experimented with:
>>>
>>> fail:
>>> for (; i-- != 0;) {
>>> struct sg_table *sgt = &rstate->sg_tables[i];
>>> ...
>>> }
>>>
>>> This performs the correct loops, with the correct indexes, but does the
>>> decrement in the condition offend coding styles ?
>>>
>>> If that's disliked even more I'll just apply your suggestion.
>>
>> You can still use "i-- > 0", which looks a little bit better IMHO.
>
> I'm fine with that option too.
>
Of course for(; X ;) is just while(X), which is also more readable ;)
And while (i-- > 0) simplifies cleanly to while (i--) which I'm sure is quite
readable.
I'll clean up and post the updated series including linux-media.
--
Kieran
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 12/16] drm/stm: remove unneeded -Iinclude/drm compiler flag
Hi Daniel, 2017-05-22 16:37 GMT+09:00 Daniel Vetter : > On Thu, May 18, 2017 at 01:29:49PM +0900, Masahiro Yamada wrote: >> With the include directives under include/drm/ fixed, this flag is >> no longer needed. >> >> Signed-off-by: Masahiro Yamada > > Ok, this and patch 1 applied, pls double-check I've done the right thing > and it's all good now (well, once linux-next has rebuild with the 2 > patches merged, which should be in 1-2 days at most). > > Thanks, Daniel Looks good. Thanks! -- Best Regards Masahiro Yamada ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/22] Tegra DRM fixes
Hello, I have already sent some of the patches contained in this series and some of them got reviews. Later I added couple more patches and the dependencies started to form, so please ignore all the patches I sent before this series. The patches without r-b signatures require a review. Dmitry Osipenko (21): drm/tegra: Fix lockup on a use of staging API drm/tegra: Correct idr_alloc() minimum id drm/tegra: Check whether page belongs to BO in tegra_bo_kmap() drm/tegra: Check for malformed offsets and sizes in the 'submit' IOCTL drm/tegra: Correct copying of waitchecks and disable them in the 'submit' IOCTL drm/tegra: Check syncpoint ID in the 'submit' IOCTL drm/tegra: Remove module ownership from the tegra_fb_ops drm/tegra: dc: Drop the reset asserts to workaround a bug drm/tegra: dc: Apply clipping to the plane drm/tegra: Disable plane if it is invisible gpu: host1x: Initialize firewall class to the jobs one gpu: host1x: Correct host1x_job_pin() error handling gpu: host1x: Do not leak BO's phys address to userspace gpu: host1x: Forbid relocation address shifting in the firewall gpu: host1x: Forbid RESTART opcode in the firewall gpu: host1x: Forbid unrelated SETCLASS opcode in the firewall gpu: host1x: Check waits in the firewall gpu: host1x: Remove unused 'struct host1x_cmdbuf' gpu: host1x: Remove unused host1x_cdma_stop() definition drm/tegra: Don't use IOMMU on Tegra20 Revert "iommu/tegra: gart: Do not register with bus" Mikko Perttunen (1): gpu: host1x: Refactor channel allocation code drivers/gpu/drm/tegra/dc.c | 77 ++- drivers/gpu/drm/tegra/drm.c| 145 ++-- drivers/gpu/drm/tegra/drm.h| 1 + drivers/gpu/drm/tegra/fb.c | 1 - drivers/gpu/drm/tegra/gem.c| 8 +- drivers/gpu/drm/tegra/gem.h| 5 ++ drivers/gpu/drm/tegra/gr2d.c | 16 +++- drivers/gpu/drm/tegra/gr3d.c | 4 +- drivers/gpu/drm/tegra/vic.c| 4 +- drivers/gpu/host1x/cdma.h | 1 - drivers/gpu/host1x/channel.c | 147 +++-- drivers/gpu/host1x/channel.h | 21 -- drivers/gpu/host1x/debug.c | 47 +--- drivers/gpu/host1x/dev.c | 12 ++- drivers/gpu/host1x/dev.h | 6 +- drivers/gpu/host1x/hw/channel_hw.c | 4 - drivers/gpu/host1x/job.c | 113 ++-- drivers/gpu/host1x/job.h | 14 drivers/iommu/tegra-gart.c | 2 +- include/linux/host1x.h | 13 +++- 20 files changed, 426 insertions(+), 215 deletions(-) -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 2/5] v4l: rcar-fcp: Add an API to retrieve the FCP device
From: Laurent Pinchart
The new rcar_fcp_get_device() function retrieves the struct device
related to the FCP device. This is useful to handle DMA mapping through
the right device.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Kieran Bingham
---
drivers/media/platform/rcar-fcp.c | 6 ++
include/media/rcar-fcp.h | 5 +
2 files changed, 11 insertions(+)
diff --git a/drivers/media/platform/rcar-fcp.c
b/drivers/media/platform/rcar-fcp.c
index e9f609edf513..2988031d285d 100644
--- a/drivers/media/platform/rcar-fcp.c
+++ b/drivers/media/platform/rcar-fcp.c
@@ -78,6 +78,12 @@ void rcar_fcp_put(struct rcar_fcp_device *fcp)
}
EXPORT_SYMBOL_GPL(rcar_fcp_put);
+struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
+{
+ return fcp->dev;
+}
+EXPORT_SYMBOL_GPL(rcar_fcp_get_device);
+
/**
* rcar_fcp_enable - Enable an FCP
* @fcp: The FCP instance
diff --git a/include/media/rcar-fcp.h b/include/media/rcar-fcp.h
index 8723f05c6321..b60a7b176c37 100644
--- a/include/media/rcar-fcp.h
+++ b/include/media/rcar-fcp.h
@@ -19,6 +19,7 @@ struct rcar_fcp_device;
#if IS_ENABLED(CONFIG_VIDEO_RENESAS_FCP)
struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np);
void rcar_fcp_put(struct rcar_fcp_device *fcp);
+struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp);
int rcar_fcp_enable(struct rcar_fcp_device *fcp);
void rcar_fcp_disable(struct rcar_fcp_device *fcp);
#else
@@ -27,6 +28,10 @@ static inline struct rcar_fcp_device *rcar_fcp_get(const
struct device_node *np)
return ERR_PTR(-ENOENT);
}
static inline void rcar_fcp_put(struct rcar_fcp_device *fcp) { }
+static inline struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
+{
+ return NULL;
+}
static inline int rcar_fcp_enable(struct rcar_fcp_device *fcp)
{
return 0;
--
git-series 0.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/22] drm/tegra: Check whether page belongs to BO in tegra_bo_kmap()
This fixes an OOPS in case of out-of-bounds accessing of a kmap'ed cmdbuf
(non-IOMMU allocation) while patching the relocations in do_relocs().
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 424569b53e57..ca0d4439e97b 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -74,6 +74,9 @@ static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int
page)
{
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
+ if (page * PAGE_SIZE >= obj->gem.size)
+ return NULL;
+
if (obj->vaddr)
return obj->vaddr + page * PAGE_SIZE;
else if (obj->gem.import_attach)
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 18/22] gpu: host1x: Remove unused 'struct host1x_cmdbuf'
The struct host1x_cmdbuf is unused, let's remove it.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/host1x/job.h | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/host1x/job.h b/drivers/gpu/host1x/job.h
index 0debd93a1849..4bda51d503ec 100644
--- a/drivers/gpu/host1x/job.h
+++ b/drivers/gpu/host1x/job.h
@@ -27,13 +27,6 @@ struct host1x_job_gather {
bool handled;
};
-struct host1x_cmdbuf {
- u32 handle;
- u32 offset;
- u32 words;
- u32 pad;
-};
-
struct host1x_job_unpin_data {
struct host1x_bo *bo;
struct sg_table *sgt;
--
2.13.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm: Primary display is recognized as secondary display
On Mon, May 22, 2017 at 09:22:03AM +0100, Chris Wilson wrote: > On Sat, May 20, 2017 at 10:02:32PM +0900, Hisao Tanabe wrote: > > DELL 27-inch display is connected to ThinkPad 250 via DisplayPort cable, > > and DELL 27-inch display is used as primary display. > > > > After upgrade kernel from 4.10 to 4.11, the DELL 27-inch display is now > > recognized as a secondary display. > > What's primary and secondary? Do you mean X's RandR PrimaryOutput, or > the layout, both of which are provided by userspace. I suspect what you > mean is that the connectors were relabelled, so the output from > before/after xrandr might help to clarify that. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre I use Fedora 25 GNOME 3. == Kernel 4.11 1) The output of the xrandr command before changing the display setting is as follows. $ xrandr Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767 eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 280mm x 160mm 1920x1080 60.04*+ 1400x1050 59.98 1600x900 60.00 1280x1024 60.02 1280x960 60.00 1368x768 60.00 1280x720 60.00 1024x768 60.00 1024x576 60.00 960x540 60.00 800x600 60.3256.25 864x486 60.00 640x480 59.94 720x405 60.00 640x360 60.00 DP1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 600mm x 340mm 2560x1440 59.95*+ 1920x1200 59.88 1920x1080 60.0060.0050.0059.9424.0023.98 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.95 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 DP2 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) 2) Change display settings using 'gnome-control-center display'. - Set the DELL 27-inch display to primary (Primary means "Show the top bar and Activities Overview on this display"). - Set the Built-in display to secondary display (Secondary Display means "Join this display with another to create an extra workspace"). - Arrange Combined Displays. 3) The output of the xrandr command after changing the display setting is as follows. $ xrandr Screen 0: minimum 8 x 8, current 2560 x 2520, maximum 32767 x 32767 eDP1 connected 1920x1080+312+1440 (normal left inverted right x axis y axis) 280mm x 160mm 1920x1080 60.04*+ 1400x1050 59.98 1600x900 60.00 1280x1024 60.02 1280x960 60.00 1368x768 60.00 1280x720 60.00 1024x768 60.00 1024x576 60.00 960x540 60.00 800x600 60.3256.25 864x486 60.00 640x480 59.94 720x405 60.00 640x360 60.00 DP1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 600mm x 340mm 2560x1440 59.95*+ 1920x1200 59.88 1920x1080 60.0060.0050.0059.9424.0023.98 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.95 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 DP2 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) 4) The output of the xrandr command after reboot the machine is as follows. This is same output 1). The 2) setting is not saved. $ xrandr Screen 0: minimum 8 x 8, current 4480 x 1440, maximum 32767 x 32767 eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 280mm x 160mm 1920x1080 60.04*+ 1400x1050 59.98 1600x900 60.00 1280x1024 60.02 1280x960 60.00 1368x768 60.00 1280x720 60.00 1024x768 60.00 1024x576 60.00 960x540 60.00 800x600 60.3256.25 864x486 60.00 640x480 59.94 720x405 60.00 640x360 60.00 DP1 connected 2560x1440+1920+0 (normal left inverted right x axis y axis) 600mm x 340mm 2560x1440 59.95*+ 1920x1200 59.88 1920x1080 60.0060.0050.0059.9424.0023.98 1920x1080i60.0050.0059.94 1600x1200 60.00 1680x1050 59.95 1280x1024
Re: [PATCH v2 4/5] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP
Hi Laurent,
On 17/05/17 00:20, Laurent Pinchart wrote:
> The display buffers must be mapped for DMA through the device that
> performs memory access. Expose an API to map and unmap memory through
> the VSP device to be used by the DU.
>
> As all the buffers allocated by the DU driver are coherent, we can skip
> cache handling when mapping and unmapping them. This will need to be
> revisited when support for non-coherent buffers will be added to the DU
> driver.
Thankyou for the patch
> Signed-off-by: Laurent Pinchart
With the small nitpick fixed:
Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/vsp1/vsp1_drm.c | 25 +
> include/media/vsp1.h | 3 +++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
> b/drivers/media/platform/vsp1/vsp1_drm.c
> index 9d235e830f5a..c809c2aadca0 100644
> --- a/drivers/media/platform/vsp1/vsp1_drm.c
> +++ b/drivers/media/platform/vsp1/vsp1_drm.c
> @@ -12,9 +12,11 @@
> */
>
> #include
> +#include
> #include
>
> #include
> +#include
This header isn't used here.
(Presumably it was before you cached the fcp dev as the vsp1->bus_master).
I'll fix this while applying locally. No need to resend.
> #include
> #include
>
> @@ -524,6 +526,29 @@ void vsp1_du_atomic_flush(struct device *dev)
> }
> EXPORT_SYMBOL_GPL(vsp1_du_atomic_flush);
>
> +int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt)
> +{
> + struct vsp1_device *vsp1 = dev_get_drvdata(dev);
> +
> + /*
> + * As all the buffers allocated by the DU driver are coherent, we can
> + * skip cache sync. This will need to be revisited when support for
> + * non-coherent buffers will be added to the DU driver.
> + */
> + return dma_map_sg_attrs(vsp1->bus_master, sgt->sgl, sgt->nents,
> + DMA_TO_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
> +}
> +EXPORT_SYMBOL_GPL(vsp1_du_map_sg);
> +
> +void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt)
> +{
> + struct vsp1_device *vsp1 = dev_get_drvdata(dev);
> +
> + dma_unmap_sg_attrs(vsp1->bus_master, sgt->sgl, sgt->nents,
> +DMA_TO_DEVICE, DMA_ATTR_SKIP_CPU_SYNC);
> +}
> +EXPORT_SYMBOL_GPL(vsp1_du_unmap_sg);
> +
> /*
> -
> * Initialization
> */
> diff --git a/include/media/vsp1.h b/include/media/vsp1.h
> index 38aac554dbba..6aa630c9f7af 100644
> --- a/include/media/vsp1.h
> +++ b/include/media/vsp1.h
> @@ -13,6 +13,7 @@
> #ifndef __MEDIA_VSP1_H__
> #define __MEDIA_VSP1_H__
>
> +#include
> #include
> #include
>
> @@ -46,5 +47,7 @@ void vsp1_du_atomic_begin(struct device *dev);
> int vsp1_du_atomic_update(struct device *dev, unsigned int rpf,
> const struct vsp1_du_atomic_config *cfg);
> void vsp1_du_atomic_flush(struct device *dev);
> +int vsp1_du_map_sg(struct device *dev, struct sg_table *sgt);
> +void vsp1_du_unmap_sg(struct device *dev, struct sg_table *sgt);
>
> #endif /* __MEDIA_VSP1_H__ */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] v4l: rcar-fcp: Don't get/put module reference
Hi Laurent,
Thanks for the patch:
On 17/05/17 00:20, Laurent Pinchart wrote:
> Direct callers of the FCP API hold a reference to the FCP module due to
> module linkage, there's no need to take another one manually. Take a
> reference to the device instead to ensure that it won't disappear behind
> the caller's back.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/rcar-fcp.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-fcp.c
> b/drivers/media/platform/rcar-fcp.c
> index 7146fc5ef168..e9f609edf513 100644
> --- a/drivers/media/platform/rcar-fcp.c
> +++ b/drivers/media/platform/rcar-fcp.c
> @@ -53,14 +53,7 @@ struct rcar_fcp_device *rcar_fcp_get(const struct
> device_node *np)
> if (fcp->dev->of_node != np)
> continue;
>
> - /*
> - * Make sure the module won't be unloaded behind our back. This
> - * is a poor man's safety net, the module should really not be
> - * unloaded while FCP users can be active.
> - */
> - if (!try_module_get(fcp->dev->driver->owner))
> - fcp = NULL;
> -
> + get_device(fcp->dev);
> goto done;
> }
>
> @@ -81,7 +74,7 @@ EXPORT_SYMBOL_GPL(rcar_fcp_get);
> void rcar_fcp_put(struct rcar_fcp_device *fcp)
> {
> if (fcp)
> - module_put(fcp->dev->driver->owner);
> + put_device(fcp->dev);
> }
> EXPORT_SYMBOL_GPL(rcar_fcp_put);
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 20/22] gpu: host1x: Refactor channel allocation code
From: Mikko Perttunen
This is largely a rewrite of the Host1x channel allocation code, bringing
several changes:
- The previous code could deadlock due to an interaction
between the 'reflock' mutex and CDMA timeout handling.
This gets rid of the mutex.
- Support for more than 32 channels, required for Tegra186
- General refactoring, including better encapsulation
of channel ownership handling into channel.c
Signed-off-by: Mikko Perttunen
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
---
drivers/gpu/drm/tegra/gr2d.c | 4 +-
drivers/gpu/drm/tegra/gr3d.c | 4 +-
drivers/gpu/drm/tegra/vic.c| 4 +-
drivers/gpu/host1x/channel.c | 147 +++--
drivers/gpu/host1x/channel.h | 21 --
drivers/gpu/host1x/debug.c | 47 +---
drivers/gpu/host1x/dev.c | 7 +-
drivers/gpu/host1x/dev.h | 6 +-
drivers/gpu/host1x/hw/channel_hw.c | 4 -
include/linux/host1x.h | 1 -
10 files changed, 135 insertions(+), 110 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index 782231c41a1a..693fd2b3aef6 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -38,7 +38,7 @@ static int gr2d_init(struct host1x_client *client)
client->syncpts[0] = host1x_syncpt_request(client->dev, flags);
if (!client->syncpts[0]) {
- host1x_channel_free(gr2d->channel);
+ host1x_channel_put(gr2d->channel);
return -ENOMEM;
}
@@ -57,7 +57,7 @@ static int gr2d_exit(struct host1x_client *client)
return err;
host1x_syncpt_free(client->syncpts[0]);
- host1x_channel_free(gr2d->channel);
+ host1x_channel_put(gr2d->channel);
return 0;
}
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 13f0d1b7cd98..cee2ab645cde 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -48,7 +48,7 @@ static int gr3d_init(struct host1x_client *client)
client->syncpts[0] = host1x_syncpt_request(client->dev, flags);
if (!client->syncpts[0]) {
- host1x_channel_free(gr3d->channel);
+ host1x_channel_put(gr3d->channel);
return -ENOMEM;
}
@@ -67,7 +67,7 @@ static int gr3d_exit(struct host1x_client *client)
return err;
host1x_syncpt_free(client->syncpts[0]);
- host1x_channel_free(gr3d->channel);
+ host1x_channel_put(gr3d->channel);
return 0;
}
diff --git a/drivers/gpu/drm/tegra/vic.c b/drivers/gpu/drm/tegra/vic.c
index cd804e404a11..47cb1aaa58b1 100644
--- a/drivers/gpu/drm/tegra/vic.c
+++ b/drivers/gpu/drm/tegra/vic.c
@@ -182,7 +182,7 @@ static int vic_init(struct host1x_client *client)
free_syncpt:
host1x_syncpt_free(client->syncpts[0]);
free_channel:
- host1x_channel_free(vic->channel);
+ host1x_channel_put(vic->channel);
detach_device:
if (tegra->domain)
iommu_detach_device(tegra->domain, vic->dev);
@@ -203,7 +203,7 @@ static int vic_exit(struct host1x_client *client)
return err;
host1x_syncpt_free(client->syncpts[0]);
- host1x_channel_free(vic->channel);
+ host1x_channel_put(vic->channel);
if (vic->domain) {
iommu_detach_device(vic->domain, vic->dev);
diff --git a/drivers/gpu/host1x/channel.c b/drivers/gpu/host1x/channel.c
index 8f437d924c10..db9b91d1384c 100644
--- a/drivers/gpu/host1x/channel.c
+++ b/drivers/gpu/host1x/channel.c
@@ -24,19 +24,33 @@
#include "job.h"
/* Constructor for the host1x device list */
-int host1x_channel_list_init(struct host1x *host)
+int host1x_channel_list_init(struct host1x_channel_list *chlist,
+unsigned int num_channels)
{
- INIT_LIST_HEAD(&host->chlist.list);
- mutex_init(&host->chlist_mutex);
-
- if (host->info->nb_channels > BITS_PER_LONG) {
- WARN(1, "host1x hardware has more channels than supported by
the driver\n");
- return -ENOSYS;
+ chlist->channels = kcalloc(num_channels, sizeof(struct host1x_channel),
+ GFP_KERNEL);
+ if (!chlist->channels)
+ return -ENOMEM;
+
+ chlist->allocated_channels =
+ kcalloc(BITS_TO_LONGS(num_channels), sizeof(unsigned long),
+ GFP_KERNEL);
+ if (!chlist->allocated_channels) {
+ kfree(chlist->channels);
+ return -ENOMEM;
}
+ bitmap_zero(chlist->allocated_channels, num_channels);
+
return 0;
}
+void host1x_channel_list_free(struct host1x_channel_list *chlist)
+{
+ kfree(chlist->allocated_channels);
+ kfree(chlist->channels);
+}
+
int host1x_job_submit(struct host1x_job *job)
{
struct host1x *host = dev_get_drvdata(job->channel->dev->parent);
@@ -47,86 +61,10
Re: [PATCH v2 2/5] v4l: rcar-fcp: Add an API to retrieve the FCP device
Hi Laurent,
Thankyou for the patch:
On 17/05/17 00:20, Laurent Pinchart wrote:
> The new rcar_fcp_get_device() function retrieves the struct device
> related to the FCP device. This is useful to handle DMA mapping through
> the right device.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
> ---
> drivers/media/platform/rcar-fcp.c | 6 ++
> include/media/rcar-fcp.h | 5 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/media/platform/rcar-fcp.c
> b/drivers/media/platform/rcar-fcp.c
> index e9f609edf513..2988031d285d 100644
> --- a/drivers/media/platform/rcar-fcp.c
> +++ b/drivers/media/platform/rcar-fcp.c
> @@ -78,6 +78,12 @@ void rcar_fcp_put(struct rcar_fcp_device *fcp)
> }
> EXPORT_SYMBOL_GPL(rcar_fcp_put);
>
> +struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
> +{
> + return fcp->dev;
> +}
> +EXPORT_SYMBOL_GPL(rcar_fcp_get_device);
> +
> /**
> * rcar_fcp_enable - Enable an FCP
> * @fcp: The FCP instance
> diff --git a/include/media/rcar-fcp.h b/include/media/rcar-fcp.h
> index 8723f05c6321..b60a7b176c37 100644
> --- a/include/media/rcar-fcp.h
> +++ b/include/media/rcar-fcp.h
> @@ -19,6 +19,7 @@ struct rcar_fcp_device;
> #if IS_ENABLED(CONFIG_VIDEO_RENESAS_FCP)
> struct rcar_fcp_device *rcar_fcp_get(const struct device_node *np);
> void rcar_fcp_put(struct rcar_fcp_device *fcp);
> +struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp);
> int rcar_fcp_enable(struct rcar_fcp_device *fcp);
> void rcar_fcp_disable(struct rcar_fcp_device *fcp);
> #else
> @@ -27,6 +28,10 @@ static inline struct rcar_fcp_device *rcar_fcp_get(const
> struct device_node *np)
> return ERR_PTR(-ENOENT);
> }
> static inline void rcar_fcp_put(struct rcar_fcp_device *fcp) { }
> +static inline struct device *rcar_fcp_get_device(struct rcar_fcp_device *fcp)
> +{
> + return NULL;
> +}
> static inline int rcar_fcp_enable(struct rcar_fcp_device *fcp)
> {
> return 0;
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 14/22] gpu: host1x: Forbid relocation address shifting in the firewall
Incorrectly shifted relocation address will cause a lower memory corruption and likely a hang on a write or a read of an arbitrary data in case of IOMMU absent. As of now there is no use for the address shifting (at least on Tegra20) and adding a proper shifting / sizes validation is much more work. Let's forbid it in the firewall till a proper validation is implemented. Signed-off-by: Dmitry Osipenko --- drivers/gpu/host1x/job.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c index 190353944d23..1a1568e64ba8 100644 --- a/drivers/gpu/host1x/job.c +++ b/drivers/gpu/host1x/job.c @@ -332,6 +332,10 @@ static bool check_reloc(struct host1x_reloc *reloc, struct host1x_bo *cmdbuf, if (reloc->cmdbuf.bo != cmdbuf || reloc->cmdbuf.offset != offset) return false; + /* relocation shift value validation isn't implemented yet */ + if (reloc->shift) + return false; + return true; } -- 2.13.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
