[Bug 91808] trine1 misrender r600g

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=91808

Dave Airlie  changed:

   What|Removed |Added

 Attachment #139029|0   |1
is obsolete||

--- Comment #14 from Dave Airlie  ---
Created attachment 139438
  --> https://bugs.freedesktop.org/attachment.cgi?id=139438=edit
clamp constant buffer data

This looks a lot better to me!

-- 
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 199621] iMac 2009, Mobility Radeon HD 4670: black screen on boot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199621

--- Comment #5 from Florian Echtler (f...@butterbrot.org) ---
I know how it's supposed to work in theory, I'll give it a try. Do you know if
there's a kernel repository that also carries the Ubuntu patches?

-- 
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] Add SPDX idenitifier and clarify license

[Thomas Hellstrom]

On 05/08/2018 11:52 PM, Alex Deucher wrote:

On Thu, May 3, 2018 at 11:41 AM, Dirk Hohndel  wrote:

On Thu, May 03, 2018 at 08:46:20AM -0400, Sean Paul wrote:

Thank you for the awesome summary, it is very helpful! So since the boilerplate
has to stay, is there a benefit to adding the SPDX header? Is it just to make
scripting/scraping easier?

Actually, the header now adds the correct information. Without the header
it is not clear that these files are supposed to be dual licensed under
MIT or GPL-2.


Should these (or any of the drm drivers for that matter) be dual
licensed or just MIT?  The code is MIT.

Alex



A "grep LICENSE `find . -name '*.c'`" seems to indicate that most if not 
all of the drm code and drivers are at least GPL licensed. Many of them 
claim "GPL and additional rights".


/Thomas


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi Christoph,

On Wed, 9 May 2018 07:08:55 +0200 Christoph Hellwig  wrote:
>
> FYI, because the dma_configure change touch so much code and the author
> wants to base more work on it it actually is in a guranteed stable
> branch with just those patches:
> 
> git://git.infradead.org/users/hch/dma-mapping.git dma-configure
> 
> Gitweb:
> 
> 
> http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-configure
>   
> Feel free to pull this into the drm tree.

Thanks for that.

-- 
Cheers,
Stephen Rothwell


pgpoZuaTzDjc2.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: build failure after merge of the drm-intel tree

[Christoph Hellwig]

On Wed, May 09, 2018 at 03:02:55PM +1000, Stephen Rothwell wrote:
> > -   ret = of_dma_configure(dev, NULL);
> > +   ret = of_dma_configure(dev, NULL, true);
> > if (ret < 0) {
> > DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
> > return ret;
> > -- 
> > 2.17.0
> 
> This is now needed for the merge of the drm and dma-mapping trees.

FYI, because the dma_configure change touch so much code and the author
wants to base more work on it it actually is in a guranteed stable
branch with just those patches:

git://git.infradead.org/users/hch/dma-mapping.git dma-configure

Gitweb:


http://git.infradead.org/users/hch/dma-mapping.git/shortlog/refs/heads/dma-configure
  
Feel free to pull this into the drm tree.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

Hi all,

On Tue, 8 May 2018 11:07:16 +1000 Stephen Rothwell  
wrote:
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
> 
> drivers/gpu/drm/xen/xen_drm_front.c: In function 'xen_drv_probe':
> drivers/gpu/drm/xen/xen_drm_front.c:740:10: error: 'struct bus_type' has no 
> member named 'force_dma'
>   dev->bus->force_dma = true;
>   ^~
> drivers/gpu/drm/xen/xen_drm_front.c:742:8: error: too few arguments to 
> function 'of_dma_configure'
>   ret = of_dma_configure(dev, NULL);
> ^~~~
> In file included from drivers/gpu/drm/xen/xen_drm_front.c:16:0:
> include/linux/of_device.h:58:5: note: declared here
>  int of_dma_configure(struct device *dev,
>  ^~~~
> 
> Caused by commit
> 
>   c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
> 
> interacting with commit
> 
>   3d6ce86ee794 ("drivers: remove force dma flag from buses")
> 
> from the dma-mapping tree.
> 
> I have added the following merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Tue, 8 May 2018 11:02:24 +1000
> Subject: [PATCH] drm/xen-front: merge fix for "drivers: remove force dma flag 
> from buses"
> 
> Signed-off-by: Stephen Rothwell 
> ---
>  drivers/gpu/drm/xen/xen_drm_front.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
> b/drivers/gpu/drm/xen/xen_drm_front.c
> index 1b0ea9ac330e..0e486cb1c10c 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front.c
> @@ -737,9 +737,8 @@ static int xen_drv_probe(struct xenbus_device *xb_dev,
>* is not correct: to fix this call of_dma_configure() with a NULL
>* node to set default DMA ops.
>*/
> - dev->bus->force_dma = true;
>   dev->coherent_dma_mask = DMA_BIT_MASK(32);
> - ret = of_dma_configure(dev, NULL);
> + ret = of_dma_configure(dev, NULL, true);
>   if (ret < 0) {
>   DRM_ERROR("Cannot setup DMA ops, ret %d", ret);
>   return ret;
> -- 
> 2.17.0

This is now needed for the merge of the drm and dma-mapping trees.
-- 
Cheers,
Stephen Rothwell


pgpUQIbosiSqH.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199633] Stable kernel regression after 4.16.3: startxfce4 no longer works: X startup seems to hang

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199633

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
google for "kernel git bisect howto"

-- 
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 199621] iMac 2009, Mobility Radeon HD 4670: black screen on boot

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199621

Alex Deucher (alexdeuc...@gmail.com) changed:

   What|Removed |Added

 CC||alexdeuc...@gmail.com

--- Comment #4 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you bisect?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106446

--- Comment #1 from Mike Bendel  ---
Something else that may be of note:

Setting amdgpu.dc to 0 sort of fixes the stutter and general performance issues
I'm seeing. Also there is no flickering/artifacts after a fresh boot, without
touching the performance level setting. It isn't 100% though, after some time
the desktop will start stuttering again when moving windows around. But right
after a fresh boot, or switching resolutions, it is completely smooth, as it
should be. In this mode however I notice the cursor skips frames. With
amdgpu.dc=1 the cursor never skips frames.

All in all, neither mode is usable for me and I've resorted to using HDMI on my
monitor which locks the refresh at 60 Hz.

-- 
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 106374] feature request: allow increasing maxium GPU power consumption like implemented in Wattman on Windows

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106374

--- Comment #1 from Alex Deucher  ---
It is implemented.  power1_cap_min/max are RO.  They define the range of values
that are valid for power.  The OEM defines the range and the information is
stored in tables in the vbios.  The driver uses that to set the range of valid
values.  My understanding is that windows does the same thing.  I'll see if I
can find out why you are seeing a different limit on windows.

-- 
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 100390] [steam] Grand Ages: Medieval crashes instantly

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=100390

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Timothy Arceri  ---
This game should now be playable using MESA_GL_VERSION_OVERRIDE=4.1COMPAT
MESA_GLSL_VERSION_OVERRIDE=410 after the following commit:

commit e7a7b712fe81aac96eaae267ad6cb5444f02e7f6
Author: Timothy Arceri 
Date:   Tue May 8 10:35:40 2018 +1000

mesa: remove hard-coded OpenGL 3.2 compat limit

Just let validate_context_version() do it instead. This fixes
MESA_GL_VERSION_OVERRIDE for compat, it will also allow us to
enable new compat versions on a per driver bases in future.

Reviewed-by: Marek Olšák 

There are still bits missing in compat but the game seems playable with the
overrides.

Since further work simply involves implementing compat profile I'm going to
close this bug.

-- 
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 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199025

--- Comment #33 from Paul van Maaren (ker...@vanmaaren.org) ---
OK, tried that. Same result...

-- 
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 106446] Stutter at higher refresh rates ( 75 Hz) and artifacts on desktop

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106446

Bug ID: 106446
   Summary: Stutter at higher refresh rates ( 75 Hz) and artifacts
on desktop
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: m...@exophase.com

Created attachment 139436
  --> https://bugs.freedesktop.org/attachment.cgi?id=139436=edit
Xorg log

I've noticed that moving around windows and scrolling seems to stutter when
running at 75 Hz on my monitor. When moving back down to 60 Hz it is completely
smooth. In fact, 60 Hz looks smoother, while 75 looks like it is skipping
frames.

In Windows however it is completely smooth at 75 Hz. This occurs on a Radeon
Pro WX 7100.

The other thing I noticed... is that when I run at 75 Hz I get artifacts all
over the desktop, which show up as flashing blue lines. This behavior is
exhibited on all AMD GPUs I own (also tested with a RX Vega 64), so it's not a
faulty card. I found that it is fixed by forcing the performance profile to
high, like so:

echo high > /sys/class/drm/card0/device/power_dpm_force_performance_level

I attached my Xorg log. I'm running the 4.16.6 kernel. Full specs:

Threadripper 1950X
64GB RAM
WX 7100
LG 38UC99 monitor

-- 
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 106434] Graphical hangs, no keyboard, rest of system still active

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106434

--- Comment #4 from Alex Deucher  ---
Do you still have the issue without the CK patches?

-- 
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

[GIT PULL] exynos-drm-fixes

[Inki Dae]

Hi Dave,

   Just fixup to pagefault issue of mixer driver I missed and
   a trivial cleanup to avoid duplicated drm_bridge_attach.

   Please kindly let me know if there is any problem

Thanks,
Inki Dae

The following changes since commit a02cbe2e34c576cdc5e7846a3cd55245ab81db47:

  Merge branch 'vmwgfx-fixes-4.17' of 
git://people.freedesktop.org/~thomash/linux into drm-fixes (2018-05-04 10:03:27 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
tags/exynos-drm-fixes-for-v4.17-rc5

for you to fetch changes up to 6f2db7dc901a1b89fbc50f7b38f0f7ee17205703:

  drm/exynos: hdmi: avoid duplicating drm_bridge_attach (2018-05-09 09:04:57 
+0900)


Fixup pagefault issue of mixer driver
- it makes sure to check shadow register for interlace scan.
- it corrects chroma_addr[1], height and vertical position values.
And trivial cleanup
- it just removes duplicated drm_bridge_attach.


Andrzej Hajda (1):
  drm/exynos/mixer: fix synchronization check in interlaced mode

Peter Rosin (1):
  drm/exynos: hdmi: avoid duplicating drm_bridge_attach

Tobias Jakobi (1):
  drm/exynos: mixer: avoid Oops in vp_video_buffer()

 drivers/gpu/drm/exynos/exynos_hdmi.c  |  2 --
 drivers/gpu/drm/exynos/exynos_mixer.c | 22 +-
 drivers/gpu/drm/exynos/regs-mixer.h   |  1 +
 3 files changed, 18 insertions(+), 7 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Fix render node numbering regression from control node removal.

[Eric Anholt]

drm_minor_alloc() does multiplication on this enum, so the removal
ended up moving render nodes down from 128 base to 64.  This caused
Mesa's surfaceless backend to be unable to open the render nodes,
since it was still looking up at 128.

Signed-off-by: Eric Anholt 
Fixes: 0d49f303e8a7 ("drm: remove all control node code")
Cc: Daniel Vetter 
Cc: Sean Paul 
---
 include/drm/drm_file.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 99ab50cbab00..69b0a8b57502 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -49,6 +49,7 @@ struct device;
 
 enum drm_minor_type {
DRM_MINOR_PRIMARY,
+   DRM_MINOR_CONTROL,
DRM_MINOR_RENDER,
 };
 
-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199025

--- Comment #32 from todd (todd...@gmail.com) ---
@Paul

p.s. Almost forgot to mention.  Again, please use the systemctl method. So to
test your systems suspend use.

systemctl suspend

-- 
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 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199025

--- Comment #31 from todd (todd...@gmail.com) ---
@Paul

Use the correct method to set your run levels.

The original post tells you how and comment #6 even tells you where to get the
information.

read the file   /etc/inittab   

The correct way is .

  systemctl set-default multi-user.target  (for text mode / runlevel 3)

  systemctl set-defaulta graphical.target (for graphical mode / runlevel 5)

Read the file /etc/inittab please.

-- 
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

[PATCH] video: fbdev: nvidia: fix spelling mistake: "scaleing" -> "scaling"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in module parameter description text

Signed-off-by: Colin Ian King 
---
 drivers/video/fbdev/nvidia/nvidia.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/nvidia/nvidia.c 
b/drivers/video/fbdev/nvidia/nvidia.c
index 418a2d0d06a9..34521f52aa3b 100644
--- a/drivers/video/fbdev/nvidia/nvidia.c
+++ b/drivers/video/fbdev/nvidia/nvidia.c
@@ -1548,7 +1548,7 @@ MODULE_PARM_DESC(noaccel,
 "(default=0)");
 module_param(noscale, int, 0);
 MODULE_PARM_DESC(noscale,
-"Disables screen scaleing. (0 or 1=disable) "
+"Disables screen scaling. (0 or 1=disable) "
 "(default=0, do scaling)");
 module_param(paneltweak, int, 0);
 MODULE_PARM_DESC(paneltweak,
-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Freedreno] [PATCH] drm/msm/gpu: Increase the pm runtime autosuspend for 5xx

[Rob Clark]

On Mon, May 7, 2018 at 6:47 PM, Jordan Crouse  wrote:
> Experimentation shows that resuming power quickly after suspending
> ends up forcing a system hang for unknown reasons on 5xx targets.
> To avoid cycling the power too much (especially during init)
> turn up the autosuspend time for a5xx to 250ms and use
> pm_runtime_put_autosuspend() when applicable.
>
> Signed-off-by: Jordan Crouse 
> ---
>  drivers/gpu/drm/msm/adreno/adreno_device.c | 13 -
>  drivers/gpu/drm/msm/adreno/adreno_gpu.c|  3 ++-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h|  1 +
>  3 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c 
> b/drivers/gpu/drm/msm/adreno/adreno_device.c
> index 8e0cb161754b..e8499fffbefb 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_device.c
> +++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
> @@ -35,6 +35,7 @@ static const struct adreno_info gpulist[] = {
> [ADRENO_FW_PFP] = "a300_pfp.fw",
> },
> .gmem  = SZ_256K,
> +   .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .init  = a3xx_gpu_init,
> }, {
> .rev   = ADRENO_REV(3, 0, 6, 0),
> @@ -45,6 +46,7 @@ static const struct adreno_info gpulist[] = {
> [ADRENO_FW_PFP] = "a300_pfp.fw",
> },
> .gmem  = SZ_128K,
> +   .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .init  = a3xx_gpu_init,
> }, {
> .rev   = ADRENO_REV(3, 2, ANY_ID, ANY_ID),
> @@ -55,6 +57,7 @@ static const struct adreno_info gpulist[] = {
> [ADRENO_FW_PFP] = "a300_pfp.fw",
> },
> .gmem  = SZ_512K,
> +   .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .init  = a3xx_gpu_init,
> }, {
> .rev   = ADRENO_REV(3, 3, 0, ANY_ID),
> @@ -65,6 +68,7 @@ static const struct adreno_info gpulist[] = {
> [ADRENO_FW_PFP] = "a330_pfp.fw",
> },
> .gmem  = SZ_1M,
> +   .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .init  = a3xx_gpu_init,
> }, {
> .rev   = ADRENO_REV(4, 2, 0, ANY_ID),
> @@ -75,6 +79,7 @@ static const struct adreno_info gpulist[] = {
> [ADRENO_FW_PFP] = "a420_pfp.fw",
> },
> .gmem  = (SZ_1M + SZ_512K),
> +   .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .init  = a4xx_gpu_init,
> }, {
> .rev   = ADRENO_REV(4, 3, 0, ANY_ID),
> @@ -85,6 +90,7 @@ static const struct adreno_info gpulist[] = {
> [ADRENO_FW_PFP] = "a420_pfp.fw",
> },
> .gmem  = (SZ_1M + SZ_512K),
> +   .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> .init  = a4xx_gpu_init,
> }, {
> .rev = ADRENO_REV(5, 3, 0, 2),
> @@ -96,6 +102,11 @@ static const struct adreno_info gpulist[] = {
> [ADRENO_FW_GPMU] = "a530v3_gpmu.fw2",
> },
> .gmem = SZ_1M,
> +   /*
> +* Increase inactive period to 250 to avoid bouncing
> +* the GDSC which appears to make it grumpy
> +*/
> +   .inactive_period = 250,

I suppose having inactive_period per-gpu is reasonable, in the sense
that I guess the time it takes to "boot" the gpu might differ (and I
guess the power cost too)..

Having an artificial high value for a530 seems a bit gross, although
not really against short-term hacks since it is a pita when things
don't work with upstream trees.  But it is kind of papering over the
issue, and no guarantee that userspace doesn't in some case wait long
enough for inactive to kick in, but not long enough after that to
anger gdsc[1].. so I think someone who knows the gdsc stuff really
needs to have a look at the root problem.

BR,
-R

[1] I'm assuming the issue is time between gdsc-off and gdsc-on... I
guess if it is time between gdsc-on and gdsc-on this might be
sufficent.  I remember in the early days of rc6 on intel, there were
similar sorts of issues, but it was really more motherboard specific
than chip specific, ie. some had power circuitry that simply wasn't up
to the task of handling the rapid toggles.

> .quirks = ADRENO_QUIRK_TWO_PASS_USE_WFI |
> ADRENO_QUIRK_FAULT_DETECT_MASK,
> .init = a5xx_gpu_init,
> @@ -158,7 +169,7 @@ struct msm_gpu *adreno_load_gpu(struct drm_device *dev)
> mutex_lock(>struct_mutex);
> ret = msm_gpu_hw_init(gpu);
> mutex_unlock(>struct_mutex);
> -   pm_runtime_put_sync(>dev);
> +   pm_runtime_put_autosuspend(>dev);
> if (ret) {
> dev_err(dev->dev, "gpu hw init 

[Bug 106188] Can't successfully set pstates in pp_od_clk_voltage

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106188

--- Comment #6 from Alex Deucher  ---
(In reply to tempel.julian from comment #4)
> However, I am still not able to raise the maximum allowed power consumption
> of the GPU.
> It's clear that "/sys/class/drm/card0/device/hwmon/hwmon0/power1_cap" sets
> the actual power limit and thus I need to raise it. But the problem is:
> - I can't set it higher than power1_cap_max, only values below work.
> - power1_cap_max equals to power1_cap, so raising power consumption is
> actually completely forbidden
> - Despite of being root, I don't have write access to power1_cap_max, unlike
> to power1_cap

The max supported power cap is defined by the OEM in a vbios table and we limit
the max to that value.  power1_cap_min and max are RO so you can't change them.
 They define the range of available values.

-- 
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 106309] MST Multi-Stream Transport Kills All Displays Using Radeon Driver On Radeon HD 7570

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106309

Alex Deucher  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #4 from Alex Deucher  ---
The radeon driver does not support MST.

-- 
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/i915/gvt: fix spelling mistake: "resseting" -> "resetting"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in gvt_dbg_core debug message

Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 2e0a02a80fe4..7b856c9b4e07 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -502,7 +502,7 @@ void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu, 
bool dmlr,
unsigned int resetting_eng = dmlr ? ALL_ENGINES : engine_mask;
 
gvt_dbg_core("--\n");
-   gvt_dbg_core("resseting vgpu%d, dmlr %d, engine_mask %08x\n",
+   gvt_dbg_core("resetting vgpu%d, dmlr %d, engine_mask %08x\n",
 vgpu->id, dmlr, engine_mask);
 
vgpu->resetting_eng = resetting_eng;
-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106306] amdgpu CIK power management issues (overdrive and wattman)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106306

--- Comment #2 from Alex Deucher  ---
CI parts default to the legacy dpm support, you need to enable powerplay to use
the new APIs.  Boot with amdgpu.dpm=1 on the kernel command line in grub to
force the driver to use powerplay rather than the old dpm code.

-- 
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 106303] amdgpu on RX 560: memory and core clocks not lowered on idle

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106303

--- Comment #4 from Alex Deucher  ---
Can you bisect?  Are you using multiple monitors?

-- 
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] Add SPDX idenitifier and clarify license

[Alex Deucher]

On Thu, May 3, 2018 at 11:41 AM, Dirk Hohndel  wrote:
> On Thu, May 03, 2018 at 08:46:20AM -0400, Sean Paul wrote:
>>
>> Thank you for the awesome summary, it is very helpful! So since the 
>> boilerplate
>> has to stay, is there a benefit to adding the SPDX header? Is it just to make
>> scripting/scraping easier?
>
> Actually, the header now adds the correct information. Without the header
> it is not clear that these files are supposed to be dual licensed under
> MIT or GPL-2.
>

Should these (or any of the drm drivers for that matter) be dual
licensed or just MIT?  The code is MIT.

Alex

> And yes, it of course simplifies tooling as well, which is why there is a
> push to get these headers broadly added to many open source projects.
>
> /D
> ___
> 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

[Bug 106404] Hang in draw function caused by interaction of glutInitWindowPosition, glutFullScreen , glDrawBuffer(GL_FRONT)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106404

Alex Deucher  changed:

   What|Removed |Added

Product|DRI |Mesa
 QA Contact||dri-devel@lists.freedesktop
   ||.org
  Component|DRM/AMDgpu  |Drivers/Gallium/radeonsi

-- 
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 106177] overclocking doesn't work with 4.17-rc1

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106177

--- Comment #5 from Alex Deucher  ---
Please use debugfs (e.g., /sys/kernel/debug/dri/0/amdgpu_pm_info) to check the
current clocks.

-- 
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 106402] amdgpu causes kernel Oops: 0002 [#1] SMP PTI

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106402

--- Comment #1 from Alex Deucher  ---
Please attach your full dmesg output and xorg log if you are using X.

-- 
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 106228] amdgpu reads back brightness 0 (which is not true) if checked before a brightness has been explicitly set

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106228

--- Comment #2 from Harry Wentland  ---
That patch only affects Carrizo and should only be needed for S3.

We don't see this issue with Ubuntu 18.04 on a Raven laptop we have available.
The OS (Gnome) shows brightness as expected on boot.

I wonder if some laptops behave differently but I can't think why.

-- 
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 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199025

--- Comment #30 from Patrice (p.pol...@free.fr) ---
I can't access the faulty machine until next Saturday - but it runs Fedora28's
latest Xfce .

-- 
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 106228] amdgpu reads back brightness 0 (which is not true) if checked before a brightness has been explicitly set

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106228

--- Comment #1 from Alex Deucher  ---
Harry, I thought we fixed something like this recently.  Maybe this patch?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c3d7bad88e3b35b981eecc1645ddbb3f13a8b54f

-- 
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: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

[Jani Nikula]

On Wed, 09 May 2018, Feng Tang  wrote:
>  >> > > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
>> >> > > > > Quoting Feng Tang (2018-05-07 11:36:09)
>> >> > > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been 
>> >> > > > > > bumped
>> >> > > > > > from 7 to 32, which may hurt the boot/init time for some 
>> >> > > > > > platforms,
>> >> > > > > > as the 32 retries may take hundreds of ms.
>> >> > > > >
>> >> > > > > If we need that many retries, so be it. No modparam, the driver 
>> >> > > > > just has
>> >> > > > > to work.
>> >> > > >
>> >> > > > I understand your point. The retry numer was originally 7, and 
>> >> > > > worked
>> >> > > > fine untill the Dell 4K monitor which changes to 32.  According to 
>> >> > > > my test,
>> >> > > > each retry will take about 8ms on the A3960 based NUC.
>> >> > > >
>> >> > > > One of our product need to boot up within a given time limit, this
>> >> > > > 32 retries will take about 1/3 of the budget (about 270ms), that's
>> >> > > > why I would try to make it a parameter.
>> >> > >
>> >> > > The essence is that probing whether a monitor is connected should not 
>> >> > > be
>> >> > > blocking boot. If an async probe tries and fails to find a monitor,
>> >> > > fine - no one will notice. If it does take 270ms to find a monitor, it
>> >> > > turns on 200ms after userspace kicks in, just like any other hotplug.
>> >> >
>> >> > Yeah, the fix here is to get the probing out of the driver load path, 
>> >> > not
>> >> > to break the driver for some funky monitors. And definitely not using a
>> >> > modparam.
>> >>
>> >> Hi Chris and Daniel,
>> >>
>> >> After reading the i915 modeset init code, I did some experiments:
>> >> 1. make the intel_modeset_init() function async (here async means
>> >>creating a async func wrapper and call async_schedul() for it)
>> >> 2. make the intel_setup_outpus()+intel_modeset_setup_hw_state() async
>> >
>> > You could just set i915_pci_driver.driver.prove_type =
>> > PROBE_PREFER_ASYNCHRONOUS for the same result, or set i915.async_probe=1
>> > for testing.
>> >
>> > However, if it's blocking on async_synchronize_full(), that will be no
>> > improvement. So if it is only an existing async_sychronize_full()
>> > causing the fbdev config to be waited on before userspace, we need to
>> > stop using the async mechanism and just use an ordinary worker and
>> > manual flushing. If it's the fbdev probing blocking you, why are you
>> > using fbdev?
>> 
>> Well if it's edp probing, then atm we do need to block since we have
>> no support for panel hotplugging. And userspace generally no
>> expectations that built-in panels come async_synchronize_full
>> making our fbdev code less async than desired is kinda a different
>> story I think here. First step would be trying to figure out why we
>> even bother with edp probing on this platform, when the thing isn't
>> there. Sounds like broken VBT.
>
> Hi Daniel,
>
> Here are some of the VBT and DPCD related logs on my A3900 (bxt + GEN9 LP)
> based NUC. but I don't have the knowledge to tell if the VBT is broken :)

Please run current upstream drm-tip when you're suggesting changes to
upstream code. Looks like you're running at most v4.14. This can't be
emphasized enough. We can't and won't merge the changes unless they make
sense with current code.

As to vbt, please send me /sys/kernel/debug/dri/0/i915_vbt.

BR,
Jani.

>
> [0.545231] [drm:intel_bios_init] Set default to SSC at 10 kHz
> [0.545237] [drm:intel_bios_init] VBT signature "$VBT BROXTON", 
> BDB version 207
> [0.545241] [drm:intel_bios_init] BDB_GENERAL_FEATURES int_tv_support 0 
> int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 12 display_clock_mode 1 
> fdi_rx_polarity_inverted 0
> [0.545245] [drm:intel_bios_init] crt_ddc_bus_pin: 2
> [0.545255] [drm:intel_opregion_get_panel_type] Failed to get panel 
> details from OpRegion (-19)
> [0.545257] [drm:intel_bios_init] Panel type: 0 (VBT)
> [0.545260] [drm:intel_bios_init] DRRS supported mode is seamless
> [0.545275] [drm:intel_bios_init] Found panel mode in BIOS VBT tables:
> [0.545281] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 
> 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x8 0xa
> [0.545292] [drm:intel_bios_init] VBT backlight PWM modulation frequency 
> 200 Hz, active high, min brightness 0, level 180, controller 1
> [0.545301] [drm:intel_bios_init] Unsupported child device size for SDVO 
> mapping.
> [0.545305] [drm:intel_bios_init] Expected child device config size for 
> VBT version 207 not known; assuming 38
> [0.545323] [drm:intel_bios_init] DRRS State Enabled:1
> [0.545334] [drm:intel_bios_init] Port A VBT info: DP:1 HDMI:0 DVI:0 EDP:1 
> CRT:0
> [0.545338] [drm:intel_bios_init] VBT HDMI level shift for port A: 0
> [0.545341] [drm:intel_bios_init] Port B VBT info: DP:0 HDMI:1 DVI:1 EDP:0 
> CRT:0
> [0.545344] 

Re: [PATCH 2/2] drm/dp: Correctly mask DP_TRAINING_AUX_RD_INTERVAL values for DP 1.4

[Rodrigo Vivi]

On Fri, May 04, 2018 at 03:18:00PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood 
> 
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new feature wait interval
> would be increased by 512 ms, when spec is max 16 ms. This behavior is
> described in table 2-158 of DP 1.4 spec address eh.
> 
> With the introduction of DP 1.4 spec main link clock recovery was
> standardized to 100 us regardless of TRAINING_AUX_RD_INTERVAL value.
> 
> To avoid breaking panels that are not spec compiant we now warn on
> invalid values.
> 
> V2: commit title/message, masking all 7 bits, warn on out of spec values.
> V3: commit message, make link train clock recovery follow DP 1.4 spec.
> V4: style changes
> V5: typo
> V6: print statement revisions, DP_REV to DPCD_REV, comment correction
> V7: typo
> V8: Style
> V9: Strip out DPCD_REV_XX into seperate patch
> v10: DPCD_REV_XX to DP_DPCD_REV_XX
> 
> Signed-off-by: Matt Atwood 
> Reviewed-by: Rodrigo Vivi 

patches pushed to drm-misc-next.

Thanks,
Rodrigo.

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 22 ++
>  include/drm/drm_dp_helper.h |  1 +
>  2 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index ffe14ec3e7f2..36c7609a4bd5 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -119,18 +119,32 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
> link_status[DP_LINK_STATUS_SI
>  EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>  
>  void drm_dp_link_train_clock_recovery_delay(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> +   DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> +   rd_interval);
> +
> + if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
>   udelay(100);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>  
>  void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE]) 
> {
> - if (dpcd[DP_TRAINING_AUX_RD_INTERVAL] == 0)
> + int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> +   DP_TRAINING_AUX_RD_MASK;
> +
> + if (rd_interval > 4)
> + DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> +   rd_interval);
> +
> + if (rd_interval == 0)
>   udelay(400);
>   else
> - mdelay(dpcd[DP_TRAINING_AUX_RD_INTERVAL] * 4);
> + mdelay(rd_interval * 4);
>  }
>  EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>  
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 96dcef479ed6..ecf3e2bf293b 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -124,6 +124,7 @@
>  # define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3) /* edp v1.2 or higher 
> */
>  
>  #define DP_TRAINING_AUX_RD_INTERVAL 0x00e   /* XXX 1.2? */
> +# define DP_TRAINING_AUX_RD_MASK0x7F/* XXX 1.2? */
>  
>  #define DP_ADAPTER_CAP   0x00f   /* 1.2 */
>  # define DP_FORCE_LOAD_SENSE_CAP (1 << 0)
> -- 
> 2.17.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199025

--- Comment #29 from Paul van Maaren (ker...@vanmaaren.org) ---
I just did the runlevel test and it does not make difference for me. I did:

ln -sf  /usr/lib/systemd/system/multi-user.target
/etc/systemd/system/default.target

and a reboot to 4.16.6-302 and ran:

echo mem > /sys/power/state

The power light stayed on and it does not wake up. I tried the same after
booting to 4.14.18-300 that worked fine.

-- 
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: amdgpu hangs on boot or shutdown on AMD Raven Ridge CPU (Engineer Sample)

[Daniel Drake]

WHi Alex,

On Thu, Apr 19, 2018 at 4:13 PM, Alex Deucher  wrote:
 https://bugs.freedesktop.org/show_bug.cgi?id=105684
>>>
>>> No progress made on that bug report so far.
>>> What can we do to help this advance?
>>
>> Ping, any news here? How can we help advance on this bug?
>
> Can you try one of these branches?
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
> https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.18-wip
> do they work any better?

It's been over 3 months since we reported this bug by email, over 6
weeks since we reported it on bugzilla, and still there has been no
meaningful diagnostics help from AMD. This follows a similar pattern
to what we have seen with other issues prior to this one.

What can we do so that this bug gets some attention from your team?

Secondarily https://bugs.freedesktop.org/show_bug.cgi?id=106228 is
another bug that needs attention. We have a growing number of consumer
platforms affected by this. When booted, the amdgpu screen brightness
value is incorrectly read back as 0, which systemd will then store on
shutdown. On next boot, it restores the very low brightness level.
This can reproduce out of the box on Fedora, Ubuntu, etc.

Thanks,
Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 00/18] Fix some build warnings/errors with Sphinx

[Luis R. Rodriguez]

On Tue, May 08, 2018 at 10:13:42AM -0600, Jonathan Corbet wrote:
> On Mon,  7 May 2018 06:35:36 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > I decided to give a try with Sphinx last stable version
> > (1.17.4), and noticed several issues. The worse one was
> > with the networking book: a non-standard footnote there
> > with [*] instead of a number causes it to break PDF building.
> > 
> > So, I took some spare time to address some warnings all over
> > the tree, and moved a few text documents to a book. 
> 
> OK, I've applied the ones that seem to make sense for me to take now.
> There's comments on the firmware one, 

I'll fold in the fixes for the firmware API which do apply to my queue.

  Luis
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/7] drm/mediatek: move dpi private data to device

[kbuild test robot]

Hi chunhui,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.17-rc4 next-20180507]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bibby-Hsieh/drm-mediatek-support-hdmi-output-for-mt2701-and-mt7623/20180508-140924
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers/gpu//drm/mediatek/mtk_dpi.c: In function 'mtk_dpi_power_on':
>> drivers/gpu//drm/mediatek/mtk_dpi.c:444:9: warning: 'ret' may be used 
>> uninitialized in this function [-Wmaybe-uninitialized]
 return ret;
^~~

vim +/ret +444 drivers/gpu//drm/mediatek/mtk_dpi.c

9e629c17 Jie Qiu 2016-01-04  405  
9e629c17 Jie Qiu 2016-01-04  406  static int mtk_dpi_power_on(struct 
mtk_dpi *dpi, enum mtk_dpi_power_ctl pctl)
9e629c17 Jie Qiu 2016-01-04  407  {
9e629c17 Jie Qiu 2016-01-04  408int ret;
9e629c17 Jie Qiu 2016-01-04  409  
51df75e5 chunhui dai 2018-05-08  410if (++dpi->refcount != 1)
51df75e5 chunhui dai 2018-05-08  411return 0;
51df75e5 chunhui dai 2018-05-08  412  
9e629c17 Jie Qiu 2016-01-04  413dpi->power_ctl |= pctl;
9e629c17 Jie Qiu 2016-01-04  414  
9e629c17 Jie Qiu 2016-01-04  415if (!(dpi->power_ctl & DPI_POWER_START) 
&&
9e629c17 Jie Qiu 2016-01-04  416!(dpi->power_ctl & 
DPI_POWER_ENABLE))
51df75e5 chunhui dai 2018-05-08  417goto err_refcount;
9e629c17 Jie Qiu 2016-01-04  418  
9e629c17 Jie Qiu 2016-01-04  419if (dpi->power_sta)
51df75e5 chunhui dai 2018-05-08  420goto err_refcount;
9e629c17 Jie Qiu 2016-01-04  421  
9e629c17 Jie Qiu 2016-01-04  422ret = 
clk_prepare_enable(dpi->engine_clk);
9e629c17 Jie Qiu 2016-01-04  423if (ret) {
9e629c17 Jie Qiu 2016-01-04  424dev_err(dpi->dev, "Failed to 
enable engine clock: %d\n", ret);
9e629c17 Jie Qiu 2016-01-04  425goto err_eng;
9e629c17 Jie Qiu 2016-01-04  426}
9e629c17 Jie Qiu 2016-01-04  427  
9e629c17 Jie Qiu 2016-01-04  428ret = 
clk_prepare_enable(dpi->pixel_clk);
9e629c17 Jie Qiu 2016-01-04  429if (ret) {
9e629c17 Jie Qiu 2016-01-04  430dev_err(dpi->dev, "Failed to 
enable pixel clock: %d\n", ret);
9e629c17 Jie Qiu 2016-01-04  431goto err_pixel;
9e629c17 Jie Qiu 2016-01-04  432}
9e629c17 Jie Qiu 2016-01-04  433  
9e629c17 Jie Qiu 2016-01-04  434mtk_dpi_enable(dpi);
9e629c17 Jie Qiu 2016-01-04  435dpi->power_sta = true;
9e629c17 Jie Qiu 2016-01-04  436return 0;
9e629c17 Jie Qiu 2016-01-04  437  
9e629c17 Jie Qiu 2016-01-04  438  err_pixel:
9e629c17 Jie Qiu 2016-01-04  439clk_disable_unprepare(dpi->engine_clk);
9e629c17 Jie Qiu 2016-01-04  440  err_eng:
9e629c17 Jie Qiu 2016-01-04  441dpi->power_ctl &= ~pctl;
51df75e5 chunhui dai 2018-05-08  442  err_refcount:
51df75e5 chunhui dai 2018-05-08  443dpi->refcount--;
9e629c17 Jie Qiu 2016-01-04 @444return ret;
9e629c17 Jie Qiu 2016-01-04  445  }
9e629c17 Jie Qiu 2016-01-04  446  

:: The code at line 444 was first introduced by commit
:: 9e629c17aa8d7a75b8c1d99ed42892cd8ba7cdc4 drm/mediatek: Add DPI sub driver

:: TO: Jie Qiu <jie@mediatek.com>
:: CC: Philipp Zabel <p.za...@pengutronix.de>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106441] Totem video playback stuttering and graphical artifacts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106441

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #139426|text/x-log  |text/plain
  mime type||

-- 
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 00/18] Fix some build warnings/errors with Sphinx

[Jonathan Corbet]

On Mon,  7 May 2018 06:35:36 -0300
Mauro Carvalho Chehab  wrote:

> I decided to give a try with Sphinx last stable version
> (1.17.4), and noticed several issues. The worse one was
> with the networking book: a non-standard footnote there
> with [*] instead of a number causes it to break PDF building.
> 
> So, I took some spare time to address some warnings all over
> the tree, and moved a few text documents to a book. 

OK, I've applied the ones that seem to make sense for me to take now.
There's comments on the firmware one, and I'd rather have Tejun's OK for
the cgroup one.  The code-comment changes should probably go via the
usual maintainers.

> I with
> I had more time to move the other ones and to solve other
> warnings.

You and me both - but each step helps!

Thanks,

jon
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 106441] Totem video playback stuttering and graphical artifacts

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=106441

Bug ID: 106441
   Summary: Totem video playback stuttering and graphical
artifacts
   Product: Mesa
   Version: 18.0
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: kaspar.t...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 139426
  --> https://bugs.freedesktop.org/attachment.cgi?id=139426=edit
Totem log

Hello!

With the update to Mesa 18, I have been having issues with Gnome's Totem
player. The issue also appears with Cheese and Maps.

After updating Gnome to 3.28.X, Totem got some update that made the software
completely unusable for me. 

1) Seeking does not work
2) Pause button does not respond
3) Next/Previos does not respond
4) Seeking menu does not work when clicking on a time frame to jump to
5) Full screen creates strange red visual artifacts
6) The video timer looks strange. Some visual artifacts are present
7) Playback of a video is very slow. There is some serious lag

I have made an illustrative video of the problem hosted here:
https://webmshare.com/rarKQ

I have some logs by using GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:2 totem 2> log
These logs are attached here.

Totem version: totem 3.26.0+37+g84700147-1
Gstreamer version: gstreamer 1.14.0-1

My system information:

System Information


  PROCESSOR:  Intel Core i5-4570 @ 3.60GHz
Core Count:   4
Extensions:   SSE 4.2 + AVX2 + AVX + RDRAND + FSGSBASE
Cache Size:   6144 KB
Microcode:0x24
Scaling Driver:   intel_pstate powersave

  GRAPHICS:   MSI AMD Radeon RX 470/480/570/580
Display Driver:   modesetting 1.19.1
Monitor:  BenQ xl2411t
Screen:   1920x1080

  MOTHERBOARD:ASUS B85-PLUS
Memory:   16384MB
Chipset:  Intel 4th Gen Core DRAM
Network:  Realtek RTL8111/8168/8411

  DISK:   128GB Samsung SSD 840 + 1000GB Seagate ST1000DM010-2DM1 +
1000GB Seagate ST1000DM003-1CH1
File-System:  btrfs
Mount Options:relatime rw space_cache ssd subvol=/ subvolid=5
Disk Scheduler:   CFQ

  OPERATING SYSTEM:   Arch rolling
Kernel:   4.16.3-1-ARCH (x86_64)
Desktop:  GNOME Shell 3.28.1
Compiler: GCC 7.3.1 20180312



The Totem developers told me to refer to Meas. I opened a bug in their tracker:
https://bugzilla.gnome.org/show_bug.cgi?id=795514

Let me know how I can give more information to you if needed. I have no idea my
self what else to look for.

-- 
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: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

[Feng Tang]

 >> > > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
> >> > > > > Quoting Feng Tang (2018-05-07 11:36:09)
> >> > > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been 
> >> > > > > > bumped
> >> > > > > > from 7 to 32, which may hurt the boot/init time for some 
> >> > > > > > platforms,
> >> > > > > > as the 32 retries may take hundreds of ms.
> >> > > > >
> >> > > > > If we need that many retries, so be it. No modparam, the driver 
> >> > > > > just has
> >> > > > > to work.
> >> > > >
> >> > > > I understand your point. The retry numer was originally 7, and worked
> >> > > > fine untill the Dell 4K monitor which changes to 32.  According to 
> >> > > > my test,
> >> > > > each retry will take about 8ms on the A3960 based NUC.
> >> > > >
> >> > > > One of our product need to boot up within a given time limit, this
> >> > > > 32 retries will take about 1/3 of the budget (about 270ms), that's
> >> > > > why I would try to make it a parameter.
> >> > >
> >> > > The essence is that probing whether a monitor is connected should not 
> >> > > be
> >> > > blocking boot. If an async probe tries and fails to find a monitor,
> >> > > fine - no one will notice. If it does take 270ms to find a monitor, it
> >> > > turns on 200ms after userspace kicks in, just like any other hotplug.
> >> >
> >> > Yeah, the fix here is to get the probing out of the driver load path, not
> >> > to break the driver for some funky monitors. And definitely not using a
> >> > modparam.
> >>
> >> Hi Chris and Daniel,
> >>
> >> After reading the i915 modeset init code, I did some experiments:
> >> 1. make the intel_modeset_init() function async (here async means
> >>creating a async func wrapper and call async_schedul() for it)
> >> 2. make the intel_setup_outpus()+intel_modeset_setup_hw_state() async
> >
> > You could just set i915_pci_driver.driver.prove_type =
> > PROBE_PREFER_ASYNCHRONOUS for the same result, or set i915.async_probe=1
> > for testing.
> >
> > However, if it's blocking on async_synchronize_full(), that will be no
> > improvement. So if it is only an existing async_sychronize_full()
> > causing the fbdev config to be waited on before userspace, we need to
> > stop using the async mechanism and just use an ordinary worker and
> > manual flushing. If it's the fbdev probing blocking you, why are you
> > using fbdev?
> 
> Well if it's edp probing, then atm we do need to block since we have
> no support for panel hotplugging. And userspace generally no
> expectations that built-in panels come async_synchronize_full
> making our fbdev code less async than desired is kinda a different
> story I think here. First step would be trying to figure out why we
> even bother with edp probing on this platform, when the thing isn't
> there. Sounds like broken VBT.

Hi Daniel,

Here are some of the VBT and DPCD related logs on my A3900 (bxt + GEN9 LP)
based NUC. but I don't have the knowledge to tell if the VBT is broken :)

[0.545231] [drm:intel_bios_init] Set default to SSC at 10 kHz
[0.545237] [drm:intel_bios_init] VBT signature "$VBT BROXTON", BDB 
version 207
[0.545241] [drm:intel_bios_init] BDB_GENERAL_FEATURES int_tv_support 0 
int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 12 display_clock_mode 1 
fdi_rx_polarity_inverted 0
[0.545245] [drm:intel_bios_init] crt_ddc_bus_pin: 2
[0.545255] [drm:intel_opregion_get_panel_type] Failed to get panel details 
from OpRegion (-19)
[0.545257] [drm:intel_bios_init] Panel type: 0 (VBT)
[0.545260] [drm:intel_bios_init] DRRS supported mode is seamless
[0.545275] [drm:intel_bios_init] Found panel mode in BIOS VBT tables:
[0.545281] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 
148500 1920 2008 2052 2200 1080 1084 1089 1125 0x8 0xa
[0.545292] [drm:intel_bios_init] VBT backlight PWM modulation frequency 200 
Hz, active high, min brightness 0, level 180, controller 1
[0.545301] [drm:intel_bios_init] Unsupported child device size for SDVO 
mapping.
[0.545305] [drm:intel_bios_init] Expected child device config size for VBT 
version 207 not known; assuming 38
[0.545323] [drm:intel_bios_init] DRRS State Enabled:1
[0.545334] [drm:intel_bios_init] Port A VBT info: DP:1 HDMI:0 DVI:0 EDP:1 
CRT:0
[0.545338] [drm:intel_bios_init] VBT HDMI level shift for port A: 0
[0.545341] [drm:intel_bios_init] Port B VBT info: DP:0 HDMI:1 DVI:1 EDP:0 
CRT:0
[0.545344] [drm:intel_bios_init] VBT HDMI level shift for port B: 8
[0.545347] [drm:intel_bios_init] Port C VBT info: DP:0 HDMI:1 DVI:1 EDP:0 
CRT:0
[0.545350] [drm:intel_bios_init] VBT HDMI level shift for port C: 8
[0.546076] [drm:gen9_set_dc_state] Setting DC state from 00 to 00
[0.546091] [drm:intel_power_well_enable] enabling power well 1
[0.546126] [drm:gvt_service_thread] gvt: core: service thread start
[0.546174] [drm:intel_update_cdclk] Current CD clock rate: 19200 kHz, VCO: 
0 kHz, ref: 19200 kHz
[

[PATCH] drm/etnaviv: replace license text with SPDX tags

[Lucas Stach]

This replaces the repetitive GPL-2.0 license text in code and header files
with the SPDX tags. Generated hardware headers aren't changed, as any changes
there need to be done in the upstream rnndb repository.

Signed-off-by: Lucas Stach 
---
Christian, I've replaced some of your copyright statements with the generic
"Etnaviv Project" statements we use almost everywhere. Please NACK this patch
if your aren't comfortable with this.
---
 drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 16 ++--
 drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c | 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 13 +
 drivers/gpu/drm/etnaviv/etnaviv_drv.c| 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_drv.h| 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_dump.c   | 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_dump.h   | 16 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gem.c| 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gem.h| 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c  | 16 ++--
 drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_hwdb.c   | 13 +
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c  | 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_iommu.h  | 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c   | 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_mmu.c| 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_mmu.h| 15 ++-
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.c| 13 +
 drivers/gpu/drm/etnaviv/etnaviv_perfmon.h| 13 +
 drivers/gpu/drm/etnaviv/etnaviv_sched.c  | 13 +
 drivers/gpu/drm/etnaviv/etnaviv_sched.h  | 13 +
 23 files changed, 40 insertions(+), 296 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c 
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index bfc6d4aa3b7c..7fea74861a87 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -1,18 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2014 Etnaviv Project
- * Author: Christian Gmeiner 
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
+ * Copyright (C) 2014-2018 Etnaviv Project
  */
 
 #include "etnaviv_cmdbuf.h"
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c 
b/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
index c107171b7f9e..b6c37da8ae15 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_cmd_parser.c
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2015 Etnaviv Project
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  If not, see .
+ * Copyright (C) 2015-2018 Etnaviv Project
  */
 
 #include 
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c 
b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
index 3746827f45eb..a3c44f145c1d 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c
@@ -1,17 +1,6 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2017 Etnaviv Project
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License version 2 as published by
- * the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but WITHOUT
- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
- * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
- * more details.
- *
- * You should have received a copy of the GNU General Public License along with
- * this program.  

[Bug 199655] amdgpu: XFX Radeon RX 580 runs its fans only in dangerously low speeds and ignores temperature

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199655

--- Comment #1 from Sergey Kondakov (virtuous...@gmail.com) ---
Created attachment 275837
  --> https://bugzilla.kernel.org/attachment.cgi?id=275837=edit
lspci_2018-05-08-quircks

-- 
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 199655] New: amdgpu: XFX Radeon RX 580 runs its fans only in dangerously low speeds and ignores temperature

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199655

Bug ID: 199655
   Summary: amdgpu: XFX Radeon RX 580 runs its fans only in
dangerously low speeds and ignores temperature
   Product: Drivers
   Version: 2.5
Kernel Version: 4.16.7
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: virtuous...@gmail.com
Regression: No

Created attachment 275835
  --> https://bugzilla.kernel.org/attachment.cgi?id=275835=edit
dmesg_2018-05-08-quircks

In Windows AMD drivers like to ignore VGA BIOS fan control settings along with
their own "Wattman" and disable fans until core temperature starts to go near
50-60 degrees, even at full load fans don't go over 2600 RPM there BUT on Linux
they get stuck at 800-900 RPM by default (if pwm1_enable is not tempered with),
at 1300-1400 RPM if pwm1_enable is set to '2', at 3500 RPM if it set to '0' and
only manual control of '1' works as expected. temp1_* settings are outright
ignored with error "permission denied". Unless manual control is used, GPU's
core may overheat to >70 degrees (I don't even want to know what's happening on
VRMs) at >90% load. This is madness.

In Linux on idle (~0% load in radeontop) GPU doesn't go lower than 41 degrees
even with 1300-1400 RPM on fans, even though under Windows it goes to 35-40
with fans completely off (which I don't want to allow anyway because I don't
know how safe are VRMs).

Easy way to overheat it is to use 'FSRCNNX_x2_r1_16-0-4-1.glsl' from
https://github.com/igv/FSRCNN-TensorFlow/releases with a ≤720p video.
https://bugs.freedesktop.org/show_bug.cgi?id=103401#c2 - my modded BIOS with
more aggressive cooling and lower frequency than stock.

-- 
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 v3 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

[Maxime Ripard]

On Mon, May 07, 2018 at 10:15:46PM +0200, Paul Kocialkowski wrote:
> > > + backlight: backlight {
> > > + compatible = "pwm-backlight";
> > > + pwms = < 0 5 PWM_POLARITY_INVERTED>;
> > > + brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
> > 
> > The increase in perceived brightness should be linear. Usually, for
> > PWMs backed backlight, an exponential list is a much better
> > approximation.
> 
> Thanks for the hint, it never occurred to me that pwm duty cycle was not
> linear with brightness, but that makes sense. I'll give that a try (on
> 255 values instead of 10 to keep some level of precision in low
> brightness). The way to go here is probably use a base-255 logarithm
> such as: duty cycle = range * log(i+1)/log(255) with i the linear
> brightness value (0 to 255) and range the amplitude of our values (that
> gets divided by the maximum brightness, so it's really up to hardware
> precision at this point). I'll go with a range of 255 as well.

Without going into something so complicated, usually a list with power
of two ending at 255 is a good approximation :)

> > > + {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <_pins_a>;
> > > + vmmc-supply = <_vcc3v3>;
> > 
> > You have the regulators described in your DT, you'd better use them
> > instead of the one coming from sunxi-common-regulators.dtsi.
> 
> Well, according to the reference A20 design, the mmc pins and the card
> are powered by the 3.3V power rail, that comes from a regular step-down
> regulator sourcing from IPSOUT, so I don't see what regulator I should
> better use. Do you have a suggestion?

That works for me then.

> > > + {
> > > + panel_power_pin: panel_power_pin@0 {
> > > + pins = "PH8";
> > > + function = "gpio_out";
> > > + };
> > > +};
> > 
> > You don't need that pinctrl node.
> 
> I'll get rid of it then. You mentioned that regulator-simple uses the
> old GPIO API, so I assumed it meant that a pinctrl node is still needed.
> For reference, it uses of_get_named_gpio (not the devm-managed fashion).

This is only relevant for the polarity of the pins, not the pinctrl part.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/etnaviv: mmuv2: support 40 bit phys address

[Lucas Stach]

MMUv2 supports up to 40 bits of physical address by folding the upper
8 bits into bits [4:11] of the PTE.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
index 2d9d09608bc2..f2e4fa773e22 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
@@ -87,11 +87,14 @@ static int etnaviv_iommuv2_map(struct etnaviv_iommu_domain 
*domain,
struct etnaviv_iommuv2_domain *etnaviv_domain =
to_etnaviv_domain(domain);
int mtlb_entry, stlb_entry, ret;
-   u32 entry = (u32)paddr | MMUv2_PTE_PRESENT;
+   u32 entry = lower_32_bits(paddr) | MMUv2_PTE_PRESENT;
 
if (size != SZ_4K)
return -EINVAL;
 
+   if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT))
+   entry |= (upper_32_bits(paddr) & 0xff) << 4;
+
if (prot & ETNAVIV_PROT_WRITE)
entry |= MMUv2_PTE_WRITEABLE;
 
-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/2] drm/etnaviv: switch MMU page tables to writecombine memory

[Lucas Stach]

We are likely to write multiple page entries at once and already ensure
proper write buffer flushing before GPU submit, so this improves CPU
time usage in the submit path without any downsides.

Signed-off-by: Lucas Stach 
---
v2: use shorter _wc function names.
---
 drivers/gpu/drm/etnaviv/etnaviv_iommu.c| 34 +-
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 74 ++
 2 files changed, 49 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
index 4b9b11ca6f03..4ada19054443 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu.c
@@ -47,11 +47,10 @@ static int __etnaviv_iommu_init(struct 
etnaviv_iommuv1_domain *etnaviv_domain)
u32 *p;
int i;
 
-   etnaviv_domain->base.bad_page_cpu = dma_alloc_coherent(
-   etnaviv_domain->base.dev,
-   SZ_4K,
-   
_domain->base.bad_page_dma,
-   GFP_KERNEL);
+   etnaviv_domain->base.bad_page_cpu =
+   dma_alloc_wc(etnaviv_domain->base.dev, SZ_4K,
+_domain->base.bad_page_dma,
+GFP_KERNEL);
if (!etnaviv_domain->base.bad_page_cpu)
return -ENOMEM;
 
@@ -59,14 +58,14 @@ static int __etnaviv_iommu_init(struct 
etnaviv_iommuv1_domain *etnaviv_domain)
for (i = 0; i < SZ_4K / 4; i++)
*p++ = 0xdead55aa;
 
-   etnaviv_domain->pgtable_cpu =
-   dma_alloc_coherent(etnaviv_domain->base.dev, PT_SIZE,
-  _domain->pgtable_dma,
-  GFP_KERNEL);
+   etnaviv_domain->pgtable_cpu = dma_alloc_wc(etnaviv_domain->base.dev,
+  PT_SIZE,
+  _domain->pgtable_dma,
+  GFP_KERNEL);
if (!etnaviv_domain->pgtable_cpu) {
-   dma_free_coherent(etnaviv_domain->base.dev, SZ_4K,
- etnaviv_domain->base.bad_page_cpu,
- etnaviv_domain->base.bad_page_dma);
+   dma_free_wc(etnaviv_domain->base.dev, SZ_4K,
+   etnaviv_domain->base.bad_page_cpu,
+   etnaviv_domain->base.bad_page_dma);
return -ENOMEM;
}
 
@@ -81,13 +80,12 @@ static void etnaviv_iommuv1_domain_free(struct 
etnaviv_iommu_domain *domain)
struct etnaviv_iommuv1_domain *etnaviv_domain =
to_etnaviv_domain(domain);
 
-   dma_free_coherent(etnaviv_domain->base.dev, PT_SIZE,
- etnaviv_domain->pgtable_cpu,
- etnaviv_domain->pgtable_dma);
+   dma_free_wc(etnaviv_domain->base.dev, PT_SIZE,
+   etnaviv_domain->pgtable_cpu, etnaviv_domain->pgtable_dma);
 
-   dma_free_coherent(etnaviv_domain->base.dev, SZ_4K,
- etnaviv_domain->base.bad_page_cpu,
- etnaviv_domain->base.bad_page_dma);
+   dma_free_wc(etnaviv_domain->base.dev, SZ_4K,
+   etnaviv_domain->base.bad_page_cpu,
+   etnaviv_domain->base.bad_page_dma);
 
kfree(etnaviv_domain);
 }
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
index 9752dbd5d28b..47785d61cd95 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
@@ -104,11 +104,10 @@ static int etnaviv_iommuv2_init(struct 
etnaviv_iommuv2_domain *etnaviv_domain)
int ret, i, j;
 
/* allocate scratch page */
-   etnaviv_domain->base.bad_page_cpu = dma_alloc_coherent(
-   etnaviv_domain->base.dev,
-   SZ_4K,
-   
_domain->base.bad_page_dma,
-   GFP_KERNEL);
+   etnaviv_domain->base.bad_page_cpu =
+   dma_alloc_wc(etnaviv_domain->base.dev, SZ_4K,
+_domain->base.bad_page_dma,
+GFP_KERNEL);
if (!etnaviv_domain->base.bad_page_cpu) {
ret = -ENOMEM;
goto fail_mem;
@@ -117,19 +116,17 @@ static int etnaviv_iommuv2_init(struct 
etnaviv_iommuv2_domain *etnaviv_domain)
for (i = 0; i < SZ_4K / 4; i++)
*p++ = 0xdead55aa;
 
-   etnaviv_domain->pta_cpu = dma_alloc_coherent(etnaviv_domain->base.dev,
-SZ_4K,
-

[PATCH v2 2/2] drm/etnaviv: mmuv2: allocate 2nd level page tables on demand

[Lucas Stach]

With etnaviv not being tied into the IOMMU framework anymore, the MMU
functions will only be called under sleeping locks. Thus we are able
to allocate the memory for the 2nd level page tables on demand without
having to deal with memory allocation in atomic context.

This speeds up driver intitialization on MMUv2 GPU cores, as we don't
need to preallocate all the page table memory and also reduces memory
consumption for most workloads, as most of them won't use the full
GPU virtual address space.

Signed-off-by: Lucas Stach 
---
v2: fill MTLB for unpopulated STLBs with PTE_EXCEPTION
---
 drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 63 --
 1 file changed, 34 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c 
b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
index 47785d61cd95..2d9d09608bc2 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c
@@ -47,8 +47,9 @@ struct etnaviv_iommuv2_domain {
u32 *mtlb_cpu;
dma_addr_t mtlb_dma;
/* S(lave) TLB aka second level pagetable */
-   u32 *stlb_cpu[1024];
-   dma_addr_t stlb_dma[1024];
+   u32 *stlb_cpu[MMUv2_MAX_STLB_ENTRIES];
+   dma_addr_t stlb_dma[MMUv2_MAX_STLB_ENTRIES];
+   DECLARE_BITMAP(stlb_allocated, MMUv2_MAX_STLB_ENTRIES);
 };
 
 static struct etnaviv_iommuv2_domain *
@@ -57,13 +58,35 @@ to_etnaviv_domain(struct etnaviv_iommu_domain *domain)
return container_of(domain, struct etnaviv_iommuv2_domain, base);
 }
 
+static int
+etnaviv_iommuv2_ensure_stlb(struct etnaviv_iommuv2_domain *etnaviv_domain,
+   int stlb)
+{
+   if (test_bit(stlb, etnaviv_domain->stlb_allocated))
+   return 0;
+
+   etnaviv_domain->stlb_cpu[stlb] =
+   dma_alloc_writecombine(etnaviv_domain->base.dev,
+  SZ_4K,
+  _domain->stlb_dma[stlb],
+  GFP_KERNEL);
+
+   if (!etnaviv_domain->stlb_cpu[stlb])
+   return -ENOMEM;
+
+   __set_bit(stlb, etnaviv_domain->stlb_allocated);
+   etnaviv_domain->mtlb_cpu[stlb] = etnaviv_domain->stlb_dma[stlb] |
+ MMUv2_PTE_PRESENT;
+   return 0;
+}
+
 static int etnaviv_iommuv2_map(struct etnaviv_iommu_domain *domain,
   unsigned long iova, phys_addr_t paddr,
   size_t size, int prot)
 {
struct etnaviv_iommuv2_domain *etnaviv_domain =
to_etnaviv_domain(domain);
-   int mtlb_entry, stlb_entry;
+   int mtlb_entry, stlb_entry, ret;
u32 entry = (u32)paddr | MMUv2_PTE_PRESENT;
 
if (size != SZ_4K)
@@ -75,6 +98,10 @@ static int etnaviv_iommuv2_map(struct etnaviv_iommu_domain 
*domain,
mtlb_entry = (iova & MMUv2_MTLB_MASK) >> MMUv2_MTLB_SHIFT;
stlb_entry = (iova & MMUv2_STLB_MASK) >> MMUv2_STLB_SHIFT;
 
+   ret = etnaviv_iommuv2_ensure_stlb(etnaviv_domain, mtlb_entry);
+   if (ret)
+   return ret;
+
etnaviv_domain->stlb_cpu[mtlb_entry][stlb_entry] = entry;
 
return 0;
@@ -101,7 +128,7 @@ static size_t etnaviv_iommuv2_unmap(struct 
etnaviv_iommu_domain *domain,
 static int etnaviv_iommuv2_init(struct etnaviv_iommuv2_domain *etnaviv_domain)
 {
u32 *p;
-   int ret, i, j;
+   int ret, i;
 
/* allocate scratch page */
etnaviv_domain->base.bad_page_cpu =
@@ -132,23 +159,8 @@ static int etnaviv_iommuv2_init(struct 
etnaviv_iommuv2_domain *etnaviv_domain)
goto fail_mem;
}
 
-   /* pre-populate STLB pages (may want to switch to on-demand later) */
-   for (i = 0; i < MMUv2_MAX_STLB_ENTRIES; i++) {
-   etnaviv_domain->stlb_cpu[i] =
-   dma_alloc_wc(etnaviv_domain->base.dev, SZ_4K,
-_domain->stlb_dma[i],
-GFP_KERNEL);
-   if (!etnaviv_domain->stlb_cpu[i]) {
-   ret = -ENOMEM;
-   goto fail_mem;
-   }
-   p = etnaviv_domain->stlb_cpu[i];
-   for (j = 0; j < SZ_4K / 4; j++)
-   *p++ = MMUv2_PTE_EXCEPTION;
-
-   etnaviv_domain->mtlb_cpu[i] = etnaviv_domain->stlb_dma[i] |
- MMUv2_PTE_PRESENT;
-   }
+   memset32(etnaviv_domain->mtlb_cpu, MMUv2_PTE_EXCEPTION,
+MMUv2_MAX_STLB_ENTRIES);
 
return 0;
 
@@ -166,13 +178,6 @@ static int etnaviv_iommuv2_init(struct 
etnaviv_iommuv2_domain *etnaviv_domain)
dma_free_wc(etnaviv_domain->base.dev, SZ_4K,
etnaviv_domain->mtlb_cpu, etnaviv_domain->mtlb_dma);
 
-   for (i = 0; i < MMUv2_MAX_STLB_ENTRIES; i++) 

[Bug 105786] System freeze, amdgpu 4.17-WIP, 4.16.0-rc1-576e538e5fe6

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105786

cd  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #2 from cd  ---
Not reproducible in 4.16.7

-- 
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 v2 10/26] drm/bridge: panel: provide an owner .odev device

[Jyri Sarha]

On 05/08/18 10:58, Peter Rosin wrote:
> On 2018-05-08 08:51, Jyri Sarha wrote:
>> On 05/04/18 16:51, Peter Rosin wrote:
>>> It gets rid of an #ifdef and the .of_node member is going away.
>>>
>>> Signed-off-by: Peter Rosin 
>>> ---
>>>  drivers/gpu/drm/bridge/panel.c | 4 +---
>>>  1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/bridge/panel.c b/drivers/gpu/drm/bridge/panel.c
>>> index 6d99d4a3beb3..f43d77b5ed20 100644
>>> --- a/drivers/gpu/drm/bridge/panel.c
>>> +++ b/drivers/gpu/drm/bridge/panel.c
>>> @@ -169,10 +169,8 @@ struct drm_bridge *drm_panel_bridge_add(struct 
>>> drm_panel *panel,
>>> panel_bridge->connector_type = connector_type;
>>> panel_bridge->panel = panel;
>>>  
>>> +   panel_bridge->bridge.odev = panel->dev;
>> I am afraid this approach will eventually conflict with my lately
>> accepted patch[1].
> I don't see how? The links are refcounted. So, if there is one link
> each for the panel and bridge between the drm device and the panel
> device that link will simply get two references. If/when the panel
> device then goes away, the drm device will be brought down because
> of that link (with two references, but that is irrelevant). When
> the drm device is brought down, it will (presumably) bring down the
> bridge as well (which will fix the refcount as the bridge link is
> killed as part of that).
> 

I guess you are right. If everything is done correctly the both links
should get removed in the tear down situation and all should be fine.


> Or have you done some test and seen an actual problem?
> 

No testing, just a hunch.

BR,
Jyri

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

[Daniel Vetter]

On Tue, May 8, 2018 at 1:33 PM, Chris Wilson  wrote:
> Quoting Feng Tang (2018-05-08 20:03:15)
>>
>> On Mon, May 07, 2018 at 05:09:21PM +0200, Daniel Vetter wrote:
>> > On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote:
>> > > Quoting Feng Tang (2018-05-07 22:26:34)
>> > > > Hi Chris,
>> > > >
>> > > > Thanks for the prompt review!
>> > > >
>> > > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
>> > > > > Quoting Feng Tang (2018-05-07 11:36:09)
>> > > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
>> > > > > > from 7 to 32, which may hurt the boot/init time for some platforms,
>> > > > > > as the 32 retries may take hundreds of ms.
>> > > > >
>> > > > > If we need that many retries, so be it. No modparam, the driver just 
>> > > > > has
>> > > > > to work.
>> > > >
>> > > > I understand your point. The retry numer was originally 7, and worked
>> > > > fine untill the Dell 4K monitor which changes to 32.  According to my 
>> > > > test,
>> > > > each retry will take about 8ms on the A3960 based NUC.
>> > > >
>> > > > One of our product need to boot up within a given time limit, this
>> > > > 32 retries will take about 1/3 of the budget (about 270ms), that's
>> > > > why I would try to make it a parameter.
>> > >
>> > > The essence is that probing whether a monitor is connected should not be
>> > > blocking boot. If an async probe tries and fails to find a monitor,
>> > > fine - no one will notice. If it does take 270ms to find a monitor, it
>> > > turns on 200ms after userspace kicks in, just like any other hotplug.
>> >
>> > Yeah, the fix here is to get the probing out of the driver load path, not
>> > to break the driver for some funky monitors. And definitely not using a
>> > modparam.
>>
>> Hi Chris and Daniel,
>>
>> After reading the i915 modeset init code, I did some experiments:
>> 1. make the intel_modeset_init() function async (here async means
>>creating a async func wrapper and call async_schedul() for it)
>> 2. make the intel_setup_outpus()+intel_modeset_setup_hw_state() async
>
> You could just set i915_pci_driver.driver.prove_type =
> PROBE_PREFER_ASYNCHRONOUS for the same result, or set i915.async_probe=1
> for testing.
>
> However, if it's blocking on async_synchronize_full(), that will be no
> improvement. So if it is only an existing async_sychronize_full()
> causing the fbdev config to be waited on before userspace, we need to
> stop using the async mechanism and just use an ordinary worker and
> manual flushing. If it's the fbdev probing blocking you, why are you
> using fbdev?

Well if it's edp probing, then atm we do need to block since we have
no support for panel hotplugging. And userspace generally no
expectations that built-in panels come async_synchronize_full
making our fbdev code less async than desired is kinda a different
story I think here. First step would be trying to figure out why we
even bother with edp probing on this platform, when the thing isn't
there. Sounds like broken VBT.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/xen-front: checking for NULL instead of IS_ERR

[Oleksandr Andrushchenko]

On 05/08/2018 12:34 PM, Oleksandr Andrushchenko wrote:

On 05/08/2018 12:26 PM, Dan Carpenter wrote:

drm_dev_alloc() returns error pointers, it never returns NULL.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display 
frontend")

Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

Applied to drm-misc-next,
Thank you


diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c

index 1b0ea9ac330e..8615e8522c7a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -543,8 +543,8 @@ static int xen_drm_drv_init(struct 
xen_drm_front_info *front_info)

  front_info->drm_info = drm_info;
    drm_dev = drm_dev_alloc(_drm_driver, dev);
-    if (!drm_dev) {
-    ret = -ENOMEM;
+    if (IS_ERR(drm_dev)) {
+    ret = PTR_ERR(drm_dev);
  goto fail;
  }
  ___
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 2/3] drm/xen-front: fix xen_drm_front_shbuf_alloc() error handling

[Oleksandr Andrushchenko]

On 05/08/2018 12:37 PM, Oleksandr Andrushchenko wrote:

On 05/08/2018 12:27 PM, Dan Carpenter wrote:

The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly. I've
changed it to always return error pointer consistently.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display 
frontend")

Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

Applied to drm-misc-next,
Thank you
diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c 
b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c

index d5705251a0d6..8099cb343ae3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
@@ -383,7 +383,7 @@ xen_drm_front_shbuf_alloc(struct 
xen_drm_front_shbuf_cfg *cfg)

    buf = kzalloc(sizeof(*buf), GFP_KERNEL);
  if (!buf)
-    return NULL;
+    return ERR_PTR(-ENOMEM);
    if (cfg->be_alloc)
  buf->ops = _ops;
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c

index 8615e8522c7a..378cb7ce0db5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -188,8 +188,8 @@ int xen_drm_front_dbuf_create(struct 
xen_drm_front_info *front_info,

  buf_cfg.be_alloc = front_info->cfg.be_alloc;
    shbuf = xen_drm_front_shbuf_alloc(_cfg);
-    if (!shbuf)
-    return -ENOMEM;
+    if (IS_ERR(shbuf))
+    return PTR_ERR(shbuf);
    ret = dbuf_add_to_list(front_info, shbuf, dbuf_cookie);
  if (ret < 0) {
___
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 3/3] drm/xen-front: Fix loop timeout

[Oleksandr Andrushchenko]

On 05/08/2018 12:37 PM, Oleksandr Andrushchenko wrote:

On 05/08/2018 12:28 PM, Dan Carpenter wrote:

If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display 
frontend")

Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

Applied to drm-misc-next,
Thank you
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c

index 378cb7ce0db5..3345ac71b391 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -778,7 +778,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
   */
  while ((xenbus_read_unsigned(front_info->xb_dev->otherend, 
"state",

   XenbusStateUnknown) != XenbusStateInitWait) &&
- to--)
+ --to)
  msleep(10);
    if (!to) {
___
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: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

[Chris Wilson]

Quoting Feng Tang (2018-05-08 20:03:15)
> 
> On Mon, May 07, 2018 at 05:09:21PM +0200, Daniel Vetter wrote:
> > On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote:
> > > Quoting Feng Tang (2018-05-07 22:26:34)
> > > > Hi Chris,
> > > > 
> > > > Thanks for the prompt review!
> > > > 
> > > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
> > > > > Quoting Feng Tang (2018-05-07 11:36:09)
> > > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
> > > > > > from 7 to 32, which may hurt the boot/init time for some platforms,
> > > > > > as the 32 retries may take hundreds of ms.
> > > > > 
> > > > > If we need that many retries, so be it. No modparam, the driver just 
> > > > > has
> > > > > to work.
> > > > 
> > > > I understand your point. The retry numer was originally 7, and worked
> > > > fine untill the Dell 4K monitor which changes to 32.  According to my 
> > > > test,
> > > > each retry will take about 8ms on the A3960 based NUC.
> > > > 
> > > > One of our product need to boot up within a given time limit, this
> > > > 32 retries will take about 1/3 of the budget (about 270ms), that's
> > > > why I would try to make it a parameter.
> > > 
> > > The essence is that probing whether a monitor is connected should not be
> > > blocking boot. If an async probe tries and fails to find a monitor,
> > > fine - no one will notice. If it does take 270ms to find a monitor, it
> > > turns on 200ms after userspace kicks in, just like any other hotplug.
> > 
> > Yeah, the fix here is to get the probing out of the driver load path, not
> > to break the driver for some funky monitors. And definitely not using a
> > modparam.
> 
> Hi Chris and Daniel,
> 
> After reading the i915 modeset init code, I did some experiments:
> 1. make the intel_modeset_init() function async (here async means
>creating a async func wrapper and call async_schedul() for it)
> 2. make the intel_setup_outpus()+intel_modeset_setup_hw_state() async 

You could just set i915_pci_driver.driver.prove_type =
PROBE_PREFER_ASYNCHRONOUS for the same result, or set i915.async_probe=1
for testing.

However, if it's blocking on async_synchronize_full(), that will be no
improvement. So if it is only an existing async_sychronize_full()
causing the fbdev config to be waited on before userspace, we need to
stop using the async mechanism and just use an ordinary worker and
manual flushing. If it's the fbdev probing blocking you, why are you
using fbdev?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 08/10] drm: Expose modes with aspect ratio, only if requested

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regardless of
whether user space requested this information or not.

This patch:
-prunes the modes with aspect-ratio information, from the
 drm_mode_get_connector modelist supplied to the user, if the
 user-space has not set the aspect ratio DRM client cap. However if
 such a mode is unique in the list, it is kept in the list, with
 aspect-ratio flags reset.
-prepares a list of exposed modes, which is used to find unique modes
 if aspect-ratio is not allowed.
-adds a new list_head 'exposed_head' in drm_mode_display, to traverse
 the list of exposed modes.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Cc: Jose Abreu 

Signed-off-by: Ankit Nautiyal 

V3: As suggested by Ville, modified the mechanism of pruning of modes
with aspect-ratio, if the aspect-ratio is not supported. Instead
of straight away pruning such a mode, the mode is retained with
aspect ratio bits set to zero, provided it is unique.
V4: rebase
V5: Addressed review comments from Ville:
-used a pointer to store last valid mode.
-avoided, modifying of picture_aspect_ratio in kernel mode,
 instead only flags bits of user mode are reset (if aspect-ratio
 is not supported).
V6: As suggested by Ville, corrected the mode pruning logic and
elaborated the mode pruning logic and the assumptions taken.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: Fixed the issue caused in kms_3d test, and enhanced the pruning
 logic to correctly identify and prune modes with aspect-ratio,
 if aspect-ratio cap is not set.
V12: As suggested by Ville, added another list_head in
 drm_mode_display to traverse the list of exposed modes and
 avoided duplication of modes.
V13: Minor modifications, as suggested by Ville.
v14: As suggested by Daniel Vetter and Ville Syrjala, corrected the
 pruning logic to avoid any dependency in the order of mode with
 aspect-ratio.
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_connector.c | 44 ++---
 include/drm/drm_modes.h | 13 
 2 files changed, 50 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index dfc8ca1..9b9ba5d 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1531,8 +1531,10 @@ static struct drm_encoder 
*drm_connector_get_encoder(struct drm_connector *conne
return connector->encoder;
 }
 
-static bool drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
-const struct drm_file *file_priv)
+static bool
+drm_mode_expose_to_userspace(const struct drm_display_mode *mode,
+const struct list_head *export_list,
+const struct drm_file *file_priv)
 {
/*
 * If user-space hasn't configured the driver to expose the stereo 3D
@@ -1540,6 +1542,23 @@ static bool drm_mode_expose_to_userspace(const struct 
drm_display_mode *mode,
 */
if (!file_priv->stereo_allowed && drm_mode_is_stereo(mode))
return false;
+   /*
+* If user-space hasn't configured the driver to expose the modes
+* with aspect-ratio, don't expose them. However if such a mode
+* is unique, let it be exposed, but reset the aspect-ratio flags
+* while preparing the list of user-modes.
+*/
+   if (!file_priv->aspect_ratio_allowed) {
+   struct drm_display_mode *mode_itr;
+
+   list_for_each_entry(mode_itr, export_list, export_head)
+   if (drm_mode_match(mode_itr, mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
+   return false;
+   }
 
return true;
 }
@@ -1559,6 +1578,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
struct drm_mode_modeinfo u_mode;
struct drm_mode_modeinfo __user *mode_ptr;
uint32_t __user *encoder_ptr;
+   LIST_HEAD(export_list);
 
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EINVAL;
@@ -1607,21 +1627,31 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
 
/* delayed so we get modes regardless of pre-fill_modes state */
list_for_each_entry(mode, >modes, head)
-   if (drm_mode_expose_to_userspace(mode, file_priv))
+   if (drm_mode_expose_to_userspace(mode, _list,
+ 

[PATCH v14 06/10] drm: Add DRM client cap for aspect-ratio

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
non-atomic user-spaces which have no intention or support to use this
aspect ratio information.

To avoid this, a new drm client cap is required to enable a non-atomic
user-space to advertise if it supports modes with aspect-ratio. Based
on this cap value, the kernel will take a call on exposing the aspect
ratio info in modes or not.

This patch adds the client cap for aspect-ratio.

Since no atomic-userspaces blow up on receiving aspect-ratio
information, the client cap for aspect-ratio is always enabled
for atomic clients.

Cc: Ville Syrjala 
Cc: Shashank Sharma 
Signed-off-by: Ankit Nautiyal 

V3: rebase
V4: As suggested by Marteen Lankhorst modified the commit message
explaining the need to use the DRM cap for aspect-ratio. Also,
tweaked the comment lines in the code for better understanding and
clarity, as recommended by Shashank Sharma.
V5: rebase
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: As suggested by Daniel Vetter and Ville Syrjala,
 always enable aspect-ratio client cap for atomic userspaces,
 if no atomic userspace breaks on aspect-ratio bits.
V13: rebase
V14: rebase

Reviewed-by: Shashank Sharma 
Reviewed-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_ioctl.c | 9 +
 include/drm/drm_file.h  | 8 
 include/uapi/drm/drm.h  | 7 +++
 3 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index eadeabc..0d4cfb2 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -324,6 +324,15 @@ drm_setclientcap(struct drm_device *dev, void *data, 
struct drm_file *file_priv)
return -EINVAL;
file_priv->atomic = req->value;
file_priv->universal_planes = req->value;
+   /*
+* No atomic user-space blows up on aspect ratio mode bits.
+*/
+   file_priv->aspect_ratio_allowed = req->value;
+   break;
+   case DRM_CLIENT_CAP_ASPECT_RATIO:
+   if (req->value > 1)
+   return -EINVAL;
+   file_priv->aspect_ratio_allowed = req->value;
break;
default:
return -EINVAL;
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 99ab50c..91a65a3 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -181,6 +181,14 @@ struct drm_file {
unsigned atomic:1;
 
/**
+* @aspect_ratio_allowed:
+*
+* True, if client can handle picture aspect ratios, and has requested
+* to pass this information along with the mode.
+*/
+   unsigned aspect_ratio_allowed:1;
+
+   /**
 * @is_master:
 *
 * This client is the creator of @master. Protected by struct
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 6fdff59..9c660e1 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -680,6 +680,13 @@ struct drm_get_cap {
  */
 #define DRM_CLIENT_CAP_ATOMIC  3
 
+/**
+ * DRM_CLIENT_CAP_ASPECT_RATIO
+ *
+ * If set to 1, the DRM core will provide aspect ratio information in modes.
+ */
+#define DRM_CLIENT_CAP_ASPECT_RATIO4
+
 /** DRM_IOCTL_SET_CLIENT_CAP ioctl argument type */
 struct drm_set_client_cap {
__u64 capability;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 05/10] video/hdmi: Reject illegal picture aspect ratios

[Nautiyal, Ankit K]

From: Ville Syrjälä 

AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Cc: Thierry Reding 
Cc: Hans Verkuil 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Ville Syrjälä 
Reviewed-by: Jose Abreu 
---
 drivers/video/hdmi.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 111a0ab..38716eb5 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -93,6 +93,9 @@ ssize_t hdmi_avi_infoframe_pack(struct hdmi_avi_infoframe 
*frame, void *buffer,
if (size < length)
return -ENOSPC;
 
+   if (frame->picture_aspect > HDMI_PICTURE_ASPECT_16_9)
+   return -EINVAL;
+
memset(buffer, 0, size);
 
ptr[0] = frame->type;
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 07/10] drm: Handle aspect ratio info in legacy modeset path

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is not supported by the user.

This patch:
1. rejects the modes with aspect-ratio info, during modeset, if the
   user does not support aspect ratio.
2. does not load the aspect-ratio info in user-mode structure, if
   aspect ratio is not supported.
3. adds helper functions for determining if aspect-ratio is expected
   in user-mode and for allowing/disallowing the aspect-ratio, if its
   not expected.

Signed-off-by: Ankit Nautiyal 

V3: Addressed review comments from Ville:
Do not corrupt the current crtc state by updating aspect-ratio on
the fly.
V4: rebase
V5: As suggested by Ville, rejected the modeset calls for modes with
aspect ratio, if the user does not set aspect-ratio cap.
V6: Used the helper functions for determining if aspect-ratio is
expected in the user-mode.
V7: rebase
V8: rebase
V9: rebase
V10: Modified the commit-message
V11: rebase
V12: Merged the patch for adding aspect-ratio helper functions
 with this patch.
V13: Minor modifications as suggested by Ville.
V14: Removed helper functions, as they were used only once in legacy
 modeset path, as suggested by Daniel Vetter.
---
 drivers/gpu/drm/drm_crtc.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index a231dd5..98a36e6 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -449,6 +449,8 @@ int drm_mode_getcrtc(struct drm_device *dev,
crtc_resp->mode_valid = 0;
}
}
+   if (!file_priv->aspect_ratio_allowed)
+   crtc_resp->mode.flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
drm_modeset_unlock(>mutex);
 
return 0;
@@ -628,6 +630,13 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
ret = -ENOMEM;
goto out;
}
+   if (!file_priv->aspect_ratio_allowed &&
+   (crtc_req->mode.flags & DRM_MODE_FLAG_PIC_AR_MASK) != 
DRM_MODE_FLAG_PIC_AR_NONE) {
+   DRM_DEBUG_KMS("Unexpected aspect-ratio flag bits\n");
+   ret = -EINVAL;
+   goto out;
+   }
+
 
ret = drm_mode_convert_umode(dev, mode, _req->mode);
if (ret) {
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 10/10] drm: Add and handle new aspect ratios in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

This patch was once reviewed and merged, and later reverted due
to lack of DRM client protection, while adding aspect ratio bits
in user modes. This is a re-spin of the series, with DRM client
cap protection.

The previous series can be found here:
https://pw-emeril.freedesktop.org/series/10850/

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul  (V2)
Reviewed-by: Jose Abreu  (V2)

Cc: Ville Syrjala 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: rebase
V4: rebase
V5: corrected the macro name for an aspect ratio, in a switch case.
V6: rebase
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 7dfabdd..c78ca0e 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1656,6 +1656,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case HDMI_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1721,6 +1727,12 @@ int drm_mode_convert_umode(struct drm_device *dev,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 50bcf42..4b3a1bb 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -93,6 +93,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -102,6 +104,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 #define  DRM_MODE_FLAG_ALL (DRM_MODE_FLAG_PHSYNC | \
 DRM_MODE_FLAG_NHSYNC | \
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 09/10] drm: Add aspect ratio parsing in DRM layer

[Nautiyal, Ankit K]

From: "Sharma, Shashank" 

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Background:
This patch was once reviewed and merged, and later reverted due to
lack of DRM cap protection. This is a re-spin of this patch, this
time with DRM cap protection, to avoid aspect ratio information, when
the client doesn't request for it.

Review link: https://pw-emeril.freedesktop.org/patch/104068/
Background discussion: https://patchwork.kernel.org/patch/9379057/

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride  (V2)
Reviewed-by: Jose Abreu  (V4)

Cc: Ville Syrjala 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Ankit Nautiyal 

V3: modified the aspect-ratio check in drm_mode_equal as per new flags
provided by Ville. https://patchwork.freedesktop.org/patch/188043/
V4: rebase
V5: rebase
V6: As recommended by Ville, avoided matching of aspect-ratio in
drm_fb_helper, while trying to find a common mode among connectors
for the target clone mode.
V7: rebase
V8: rebase
V9: rebase
V10: rebase
V11: rebase
V12: rebase
V13: rebase
V14: rebase
---
 drivers/gpu/drm/drm_fb_helper.c | 12 ++--
 drivers/gpu/drm/drm_modes.c | 35 ++-
 2 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 0646b10..2ee1eaa 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2183,7 +2183,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
for (j = 0; j < i; j++) {
if (!enabled[j])
continue;
-   if (!drm_mode_equal(modes[j], modes[i]))
+   if (!drm_mode_match(modes[j], modes[i],
+   DRM_MODE_MATCH_TIMINGS |
+   DRM_MODE_MATCH_CLOCK |
+   DRM_MODE_MATCH_FLAGS |
+   DRM_MODE_MATCH_3D_FLAGS))
can_clone = false;
}
}
@@ -2203,7 +2207,11 @@ static bool drm_target_cloned(struct drm_fb_helper 
*fb_helper,
 
fb_helper_conn = fb_helper->connector_info[i];
list_for_each_entry(mode, _helper_conn->connector->modes, 
head) {
-   if (drm_mode_equal(mode, dmt_mode))
+   if (drm_mode_match(mode, dmt_mode,
+  DRM_MODE_MATCH_TIMINGS |
+  DRM_MODE_MATCH_CLOCK |
+  DRM_MODE_MATCH_FLAGS |
+  DRM_MODE_MATCH_3D_FLAGS))
modes[i] = mode;
}
if (!modes[i])
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index c395a24..7dfabdd 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1049,7 +1049,8 @@ bool drm_mode_equal(const struct drm_display_mode *mode1,
  DRM_MODE_MATCH_TIMINGS |
  DRM_MODE_MATCH_CLOCK |
  DRM_MODE_MATCH_FLAGS |
- DRM_MODE_MATCH_3D_FLAGS);
+ DRM_MODE_MATCH_3D_FLAGS|
+ DRM_MODE_MATCH_ASPECT_RATIO);
 }
 EXPORT_SYMBOL(drm_mode_equal);
 
@@ -1647,6 +1648,20 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1693,6 +1708,24 @@ int drm_mode_convert_umode(struct drm_device *dev,
strncpy(out->name, in->name, 

[PATCH v14 03/10] drm/edid: Fix cea mode aspect ratio handling

[Nautiyal, Ankit K]

From: Ville Syrjälä 

commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.

Let's handle this by considering the aspect ratio as a requirement
for cea mode matching only if the passed in mode actually has a
non-zero aspect ratio field. This will keep userspace that doesn't
provide an aspect ratio working as before by matching it to the
first otherwise equal cea mode. And once userspace starts to
provide the aspect ratio it will be considerd a hard requirement
for the match.

Also change the hdmi mode matching to use drm_mode_match() for
consistency, but we don't match on aspect ratio there since the
spec doesn't list a specific aspect ratio for those modes.

Cc: Shashank Sharma 
Cc: "Lin, Jia" 
Cc: Akashdeep Sharma 
Cc: Jim Bride 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 5475f31..3f157c8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2930,11 +2930,15 @@ cea_mode_alternate_timings(u8 vic, struct 
drm_display_mode *mode)
 static u8 drm_match_cea_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
 unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2948,7 +2952,7 @@ static u8 drm_match_cea_mode_clock_tolerance(const struct 
drm_display_mode *to_m
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -2965,11 +2969,15 @@ static u8 drm_match_cea_mode_clock_tolerance(const 
struct drm_display_mode *to_m
  */
 u8 drm_match_cea_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
return 0;
 
+   if (to_match->picture_aspect_ratio)
+   match_flags |= DRM_MODE_MATCH_ASPECT_RATIO;
+
for (vic = 1; vic < ARRAY_SIZE(edid_cea_modes); vic++) {
struct drm_display_mode cea_mode = edid_cea_modes[vic];
unsigned int clock1, clock2;
@@ -2983,7 +2991,7 @@ u8 drm_match_cea_mode(const struct drm_display_mode 
*to_match)
continue;
 
do {
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, 
_mode))
+   if (drm_mode_match(to_match, _mode, match_flags))
return vic;
} while (cea_mode_alternate_timings(vic, _mode));
}
@@ -3030,6 +3038,7 @@ hdmi_mode_alternate_clock(const struct drm_display_mode 
*hdmi_mode)
 static u8 drm_match_hdmi_mode_clock_tolerance(const struct drm_display_mode 
*to_match,
  unsigned int clock_tolerance)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3047,7 +3056,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
+   if (drm_mode_match(to_match, hdmi_mode, match_flags))
return vic;
}
 
@@ -3064,6 +3073,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
  */
 static u8 drm_match_hdmi_mode(const struct drm_display_mode *to_match)
 {
+   unsigned int match_flags = DRM_MODE_MATCH_TIMINGS | 
DRM_MODE_MATCH_FLAGS;
u8 vic;
 
if (!to_match->clock)
@@ -3079,7 +3089,7 @@ static u8 drm_match_hdmi_mode(const struct 
drm_display_mode *to_match)
 
if 

[PATCH v14 04/10] drm/edid: Don't send bogus aspect ratios in AVI infoframes

[Nautiyal, Ankit K]

From: Ville Syrjälä 

If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.

Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of signalling none,
4:3, and 16:9. Currently we're sending these bogus infoframes
whenever the cea mode specifies some other aspect ratio.

Cc: Shashank Sharma 
Cc: Sean Paul 
Cc: Jose Abreu 
Cc: Daniel Vetter 
Cc: Emil Velikov 
Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3f157c8..40e1e24 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4833,6 +4833,7 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 const struct drm_display_mode *mode,
 bool is_hdmi2_sink)
 {
+   enum hdmi_picture_aspect picture_aspect;
int err;
 
if (!frame || !mode)
@@ -4875,13 +4876,23 @@ drm_hdmi_avi_infoframe_from_display_mode(struct 
hdmi_avi_infoframe *frame,
 * Populate picture aspect ratio from either
 * user input (if specified) or from the CEA mode list.
 */
-   if (mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_4_3 ||
-   mode->picture_aspect_ratio == HDMI_PICTURE_ASPECT_16_9)
-   frame->picture_aspect = mode->picture_aspect_ratio;
-   else if (frame->video_code > 0)
-   frame->picture_aspect = drm_get_cea_aspect_ratio(
-   frame->video_code);
+   picture_aspect = mode->picture_aspect_ratio;
+   if (picture_aspect == HDMI_PICTURE_ASPECT_NONE)
+   picture_aspect = drm_get_cea_aspect_ratio(frame->video_code);
 
+   /*
+* The infoframe can't convey anything but none, 4:3
+* and 16:9, so if the user has asked for anything else
+* we can only satisfy it by specifying the right VIC.
+*/
+   if (picture_aspect > HDMI_PICTURE_ASPECT_16_9) {
+   if (picture_aspect !=
+   drm_get_cea_aspect_ratio(frame->video_code))
+   return -EINVAL;
+   picture_aspect = HDMI_PICTURE_ASPECT_NONE;
+   }
+
+   frame->picture_aspect = picture_aspect;
frame->active_aspect = HDMI_ACTIVE_ASPECT_PICTURE;
frame->scan_mode = HDMI_SCAN_MODE_UNDERSCAN;
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 02/10] drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.

This doesn't actually change anything since the input mode
comes from detailed timings and we match it against
edid_4k_modes[] which. So none of those modes can have stereo
flags set.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_edid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 08d33b4..5475f31 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3047,7 +3047,7 @@ static u8 drm_match_hdmi_mode_clock_tolerance(const 
struct drm_display_mode *to_
abs(to_match->clock - clock2) > clock_tolerance)
continue;
 
-   if (drm_mode_equal_no_clocks(to_match, hdmi_mode))
+   if (drm_mode_equal_no_clocks_no_stereo(to_match, hdmi_mode))
return vic;
}
 
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 00/10] Aspect ratio support in DRM layer

[Nautiyal, Ankit K]

From: Ankit Nautiyal 

This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.

The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out of which 2 patches were reverted due to lack of drm client
protection while loading the aspect information.

This patch series also includes 5 patches from Ville Syrjälä's series for
'Info-frame cleanup and fixes':
https://patchwork.freedesktop.org/series/33730/ which fixes the mode
matching mechanism via flags, and also ensures that no bogus aspect-ratios
are sent in the AVI infoframes.

This patch series, adds a DRM client option for aspect ratio, and loads
aspect ratio flags, only when the client sets this cap. 

To test this patch, the testdiplay IGT test is modified to have an option
to do a modeset with only aspect ratio modes.
Also, there is a userspace implementation in Wayland/weston layer:
https://patchwork.freedesktop.org/patch/188125/
(Which is already ACK'ed by wayland community.)

This, helps us in passing HDMI compliance test cases like 7-27, where the
test equipment applies a CEA mode, and expects the exact VIC in the AVI
infoframes.

Ankit Nautiyal (3):
  drm: Add DRM client cap for aspect-ratio
  drm: Handle aspect ratio info in legacy modeset path
  drm: Expose modes with aspect ratio, only if requested

Sharma, Shashank (2):
  drm: Add aspect ratio parsing in DRM layer
  drm: Add and handle new aspect ratios in DRM layer

Ville Syrjälä (5):
  drm/modes: Introduce drm_mode_match()
  drm/edid: Use drm_mode_match_no_clocks_no_stereo() for consistentcy
  drm/edid: Fix cea mode aspect ratio handling
  drm/edid: Don't send bogus aspect ratios in AVI infoframes
  video/hdmi: Reject illegal picture aspect ratios

 drivers/gpu/drm/drm_connector.c |  44 --
 drivers/gpu/drm/drm_crtc.c  |   9 ++
 drivers/gpu/drm/drm_edid.c  |  41 ++---
 drivers/gpu/drm/drm_fb_helper.c |  12 ++-
 drivers/gpu/drm/drm_ioctl.c |   9 ++
 drivers/gpu/drm/drm_modes.c | 179 +---
 drivers/video/hdmi.c|   3 +
 include/drm/drm_file.h  |   8 ++
 include/drm/drm_modes.h |  22 +
 include/uapi/drm/drm.h  |   7 ++
 include/uapi/drm/drm_mode.h |   6 ++
 11 files changed, 290 insertions(+), 50 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v14 01/10] drm/modes: Introduce drm_mode_match()

[Nautiyal, Ankit K]

From: Ville Syrjälä 

Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.

Signed-off-by: Ville Syrjälä 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_modes.c | 134 ++--
 include/drm/drm_modes.h |   9 +++
 2 files changed, 112 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index e82b61e..c395a24 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -939,17 +939,68 @@ struct drm_display_mode *drm_mode_duplicate(struct 
drm_device *dev,
 }
 EXPORT_SYMBOL(drm_mode_duplicate);
 
+static bool drm_mode_match_timings(const struct drm_display_mode *mode1,
+  const struct drm_display_mode *mode2)
+{
+   return mode1->hdisplay == mode2->hdisplay &&
+   mode1->hsync_start == mode2->hsync_start &&
+   mode1->hsync_end == mode2->hsync_end &&
+   mode1->htotal == mode2->htotal &&
+   mode1->hskew == mode2->hskew &&
+   mode1->vdisplay == mode2->vdisplay &&
+   mode1->vsync_start == mode2->vsync_start &&
+   mode1->vsync_end == mode2->vsync_end &&
+   mode1->vtotal == mode2->vtotal &&
+   mode1->vscan == mode2->vscan;
+}
+
+static bool drm_mode_match_clock(const struct drm_display_mode *mode1,
+ const struct drm_display_mode *mode2)
+{
+   /*
+* do clock check convert to PICOS
+* so fb modes get matched the same
+*/
+   if (mode1->clock && mode2->clock)
+   return KHZ2PICOS(mode1->clock) == KHZ2PICOS(mode2->clock);
+   else
+   return mode1->clock == mode2->clock;
+}
+
+static bool drm_mode_match_flags(const struct drm_display_mode *mode1,
+const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & ~DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_3d_flags(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return (mode1->flags & DRM_MODE_FLAG_3D_MASK) ==
+   (mode2->flags & DRM_MODE_FLAG_3D_MASK);
+}
+
+static bool drm_mode_match_aspect_ratio(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2)
+{
+   return mode1->picture_aspect_ratio == mode2->picture_aspect_ratio;
+}
+
 /**
- * drm_mode_equal - test modes for equality
+ * drm_mode_match - test modes for (partial) equality
  * @mode1: first mode
  * @mode2: second mode
+ * @match_flags: which parts need to match (DRM_MODE_MATCH_*)
  *
  * Check to see if @mode1 and @mode2 are equivalent.
  *
  * Returns:
- * True if the modes are equal, false otherwise.
+ * True if the modes are (partially) equal, false otherwise.
  */
-bool drm_mode_equal(const struct drm_display_mode *mode1, const struct 
drm_display_mode *mode2)
+bool drm_mode_match(const struct drm_display_mode *mode1,
+   const struct drm_display_mode *mode2,
+   unsigned int match_flags)
 {
if (!mode1 && !mode2)
return true;
@@ -957,15 +1008,48 @@ bool drm_mode_equal(const struct drm_display_mode 
*mode1, const struct drm_displ
if (!mode1 || !mode2)
return false;
 
-   /* do clock check convert to PICOS so fb modes get matched
-* the same */
-   if (mode1->clock && mode2->clock) {
-   if (KHZ2PICOS(mode1->clock) != KHZ2PICOS(mode2->clock))
-   return false;
-   } else if (mode1->clock != mode2->clock)
+   if (match_flags & DRM_MODE_MATCH_TIMINGS &&
+   !drm_mode_match_timings(mode1, mode2))
return false;
 
-   return drm_mode_equal_no_clocks(mode1, mode2);
+   if (match_flags & DRM_MODE_MATCH_CLOCK &&
+   !drm_mode_match_clock(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_FLAGS &&
+   !drm_mode_match_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_3D_FLAGS &&
+   !drm_mode_match_3d_flags(mode1, mode2))
+   return false;
+
+   if (match_flags & DRM_MODE_MATCH_ASPECT_RATIO &&
+   !drm_mode_match_aspect_ratio(mode1, mode2))
+   return false;
+
+   return true;
+}
+EXPORT_SYMBOL(drm_mode_match);
+
+/**
+ * drm_mode_equal - test modes for equality
+ * @mode1: first mode
+ * @mode2: second mode
+ *
+ * Check to see if @mode1 and @mode2 are equivalent.
+ *
+ * Returns:
+ * True if the modes are equal, false otherwise.
+ */
+bool drm_mode_equal(const struct drm_display_mode *mode1,
+   const struct drm_display_mode 

Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

[Feng Tang]

On Mon, May 07, 2018 at 05:09:21PM +0200, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote:
> > Quoting Feng Tang (2018-05-07 22:26:34)
> > > Hi Chris,
> > > 
> > > Thanks for the prompt review!
> > > 
> > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote:
> > > > Quoting Feng Tang (2018-05-07 11:36:09)
> > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been bumped
> > > > > from 7 to 32, which may hurt the boot/init time for some platforms,
> > > > > as the 32 retries may take hundreds of ms.
> > > > 
> > > > If we need that many retries, so be it. No modparam, the driver just has
> > > > to work.
> > > 
> > > I understand your point. The retry numer was originally 7, and worked
> > > fine untill the Dell 4K monitor which changes to 32.  According to my 
> > > test,
> > > each retry will take about 8ms on the A3960 based NUC.
> > > 
> > > One of our product need to boot up within a given time limit, this
> > > 32 retries will take about 1/3 of the budget (about 270ms), that's
> > > why I would try to make it a parameter.
> > 
> > The essence is that probing whether a monitor is connected should not be
> > blocking boot. If an async probe tries and fails to find a monitor,
> > fine - no one will notice. If it does take 270ms to find a monitor, it
> > turns on 200ms after userspace kicks in, just like any other hotplug.
> 
> Yeah, the fix here is to get the probing out of the driver load path, not
> to break the driver for some funky monitors. And definitely not using a
> modparam.

Hi Chris and Daniel,

After reading the i915 modeset init code, I did some experiments:
1. make the intel_modeset_init() function async (here async means
   creating a async func wrapper and call async_schedul() for it)
2. make the intel_setup_outpus()+intel_modeset_setup_hw_state() async 

But both of them will trigger kernel panic (log msg pasted in the end),
did I made some mistakes, or maybe the i915 codes following these functions
has dependency over them?

IIUC the dpcd access first happens in
i915_driver_load --> i915_load_modeset_init --> intel_modeset_init
--> intel_setup_outputs --> intel_ddi_init --> intel_edp_init_connector
--> intel_edp_init_dpcd (to check if DPCD exist)

Should we postpone it to later phase or even after user space kick in?

Thanks,
Feng

---
Error msg for my async experiment:

[0.715706] No backend configured for hyper_dmabuf in kernel config
[0.716079] Hyper_dmabuf: no backend found
[0.736361] intel_powerclamp: CPU does not support MWAIT
[0.737643] [drm:wait_panel_status] *ERROR* PPS state mismatch
[0.741381] genirq: Setting trigger mode 3 for irq 127 failed 
(intel_gpio_irq_type+0x0/0x110)
[0.743244] dmi-sysfs: dmi entry is absent.
[0.765116] [edp_panel_vdd_on()]: exit
[0.765360] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[0.765809] IP:   (null)
[0.766005] PGD 0 P4D 0 
[0.766168] Oops: 0010 [#1] PREEMPT SMP
[0.766401] Modules linked in:
[0.766592] CPU: 0 PID: 28 Comm: kworker/u8:1 Tainted: G U  W   
4.14.39-sos+ #26
[0.767075] Workqueue: events_unbound async_run_entry_fn
[0.767392] task: 88027433c240 task.stack: 88027434
[0.767743] RIP: 0010:  (null)
[0.767969] RSP: :880274343ab8 EFLAGS: 00010246
[0.768281] RAX:  RBX: 2d4003ff RCX: 0001
[0.768701] RDX: 8000 RSI:  RDI: 880272f21100
[0.769121] RBP:  R08: 2d4003ff R09: 0001
[0.769541] R10: 880274343a60 R11: 82e7fe0d R12: 0001
[0.769961] R13: 880273038000 R14: 0004 R15: 880272f21100
[0.770383] FS:  () GS:88027dc0() 
knlGS:
[0.770858] CS:  0010 DS:  ES:  CR0: 80050033
[0.771199] CR2:  CR3: 02613000 CR4: 003426f0
[0.771619] Call Trace:
[0.771779]  ? intel_dp_aux_ch+0x1a7/0x770
[0.772031]  ? remove_wait_queue+0x60/0x60
[0.772281]  ? intel_dp_aux_transfer+0xa6/0x200
[0.772556]  ? drm_dp_dpcd_access+0x9d/0x150
[0.772815]  ? drm_dp_dpcd_read+0x2c/0x60
[0.773059]  ? drm_dp_read_desc+0x43/0xf0
[0.773303]  ? intel_dp_detect+0x346/0x6a0
[0.773554]  ? drm_helper_probe_single_connector_modes+0xcd/0x6b0
[0.773920]  ? _raw_spin_unlock+0x14/0x30
[0.774165]  ? vt_console_print+0x22a/0x3d0
[0.774420]  ? preempt_count_add+0x56/0xa0
[0.774669]  ? _raw_spin_lock_irqsave+0x32/0x40
[0.774944]  ? drm_setup_crtcs+0x143/0x9e0
[0.775195]  ? __drm_fb_helper_initial_config_and_unlock+0x3f/0x410
[0.775567]  ? mutex_lock+0x1c/0x40
[0.775783]  ? intel_fbdev_initial_config+0x14/0x30
[0.776076]  ? async_run_entry_fn+0x39/0x160
[0.776335]  ? process_one_work+0x14a/0x3c0
[0.776588]  ? worker_thread+0x4d/0x3e0
[

Re: [PATCH V2 4/5] backlight: qcom-wled: Add support for OVP interrupt handling

[Daniel Thompson]

On Thu, May 03, 2018 at 03:42:31PM +0530, Kiran Gunda wrote:
> WLED peripheral has over voltage protection(OVP) circuitry and the OVP
> fault is notified through an interrupt. Though this fault condition rising
> is due to an incorrect hardware configuration is mitigated in the hardware,
> it still needs to be detected and handled. Add support for it.

Why detect and handle it? The interrupt handler doesn't appear to do
anything other than clear the interrupt... and it appears that the 
interrupt can be masked.


> When WLED module is enabled, keep OVP fault interrupt disabled for 10 ms to
> account for soft start delay.
> 
> Signed-off-by: Kiran Gunda 
> ---
>  drivers/video/backlight/qcom-wled.c | 118 
> +++-
>  1 file changed, 116 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/video/backlight/qcom-wled.c 
> b/drivers/video/backlight/qcom-wled.c
> index 2cfba77..80ae084 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -23,14 +23,20 @@
>  
>  /* From DT binding */
>  #define WLED_DEFAULT_BRIGHTNESS  2048
> -
> +#define WLED_SOFT_START_DLY_US   1
>  #define WLED3_SINK_REG_BRIGHT_MAX0xFFF
>  
>  /* WLED3 Control registers */
>  #define WLED3_CTRL_REG_FAULT_STATUS  0x08
> +#define  WLED3_CTRL_REG_ILIM_FAULT_BIT   BIT(0)
> +#define  WLED3_CTRL_REG_OVP_FAULT_BITBIT(1)
> +#define  WLED4_CTRL_REG_SC_FAULT_BIT BIT(2)
> +
> +#define WLED3_CTRL_REG_INT_RT_STS0x10
>  
>  #define WLED3_CTRL_REG_MOD_EN0x46
>  #define  WLED3_CTRL_REG_MOD_EN_MASK  BIT(7)
> +#define  WLED3_CTRL_REG_MOD_EN_BIT   BIT(7)
>  
>  #define WLED3_CTRL_REG_FREQ  0x4c
>  #define  WLED3_CTRL_REG_FREQ_MASKGENMASK(3, 0)
> @@ -161,9 +167,12 @@ struct wled {
>   u32 short_count;
>   const int *version;
>   int short_irq;
> + int ovp_irq;
>   bool force_mod_disable;
> + bool ovp_irq_disabled;
>  
>   struct wled_config cfg;
> + struct delayed_work ovp_work;
>   int (*wled_set_brightness)(struct wled *wled, u16 brightness);
>   int (*wled_sync_toggle)(struct wled *wled);
>  };
> @@ -209,6 +218,32 @@ static int wled4_set_brightness(struct wled *wled, u16 
> brightness)
>   return 0;
>  }
>  
> +static void wled_ovp_work(struct work_struct *work)
> +{
> + u32 val;
> + int rc;
> +
> + struct wled *wled = container_of(work,
> +  struct wled, ovp_work.work);
> +
> + rc = regmap_read(wled->regmap, wled->ctrl_addr + WLED3_CTRL_REG_MOD_EN,
> +  );
> + if (rc < 0)
> + return;
> +
> + if (val & WLED3_CTRL_REG_MOD_EN_BIT) {
> + if (wled->ovp_irq > 0 && wled->ovp_irq_disabled) {
> + enable_irq(wled->ovp_irq);
> + wled->ovp_irq_disabled = false;
> + }
> + } else {
> + if (wled->ovp_irq > 0 && !wled->ovp_irq_disabled) {
> + disable_irq(wled->ovp_irq);
> + wled->ovp_irq_disabled = true;
> + }
> + }
> +}
> +
>  static int wled_module_enable(struct wled *wled, int val)
>  {
>   int rc;
> @@ -220,7 +255,12 @@ static int wled_module_enable(struct wled *wled, int val)
>   WLED3_CTRL_REG_MOD_EN,
>   WLED3_CTRL_REG_MOD_EN_MASK,
>   WLED3_CTRL_REG_MOD_EN_MASK);
> - return rc;
> + if (rc < 0)
> + return rc;
> +
> + schedule_delayed_work(>ovp_work, WLED_SOFT_START_DLY_US);
> +
> + return 0;
>  }
>  
>  static int wled3_sync_toggle(struct wled *wled)
> @@ -346,6 +386,36 @@ static irqreturn_t wled_short_irq_handler(int irq, void 
> *_wled)
>   return IRQ_HANDLED;
>  }
>  
> +static irqreturn_t wled_ovp_irq_handler(int irq, void *_wled)
> +{
> + struct wled *wled = _wled;
> + int rc;
> + u32 int_sts, fault_sts;
> +
> + rc = regmap_read(wled->regmap,
> +  wled->ctrl_addr + WLED3_CTRL_REG_INT_RT_STS, _sts);
> + if (rc < 0) {
> + dev_err(wled->dev, "Error in reading WLED3_INT_RT_STS rc=%d\n",
> + rc);
> + return IRQ_HANDLED;
> + }
> +
> + rc = regmap_read(wled->regmap, wled->ctrl_addr +
> +  WLED3_CTRL_REG_FAULT_STATUS, _sts);
> + if (rc < 0) {
> + dev_err(wled->dev, "Error in reading WLED_FAULT_STATUS rc=%d\n",
> + rc);
> + return IRQ_HANDLED;
> + }
> +
> + if (fault_sts &
> + (WLED3_CTRL_REG_OVP_FAULT_BIT | WLED3_CTRL_REG_ILIM_FAULT_BIT))
> + dev_dbg(wled->dev, "WLED OVP fault detected, int_sts=%x 
> fault_sts= %x\n",

Re: [PATCH V2 3/5] backlight: qcom-wled: Add support for short circuit handling

[Daniel Thompson]

On Thu, May 03, 2018 at 03:42:30PM +0530, Kiran Gunda wrote:
> Handle the short circuit interrupt and check if the short circuit
> interrupt is valid. Re-enable the module to check if it goes
> away. Disable the module altogether if the short circuit event
> persists.
> 
> Signed-off-by: Kiran Gunda 
> ---
>  drivers/video/backlight/qcom-wled.c | 134 
> ++--
>  1 file changed, 130 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/backlight/qcom-wled.c 
> b/drivers/video/backlight/qcom-wled.c
> index be8b8d3..2cfba77 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -10,6 +10,9 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -23,7 +26,9 @@
>  
>  #define WLED3_SINK_REG_BRIGHT_MAX0xFFF
>  
> -/* Control registers */
> +/* WLED3 Control registers */
> +#define WLED3_CTRL_REG_FAULT_STATUS  0x08
> +
>  #define WLED3_CTRL_REG_MOD_EN0x46
>  #define  WLED3_CTRL_REG_MOD_EN_MASK  BIT(7)
>  
> @@ -36,7 +41,17 @@
>  #define WLED3_CTRL_REG_ILIMIT0x4e
>  #define  WLED3_CTRL_REG_ILIMIT_MASK  GENMASK(2, 0)
>  
> -/* sink registers */
> +/* WLED4 control registers */
> +#define WLED4_CTRL_REG_SHORT_PROTECT 0x5e
> +#define  WLED4_CTRL_REG_SHORT_EN_MASKBIT(7)
> +
> +#define WLED4_CTRL_REG_SEC_ACCESS0xd0
> +#define  WLED4_CTRL_REG_SEC_UNLOCK   0xa5
> +
> +#define WLED4_CTRL_REG_TEST1 0xe2
> +#define  WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2 0x09
> +
> +/* WLED3 sink registers */
>  #define WLED3_SINK_REG_SYNC  0x47
>  #define  WLED3_SINK_REG_SYNC_MASKGENMASK(2, 0)
>  #define  WLED4_SINK_REG_SYNC_MASKGENMASK(3, 0)
> @@ -130,17 +145,23 @@ struct wled_config {
>   bool cs_out_en;
>   bool ext_gen;
>   bool cabc;
> + bool external_pfet;
>  };
>  
>  struct wled {
>   const char *name;
>   struct device *dev;
>   struct regmap *regmap;
> + struct mutex lock;  /* Lock to avoid race from ISR */
> + ktime_t last_short_event;
>   u16 ctrl_addr;
>   u16 sink_addr;
>   u32 brightness;
>   u32 max_brightness;
> + u32 short_count;
>   const int *version;
> + int short_irq;
> + bool force_mod_disable;
>  
>   struct wled_config cfg;
>   int (*wled_set_brightness)(struct wled *wled, u16 brightness);
> @@ -192,6 +213,9 @@ static int wled_module_enable(struct wled *wled, int val)
>  {
>   int rc;
>  
> + if (wled->force_mod_disable)
> + return 0;
> +
>   rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
>   WLED3_CTRL_REG_MOD_EN,
>   WLED3_CTRL_REG_MOD_EN_MASK,
> @@ -248,12 +272,13 @@ static int wled_update_status(struct backlight_device 
> *bl)
>   bl->props.state & BL_CORE_FBBLANK)
>   brightness = 0;
>  
> + mutex_lock(>lock);
>   if (brightness) {
>   rc = wled->wled_set_brightness(wled, brightness);
>   if (rc < 0) {
>   dev_err(wled->dev, "wled failed to set brightness 
> rc:%d\n",
>   rc);
> - return rc;
> + goto unlock_mutex;
>   }
>  
>   rc = wled->wled_sync_toggle(wled);
> @@ -267,15 +292,60 @@ static int wled_update_status(struct backlight_device 
> *bl)
>   rc = wled_module_enable(wled, !!brightness);
>   if (rc < 0) {
>   dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
> - return rc;
> + goto unlock_mutex;
>   }
>   }
>  
>   wled->brightness = brightness;
>  
> +unlock_mutex:
> + mutex_unlock(>lock);
> +
>   return rc;
>  }
>  
> +#define WLED_SHORT_DLY_MS20
> +#define WLED_SHORT_CNT_MAX   5
> +#define WLED_SHORT_RESET_CNT_DLY_US  HZ

So we think a short report every quarter second is harmless?


> +static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
> +{
> + struct wled *wled = _wled;
> + int rc;
> + s64 elapsed_time;
> +
> + wled->short_count++;
> + mutex_lock(>lock);
> + rc = wled_module_enable(wled, false);
> + if (rc < 0) {
> + dev_err(wled->dev, "wled disable failed rc:%d\n", rc);
> + goto unlock_mutex;
> + }
> +
> + elapsed_time = ktime_us_delta(ktime_get(),
> +   wled->last_short_event);
> + if (elapsed_time > WLED_SHORT_RESET_CNT_DLY_US)
> + wled->short_count = 0;
> +
> + if (wled->short_count > WLED_SHORT_CNT_MAX) 

Re: [PATCH v2 10/26] drm/bridge: panel: provide an owner .odev device

[Daniel Vetter]

On Tue, May 08, 2018 at 09:58:49AM +0200, Peter Rosin wrote:
> On 2018-05-08 08:51, Jyri Sarha wrote:
> > On 05/04/18 16:51, Peter Rosin wrote:
> >> It gets rid of an #ifdef and the .of_node member is going away.
> >>
> >> Signed-off-by: Peter Rosin 
> >> ---
> >>  drivers/gpu/drm/bridge/panel.c | 4 +---
> >>  1 file changed, 1 insertion(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/panel.c 
> >> b/drivers/gpu/drm/bridge/panel.c
> >> index 6d99d4a3beb3..f43d77b5ed20 100644
> >> --- a/drivers/gpu/drm/bridge/panel.c
> >> +++ b/drivers/gpu/drm/bridge/panel.c
> >> @@ -169,10 +169,8 @@ struct drm_bridge *drm_panel_bridge_add(struct 
> >> drm_panel *panel,
> >>panel_bridge->connector_type = connector_type;
> >>panel_bridge->panel = panel;
> >>  
> >> +  panel_bridge->bridge.odev = panel->dev;
> > 
> > I am afraid this approach will eventually conflict with my lately
> > accepted patch[1].
> 
> I don't see how? The links are refcounted. So, if there is one link
> each for the panel and bridge between the drm device and the panel
> device that link will simply get two references. If/when the panel
> device then goes away, the drm device will be brought down because
> of that link (with two references, but that is irrelevant). When
> the drm device is brought down, it will (presumably) bring down the
> bridge as well (which will fix the refcount as the bridge link is
> killed as part of that).
> 
> Or have you done some test and seen an actual problem?
> 
> > The panel already has a device pointer of its own, and technically the
> > bridge element created here is created by the master drm device itself.
> 
> Not always, some bridges also call drm_panel_bridge_add for connecting
> its output to either a panel or another bridge.
> 
> And by that line of argument, the devm_kzalloc in drm_panel_bridge_add
> attaches the bridge memory to the wrong device as well. Maybe that
> should be fixed? Seems orthogonal though, but it would introduce a
> natural struct device in that function to assign to .odev. I think
> the device owning the bridge memory should be the same as the .odev
> device of the bridge.

Drive-by comment: You can't allocate anything with devm_* functions that
represents a core drm struct attached to a drm_device. There's no struct
device anywhere that has the right lifetime (since the drm_device can
easily outlive any physical device).

Yes that makes roughly 100% of all armsoc drm drivers buggy :-/ But it
doesn't matter, since you can't really unplug those devices physically,
hence will only blow up if you force an unbind through sysfs, and then you
get to keep all the pieces. Ignorance is bliss meanwhile ...
-Daniel

> 
> > I suggest assigning odev here to NULL or to master drm device itself.
> 
> I'd rather not use NULL, since it is nice to be able to rely on the
> .odev being there, and WARN if it isn't.
> 
> Cheers,
> Peter
> 
> > Best regards,
> > Jyri
> > 
> >>panel_bridge->bridge.funcs = _bridge_bridge_funcs;
> >> -#ifdef CONFIG_OF
> >> -  panel_bridge->bridge.of_node = panel->dev->of_node;
> >> -#endif
> >>  
> >>drm_bridge_add(_bridge->bridge);
> >>  
> >>
> > 
> > [1] https://lists.freedesktop.org/archives/dri-devel/2018-April/174559.html
> > 
> 

-- 
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] dma-buf: Remove unused sync_dump()

[Chris Wilson]

Quoting Chris Wilson (2018-02-08 10:09:06)
> sync_dump() is an unused, unexported, function that adds 64k to the
> kernel image and doesn't even provide locking around the global array it
> uses.
> 
> add/remove: 0/2 grow/shrink: 0/0 up/down: 0/-65734 (-65734)
> Function old new   delta
> sync_dump198   --198
> sync_dump_buf  65536   -  -65536
> 
> Signed-off-by: Chris Wilson 
> Cc: Sumit Semwal 
> Cc: Gustavo Padovan 

I see the patch to remove the stubs was applied, but we still have this
64k unused buffer...
-Chris

> ---
>  drivers/dma-buf/sync_debug.c | 26 --
>  drivers/dma-buf/sync_debug.h |  2 --
>  2 files changed, 28 deletions(-)
> 
> diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
> index c4c8ecb24aa9..d1caa9f060a1 100644
> --- a/drivers/dma-buf/sync_debug.c
> +++ b/drivers/dma-buf/sync_debug.c
> @@ -207,29 +207,3 @@ static __init int sync_debugfs_init(void)
> return 0;
>  }
>  late_initcall(sync_debugfs_init);
> -
> -#define DUMP_CHUNK 256
> -static char sync_dump_buf[64 * 1024];
> -void sync_dump(void)
> -{
> -   struct seq_file s = {
> -   .buf = sync_dump_buf,
> -   .size = sizeof(sync_dump_buf) - 1,
> -   };
> -   int i;
> -
> -   sync_debugfs_show(, NULL);
> -
> -   for (i = 0; i < s.count; i += DUMP_CHUNK) {
> -   if ((s.count - i) > DUMP_CHUNK) {
> -   char c = s.buf[i + DUMP_CHUNK];
> -
> -   s.buf[i + DUMP_CHUNK] = 0;
> -   pr_cont("%s", s.buf + i);
> -   s.buf[i + DUMP_CHUNK] = c;
> -   } else {
> -   s.buf[s.count] = 0;
> -   pr_cont("%s", s.buf + i);
> -   }
> -   }
> -}
> diff --git a/drivers/dma-buf/sync_debug.h b/drivers/dma-buf/sync_debug.h
> index d615a89f774c..1fd4d9ab3c4a 100644
> --- a/drivers/dma-buf/sync_debug.h
> +++ b/drivers/dma-buf/sync_debug.h
> @@ -70,14 +70,12 @@ void sync_timeline_debug_add(struct sync_timeline *obj);
>  void sync_timeline_debug_remove(struct sync_timeline *obj);
>  void sync_file_debug_add(struct sync_file *fence);
>  void sync_file_debug_remove(struct sync_file *fence);
> -void sync_dump(void);
>  
>  #else
>  # define sync_timeline_debug_add(obj)
>  # define sync_timeline_debug_remove(obj)
>  # define sync_file_debug_add(fence)
>  # define sync_file_debug_remove(fence)
> -# define sync_dump()
>  #endif
>  
>  #endif /* _LINUX_SYNC_H */
> -- 
> 2.16.1
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 7/8] drm/vmwgfx: add SPDX idenitifier and clarify license

[Emil Velikov]

Hi Dirk,

On 7 May 2018 at 00:16, Dirk Hohndel (VMware)  wrote:
> These files are licensed under GPL-2.0.
> Removing the MIT boilerplate as that really didn't make any sense for
> those two header files.
>
> Signed-off-by: Dirk Hohndel (VMware) 
> ---
>  drivers/gpu/drm/vmwgfx/Kconfig|  1 +
>  .../vmwgfx/device_include/vmware_pack_begin.h | 25 +--
>  .../vmwgfx/device_include/vmware_pack_end.h   | 25 +--
>  3 files changed, 3 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/Kconfig b/drivers/gpu/drm/vmwgfx/Kconfig
> index 8c308dac99c5..6b28a326f8bb 100644
> --- a/drivers/gpu/drm/vmwgfx/Kconfig
> +++ b/drivers/gpu/drm/vmwgfx/Kconfig
> @@ -1,3 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
>  config DRM_VMWGFX
> tristate "DRM driver for VMware Virtual GPU"
> depends on DRM && PCI && X86 && MMU
> diff --git a/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_begin.h 
> b/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_begin.h
> index 7e7b0ce34aa2..75308bd0d970 100644
> --- a/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_begin.h
> +++ b/drivers/gpu/drm/vmwgfx/device_include/vmware_pack_begin.h
> @@ -1,25 +1,2 @@
> -/**
> - * Copyright 2015 VMware, Inc.  All rights reserved.
> - *
> - * Permission is hereby granted, free of charge, to any person
> - * obtaining a copy of this software and associated documentation
> - * files (the "Software"), to deal in the Software without
> - * restriction, including without limitation the rights to use, copy,
> - * modify, merge, publish, distribute, sublicense, and/or sell copies
> - * of the Software, and to permit persons to whom the Software is
> - * furnished to do so, subject to the following conditions:
> - *
> - * The above copyright notice and this permission notice shall be
> - * included in all copies or substantial portions of the Software.
> - *
> - * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> - * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> - * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> - * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> - * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> - * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> - * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> - * SOFTWARE.
> - *
> - **/
> +/* SPDX-License-Identifier: GPL-2.0 */


IIRC "LFC191: Compliance Basics for Developers" was pretty clear that
the copyright line should stay.
If so, vmware_pack_end.h should also have it's copyright line reinstated.

Mildly related:
This patch adds the one-line license identifier and removes the bulky
license text.
While a later patch, does the former and not the latter. Any reason
why they're not consistent?

HTH
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199025

--- Comment #28 from Paul van Maaren (ker...@vanmaaren.org) ---
I will change the runlevel to text and see if it resolves the problem. I assume
I can test by typing: "echo mem > /sys/power/state" ?

-- 
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 2/3] drm/xen-front: fix xen_drm_front_shbuf_alloc() error handling

[Oleksandr Andrushchenko]

On 05/08/2018 12:27 PM, Dan Carpenter wrote:

The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly.  I've
changed it to always return error pointer consistently.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c 
b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
index d5705251a0d6..8099cb343ae3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
@@ -383,7 +383,7 @@ xen_drm_front_shbuf_alloc(struct xen_drm_front_shbuf_cfg 
*cfg)
  
  	buf = kzalloc(sizeof(*buf), GFP_KERNEL);

if (!buf)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
  
  	if (cfg->be_alloc)

buf->ops = _ops;
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 8615e8522c7a..378cb7ce0db5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -188,8 +188,8 @@ int xen_drm_front_dbuf_create(struct xen_drm_front_info 
*front_info,
buf_cfg.be_alloc = front_info->cfg.be_alloc;
  
  	shbuf = xen_drm_front_shbuf_alloc(_cfg);

-   if (!shbuf)
-   return -ENOMEM;
+   if (IS_ERR(shbuf))
+   return PTR_ERR(shbuf);
  
  	ret = dbuf_add_to_list(front_info, shbuf, dbuf_cookie);

if (ret < 0) {
___
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 3/3] drm/xen-front: Fix loop timeout

[Oleksandr Andrushchenko]

On 05/08/2018 12:28 PM, Dan Carpenter wrote:

If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 378cb7ce0db5..3345ac71b391 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -778,7 +778,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
 */
while ((xenbus_read_unsigned(front_info->xb_dev->otherend, "state",
 XenbusStateUnknown) != XenbusStateInitWait) 
&&
-to--)
+--to)
msleep(10);
  
  	if (!to) {

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/exynos/dsi: mask frame-done interrupt

[Andrzej Hajda]

DSI driver is not really interested in this interrupt. It causes only
unnecessary code execution of interrupt handler and could possibly
cause FIFO overflow - as it triggers DSI interrupt handler to process
next DSI transfer. With this patch we will get rid of about 30 IRQ
handler calls per second.

Fixes: e6f988a45857 ("drm/exynos: dsi: add support for Exynos5433")
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index eae44fd714f0..7c3030b7e586 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -1264,15 +1264,15 @@ static irqreturn_t exynos_dsi_irq(int irq, void *dev_id)
 
if (status & DSIM_INT_SW_RST_RELEASE) {
u32 mask = ~(DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
-   DSIM_INT_SFR_HDR_FIFO_EMPTY | DSIM_INT_FRAME_DONE |
-   DSIM_INT_RX_ECC_ERR | DSIM_INT_SW_RST_RELEASE);
+   DSIM_INT_SFR_HDR_FIFO_EMPTY | DSIM_INT_RX_ECC_ERR |
+   DSIM_INT_SW_RST_RELEASE);
exynos_dsi_write(dsi, DSIM_INTMSK_REG, mask);
complete(>completed);
return IRQ_HANDLED;
}
 
if (!(status & (DSIM_INT_RX_DONE | DSIM_INT_SFR_FIFO_EMPTY |
-   DSIM_INT_FRAME_DONE | DSIM_INT_PLL_STABLE)))
+   DSIM_INT_PLL_STABLE)))
return IRQ_HANDLED;
 
if (exynos_dsi_transfer_finish(dsi))
-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/xen-front: checking for NULL instead of IS_ERR

[Oleksandr Andrushchenko]

On 05/08/2018 12:26 PM, Dan Carpenter wrote:

drm_dev_alloc() returns error pointers, it never returns NULL.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

Thank you,
Reviewed-by: Oleksandr Andrushchenko 


diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1b0ea9ac330e..8615e8522c7a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -543,8 +543,8 @@ static int xen_drm_drv_init(struct xen_drm_front_info 
*front_info)
front_info->drm_info = drm_info;
  
  	drm_dev = drm_dev_alloc(_drm_driver, dev);

-   if (!drm_dev) {
-   ret = -ENOMEM;
+   if (IS_ERR(drm_dev)) {
+   ret = PTR_ERR(drm_dev);
goto fail;
}
  
___

dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm/xen-front: Fix loop timeout

[Dan Carpenter]

If the loop times out then we want to exit with "to" set to zero, but in
the current code it's set to -1.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 378cb7ce0db5..3345ac71b391 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -778,7 +778,7 @@ static int xen_drv_remove(struct xenbus_device *dev)
 */
while ((xenbus_read_unsigned(front_info->xb_dev->otherend, "state",
 XenbusStateUnknown) != 
XenbusStateInitWait) &&
-to--)
+--to)
msleep(10);
 
if (!to) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm/xen-front: fix xen_drm_front_shbuf_alloc() error handling

[Dan Carpenter]

The xen_drm_front_shbuf_alloc() function was returning a mix of error
pointers and NULL and the the caller wasn't checking correctly.  I've
changed it to always return error pointer consistently.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c 
b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
index d5705251a0d6..8099cb343ae3 100644
--- a/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
+++ b/drivers/gpu/drm/xen/xen_drm_front_shbuf.c
@@ -383,7 +383,7 @@ xen_drm_front_shbuf_alloc(struct xen_drm_front_shbuf_cfg 
*cfg)
 
buf = kzalloc(sizeof(*buf), GFP_KERNEL);
if (!buf)
-   return NULL;
+   return ERR_PTR(-ENOMEM);
 
if (cfg->be_alloc)
buf->ops = _ops;
diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 8615e8522c7a..378cb7ce0db5 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -188,8 +188,8 @@ int xen_drm_front_dbuf_create(struct xen_drm_front_info 
*front_info,
buf_cfg.be_alloc = front_info->cfg.be_alloc;
 
shbuf = xen_drm_front_shbuf_alloc(_cfg);
-   if (!shbuf)
-   return -ENOMEM;
+   if (IS_ERR(shbuf))
+   return PTR_ERR(shbuf);
 
ret = dbuf_add_to_list(front_info, shbuf, dbuf_cookie);
if (ret < 0) {
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm/xen-front: checking for NULL instead of IS_ERR

[Dan Carpenter]

drm_dev_alloc() returns error pointers, it never returns NULL.

Fixes: c575b7eeb89f ("drm/xen-front: Add support for Xen PV display frontend")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/xen/xen_drm_front.c 
b/drivers/gpu/drm/xen/xen_drm_front.c
index 1b0ea9ac330e..8615e8522c7a 100644
--- a/drivers/gpu/drm/xen/xen_drm_front.c
+++ b/drivers/gpu/drm/xen/xen_drm_front.c
@@ -543,8 +543,8 @@ static int xen_drm_drv_init(struct xen_drm_front_info 
*front_info)
front_info->drm_info = drm_info;
 
drm_dev = drm_dev_alloc(_drm_driver, dev);
-   if (!drm_dev) {
-   ret = -ENOMEM;
+   if (IS_ERR(drm_dev)) {
+   ret = PTR_ERR(drm_dev);
goto fail;
}
 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199653] [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199653

--- Comment #3 from Marcus Husar (marcus.hu...@gmail.com) ---
Created attachment 275833
  --> https://bugzilla.kernel.org/attachment.cgi?id=275833=edit
Call trace of i2c designware warning (taints kernel)

-- 
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 199653] [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199653

--- Comment #2 from Marcus Husar (marcus.hu...@gmail.com) ---
Created attachment 275831
  --> https://bugzilla.kernel.org/attachment.cgi?id=275831=edit
Journal log with amdgpu.dc_log=1 drm.debug=6

-- 
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 199653] [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199653

--- Comment #1 from Marcus Husar (marcus.hu...@gmail.com) ---
Created attachment 275829
  --> https://bugzilla.kernel.org/attachment.cgi?id=275829=edit
Original call trace of crash

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199653] New: [AMDGPU][DC] BUG: unable to handle kernel NULL pointer dereference (trace decoded)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199653

Bug ID: 199653
   Summary: [AMDGPU][DC] BUG: unable to handle kernel NULL pointer
dereference (trace decoded)
   Product: Drivers
   Version: 2.5
Kernel Version: drm-next-4.18-wip (agd5f, AMDGPU)
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: marcus.hu...@gmail.com
Regression: No

Created attachment 275827
  --> https://bugzilla.kernel.org/attachment.cgi?id=275827=edit
Call trace of crash decoded with decode_stacktrace.sh

kernel: BUG: unable to handle kernel NULL pointer dereference at
02e4

This happens multiple times a day on my machine. It leads to a complete system
freeze. Yesterday I was lucky and got a stack trace.

It mostly happens browsing the web with Firefox (WebRender enabled, XWayland,
Gnome-Shell) when the cursor moves or rotates. But it can happen anywhere and
anytime.

The used kernel is from branch drm-next-4.18-wip@92fb374 of Alex Deucher, AMD
(agd5f). See: git://people.freedesktop.org/~agd5f/linux.

My machine:
 * Hardware name: Acer Swift SF315-41/Becks_RR, BIOS V1.04 01/09/2018
 * Ryzen Mobile 2500U
 * Firmware: VCN: 1.73 (latest available version)
 * My kernel is tainted because the i2c designware driver emits a warning
during
   boot. This should be unrelated to AMDGPU
   (see attachment i2c_designware_trace.txt).

Please ask if anything else is needed.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 26/26] drm/bridge: establish a link between the bridge supplier and consumer

[Andrzej Hajda]

On 07.05.2018 15:43, Peter Rosin wrote:
> On 2018-05-07 14:59, Andrzej Hajda wrote:
>> On 04.05.2018 15:52, Peter Rosin wrote:
>>> If the bridge supplier is unbound, this will bring the bridge consumer
>>> down along with the bridge. Thus, there will no longer linger any
>>> dangling pointers from the bridge consumer (the drm_device) to some
>>> non-existent bridge supplier.
>> I understand rationales behind this patch, but it is another step into
>> making drm_dev one big driver with subcomponents, where drm will work
>> only if every subcomponent is working/loaded.
> The step is very small IMHO. Just a device-link, which is very easy to
> remove once whatever other solution is ready.
>
>>   Do we need to go this way?
> If the drivers expect the parts to be there, and there is no other safety
> net in place if they are not, what is the (short-term) alternative?
>
>> In case of many platforms such approach results in display turned on
>> very late on boot for example due to late initialization of some
>> regulator exposed by some i2c device, which is used by hdmi bridge. And
>> this hdmi bridge is just to provide alternative(rarely used) display
>> path, the main display path would work anyway.
> This patch does not contribute to any late init and any such delay is not
> affected by this. At all.
>
>> So the main question to drm maintainers is about evolution of bridges,
>> if drm_bridges should become mandatory components of drm device or they
>> could be added/removed dynamically?
> That is a much bigger question than this patch/series. Conflating the
> two is not fair IMHO. You could run this very same argument for every
> driver that gets added, since any additional driver will just make it
> harder to make everything dynamic. Should we stop development right
> away?
>
> Besides, as long as the drm devices are in fact acting as big static
> drivers (built from smaller parts), 

not true

> this should be considered a bug-fix
> that will prevent dereference of stale pointers.
>
> Or will some other solution appear and magically make all bridges and
> drm drivers capable of dynamic reconfiguration in the next few weeks?
> Yeah, right...

You are not changing single driver, you are changing framework and it
affects all the drivers using it, being more cautious about such patches
seems quite natural.

Anyway, I have realized that since drm_bridge_detach will remove the
link, so with properly written dynamic bridge removal, your patch should
not be a blocker.

Regards
Andrzej

>
> Cheers,
> Peter
>
>> Regards
>> Andrzej
>>
>>
>>> Signed-off-by: Peter Rosin 
>>> ---
>>>  drivers/gpu/drm/drm_bridge.c | 18 ++
>>>  include/drm/drm_bridge.h |  2 ++
>>>  2 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
>>> index 78d186b6831b..0259f0a3ff27 100644
>>> --- a/drivers/gpu/drm/drm_bridge.c
>>> +++ b/drivers/gpu/drm/drm_bridge.c
>>> @@ -26,6 +26,7 @@
>>>  #include 
>>>  
>>>  #include 
>>> +#include 
>>>  #include 
>>>  
>>>  #include "drm_crtc_internal.h"
>>> @@ -127,12 +128,25 @@ int drm_bridge_attach(struct drm_encoder *encoder, 
>>> struct drm_bridge *bridge,
>>> if (bridge->dev)
>>> return -EBUSY;
>>>  
>>> +   if (encoder->dev->dev != bridge->odev) {
>>> +   bridge->link = device_link_add(encoder->dev->dev,
>>> +  bridge->odev, 0);
>>> +   if (!bridge->link) {
>>> +   dev_err(bridge->odev, "failed to link bridge to %s\n",
>>> +   dev_name(encoder->dev->dev));
>>> +   return -EINVAL;
>>> +   }
>>> +   }
>>> +
>>> bridge->dev = encoder->dev;
>>> bridge->encoder = encoder;
>>>  
>>> if (bridge->funcs->attach) {
>>> ret = bridge->funcs->attach(bridge);
>>> if (ret < 0) {
>>> +   if (bridge->link)
>>> +   device_link_del(bridge->link);
>>> +   bridge->link = NULL;
>>> bridge->dev = NULL;
>>> bridge->encoder = NULL;
>>> return ret;
>>> @@ -159,6 +173,10 @@ void drm_bridge_detach(struct drm_bridge *bridge)
>>> if (bridge->funcs->detach)
>>> bridge->funcs->detach(bridge);
>>>  
>>> +   if (bridge->link)
>>> +   device_link_del(bridge->link);
>>> +   bridge->link = NULL;
>>> +
>>> bridge->dev = NULL;
>>>  }
>>>  
>>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>>> index b656e505d11e..804189c63a4c 100644
>>> --- a/include/drm/drm_bridge.h
>>> +++ b/include/drm/drm_bridge.h
>>> @@ -261,6 +261,7 @@ struct drm_bridge_timings {
>>>   * @list: to keep track of all added bridges
>>>   * @timings: the timing specification for the bridge, if any (may
>>>   * be NULL)
>>> + * @link: drm consumer <-> bridge supplier
>>>   * @funcs: control functions
>>>   * 

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[Daniel Thompson]

On Thu, May 03, 2018 at 03:42:28PM +0530, Kiran Gunda wrote:
> pm8941-wled.c driver is supporting the WLED peripheral
> on pm8941. Rename it to qcom-wled.c so that it can support
> WLED on multiple PMICs.
> 
> Signed-off-by: Kiran Gunda 
> ---
>  .../bindings/leds/backlight/{pm8941-wled.txt => qcom-wled.txt}| 2 +-
>  drivers/video/backlight/Kconfig   | 8 
> 
>  drivers/video/backlight/Makefile  | 2 +-
>  drivers/video/backlight/{pm8941-wled.c => qcom-wled.c}| 0

For me this hovers extremely close to being a gratuitous renaming
especially with no effort to bridge the gap between old and new names.

On the other hand, no current defconfig enables BACKLIGHT_PM8941_WLED,
it is configured by DT (so modules.conf tricks are unlikely) and any distros
that already have it enables are likely to be aggressive in enabling
drivers (so will probably turn on BACKLIGHT_QCOM_WLED as soon as it
appears).

On that basis I can live with this... but will also listen for any
complaints!


Daniel.

>  4 files changed, 6 insertions(+), 6 deletions(-)
>  rename Documentation/devicetree/bindings/leds/backlight/{pm8941-wled.txt => 
> qcom-wled.txt} (95%)
>  rename drivers/video/backlight/{pm8941-wled.c => qcom-wled.c} (100%)
> 
> diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt 
> b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> similarity index 95%
> rename from Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> rename to Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> index e5b294d..fb39e32 100644
> --- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
> +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> @@ -1,4 +1,4 @@
> -Binding for Qualcomm PM8941 WLED driver
> +Binding for Qualcomm Technologies, Inc. WLED driver
>  
>  Required properties:
>  - compatible: should be "qcom,pm8941-wled"
> diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
> index 4e1d2ad..8c095e3 100644
> --- a/drivers/video/backlight/Kconfig
> +++ b/drivers/video/backlight/Kconfig
> @@ -299,12 +299,12 @@ config BACKLIGHT_TOSA
> If you have an Sharp SL-6000 Zaurus say Y to enable a driver
> for its backlight
>  
> -config BACKLIGHT_PM8941_WLED
> - tristate "Qualcomm PM8941 WLED Driver"
> +config BACKLIGHT_QCOM_WLED
> + tristate "Qualcomm PMIC WLED Driver"
>   select REGMAP
>   help
> -   If you have the Qualcomm PM8941, say Y to enable a driver for the
> -   WLED block.
> +   If you have the Qualcomm PMIC, say Y to enable a driver for the
> +   WLED block. Currently it supports PM8941 and PMI8998.
>  
>  config BACKLIGHT_SAHARA
>   tristate "Tabletkiosk Sahara Touch-iT Backlight Driver"
> diff --git a/drivers/video/backlight/Makefile 
> b/drivers/video/backlight/Makefile
> index 5e28f01..6fd76ef 100644
> --- a/drivers/video/backlight/Makefile
> +++ b/drivers/video/backlight/Makefile
> @@ -49,8 +49,8 @@ obj-$(CONFIG_BACKLIGHT_OMAP1)   += omap1_bl.o
>  obj-$(CONFIG_BACKLIGHT_OT200)+= ot200_bl.o
>  obj-$(CONFIG_BACKLIGHT_PANDORA)  += pandora_bl.o
>  obj-$(CONFIG_BACKLIGHT_PCF50633) += pcf50633-backlight.o
> -obj-$(CONFIG_BACKLIGHT_PM8941_WLED)  += pm8941-wled.o
>  obj-$(CONFIG_BACKLIGHT_PWM)  += pwm_bl.o
> +obj-$(CONFIG_BACKLIGHT_QCOM_WLED)+= qcom-wled.o
>  obj-$(CONFIG_BACKLIGHT_SAHARA)   += kb3886_bl.o
>  obj-$(CONFIG_BACKLIGHT_SKY81452) += sky81452-backlight.o
>  obj-$(CONFIG_BACKLIGHT_TOSA) += tosa_bl.o
> diff --git a/drivers/video/backlight/pm8941-wled.c 
> b/drivers/video/backlight/qcom-wled.c
> similarity index 100%
> rename from drivers/video/backlight/pm8941-wled.c
> rename to drivers/video/backlight/qcom-wled.c
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>  a Linux Foundation Collaborative Project
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2 1/5] backlight: qcom-wled: Rename pm8941-wled.c to qcom-wled.c

[Daniel Thompson]

On Mon, May 07, 2018 at 11:26:59AM +0530, kgu...@codeaurora.org wrote:
> Hi Jingoo Han,
> Thanks for the response.
> 
> Thanks,
> Kiran
> On 2018-05-04 21:25, Jingoo Han wrote:
> > On Thursday, May 3, 2018 6:12 AM, Kiran Gunda wrote:
> > 
> > If you really want someone to review your patch, please add more
> > detailed
> > explanations.
> > 
> > 1. Please add 0th patch.
> I have already added the 0th patch (cover letter). Following is the subject
> for the same.
> forwarding the same to you.
> [PATCH V2 0/5] backlight: qcom-wled: Support for QCOM wled driver

Perhaps you should interpret Jingoo's comment as a request to improve
the To: and Cc: list on the 0th patch the next time you circulate it.

Many maintainers configure their mailers to give patches where they are
in the To: or Cc: list special treatment so it confusing when a series
arrives with a spartan set of recipients for the 0th patch (and doubly
confusing when every patch in the set targets the same driver).


Daniel.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 199025] Suspend hangs. Never fully suspends and impossible to return to running state.

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=199025

--- Comment #27 from todd (todd...@gmail.com) ---
@Chen

After seeing a few responses from people I'm starting to see that this is
definitely not a video driver specific issue. Not everybody is using Nouveau. I
suspected it wasn't from the start because the default generic video driver for
Nvidia (Nouveau) has not changed from the start of fedora 27 to the end of
fedora 27, and the problem didn't start until an update somewhere in the
middle.

So Nouveau was never updated, yet the problem started with a newer kernel. But
that could be a coincidence. So I just checked the update history on this
machine and found that on 2018-02-17 there was a kernel update to 4.15.3 and
there was also another important update that day which could very well be the
problem.

xorg-x11-server-Xorg
and 
xorg-x11-server-common

I had been out of town for a while and thus missed all updates from 4.14.16 to
4.15.3 So any packages between then I don't have a listing for.

With that in mind I remember that the problem does not exist if you restart X
or if you boot into text mode and then manually startX. Plus because Paul just
stated that he is using KDE than I guess that pretty much eliminates the
desktop environment because I use Xfce.

So I think you're right. We need to report this over at freedesktop bugzilla as
well. 

Great, more work :(
I already started a post at bugzilla fedora, they said its likely kernel
related so my post was closed with a note to post at bugzilla kernel. Now I
gotta start a 3rd one. 
If I had lots of time I wouldn't mind. Perhaps we can con you into starting one
over there. If you do, please post link to it. Otherwise When I get more time I
will.

-- 
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: [Intel-gfx] [PATCH v9 1/2] drm: content-type property for HDMI connector

[Daniel Vetter]

On Tue, May 08, 2018 at 07:18:20AM +, Lisovskiy, Stanislav wrote:
> On Mon, 2018-05-07 at 16:05 +0200, Daniel Vetter wrote:
> > On Mon, May 07, 2018 at 04:16:40PM +0300, StanLis wrote:
> > > From: Stanislav Lisovskiy 
> > > 
> > > Added content_type property to drm_connector_state
> > > in order to properly handle external HDMI TV content-type setting.
> > > 
> > > v2:
> > >  * Moved helper function which attaches content type property
> > >to the drm core, as was suggested.
> > >Removed redundant connector state initialization.
> > > 
> > > v3:
> > >  * Removed caps in drm_content_type_enum_list.
> > >After some discussion it turned out that HDMI Spec 1.4
> > >was wrongly assuming that IT Content(itc) bit doesn't affect
> > >Content type states, however itc bit needs to be manupulated
> > >as well. In order to not expose additional property for itc,
> > >for sake of simplicity it was decided to bind those together
> > >in same "content type" property.
> > > 
> > > v4:
> > >  * Added it_content checking in
> > > intel_digital_connector_atomic_check.
> > >Fixed documentation for new content type enum.
> > > 
> > > v5:
> > >  * Moved patch revision's description to commit messages.
> > > 
> > > v6:
> > >  * Minor naming fix for the content type enumeration string.
> > > 
> > > v7:
> > >  * Fix parameter name for documentation and parameter alignment
> > >in order not to get warning. Added Content Type description to
> > >new HDMI connector properties section.
> > > 
> > > v8:
> > >  * Thrown away unneeded numbers from HDMI content-type property
> > >description. Switch to strings desription instead of plain
> > >definitions.
> > > 
> > > v9:
> > >  * Moved away hdmi specific content-type enum from
> > >drm_connector_state. Content type property should probably not
> > >be bound to any specific connector interface in
> > >drm_connector_state.
> > >Same probably should be done to hdmi_picture_aspect_ration enum
> > >which is also contained in drm_connector_state. Added special
> > >helper function to get derive hdmi specific relevant infoframe
> > >fields.
> > > 
> > > Signed-off-by: Stanislav Lisovskiy 
> > > ---
> > >  Documentation/gpu/drm-kms.rst|  6 +++
> > >  Documentation/gpu/kms-properties.csv |  1 +
> > >  drivers/gpu/drm/drm_atomic.c |  4 ++
> > >  drivers/gpu/drm/drm_connector.c  | 74
> > > 
> > >  drivers/gpu/drm/drm_edid.c   | 55 +
> > >  include/drm/drm_connector.h  | 12 +
> > >  include/drm/drm_edid.h   |  6 +++
> > >  include/drm/drm_mode_config.h|  5 ++
> > >  include/uapi/drm/drm_mode.h  |  7 +++
> > >  9 files changed, 170 insertions(+)
> > > 
> > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> > > kms.rst
> > > index 1dffd1ac4cd4..e233c2626bd0 100644
> > > --- a/Documentation/gpu/drm-kms.rst
> > > +++ b/Documentation/gpu/drm-kms.rst
> > > @@ -517,6 +517,12 @@ Standard Connector Properties
> > >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > > :doc: standard connector properties
> > >  
> > > +HDMI Specific Connector Properties
> > > +-
> > > +
> > > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > > +   :doc: HDMI connector properties
> > > +
> > >  Plane Composition Properties
> > >  
> > >  
> > > diff --git a/Documentation/gpu/kms-properties.csv
> > > b/Documentation/gpu/kms-properties.csv
> > > index 07ed22ea3bd6..bfde04eddd14 100644
> > > --- a/Documentation/gpu/kms-properties.csv
> > > +++ b/Documentation/gpu/kms-properties.csv
> > > @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property
> > > Name,Type,Property Values,Object attached,De
> > >  ,Virtual GPU,“suggested X”,RANGE,"Min=0,
> > > Max=0x",Connector,property to suggest an X offset for a
> > > connector
> > >  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property
> > > to suggest an Y offset for a connector
> > >  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> > > }",Connector,TDB
> > > +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"",
> > > ""Photo"", ""Cinema"", ""Game"" }",Connector,TBD
> > >  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"",
> > > ""Limited 16:235"" }",Connector,"When this property is set to
> > > Limited 16:235 and CTM is set, the hardware will be programmed with
> > > the result of the multiplication of CTM by the limited range matrix
> > > to ensure the pixels normaly in the range 0..1.0 are remapped to
> > > the range 16/255..235/255."
> > >  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on""
> > > }",Connector,TBD
> > >  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"",
> > > ""PAL_B"" } etc.",Connector,TBD
> > > diff --git a/drivers/gpu/drm/drm_atomic.c
> > > 

Re: [PATCH v2] drm: Allow CAP_DUMB_BUFFERS on !MODESET

[Daniel Vetter]

On Tue, May 08, 2018 at 01:52:01AM -0300, Ezequiel Garcia wrote:
> It's perfectly possible to get dumb buffers out of drivers
> that don't support modeset. This is the case of vgem,
> which can be used to export dmabuf to run various tests.
> 
> Inspired by commit f3f4c4d68a28 ("drm: Allow CAP_PRIME on !MODESET").

Prime makes sense, because render-only drivers _really_ want to be able to
share buffers.

But dumb buffers are really meant for dumb userspace running on kms
drivers only, there's no need ever to tell userspace that dumb buffers are
supported on non-kms drivers. It's kinda abuse of ioctls, but oh well,
uapi is fixed forever. And you can still call the ioctls if you know
they're there (which is always the case for the render-side of drm,
there's no generic alloc ioctl for those).
-Daniel

> Fixes: d5264ed3823a ("drm: Return -ENOTSUPP when called for KMS cap with a 
> non-KMS driver")
> Signed-off-by: Ezequiel Garcia 
> ---
> Changes from v1:
>  * Drop the bitwise-OR assignment op
> 
>  drivers/gpu/drm/drm_ioctl.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index af782911c505..a5b879ce8f2c 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -244,6 +244,9 @@ static int drm_getcap(struct drm_device *dev, void *data, 
> struct drm_file *file_
>   case DRM_CAP_SYNCOBJ:
>   req->value = drm_core_check_feature(dev, DRIVER_SYNCOBJ);
>   return 0;
> + case DRM_CAP_DUMB_BUFFER:
> + req->value = dev->driver->dumb_create ? 1 : 0;
> + return 0;
>   }
>  
>   /* Other caps only work with KMS drivers */
> @@ -251,10 +254,6 @@ static int drm_getcap(struct drm_device *dev, void 
> *data, struct drm_file *file_
>   return -ENOTSUPP;
>  
>   switch (req->capability) {
> - case DRM_CAP_DUMB_BUFFER:
> - if (dev->driver->dumb_create)
> - req->value = 1;
> - break;
>   case DRM_CAP_VBLANK_HIGH_CRTC:
>   req->value = 1;
>   break;
> -- 
> 2.16.3
> 
> ___
> 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/3] drm/sti: do not remove the drm_bridge that was never added

[Daniel Vetter]

On Mon, May 07, 2018 at 04:24:43PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:59, Peter Rosin wrote:
> > On 2018-05-07 15:39, Daniel Vetter wrote:
> >> On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >>> On 2018-05-03 11:06, Daniel Vetter wrote:
>  On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
> > The more natural approach would perhaps be to add an drm_bridge_add,
> > but there are several other bridges that never call drm_bridge_add.
> > Just removing the drm_bridge_remove is the easier fix.
> >
> > Signed-off-by: Peter Rosin 
> 
>  This mess is much bigger. There's 2 pairs of bridge functions:
> 
>  - drm_bridge_attach/detach. Those are meant to be called by the overall
>    drm driver to connect/disconnect a drm_bridge.
> 
>  - drm_bridge_add/remove. These are supposed to be called by the bridge
>    driver itself to register/unregister itself. Maybe we should rename
>    them, since the same issue happens with drm_panel, with the same
>    confusion.
> 
>  I thought someone was working on a cleanup series to fix this mess, but I
>  didn't find anything.
> >>>
> >>> Ok, I just spotted the imbalance and didn't really dig into what
> >>> actually happens in these error paths. Now that I have done so I
> >>> believe that the removed drm_bridge_remove calls causes NULL
> >>> dereferences if/when the error paths are triggered.
> >>>
> >>> So, I don't think this can wait for some bigger cleanup.
> >>>
> >>> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> >>> __list_del with NULL in both prev and next since the list member
> >>> is never initialized. prev and next are dereferenced by __list_del
> >>> and you have *boom*
> >>>
> >>> I recommend adding the tag
> >>>
> >>> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> >>>
> >>> so that stable picks this one up.
> >>
> >> I just wanted to correct your commit message text - the correct solution
> >> is definitely _not_ for sti here to call drm_bridge_add.
> > 
> > Ah, I see what you mean. Do you want me to respin?
> 
> Hold on, no I don't agree. sti_hda.c does create a bridge for it's own
> internal use. It does not drm_bridge_add it, because all that ever does
> is adding the bridge to the global lost of bridges. But since this is
> a bridge for internal use, there is little point in calling drm_bridge_add,
> the driver currently gains nothing by doing so.
> 
> But, drm_bridge_add might be a good place to put common stuff for every
> bridge in the system, so it might be worthwhile to start requiring all
> bridges to be drm_bridge_add-ed. And IMHO, it would not be wrong to have
> the sti-hda driver call drm_bridge_add on the bridge it creates.
> 
> Do you really think it is actively wrong to call drm_bridge_add for
> internal bridges such as this?

If we want to share bridge init code, then I think we need a
drm_bridge_init(). Not overload drm_bridge_add (which really should be
drm_bridge_register I think, but oh well, it's at least consistent with
drm_panel_add).
-Daniel

> 
> Cheers,
> Peter
> ___
> 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

[PATCH v10 2/2] i915: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.

This requires also manipulationg ITC bit, as stated in
HDMI spec.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

v10:
 * Added usage description to HDMI properties kernel doc.

Acked-by: Hans Verkuil 
Acked-by: Daniel Vetter 
Signed-off-by: Stanislav Lisovskiy 
---
 drivers/gpu/drm/i915/intel_atomic.c |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c   | 24 ++--
 2 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 40285d1b91b7..61ddb5871d8a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -124,6 +124,7 @@ int intel_digital_connector_atomic_check(struct 
drm_connector *conn,
if (new_conn_state->force_audio != old_conn_state->force_audio ||
new_conn_state->broadcast_rgb != old_conn_state->broadcast_rgb ||
new_conn_state->base.picture_aspect_ratio != 
old_conn_state->base.picture_aspect_ratio ||
+   new_conn_state->base.content_type != 
old_conn_state->base.content_type ||
new_conn_state->base.scaling_mode != 
old_conn_state->base.scaling_mode)
crtc_state->mode_changed = true;
 
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index ee929f31f7db..1080254a578b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -460,8 +460,10 @@ static void intel_write_infoframe(struct drm_encoder 
*encoder,
intel_dig_port->write_infoframe(encoder, crtc_state, frame->any.type, 
buffer, len);
 }
 
+
 static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
-const struct intel_crtc_state 
*crtc_state)
+const struct intel_crtc_state 
*crtc_state,
+const struct drm_connector_state 
*conn_state)
 {
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
const struct drm_display_mode *adjusted_mode =
@@ -469,6 +471,8 @@ static void intel_hdmi_set_avi_infoframe(struct drm_encoder 
*encoder,
struct drm_connector *connector = _hdmi->attached_connector->base;
bool is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
union hdmi_infoframe frame;
+   enum hdmi_content_type content_type;
+   bool itc;
int ret;
 
ret = drm_hdmi_avi_infoframe_from_display_mode(,
@@ -491,6 +495,13 @@ static void intel_hdmi_set_avi_infoframe(struct 
drm_encoder *encoder,
   
intel_hdmi->rgb_quant_range_selectable,
   is_hdmi2_sink);
 
+   /* convert generic content type property to HDMI specific */
+   itc = drm_hdmi_get_itc_bit_from_property(conn_state->content_type);
+   content_type = 
drm_hdmi_get_content_type_from_property(conn_state->content_type);
+
+   frame.avi.itc = itc;
+   frame.avi.content_type = content_type;
+
/* TODO: handle pixel repetition for YCBCR420 outputs */
intel_write_infoframe(encoder, crtc_state, );
 }
@@ -586,7 +597,7 @@ static void g4x_set_infoframes(struct 

[PATCH v10 1/2] drm: content-type property for HDMI connector

[StanLis]

From: Stanislav Lisovskiy 

Added content_type property to drm_connector_state
in order to properly handle external HDMI TV content-type setting.

v2:
 * Moved helper function which attaches content type property
   to the drm core, as was suggested.
   Removed redundant connector state initialization.

v3:
 * Removed caps in drm_content_type_enum_list.
   After some discussion it turned out that HDMI Spec 1.4
   was wrongly assuming that IT Content(itc) bit doesn't affect
   Content type states, however itc bit needs to be manupulated
   as well. In order to not expose additional property for itc,
   for sake of simplicity it was decided to bind those together
   in same "content type" property.

v4:
 * Added it_content checking in intel_digital_connector_atomic_check.
   Fixed documentation for new content type enum.

v5:
 * Moved patch revision's description to commit messages.

v6:
 * Minor naming fix for the content type enumeration string.

v7:
 * Fix parameter name for documentation and parameter alignment
   in order not to get warning. Added Content Type description to
   new HDMI connector properties section.

v8:
 * Thrown away unneeded numbers from HDMI content-type property
   description. Switch to strings desription instead of plain
   definitions.

v9:
 * Moved away hdmi specific content-type enum from
   drm_connector_state. Content type property should probably not
   be bound to any specific connector interface in
   drm_connector_state.
   Same probably should be done to hdmi_picture_aspect_ration enum
   which is also contained in drm_connector_state. Added special
   helper function to get derive hdmi specific relevant infoframe
   fields.

v10:
 * Added usage description to HDMI properties kernel doc.

Acked-by: Hans Verkuil 
Acked-by: Daniel Vetter 
Signed-off-by: Stanislav Lisovskiy 
---
 Documentation/gpu/drm-kms.rst|  6 +++
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c |  4 ++
 drivers/gpu/drm/drm_connector.c  | 80 
 drivers/gpu/drm/drm_edid.c   | 55 +++
 include/drm/drm_connector.h  | 12 +
 include/drm/drm_edid.h   |  6 +++
 include/drm/drm_mode_config.h|  5 ++
 include/uapi/drm/drm_mode.h  |  7 +++
 9 files changed, 176 insertions(+)

diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
index 1dffd1ac4cd4..e233c2626bd0 100644
--- a/Documentation/gpu/drm-kms.rst
+++ b/Documentation/gpu/drm-kms.rst
@@ -517,6 +517,12 @@ Standard Connector Properties
 .. kernel-doc:: drivers/gpu/drm/drm_connector.c
:doc: standard connector properties
 
+HDMI Specific Connector Properties
+-
+
+.. kernel-doc:: drivers/gpu/drm/drm_connector.c
+   :doc: HDMI connector properties
+
 Plane Composition Properties
 
 
diff --git a/Documentation/gpu/kms-properties.csv 
b/Documentation/gpu/kms-properties.csv
index 07ed22ea3bd6..bfde04eddd14 100644
--- a/Documentation/gpu/kms-properties.csv
+++ b/Documentation/gpu/kms-properties.csv
@@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property Name,Type,Property 
Values,Object attached,De
 ,Virtual GPU,“suggested X”,RANGE,"Min=0, Max=0x",Connector,property to 
suggest an X offset for a connector
 ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property to suggest an 
Y offset for a connector
 ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9"" 
}",Connector,TDB
+,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"", ""Photo"", 
""Cinema"", ""Game"" }",Connector,TBD
 i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"", ""Limited 
16:235"" }",Connector,"When this property is set to Limited 16:235 and CTM is 
set, the hardware will be programmed with the result of the multiplication of 
CTM by the limited range matrix to ensure the pixels normaly in the range 
0..1.0 are remapped to the range 16/255..235/255."
 ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on"" }",Connector,TBD
 ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"", ""PAL_B"" } 
etc.",Connector,TBD
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3d9ae057a6cd..6c1e1e774517 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1270,6 +1270,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
state->link_status = val;
} else if (property == config->aspect_ratio_property) {
state->picture_aspect_ratio = val;
+   } else if (property == config->content_type_property) {
+   state->content_type = val;
} else if (property == connector->scaling_mode_property) {
state->scaling_mode = val;
} else if (property == 

[PATCH v10 0/2] Enabling content-type setting for HDMI displays.

[StanLis]

From: Stanislav Lisovskiy 

Added content type setting property to drm_connector(part 1)
and enabled transmitting it with HDMI AVI infoframes
for i915(part 2).

Stanislav Lisovskiy (2):
  drm: content-type property for HDMI connector
  i915: content-type property for HDMI connector

 Documentation/gpu/drm-kms.rst|  6 +++
 Documentation/gpu/kms-properties.csv |  1 +
 drivers/gpu/drm/drm_atomic.c |  4 ++
 drivers/gpu/drm/drm_connector.c  | 80 
 drivers/gpu/drm/drm_edid.c   | 55 +++
 drivers/gpu/drm/i915/intel_atomic.c  |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c| 24 ++---
 include/drm/drm_connector.h  | 12 +
 include/drm/drm_edid.h   |  6 +++
 include/drm/drm_mode_config.h|  5 ++
 include/uapi/drm/drm_mode.h  |  7 +++
 11 files changed, 195 insertions(+), 6 deletions(-)

-- 
2.17.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/3] drm/sti: do not remove the drm_bridge that was never added

[Daniel Vetter]

On Mon, May 07, 2018 at 03:59:04PM +0200, Peter Rosin wrote:
> On 2018-05-07 15:39, Daniel Vetter wrote:
> > On Thu, May 03, 2018 at 11:12:21PM +0200, Peter Rosin wrote:
> >> On 2018-05-03 11:06, Daniel Vetter wrote:
> >>> On Wed, May 02, 2018 at 09:40:23AM +0200, Peter Rosin wrote:
>  The more natural approach would perhaps be to add an drm_bridge_add,
>  but there are several other bridges that never call drm_bridge_add.
>  Just removing the drm_bridge_remove is the easier fix.
> 
>  Signed-off-by: Peter Rosin 
> >>>
> >>> This mess is much bigger. There's 2 pairs of bridge functions:
> >>>
> >>> - drm_bridge_attach/detach. Those are meant to be called by the overall
> >>>   drm driver to connect/disconnect a drm_bridge.
> >>>
> >>> - drm_bridge_add/remove. These are supposed to be called by the bridge
> >>>   driver itself to register/unregister itself. Maybe we should rename
> >>>   them, since the same issue happens with drm_panel, with the same
> >>>   confusion.
> >>>
> >>> I thought someone was working on a cleanup series to fix this mess, but I
> >>> didn't find anything.
> >>
> >> Ok, I just spotted the imbalance and didn't really dig into what
> >> actually happens in these error paths. Now that I have done so I
> >> believe that the removed drm_bridge_remove calls causes NULL
> >> dereferences if/when the error paths are triggered.
> >>
> >> So, I don't think this can wait for some bigger cleanup.
> >>
> >> drm_bridge_remove calls list_del_init calls __list_del_entry calls
> >> __list_del with NULL in both prev and next since the list member
> >> is never initialized. prev and next are dereferenced by __list_del
> >> and you have *boom*
> >>
> >> I recommend adding the tag
> >>
> >> Fixes: 84601dbdea36 ("drm: sti: rework init sequence")
> >>
> >> so that stable picks this one up.
> > 
> > I just wanted to correct your commit message text - the correct solution
> > is definitely _not_ for sti here to call drm_bridge_add.
> 
> Ah, I see what you mean. Do you want me to respin?
> 
> >  It should call
> > drm_bridge_attach/detach only, as a pair.
> 
> Alas, the attach/detach functions are generally not called from the same
> level. After the bridge has been attached to an encoder, it is detached
> in the generic code shutting down the encoder, i.e. the bridge consumer
> is not explicitly involved with bridge detaching.
> 
> > I didn't check whether you instead have a _detach call missing or what's
> > going on here.
> 
> So, even though there is no _detach call, it is still not "missing" as
> it is not supposed to be there...

Oh, TIL. Totally missed that we've improved this to be closer to dwim()
semantics. I think your patch is correct as-is and has my

Acked-by: Daniel Vetter 

It'd be great to improve the kerneldoc for drm_bridge_attach though to
mention that bridges get auto-detached on encoder cleanup as don in
drm_encoder_cleanup(). Care to do that?

And on that note I've again realized that most drivers totally get this
wrong when they set their ->destroy callback to drm_encoder_cleanup
(similar for other kms objects), because that one does _not_ do the final
kfree. Oh well.
-Daniel

> 
> Cheers,
> Peter
> 
> > -Daniel
> >>
> >> Cheers,
> >> Peter
> >>
> >>> -Daniel
> >>>
>  ---
>   drivers/gpu/drm/sti/sti_hda.c  | 1 -
>   drivers/gpu/drm/sti/sti_hdmi.c | 1 -
>   2 files changed, 2 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/sti/sti_hda.c 
>  b/drivers/gpu/drm/sti/sti_hda.c
>  index 67bbdb49fffc..199db13f565c 100644
>  --- a/drivers/gpu/drm/sti/sti_hda.c
>  +++ b/drivers/gpu/drm/sti/sti_hda.c
>  @@ -721,7 +721,6 @@ static int sti_hda_bind(struct device *dev, struct 
>  device *master, void *data)
>   return 0;
>   
>   err_sysfs:
>  -drm_bridge_remove(bridge);
>   return -EINVAL;
>   }
>   
>  diff --git a/drivers/gpu/drm/sti/sti_hdmi.c 
>  b/drivers/gpu/drm/sti/sti_hdmi.c
>  index 58f431102512..932724784942 100644
>  --- a/drivers/gpu/drm/sti/sti_hdmi.c
>  +++ b/drivers/gpu/drm/sti/sti_hdmi.c
>  @@ -1315,7 +1315,6 @@ static int sti_hdmi_bind(struct device *dev, 
>  struct device *master, void *data)
>   return 0;
>   
>   err_sysfs:
>  -drm_bridge_remove(bridge);
>   hdmi->drm_connector = NULL;
>   return -EINVAL;
>   }
>  -- 
>  2.11.0
> 
>  ___
>  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
> > 
> 
> ___
> 

[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=105733

--- Comment #14 from Koz Ross  ---
I also seem to be having similar issues - I have given a full report as bug
#106434.

-- 
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: [Intel-gfx] [PATCH v9 1/2] drm: content-type property for HDMI connector

[Lisovskiy, Stanislav]

On Mon, 2018-05-07 at 16:05 +0200, Daniel Vetter wrote:
> On Mon, May 07, 2018 at 04:16:40PM +0300, StanLis wrote:
> > From: Stanislav Lisovskiy 
> > 
> > Added content_type property to drm_connector_state
> > in order to properly handle external HDMI TV content-type setting.
> > 
> > v2:
> >  * Moved helper function which attaches content type property
> >to the drm core, as was suggested.
> >Removed redundant connector state initialization.
> > 
> > v3:
> >  * Removed caps in drm_content_type_enum_list.
> >After some discussion it turned out that HDMI Spec 1.4
> >was wrongly assuming that IT Content(itc) bit doesn't affect
> >Content type states, however itc bit needs to be manupulated
> >as well. In order to not expose additional property for itc,
> >for sake of simplicity it was decided to bind those together
> >in same "content type" property.
> > 
> > v4:
> >  * Added it_content checking in
> > intel_digital_connector_atomic_check.
> >Fixed documentation for new content type enum.
> > 
> > v5:
> >  * Moved patch revision's description to commit messages.
> > 
> > v6:
> >  * Minor naming fix for the content type enumeration string.
> > 
> > v7:
> >  * Fix parameter name for documentation and parameter alignment
> >in order not to get warning. Added Content Type description to
> >new HDMI connector properties section.
> > 
> > v8:
> >  * Thrown away unneeded numbers from HDMI content-type property
> >description. Switch to strings desription instead of plain
> >definitions.
> > 
> > v9:
> >  * Moved away hdmi specific content-type enum from
> >drm_connector_state. Content type property should probably not
> >be bound to any specific connector interface in
> >drm_connector_state.
> >Same probably should be done to hdmi_picture_aspect_ration enum
> >which is also contained in drm_connector_state. Added special
> >helper function to get derive hdmi specific relevant infoframe
> >fields.
> > 
> > Signed-off-by: Stanislav Lisovskiy 
> > ---
> >  Documentation/gpu/drm-kms.rst|  6 +++
> >  Documentation/gpu/kms-properties.csv |  1 +
> >  drivers/gpu/drm/drm_atomic.c |  4 ++
> >  drivers/gpu/drm/drm_connector.c  | 74
> > 
> >  drivers/gpu/drm/drm_edid.c   | 55 +
> >  include/drm/drm_connector.h  | 12 +
> >  include/drm/drm_edid.h   |  6 +++
> >  include/drm/drm_mode_config.h|  5 ++
> >  include/uapi/drm/drm_mode.h  |  7 +++
> >  9 files changed, 170 insertions(+)
> > 
> > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-
> > kms.rst
> > index 1dffd1ac4cd4..e233c2626bd0 100644
> > --- a/Documentation/gpu/drm-kms.rst
> > +++ b/Documentation/gpu/drm-kms.rst
> > @@ -517,6 +517,12 @@ Standard Connector Properties
> >  .. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > :doc: standard connector properties
> >  
> > +HDMI Specific Connector Properties
> > +-
> > +
> > +.. kernel-doc:: drivers/gpu/drm/drm_connector.c
> > +   :doc: HDMI connector properties
> > +
> >  Plane Composition Properties
> >  
> >  
> > diff --git a/Documentation/gpu/kms-properties.csv
> > b/Documentation/gpu/kms-properties.csv
> > index 07ed22ea3bd6..bfde04eddd14 100644
> > --- a/Documentation/gpu/kms-properties.csv
> > +++ b/Documentation/gpu/kms-properties.csv
> > @@ -17,6 +17,7 @@ Owner Module/Drivers,Group,Property
> > Name,Type,Property Values,Object attached,De
> >  ,Virtual GPU,“suggested X”,RANGE,"Min=0,
> > Max=0x",Connector,property to suggest an X offset for a
> > connector
> >  ,,“suggested Y”,RANGE,"Min=0, Max=0x",Connector,property
> > to suggest an Y offset for a connector
> >  ,Optional,"""aspect ratio""",ENUM,"{ ""None"", ""4:3"", ""16:9""
> > }",Connector,TDB
> > +,Optional,"""content type""",ENUM,"{ ""No Data"", ""Graphics"",
> > ""Photo"", ""Cinema"", ""Game"" }",Connector,TBD
> >  i915,Generic,"""Broadcast RGB""",ENUM,"{ ""Automatic"", ""Full"",
> > ""Limited 16:235"" }",Connector,"When this property is set to
> > Limited 16:235 and CTM is set, the hardware will be programmed with
> > the result of the multiplication of CTM by the limited range matrix
> > to ensure the pixels normaly in the range 0..1.0 are remapped to
> > the range 16/255..235/255."
> >  ,,“audio”,ENUM,"{ ""force-dvi"", ""off"", ""auto"", ""on""
> > }",Connector,TBD
> >  ,SDVO-TV,“mode”,ENUM,"{ ""NTSC_M"", ""NTSC_J"", ""NTSC_443"",
> > ""PAL_B"" } etc.",Connector,TBD
> > diff --git a/drivers/gpu/drm/drm_atomic.c
> > b/drivers/gpu/drm/drm_atomic.c
> > index 3d9ae057a6cd..6c1e1e774517 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -1270,6 +1270,8 @@ static int
> > drm_atomic_connector_set_property(struct drm_connector *connector,
> > 

Re: [PATCH v5 1/4] drm/bridge: add support for sn65dsi86 bridge driver

[Stephen Boyd]

Quoting Sean Paul (2018-05-02 12:03:16)
> On Wed, May 02, 2018 at 10:01:59AM +0530, Sandeep Panda wrote:
> 
> > + struct drm_display_mode curr_mode;
> > + struct mutex lock;
> > + unsigned int ctrl_ref_count;
> > +};
> > +
> > +static const struct regmap_range ti_sn_bridge_volatile_ranges[] = {
> > + { .range_min = 0, .range_max = 0xff },
> > +};
> > +
> > +static const struct regmap_access_table ti_sn_bridge_volatile_table = {
> > + .yes_ranges = ti_sn_bridge_volatile_ranges,
> > + .n_yes_ranges = ARRAY_SIZE(ti_sn_bridge_volatile_ranges),
> > +};
> > +
> > +static const struct regmap_config ti_sn_bridge_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .volatile_table = _sn_bridge_volatile_table,
> > + .cache_type = REGCACHE_NONE,
> > +};
> > +
> > +static int ti_sn_bridge_power_ctrl(struct ti_sn_bridge *pdata, bool enable)
> > +{
> > + int ret = 0;
> > +
> > + mutex_lock(>lock);
> > + if (enable)
> > + pdata->ctrl_ref_count++;
> > + else
> > + pdata->ctrl_ref_count--;
> 
> I think you should use a kref instead of rolling your own ref_count. You can
> handle release by calling kref_put_mutex(), which will handle the reference 
> and
> the lock. On the acquire side, you can use kref_get_unless_zero which will be
> fast if the reference is already active.

Why not use runtime PM?

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V1 3/5] backlight: qcom-wled: Add support for short circuit handling

[Bjorn Andersson]

On Thu 03 May 02:57 PDT 2018, Kiran Gunda wrote:

> Handle the short circuit interrupt and check if the short circuit
> interrupt is valid. Re-enable the module to check if it goes
> away. Disable the module altogether if the short circuit event
> persists.
> 
> Signed-off-by: Kiran Gunda 
> ---
>  drivers/video/backlight/qcom-wled.c | 134 
> ++--
>  1 file changed, 130 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/video/backlight/qcom-wled.c 
> b/drivers/video/backlight/qcom-wled.c
> index be8b8d3..2cfba77 100644
> --- a/drivers/video/backlight/qcom-wled.c
> +++ b/drivers/video/backlight/qcom-wled.c
> @@ -10,6 +10,9 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -23,7 +26,9 @@
>  
>  #define WLED3_SINK_REG_BRIGHT_MAX0xFFF
>  
> -/* Control registers */
> +/* WLED3 Control registers */

Minor nit, please move the change of this comment to the previous patch.

> +#define WLED3_CTRL_REG_FAULT_STATUS  0x08

Unused.

> +
>  #define WLED3_CTRL_REG_MOD_EN0x46
>  #define  WLED3_CTRL_REG_MOD_EN_MASK  BIT(7)
>  
> @@ -36,7 +41,17 @@
>  #define WLED3_CTRL_REG_ILIMIT0x4e
>  #define  WLED3_CTRL_REG_ILIMIT_MASK  GENMASK(2, 0)
>  
> -/* sink registers */

Please move comment change to previous commit.

> +/* WLED4 control registers */
> +#define WLED4_CTRL_REG_SHORT_PROTECT 0x5e
> +#define  WLED4_CTRL_REG_SHORT_EN_MASKBIT(7)
> +
> +#define WLED4_CTRL_REG_SEC_ACCESS0xd0
> +#define  WLED4_CTRL_REG_SEC_UNLOCK   0xa5
> +
> +#define WLED4_CTRL_REG_TEST1 0xe2
> +#define  WLED4_CTRL_REG_TEST1_EXT_FET_DTEST2 0x09
> +
> +/* WLED3 sink registers */
>  #define WLED3_SINK_REG_SYNC  0x47
>  #define  WLED3_SINK_REG_SYNC_MASKGENMASK(2, 0)
>  #define  WLED4_SINK_REG_SYNC_MASKGENMASK(3, 0)
> @@ -130,17 +145,23 @@ struct wled_config {
>   bool cs_out_en;
>   bool ext_gen;
>   bool cabc;
> + bool external_pfet;
>  };
>  
>  struct wled {
>   const char *name;
>   struct device *dev;
>   struct regmap *regmap;
> + struct mutex lock;  /* Lock to avoid race from ISR */
> + ktime_t last_short_event;
>   u16 ctrl_addr;
>   u16 sink_addr;
>   u32 brightness;
>   u32 max_brightness;
> + u32 short_count;
>   const int *version;
> + int short_irq;
> + bool force_mod_disable;

"bool disabled_by_short" would describe what's going on better.

>  
>   struct wled_config cfg;
>   int (*wled_set_brightness)(struct wled *wled, u16 brightness);
> @@ -192,6 +213,9 @@ static int wled_module_enable(struct wled *wled, int val)
>  {
>   int rc;
>  
> + if (wled->force_mod_disable)
> + return 0;
> +

I don't fancy the idea of not telling user space that it's request to
turn on the backlight is ignored. Can we return some error here so that
it's possible for something to do something about this problem?

>   rc = regmap_update_bits(wled->regmap, wled->ctrl_addr +
>   WLED3_CTRL_REG_MOD_EN,
>   WLED3_CTRL_REG_MOD_EN_MASK,
> @@ -248,12 +272,13 @@ static int wled_update_status(struct backlight_device 
> *bl)
>   bl->props.state & BL_CORE_FBBLANK)
>   brightness = 0;
>  
> + mutex_lock(>lock);
>   if (brightness) {
>   rc = wled->wled_set_brightness(wled, brightness);
>   if (rc < 0) {
>   dev_err(wled->dev, "wled failed to set brightness 
> rc:%d\n",
>   rc);
> - return rc;
> + goto unlock_mutex;
>   }
>  
>   rc = wled->wled_sync_toggle(wled);
> @@ -267,15 +292,60 @@ static int wled_update_status(struct backlight_device 
> *bl)
>   rc = wled_module_enable(wled, !!brightness);
>   if (rc < 0) {
>   dev_err(wled->dev, "wled enable failed rc:%d\n", rc);
> - return rc;
> + goto unlock_mutex;
>   }
>   }
>  
>   wled->brightness = brightness;
>  
> +unlock_mutex:
> + mutex_unlock(>lock);
> +
>   return rc;
>  }
>  
> +#define WLED_SHORT_DLY_MS20
> +#define WLED_SHORT_CNT_MAX   5
> +#define WLED_SHORT_RESET_CNT_DLY_US  HZ

HZ is in the unit of jiffies, not micro seconds.

> +static irqreturn_t wled_short_irq_handler(int irq, void *_wled)
> +{
> + struct wled *wled = _wled;
> + int rc;
> + s64 elapsed_time;
> +
> + wled->short_count++;
> + mutex_lock(>lock);
> + rc = wled_module_enable(wled, false);
> + if (rc < 0) {
>