[Bug 106892] GPU hang with radeon glx driver

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106892 --- Comment #1 from Simon --- Ok seems the radeon driver has problems with my monitor at 1440x900@75Hz, because if I reduce that to 1440x900@60Hz it seems to work stable, though my Intel iGPU never had problems with 75Hz.. -- You are

Re: [PULL] drm-intel-next

2018-06-11 Thread Dave Airlie
On 12 June 2018 at 02:27, Rodrigo Vivi wrote: > Hi Dave, > > This is the first round targeting 4.19. > Does this tree feed into linux-next already? Since we shouldn't have new stuff for linux-next feeding into it until after rc1. I won't be pulling this until after rc1 anyways. Dave.

RE: [RFC v3 0/8] Add Plane Color Properties

2018-06-11 Thread Shankar, Uma
>-Original Message- >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of >Alexandru-Cosmin Gheorghe >Sent: Monday, June 11, 2018 3:47 PM >To: Shankar, Uma >Cc: dcasta...@chromium.org; intel-...@lists.freedesktop.org; >emil.l.veli...@gmail.com;

[Bug 199959] amdgpu, regression?: system freezes after resume

2018-06-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #15 from Alexander Mezin (mezin.alexan...@gmail.com) --- No, it doesn't change anything, system freezes on resume. -- You are receiving this mail because: You are watching the assignee of the bug.

Re: [PATCH 20/21] drm/omap: Pass both output and display omap_dss_device to encoder init

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:49PM +0300, Laurent Pinchart wrote: > The drm_encoder implementation requires access to the omap_dss_device > corresponding to the display, which is passed to its initialization > function and stored internally. Clean up of the HDMI mode and infoframe > handling

Re: [PATCH 21/21] drm/omap: Don't call HDMI mode and infoframe operations recursively

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:50PM +0300, Laurent Pinchart wrote: > The HDMI mode (.set_hdmi_mode()) and infoframe (.set_infoframe()) > operations are called recursively from the display device back to the > HDMI encoder. This isn't required, as all components other than the HDMI > encoder

[Bug 106446] Stutter at higher refresh rates ( 75 Hz) and artifacts on desktop

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106446 --- Comment #7 from Mike Bendel --- Adding amdgpu.dpm=1 did not fix it, unfortunately. Noticed no change on my WX7100. Thanks for the suggestion though. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 19/21] drm/omap: Get from CRTC to display device directly

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:48PM +0300, Laurent Pinchart wrote: > The CRTC mode set implementation needs to access the omap_dss_device for > the pipeline display. To do so, it iterates over all pipelines to find > the one that contains an encoder corresponding to the CRTC, and request > the

Re: [PATCH 04/21] drm/omap: Check omap_dss_device type based on the output_type field

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:33PM +0300, Laurent Pinchart wrote: > Various functions that need to differentiate between omap_dss_device > instances corresponding to displays and to internal encoders use the > omap_dss_device.driver field, which is only set for display instances. > This gets

Re: [PATCH 18/21] drm/omap: Don't call EDID read operation recursively

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:47PM +0300, Laurent Pinchart wrote: > Instead of calling the EDID read operation (.read_edid()) recursively > from the display device back to the first device that provides EDID read > support, iterate over the devices manually in the DRM connector code. > This

Re: [PATCH 17/21] drm/omap: Move HPD disconnection handling to omap_connector

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:46PM +0300, Laurent Pinchart wrote: > On HDMI outputs, CEC support requires notification of HPD signal > deassertion. The HPD signal can be handled by various omap_dss_device > instances in the pipeline, and all of them forward HPD events to the > OMAP4 internal

Re: [PATCH 16/21] drm/omap: Merge HPD enable operation with HPD callback registration

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:45PM +0300, Laurent Pinchart wrote: > The omap_dss_device .enable_hpd() and .disable_hpd() are used to enable > and disable hot-plug detection at omapdrm probe and remove time. This is > required to avoid reporting hot-plug detection events before the DRM >

Re: [PATCH 15/21] drm/omap: Remove unneeded safety checks in the HPD operations

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:44PM +0300, Laurent Pinchart wrote: > The HPD-related omap_dss_device operations are now only called when the > device supports HPD. There's no need to duplicate that check in the > omap_dss_device drivers. The .register_hpd_cb() operation can as a > result be

Re: [PATCH 14/21] drm/omap: Don't call HPD registration operations recursively

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:43PM +0300, Laurent Pinchart wrote: > Instead of calling the hot-plug detection callback registration > operations (.register_hpd_cb() and .unregister_hpd_cb()) recursively > from the display device back to the first device that provides hot plug > detection

Re: [PATCH 3/5] drm/msm/adreno: Load the firmware before bringing up the hardware

2018-06-11 Thread kbuild test robot
Hi Jordan, Thank you for the patch! Yet something to improve: [auto build test ERROR on robclark/msm-next] [also build test ERROR on v4.17 next-20180608] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

[Bug 104520] Intermittent X crashes: GPU HANG: ecode 9:0:0x85dffffb, in Xorg [443], reason: Hang on rcs0, action: reset

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=104520 --- Comment #22 from Alif Wahid --- Created attachment 140127 --> https://bugs.freedesktop.org/attachment.cgi?id=140127=edit Log dump from /sys/class/drm/card0/error after GPU hang (as printed in dmesg output). I see this error

[DPU PATCH v3 6/7] drm/msm: remove msm_prop files

2018-06-11 Thread Jeykumar Sankaran
Remove hand rolled msm property caching to handle DPU custom properties. This change also cleans up all its dependencies to cache and restore respective drm states. changes in v2: - none changes in v3: - rebased on https://gitlab.freedesktop.org/seanpaul/

[DPU PATCH v3 5/7] Remove dpu crtc custom properties and its handlers.

2018-06-11 Thread Jeykumar Sankaran
changes in v2: - none changes in v3: - rebased on https://gitlab.freedesktop.org/seanpaul/ dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5 Signed-off-by: Jeykumar Sankaran Reviewed-by: Sean Paul --- drivers/gpu/drm/msm/Makefile | 1 -

[DPU PATCH v3 7/7] drm/msm: remove dpu specific uapi header

2018-06-11 Thread Jeykumar Sankaran
remove unwanted dpu uapi headers exposing custom payload layouts for custom properties changs in v2: - none changes in v3: - rebased on https://gitlab.freedesktop.org/seanpaul/ dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5 Signed-off-by: Jeykumar Sankaran

[DPU PATCH v3 1/7] drm/msm: remove connector custom properties

2018-06-11 Thread Jeykumar Sankaran
Cleanup residual connector property enumerations. changes in v2: - none changes in v3: - rebased on https://gitlab.freedesktop.org/seanpaul/ dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5 Signed-off-by: Jeykumar Sankaran Reviewed-by: Sean Paul ---

[DPU PATCH v3 3/7] drm/msm: enable zpos normalization

2018-06-11 Thread Jeykumar Sankaran
Enable drm core zpos normalization for planes. changes in v2: - none changes in v3: - rebased on https://gitlab.freedesktop.org/seanpaul/ dpu-staging/commit/481d29d31cd629fd216381b53de5695f645465d5 Signed-off-by: Jeykumar Sankaran Reviewed-by: Sean Paul ---

[DPU PATCH v3 0/7] clean up DPU custom properties

2018-06-11 Thread Jeykumar Sankaran
Submitting a series of patches to further clean up DPU driver by stripping down a list of custom properties supporting proprietary features. It removes the property installers/handlers and cleans up relevant files of of some of the advanced features. This series is based on the patch[1]

[DPU PATCH v3 4/7] drm/msm/dpu: switch to drm zpos property

2018-06-11 Thread Jeykumar Sankaran
Replace custom plane zpos property with drm core zpos property. CRTC relies on the normalized zpos values to configure blend stages of each plane. changes in v2: - Move out unrelated changes in plane init (Sean Paul) changes in v3: - rebased on https://gitlab.freedesktop.org/seanpaul/

Re: [PATCH v2 44/60] drm/omap: dss: Add for_each_dss_output() macro

2018-06-11 Thread Sebastian Reichel
Hi, On Mon, Jun 11, 2018 at 08:11:09PM +0300, Laurent Pinchart wrote: > Hi Sebastian, > > On Monday, 11 June 2018 02:52:44 EEST Sebastian Reichel wrote: > > On Sat, May 26, 2018 at 08:25:02PM +0300, Laurent Pinchart wrote: > > > Similarly to for_each_dss_display(), the for_each_dss_output()

Re: [PATCH v2 46/60] drm/omap: dss: Remove duplicated parameter to dss_mgr_(dis)connect()

2018-06-11 Thread Sebastian Reichel
Hi, On Mon, Jun 11, 2018 at 08:16:24PM +0300, Laurent Pinchart wrote: > Hi Sebastian, > > On Monday, 11 June 2018 02:48:45 EEST Sebastian Reichel wrote: > > On Sat, May 26, 2018 at 08:25:04PM +0300, Laurent Pinchart wrote: > > > The dss_mgr_connect() and dss_mgr_disconnect() functions take two >

[Bug 106892] GPU hang with radeon glx driver

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106892 Bug ID: 106892 Summary: GPU hang with radeon glx driver Product: Mesa Version: 18.0 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major

[PATCH 3/3] drm/i915: Print prop name/id when rejecting it

2018-06-11 Thread Ville Syrjala
From: Ville Syrjälä Use the '[PROP:id:name]' format I introduced for the core in the driver debug messages as well. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_atomic.c | 6 -- drivers/gpu/drm/i915/intel_atomic_plane.c | 6 -- 2 files changed, 8 insertions(+), 4

[PATCH 2/3] drm: Print bad user modes

2018-06-11 Thread Ville Syrjala
From: Ville Syrjälä Print out the modeline when we reject a bad user mode. Avoids having to guess why it was rejected. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 20 +--- drivers/gpu/drm/drm_crtc.c | 4 +++-

[PATCH 1/3] drm/atomic: Improve debug messages

2018-06-11 Thread Ville Syrjala
From: Ville Syrjälä Print the id/name of the object we're dealing with. Makes it easier to figure out what's going on. Also toss in a few extra debug prints that might be useful. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c | 88 ++-- 1

[Bug 106871] Screen with blank cursor (raven ridge on MSI B350)

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106871 --- Comment #2 from Erik --- Thank a lot!, i will forward the bug. (Still interesting how you can figure this out from my logging.) -- You are receiving this mail because: You are the assignee for the

Re: Kernel and ADM hardware roulette ( was AMD graphics performance regression in 4.15 and later )

2018-06-11 Thread Linus Torvalds
On Mon, Jun 11, 2018 at 12:07 AM Christoph Hellwig wrote: > > For now I'd say revert this commit for 4.17/4.18-rc and I'll look into > addressing these issues properly. Ok, reverted in my tree, and marked for stable (for 4.17). Thanks, Linus

Re: [PATCH v2 51/60] drm/omap: Reverse direction of DSS device (dis)connect operations

2018-06-11 Thread Laurent Pinchart
Hi Sebastian, On Monday, 11 June 2018 14:59:13 EEST Sebastian Reichel wrote: > On Sat, May 26, 2018 at 08:25:09PM +0300, Laurent Pinchart wrote: > > The omapdrm and omapdss drivers are architectured based on display > > pipelines made of multiple components handled from sink (display) to > >

[PATCH 2/5] drm/msm: Add a helper function to parse clock names

2018-06-11 Thread Jordan Crouse
Add a helper function to parse the clock names and set up the bulk data so we can take advantage of the bulk clock functions instead of rolling our own. This is added as a helper function so the upcoming a6xx GMU code can also take advantage of it. Signed-off-by: Jordan Crouse ---

[PATCH 4/5] drm/msm: Add generated headers for A6XX

2018-06-11 Thread Jordan Crouse
From: Sharat Masetty Add initial register headers for A6XX targets. Signed-off-by: Sharat Masetty Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1784 + drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 + 2 files changed, 2166

[PATCH 1/5] drm/msm: Remove pm_runtime operations from msm_iommu

2018-06-11 Thread Jordan Crouse
Now that the IOMMU is the master of it's own power we don't need to bring up the GPU to do IOMMU operations. This is good because bringing up a6xx requires the GMU so calling pm_runtime_get_sync() too early in the process gets us into some nasty circular dependency situations. Signed-off-by:

[PATCH 5/5] drm/msm: Add A6XX device support

2018-06-11 Thread Jordan Crouse
Add support for the A6XX family of Adreno GPUs. The biggest addition is the GMU (Graphics Management Unit) which takes over most of the power management of the GPU itself but in a ironic twist of fate needs a goodly amount of management itself. Add support for the A6XX core code, the GMU and the

[PATCH 3/5] drm/msm/adreno: Load the firmware before bringing up the hardware

2018-06-11 Thread Jordan Crouse
Failure to load firwmare is the primary reason to fail adreno_load_gpu(). Try to load it first before going into the hardware initialization code and unwinding it. This is important for a6xx because the GMU gets loaded from the runtime power code and it is more costly to fail in that path because

[PATCH 0/5] drm/msm: Add support for Adreno a6xx

2018-06-11 Thread Jordan Crouse
This is an initial version of support for the Adreno a6xx GPU family starting with the a630 from the sdm845 SoC. This code is ahead of much of the sdm845 code that would be needed to actually bring up a device and it is also in advance of any user side support for the a6xx GPU so this is mainly

[PATCH] staging: android: ion: Return an ERR_PTR in ion_map_kernel

2018-06-11 Thread Laura Abbott
The expected return value from ion_map_kernel is an ERR_PTR. The error path for a vmalloc failure currently just returns NULL, triggering a warning in ion_buffer_kmap_get. Encode the vmalloc failure as an ERR_PTR. Reported-by: syzbot+55b1d9f811650de94...@syzkaller.appspotmail.com Signed-off-by:

Re: [PATCH v2 02/13] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

2018-06-11 Thread Ville Syrjälä
On Mon, Jun 04, 2018 at 11:13:53AM -0700, Sinclair Yeh wrote: > On Wed, May 30, 2018 at 11:08:57PM +0300, Ville Syrjälä wrote: > > On Fri, May 25, 2018 at 09:50:34PM +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > Instead of plane->fb (which we're going to deprecate for atomic

[Bug 106287] 18.0.1 introduced glitches in Dying Light

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106287 --- Comment #9 from Henrik Holst --- Just tried that and the black box around the sight vanished but the water effect is still there for me, this is on 18.0.1 however so perhaps 18.1.x works differently there. Wouldn't be surprised either if

Re: [PATCH v2 46/60] drm/omap: dss: Remove duplicated parameter to dss_mgr_(dis)connect()

2018-06-11 Thread Laurent Pinchart
Hi Sebastian, On Monday, 11 June 2018 02:48:45 EEST Sebastian Reichel wrote: > On Sat, May 26, 2018 at 08:25:04PM +0300, Laurent Pinchart wrote: > > The dss_mgr_connect() and dss_mgr_disconnect() functions take two > > omap_dss_device pointers as parameters, which are always set to the same > >

[Bug 106872] vram sizes reported by the kernel totally off

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106872 --- Comment #1 from Michel Dänzer --- Please attach the dmesg output from the affected system, preferably captured while or after the problem occurs. (In reply to Bas Nieuwenhuizen from comment #0) > e.g. the last report we had kernel reported

Re: [PATCH v2 44/60] drm/omap: dss: Add for_each_dss_output() macro

2018-06-11 Thread Laurent Pinchart
Hi Sebastian, On Monday, 11 June 2018 02:52:44 EEST Sebastian Reichel wrote: > On Sat, May 26, 2018 at 08:25:02PM +0300, Laurent Pinchart wrote: > > Similarly to for_each_dss_display(), the for_each_dss_output() macro > > iterates over all the DSS connected outputs. > > > > Signed-off-by:

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

2018-06-11 Thread Stefano Stabellini
On Mon, 11 Jun 2018, Oleksandr Andrushchenko wrote: > On 06/08/2018 10:21 PM, Boris Ostrovsky wrote: > > On 06/08/2018 01:59 PM, Stefano Stabellini wrote: > > > > > > > > > >    @@ -325,6 +401,14 @@ static int map_grant_pages(struct > > > > > > > > > > grant_map > > > > > > > > > > *map) > > > >

Re: [PATCH] drm: Constify mode argument to connector .mode_valid() helper operation

2018-06-11 Thread Ville Syrjälä
On Thu, Jun 07, 2018 at 03:13:23PM +0300, Laurent Pinchart wrote: > Hi Ville, > > On Thursday, 7 June 2018 15:03:12 EEST Ville Syrjälä wrote: > > On Wed, Jun 06, 2018 at 12:08:12PM +0300, Laurent Pinchart wrote: > > > The drm_connector_helper_funcs .mode_valid() operation should not modify > > >

[PATCH][V2] drm/i915/guc: fix GEM_BUG_ON check

2018-06-11 Thread Colin King
From: Colin Ian King The check for level being less than zero always false because flags is currently unsigned and can never be negative. Fix this by making flags a s32. Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0") Signed-off-by: Colin Ian King --- V2: Make flags

Re: [Intel-gfx] [PATCH] drm/i915/guc: remove redundant GEM_BUG_ON check

2018-06-11 Thread Colin Ian King
On 11/06/18 17:25, Ville Syrjälä wrote: > On Mon, Jun 11, 2018 at 05:00:37PM +0100, Colin King wrote: >> From: Colin Ian King >> >> The check for level being less than zero is redundant as level >> is an unsigned u32 and hence will never be less than zero. >> Remove this redundant check. >> >>

[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+

2018-06-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=199619 --- Comment #8 from Giorgio (giorgio.colacc...@gmail.com) --- Hi Elmar, I don’t know if it may be of help, anyway I have a similar problem: the point is that my problem does not seem related to graphic drivers. My OS is Slackware64 14.2, kernel

[Bug 199619] screen stays dark for long on bootup since kernel 4.17.0-rc2+

2018-06-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=199619 Giorgio (giorgio.colacc...@gmail.com) changed: What|Removed |Added CC|

[PULL] drm-intel-next

2018-06-11 Thread Rodrigo Vivi
Hi Dave, This is the first round targeting 4.19. Here goes drm-intel-next-2018-06-06: - Ice Lake's display enabling patches (Jose, Mahesh, Dhinakaran, Paulo, Manasi, Anusha, Arkadiusz) - Ice Lake's workarounds (Oscar and Yunwei) - Ice Lake interrupt registers fixes (Oscar) - Context switch

Re: [Intel-gfx] [PATCH] drm/i915/guc: remove redundant GEM_BUG_ON check

2018-06-11 Thread Ville Syrjälä
On Mon, Jun 11, 2018 at 05:00:37PM +0100, Colin King wrote: > From: Colin Ian King > > The check for level being less than zero is redundant as level > is an unsigned u32 and hence will never be less than zero. > Remove this redundant check. > > Detected by CoverityScan, CID#1468363 ("Macro

Re: [PATCH 12/21] drm/omap: dss: Add device operations flags

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:41PM +0300, Laurent Pinchart wrote: > When an omap_dss_device operation can be implemented in multiple places > in a chain of devices, it is important to find out which device to > address to perfom the operation. This is currently done by calling the > operation

Re: [PATCH 13/21] drm/omap: Don't call .detect() operation recursively

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:42PM +0300, Laurent Pinchart wrote: > Instead of calling the .detect() operation recursively from the display > device back to the first device that provides hot plug detection > support, iterate over the devices manually in the DRM connector > .detect()

[PATCH] drm/i915/guc: remove redundant GEM_BUG_ON check

2018-06-11 Thread Colin King
From: Colin Ian King The check for level being less than zero is redundant as level is an unsigned u32 and hence will never be less than zero. Remove this redundant check. Detected by CoverityScan, CID#1468363 ("Macro compares unsigned to 0") Signed-off-by: Colin Ian King ---

Re: [PATCH 11/21] drm/omap: Move most omap_dss_driver operations to omap_dss_device_ops

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:40PM +0300, Laurent Pinchart wrote: > omap_dss_device instances have two ops structures, omap_dss_driver and > omap_dss_device_ops. The former is used for devices at the end of the > pipeline (a.k.a. display devices), and the latter for intermediate > devices. >

Re: [PATCH] Documentation: devicetree: tilcdc: fix spelling mistake "suppors" -> "supports"

2018-06-11 Thread Rob Herring
On Wed, Jun 06, 2018 at 05:39:42PM +0200, Enric Balletbo i Serra wrote: > Trivial fix to spelling mistake in tilcdc.txt devicetree documentation. > > Signed-off-by: Enric Balletbo i Serra > --- > > Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt | 2 +- > 1 file changed, 1

Re: [PATCH v4 0/3] re-factor devfreq common code

2018-06-11 Thread Jordan Crouse
On Fri, Jun 08, 2018 at 11:56:04AM +0530, Sharat Masetty wrote: > This series re-factors the devfreq code a bit in preparation for the upcoming > A6x related devfreq changes. The code applies cleanly on 4.17 and has been > verified on DB820C. > > V2: Addressed code review comments from Jordan

Re: [PATCH 10/21] drm/omap: panel-tpo-td043mtea1: Convert to the GPIO descriptors API

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:39PM +0300, Laurent Pinchart wrote: > The GPIO descriptor API is favoured over the plain GPIO API for consumer > drivers. Using it simplifies the driver code. > > As the descriptor API handles the active-low flag internally we need to > invert the polarity of

[Bug 199959] amdgpu, regression?: system freezes after resume

2018-06-11 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=199959 --- Comment #14 from Christian König (christian.koe...@amd.com) --- Created attachment 276471 --> https://bugzilla.kernel.org/attachment.cgi?id=276471=edit Testing patch Please test if this patch helps as well. It limits the work done during

Re: [PATCH 09/21] drm/omap: panel-tpo-td028ttec1: Drop unneeded linux/gpio.h header

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:38PM +0300, Laurent Pinchart wrote: > The driver doesn't use GPIOs and thus doesn't need to include the > linux/gpio.h header. > > Signed-off-by: Laurent Pinchart > --- Reviewed-by: Sebastian Reichel -- Sebastian >

Re: [PATCH 08/21] drm/omap: panel-sony-acx565akm: Convert to the GPIO descriptors API

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:37PM +0300, Laurent Pinchart wrote: > The GPIO descriptor API is favoured over the plain GPIO API for consumer > drivers. Using it simplifies the driver code. > > Signed-off-by: Laurent Pinchart > --- Reviewed-by: Sebastian Reichel -- Sebastian >

Re: [PATCH 07/21] drm/omap: panel-nec-nl8048hl11: Convert to the GPIO descriptors API

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:36PM +0300, Laurent Pinchart wrote: > The GPIO descriptor API is favoured over the plain GPIO API for consumer > drivers. Using it simplifies the driver code. > > The reset GPIO is mandatory, so drop conditional tests through the > driver. The qvga GPIO is

Re: [PATCH 06/21] drm/omap: encoder-tfp410: Convert to the GPIO descriptors API

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:35PM +0300, Laurent Pinchart wrote: > The GPIO descriptor API is favoured over the plain GPIO API for consumer > drivers. Using it simplifies the driver code. > > As the descriptor API handles the active-low flag internally we need to > invert the polarity of

Re: [PATCH 05/21] drm/omap: connector-hdmi: Convert to the GPIO descriptors API

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:34PM +0300, Laurent Pinchart wrote: > The GPIO descriptor API is favoured over the plain GPIO API for consumer > drivers. Using it simplifies the driver code. > > Signed-off-by: Laurent Pinchart > --- Reviewed-by: Sebastian Reichel -- Sebastian >

Re: [PATCH 03/21] drm/omap: Remove unnecessary display output sanity checks

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:32PM +0300, Laurent Pinchart wrote: > The omapdrm driver checks at suspend and resume time whether the > displays it operates on have their driver operations set. This check is > unneeded, as all display drivers set the driver operations field at > probe time and

Re: [PATCH 02/21] drm/omap: dss: Remove omap_dss_driver .[gs]et_mirror operations

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:31PM +0300, Laurent Pinchart wrote: > The .get_mirror() and .set_mirror() omap_dss_driver operations are > implemented by the panel-tpo-td043mtea1 driver but are never used. > Remove them. > > Signed-off-by: Laurent Pinchart > --- Reviewed-by: Sebastian

Re: [PATCH 01/21] drm/omap: dss: Remove unused omap_dss_driver operations

2018-06-11 Thread Sebastian Reichel
Hi, On Wed, Jun 06, 2018 at 12:36:30PM +0300, Laurent Pinchart wrote: > The .probe(), .remove(), .run_test(), .get_rotate() and .set_rotate() > omap_dss_driver operations are not used. Remove them. > > Signed-off-by: Laurent Pinchart > --- Reviewed-by: Sebastian Reichel -- Sebastian >

Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info

2018-06-11 Thread Heiko Stuebner
Hi Andrzej et all, just so we don't discuss in a theoretic way much longer I've just sent a RFC with my current state of work for the dw-mipi-dsi dual-dsi support - aka the old "let code speak" ;-) I've found a somewhat nice way to get from one dsi-controller node to the node of the other

[PATCH 6/8] drm/dsi: add helper function to find the second host in a dual-dsi setup

2018-06-11 Thread Heiko Stuebner
From a specified output port of one dsi controller this function allows to iterate over the list of registered dsi controllers trying to find a second instance connected to the same display, like it is used in dual-dsi setups. Signed-off-by: Heiko Stuebner --- drivers/gpu/drm/drm_mipi_dsi.c |

[PATCH 8/8] drm/rockchip: dsi: add dual mipi support

2018-06-11 Thread Heiko Stuebner
Add the Rockchip-sepcific dual-dsi setup and hook it into the VOP as well. As described in the general dual-dsi devicetree binding, the panel should define two input ports and point each of them to one of the used dsi- controllers, as well as declare one of them as clock-master. This is used to

[PATCH 2/8] drm/bridge/synopsys: dsi: don't call __dw_mipi_dsi_probe from dw_mipi_dsi_bind

2018-06-11 Thread Heiko Stuebner
__dw_mipi_dsi_probe() does all the grabbing of resources and does it using devm-helpers. So this is happening on each try of master bringup possibly slowing down things a lot. Drivers using the component framework may instead want call dw_mipi_dsi_probe separately in their probe function setup

[PATCH 3/8] drm/bridge/synopsys: dsi: defer probing if panel not available in bridge-attach

2018-06-11 Thread Heiko Stuebner
When the panel-driver is build as a module it currently fails hard as the panel cannot be probed directly: dw_mipi_dsi_bind() __dw_mipi_dsi_probe() creates dsi bus creates panel device triggers panel module load panel not probed (module not loaded or panel probe slow)

[RFC PATCH 0/8] drm/rockchip: migrate to common dw-mipi-dsi bridge and dual-dsi

2018-06-11 Thread Heiko Stuebner
The Rockchip DSI driver was separate till now, not using the common bridge driver that was introduced a bit later. So this series migrates over to use that common bridge driver and then also adds support for dual-dsi to both the bridge and Rockchip glue code. The bridge-migration itself is v8

[PATCH 7/8] drm/bridge/synopsys: dsi: add dual-dsi support

2018-06-11 Thread Heiko Stuebner
From: Nickey Yang Allow to also drive a slave dw-mipi-dsi controller in a dual-dsi setup. This will require additional implementation-specific code to look up the slave instance and do specific setup. Also will probably need code in the specific crtcs as dual-dsi does not equal two separate dsi

[PATCH 4/8] dt-bindings: display: rockchip: update DSI controller

2018-06-11 Thread Heiko Stuebner
From: Nickey Yang This patch update describe panel/port links, including unit addresses in documentation of device tree bindings for the rockchip DSI controller based on the Synopsys DesignWare MIPI DSI host controller. Signed-off-by: Nickey Yang Reviewed-by: Brian Norris Signed-off-by: Heiko

[PATCH v8 5/8] drm/rockchip: dsi: migrate to use dw-mipi-dsi bridge driver

2018-06-11 Thread Heiko Stuebner
From: Nickey Yang Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare MIPI DSI host controller bridge and remove the old separate one. changes: v2: add err_pllref, remove unnecessary encoder.enable & disable correct spelling mistakes v3: call dw_mipi_dsi_unbind()

[PATCH 1/8] drm/bridge/synopsys: dsi: move mipi_dsi_host_unregister to __dw_mipi_dsi_remove

2018-06-11 Thread Heiko Stuebner
Right now the host is only unregistered when the driver is used via the bridge api and not via the component api, leading to the host staying registered in cases like probe deferral. So move the host unregister to the general remove function, so that it gets cleaned up in all cases.

Re: [Xen-devel] [PATCH v2 5/9] xen/gntdev: Allow mappings for DMA buffers

2018-06-11 Thread Oleksandr Andrushchenko
On 06/08/2018 10:21 PM, Boris Ostrovsky wrote: On 06/08/2018 01:59 PM, Stefano Stabellini wrote:    @@ -325,6 +401,14 @@ static int map_grant_pages(struct grant_map *map)    map->unmap_ops[i].handle = map->map_ops[i].handle;    if (use_ptemod)   

[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105145 --- Comment #12 from Christian König --- (In reply to k.philipp from comment #11) > Is the interlaced format necessary in the first place? Unfortunately yes it is. The pixel shader used for de-interlacing needs to have access to the

[Bug 105145] vaExportSurfaceHandle interaction with surface interlaced flag prevents switching on vaapi deinterlacing dynamically

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=105145 --- Comment #11 from k.phil...@gmail.com --- Hi again, > The PR got merged. I do have a patch ready (it's just a few lines anyway), but vaapi has not seen a release yet so it is unclear which API version it should depend on. Also we have

[PATCH 3/3] drm/exynos: Ensure suspended runtime PM state during system suspend

2018-06-11 Thread Marek Szyprowski
Add calls to pm_runtime_force_{suspend,resume} as SYSTEM_SLEEP_PM_OPS for all drivers for the real Exynos DRM hardware modules. This ensures that the resources will be released for the system PM suspend/resume cycle. Exynos DRM core already takes care of suspending the whole display pipeline

[PATCH 0/3] Exynos DRM: cleanup of suspend/resume code

2018-06-11 Thread Marek Szyprowski
Dear all, This patchset performs a significant cleanup of Exynos DRM suspend/resume code. A side effect of this cleanup is working system suspend/resume on Exynos5433 SoCs, where there are more dependencies between hardware device drivers, clock controllers and power domains than in case of the

[PATCH 1/3] drm/exynos: Drop useless check from exynos_drm_{suspend,resume}

2018-06-11 Thread Marek Szyprowski
The virtual Exynos DRM device has no runtime PM enabled, so checking for its runtime suspended state is useless. Signed-off-by: Marek Szyprowski --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 2/3] drm/exynos: Suspend/resume display pipeline as early/late as possible

2018-06-11 Thread Marek Szyprowski
In the current code, exynos_drm_suspend() function is called after all real devices (CRTCs, Encoders, etc) are suspended, because Exynos DRM virtual platform device is created as last device in the system (as a part of DRM registration). None of the devices for real hardware modules has its own

Re: Fwd: Re: [PATCHv5 0/3] drm/i915: add DisplayPort CEC-Tunneling-over-AUX support

2018-06-11 Thread Hans Verkuil
Hi Ville, I finally found some time to dig deeper into when a CEC device should be registered. Since it's been a long while since we discussed this let me just recap the situation and then propose three solutions: CEC is implemented for DP-to-HDMI branch devices through DPCD CEC registers.

Re: [PATCH v2 60/60] drm/omap: dss: Remove the dss_mgr_(dis)connect() operations

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:18PM +0300, Laurent Pinchart wrote: > The dss_mgr .connect() and .disconnect() are implemented as no-op in > omapdrm. The operations are unneeded, remove them. > > Signed-off-by: Laurent Pinchart > --- Reviewed-by: Sebastian Reichel -- Sebastian >

Re: [PATCH v2 59/60] drm/omap: Set dispc_channel_connect from DSS output connect handlers

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:17PM +0300, Laurent Pinchart wrote: > The omap_dss_device.dispc_channel_connect field is used by DSS outputs > to fail the .enable() operation if they're not connected. Set the field > directly from the (dis)connect handlers of the DSS outputs instead of > going

Re: [PATCH v2 56/60] drm/omap: Store CRTC lookup by channel table in omap_drm_private

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:14PM +0300, Laurent Pinchart wrote: > The omap_crtcs global array is used to store pointers to omap_crtc > indexed by DISPC channel number, in order to look them up in the dss_mgr > operations. Store the information in the omap_drm_private structure in > the form

Re: [PATCH v2 57/60] drm/omap: Remove omap_crtc_output global array

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:15PM +0300, Laurent Pinchart wrote: > The omap_crtc_output global array is used to look up the DSS output > device by channel. We can replace that by accessing the output device > from the pipeline if we store the pipeline pointer in the omap_crtc > structure. >

Re: [PATCH v2 58/60] drm/omap: Remove supported output check in CRTC connect handler

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:16PM +0300, Laurent Pinchart wrote: > The CRTC connect handler checks whether the DSS output supports the > DISPC channel assigned to it. As the channel is assigned to the output > by the output driver a failure there could only result from a driver > bug. All

Re: [PATCH v2 55/60] drm/omap: Pass pipe pointer to omap_crtc_init()

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:13PM +0300, Laurent Pinchart wrote: > Replace the dss display device pointer by a pipe pointer that will allow > the omap_crtc_init() function to access both the display and the DSS > output. As a result we can remove the omapdss_device_get_dispc_channel() >

Re: [PATCH v2 54/60] drm/omap: dss: Merge two disconnection helpers

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:12PM +0300, Laurent Pinchart wrote: > To simplify the pipeline disconnection handling merge the > omapdss_device_disconnect() and omapdss_output_unset_device() functions. > The device state check is now called for every device in the pipeline, > extending this

Re: [PATCH v2 53/60] drm/omap: dss: Move display type validation to initialization time

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:11PM +0300, Laurent Pinchart wrote: > The display type is validated when the display is connected to the DSS > output. We already have all the information we need for validation when > initializing the outputs. Move validation to output initialization to >

Re: [PATCH v2 52/60] drm/omap: dss: Move connection checks to omapdss_device_(dis)connect

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:10PM +0300, Laurent Pinchart wrote: > When a DSS output is (dis)connected the omapdss_output_(un)set_device() > function performs a sanity check to ensure that the output isn't already > (dis)connected. The check is unnecessary as those situations should > never

Re: [PATCH v2 51/60] drm/omap: Reverse direction of DSS device (dis)connect operations

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:09PM +0300, Laurent Pinchart wrote: > The omapdrm and omapdss drivers are architectured based on display > pipelines made of multiple components handled from sink (display) to > source (DSS output). This is incompatible with the DRM bridge and panel > APIs that

Re: RE: [Intel-gfx] DRM Inquiry

2018-06-11 Thread Jani Nikula
On Mon, 11 Jun 2018, John Sledge wrote: > Thanks for the help. I was able to manage your advice on the > drm_dp_aux_chardev. Though I still need to learn more about the DRM vs > kernel process flow. Like for example, upon changing/adding > DRM_DP_AUX_CHARDEV in kernel .config, How did

Re: [PATCH v2 50/60] drm/omap: Group CRTC, encoder, connector and dssdev in a structure

2018-06-11 Thread Sebastian Reichel
Hi, On Sat, May 26, 2018 at 08:25:08PM +0300, Laurent Pinchart wrote: > Create an omap_drm_pipeline structure to model display pipelines, made > of a CRTC, an encoder, a connector and a DSS display device. This allows > grouping related parameters together instead of storing them in > independent

[Bug 106418] kernel BUG at drivers/dma-buf/reservation.c:234!

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106418 --- Comment #4 from Michel Dänzer --- (In reply to Christian König from comment #3) > Good to know, David and I actually already fixed one cause for this. So I > assumed that this should do it, but that obviously isn't the case. FWIW, I hit it

[Bug 106418] kernel BUG at drivers/dma-buf/reservation.c:234!

2018-06-11 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=106418 --- Comment #3 from Christian König --- (In reply to Michel Dänzer from comment #2) > Christian, could this be related to commit a35f2f34b5b4 "dma-buf: make > returning the exclusive fence optional", or do you have other ideas? I'm now >

  1   2   >