iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip

[Eric Wong]

I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57
chipset) and hit some kernel panics while trying to view
image/animation-intensive stuff in Firefox (X11) unless I use
"iommu_intel=igfx_off".

With Debian stable backport kernels, "linux-image-4.17.0-0.bpo.3-amd64"
(4.17.17-1~bpo9+1) has no problems.  But "linux-image-4.18.0-0.bpo.3-amd64"
(4.18.20-2~bpo9+1) gives a blank screen before I can login via agetty
and run startx.

Building 4.19.12 myself got me into X11 and able to start
Firefox to panic the kernel.  I also updated to the latest BIOS
(1.40), but it's an EOL laptop (but it's still the most powerful
laptop I use).  I intend to replace the BIOS with Coreboot soon...

Initially, I thought I was hitting another GPU hang from 4.18+:

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

But building drm-tip @ commit 28bb1fc015cedadf3b099b8bd0bb27609849f362
("drm-tip: 2018y-12m-25d-08h-12m-37s UTC integration manifest")
I was still able to reproduce the panic unless I use iommu_intel=igfx_off
"i915.reset=1" did not help matters, either.

Below is what I got from netconsole while on drm-tip:

Kernel panic - not syncing: DMAR hardware is malfunctioning
Shutting down cpus with NMI
Kernel Offset: disabled
---[ end Kernel panic - not syncing: DMAR hardware is malfunctioning ]---
[ cut here ]
sched: Unexpected reschedule of offline CPU#3!
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant 
snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass 
crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel 
aes_x86_64 crypto_simd cryptd mac80211 glue_helper intel_cstate iwlwifi 
intel_uncore i915 intel_gtt i2c_algo_bit iosf_mbi drm_kms_helper cfbfillrect 
syscopyarea intel_ips cfbimgblt sysfillrect sysimgblt fb_sys_fops cfbcopyarea 
thinkpad_acpi prime_numbers cfg80211 ledtrig_audio i2c_i801 sg snd_hda_intel 
led_class snd_hda_codec drm ac drm_panel_orientation_quirks snd_hwdep battery 
e1000e agpgart snd_hda_core snd_pcm snd_timer ptp snd soundcore pps_core 
ehci_pci ehci_hcd lpc_ich video mfd_core button acpi_cpufreq ecryptfs ip_tables 
x_tables ipv6 evdev thermal [last unloaded: netconsole]
CPU: 0 PID: 105 Comm: kworker/u8:3 Not tainted 4.20.0-rc7b1+ #1
Hardware name: LENOVO 3680FBU/3680FBU, BIOS 6QET70WW (1.40 ) 10/11/2012
Workqueue: i915 __i915_gem_free_work [i915]
RIP: 0010:native_smp_send_reschedule+0x34/0x40
Code: 05 69 c6 c9 00 73 15 48 8b 05 18 2d b3 00 be fd 00 00 00 48 8b 40 30 e9 
9a 58 7d 00 89 fe 48 c7 c7 78 73 af 81 e8 dc c2 01 00 <0f> 0b c3 66 0f 1f 84 00 
00 00 00 00 66 66 66 66 90 8b 05 0d 7d df
RSP: 0018:888075003d98 EFLAGS: 00010092
RAX: 002e RBX: 8880751a0740 RCX: 0006
RDX: 0007 RSI: 0082 RDI: 888075015440
RBP: 88806e823700 R08:  R09: 888072fc07c0
R10: 888075003d60 R11: fff5c002 R12: 8880751a0740
R13: 8880751a0740 R14:  R15: 0003
FS:  () GS:88807500() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7fdb1f53f000 CR3: 01c0a004 CR4: 000206f0
Call Trace:
 
 ? check_preempt_curr+0x4e/0x90
 ? ttwu_do_wakeup.isra.19+0x14/0xf0
 ? try_to_wake_up+0x323/0x410
 ? autoremove_wake_function+0xe/0x30
 ? __wake_up_common+0x8d/0x140
 ? __wake_up_common_lock+0x6c/0x90
 ? irq_work_run_list+0x49/0x80
 ? tick_sched_handle.isra.6+0x50/0x50
 ? update_process_times+0x3b/0x50
 ? tick_sched_handle.isra.6+0x30/0x50
 ? tick_sched_timer+0x3b/0x80
 ? __hrtimer_run_queues+0xea/0x270
 ? hrtimer_interrupt+0x101/0x240
 ? smp_apic_timer_interrupt+0x6a/0x150
 ? apic_timer_interrupt+0xf/0x20
 
 ? panic+0x1ca/0x212
 ? panic+0x1c7/0x212
 ? __iommu_flush_iotlb+0x19e/0x1c0
 ? iommu_flush_iotlb_psi+0x96/0xf0
 ? intel_unmap+0xbf/0xf0
 ? i915_gem_object_put_pages_gtt+0x36/0x220 [i915]
 ? drm_ht_remove+0x20/0x20 [drm]
 ? drm_mm_remove_node+0x1ad/0x310 [drm]
 ? __pm_runtime_resume+0x54/0x70
 ? __i915_gem_object_unset_pages+0x129/0x170 [i915]
 ? __i915_gem_object_put_pages+0x70/0xa0 [i915]
 ? __i915_gem_free_objects+0x245/0x4e0 [i915]
 ? __switch_to_asm+0x24/0x60
 ? __i915_gem_free_work+0x65/0xa0 [i915]
 ? process_one_work+0x1fd/0x410
 ? worker_thread+0x49/0x3f0
 ? kthread+0xf8/0x130
 ? process_one_work+0x410/0x410
 ? kthread_park+0x90/0x90
 ? ret_from_fork+0x35/0x40
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
---[ end trace 7dd2184d8c86cef5 ]---
[ cut here ]
sched: Unexpected reschedule of offline CPU#2!
WARNING: CPU: 0 PID: 105 at native_smp_send_reschedule+0x34/0x40
Modules linked in: netconsole ccm snd_hda_codec_hdmi snd_hda_codec_conexant 
snd_hda_codec_generic intel_powerclamp coretemp kvm_intel kvm irqbypass 
crc32_pclmul crc32c_intel ghash_clmulni_intel arc4 iwldvm aesni_intel 
aes_x86_64 crypto_simd cryptd mac80211 

Re: [RFC PATCH 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2

[Ivan Mironov]

On Thu, 2018-12-27 at 13:00 +0100, Daniel Vetter wrote: 
> > +   /*
> > +* Workaround for SDL 1.2, which is known to be setting all pixel format
> > +* fields values to zero in some cases. We treat this situation as a
> > +* kind of "use some reasonable autodetected values".
> > +*/
> > +   if (!var->red.offset && !var->green.offset&&
> > +   !var->blue.offset&& !var->transp.offset   &&
> > +   !var->red.length && !var->green.length&&
> > +   !var->blue.length&& !var->transp.length   &&
> > +   !var->red.msb_right  && !var->green.msb_right &&
> > +   !var->blue.msb_right && !var->transp.msb_right) {
> > +   u8 depth;
> > +
> > +   /*
> > +* There is no way to guess the right value for depth when
> > +* bpp is 16 or 32. So we just restore the behaviour previously
> > +* introduced here by commit 785b93ef8c309. In fact, this was
> > +* implemented even earlier in various device drivers.
> > +*/
> > +   switch (var->bits_per_pixel) {
> > +   case 16:
> > +   depth = 15;
> > +   break;
> > +   case 32:
> > +   depth = 24;
> > +   break;
> > +   default:
> > +   depth = var->bits_per_pixel;
> > +   break;
> > +   }
> 
> The guesswork here looks fishy. We should still have the drm-side format,
> and should use that.

This existed for a very long time until problematic commit was applied.
And there is a clear evidence that it was actually used by
applications.

> Otherwise the patches look good I think, but they
> need a Fixes: tag and cc: stable so backporters know what to do with
> these.
> 

I added "cc: stable" into the regression fix. Also added more info into
the commit messages. See the PATCH v1 in the mailing list.

Thanks.



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

Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS

[Liviu Dudau]

On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology 
China) wrote:
> On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology 
> > China) wrote:
> > > Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> > >   CRTC: according to the komeda_pipeline
> > >   PLANE: according to komeda_layer (layer input pipeline)
> > >   PRIVATE_OBJS: komeda_pipeline/component all will be treat as 
> > > private_objs
> > > 
> > > komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> > > kms object properties according to the komeda_dev, and pass/convert KMS's
> > > requirement to komeda_dev.
> > > 
> > > Changes in v3:
> > > - Fixed style problem found by checkpatch.pl --strict.
> > > 
> > > Changes in v2:
> > > - Unified abbreviation of "pipeline" to "pipe".
> > > 
> > > Signed-off-by: James (Qian) Wang 
> > > ---
> > >  drivers/gpu/drm/arm/display/komeda/Makefile   |   6 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 106 +++
> > >  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  19 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 169 ++
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.h   | 113 
> > >  .../drm/arm/display/komeda/komeda_pipeline.h  |   3 +
> > >  .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> > >  .../arm/display/komeda/komeda_private_obj.c   |  88 +
> > >  8 files changed, 608 insertions(+), 5 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> > >  create mode 100644 
> > > drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> > > 
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> > > b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > index 25beae900ed2..1b875e5dc0f6 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> > > +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > @@ -9,7 +9,11 @@ komeda-y := \
> > >   komeda_dev.o \
> > >   komeda_format_caps.o \
> > >   komeda_pipeline.o \
> > > - komeda_framebuffer.o
> > > + komeda_framebuffer.o \
> > > + komeda_kms.o \
> > > + komeda_crtc.o \
> > > + komeda_plane.o \
> > > + komeda_private_obj.o
> > >  
> > >  komeda-y += \
> > >   d71/d71_dev.o
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > new file mode 100644
> > > index ..5bb5a55f6b31
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -0,0 +1,106 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > > + * Author: James.Qian.Wang 
> > > + *
> > > + */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "komeda_dev.h"
> > > +#include "komeda_kms.h"
> > > +
> > > +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> > > +};
> > > +
> > > +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> > > +};
> > > +
> > > +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> > > +struct komeda_dev *mdev)
> > > +{
> > > + struct komeda_crtc *crtc;
> > > + struct komeda_pipeline *master;
> > > + char str[16];
> > > + int i;
> > > +
> > > + kms->n_crtcs = 0;
> > > +
> > > + for (i = 0; i < mdev->n_pipelines; i++) {
> > > + crtc = >crtcs[kms->n_crtcs];
> > > + master = mdev->pipelines[i];
> > > +
> > > + crtc->master = master;
> > > + crtc->slave  = NULL;
> > > +
> > > + if (crtc->slave)
> > > + sprintf(str, "pipe-%d", crtc->slave->id);
> > > + else
> > > + sprintf(str, "None");
> > > +
> > > + DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: %s.\n",
> > > +  kms->n_crtcs, master->id, str,
> > > +  master->of_output_dev ?
> > > +  master->of_output_dev->full_name : "None");
> > > +
> > > + kms->n_crtcs++;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static struct drm_plane *
> > > +get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> > > +{
> > > + struct komeda_plane *kplane;
> > > + struct drm_plane *plane;
> > > +
> > > + drm_for_each_plane(plane, >base) {
> > > + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> > > + continue;
> > > +
> > > + kplane = to_kplane(plane);
> > > + /* only master can be primary */
> > > + if (kplane->layer->base.pipeline == crtc->master)
> > > + return plane;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +
> > > +static 

Re: [PATCH 2/3] dt-bindings: gpu: samsung-rotator: Document s5pv210 support

[Paweł Chmiel]

Dnia środa, 19 grudnia 2018 17:22:51 CET Krzysztof Kozlowski pisze:
> On Wed, 19 Dec 2018 at 17:04, Paweł Chmiel
>  wrote:
> >
> > This commit documents new compatible for s5pv210 soc,
> > which will be also supported by this driver.
> >
> > Signed-off-by: Paweł Chmiel 
> > ---
> >  Documentation/devicetree/bindings/gpu/samsung-rotator.txt | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt 
> > b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > index 82cd1ed0be93..78658dec6941 100644
> > --- a/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > +++ b/Documentation/devicetree/bindings/gpu/samsung-rotator.txt
> > @@ -5,6 +5,7 @@ Required properties:
> > (a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210
> > (b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412
> > (c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250
> > +   (d) "samsung,s5pv210-rotator" for Rotator IP in S5PV210
> 
> How about putting it at beginning as the oldest chipset? This would
> require reordering the list so maybe let's remove the a/b/c list
> enumerations? They are kind of useless.
Ok, i'll send v2 of patchset with this change.
> 
> Best regards,
> Krzysztof




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

[PATCH v1 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2

[Ivan Mironov]

SDL 1.2 sets all fields related to the pixel format to zero in some
cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
pixel format changing requests"), there was an unintentional workaround
for this that existed for more than a decade. First in device-specific DRM
drivers, then here in drm_fb_helper.c.

Previous code containing this workaround just ignores pixel format fields
from userspace code. Not a good thing either, as this way, driver may
silently use pixel format different from what client actually requested,
and this in turn will lead to displaying garbage on the screen. I think
that returning EINVAL to userspace in this particular case is the right
option, so I decided to left code from problematic commit untouched
instead of just reverting it entirely.

Here is the steps required to reproduce this problem exactly:
1) Compile fceux[2] with SDL 1.2.15 and without GTK or OpenGL
   support. SDL should be compiled with fbdev support (which is
   on by default).
2) Create /etc/fb.modes with following contents (values seems
   not used, and just required to trigger problematic code in
   SDL):

mode "test"
geometry 1 1 1 1 1
timings 1 1 1 1 1 1 1
endmode

3) Create ~/.fceux/fceux.cfg with following contents:

SDL.Hotkeys.Quit = 27
SDL.DoubleBuffering = 1

4) Ensure that screen resolution is at least 1280x960 (e.g.
   append "video=Virtual-1:1280x960-32" to the kernel cmdline
   for qemu/QXL).

5) Try to run fceux on VT with some ROM file[3]:

# ./fceux color_test.nes

[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
FB_SetVideoMode()
[2] http://www.fceux.com
[3] Example ROM: 
https://github.com/bokuweb/rustynes/blob/master/roms/color_test.nes

Reported-by: saahriktu 
Suggested-by: saahriktu 
Cc: sta...@vger.kernel.org
Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing 
requests")
Signed-off-by: Ivan Mironov 
---
 drivers/gpu/drm/drm_fb_helper.c | 146 
 1 file changed, 93 insertions(+), 53 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d3af098b0922..aff576c3c4fb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(const struct 
fb_var_screeninfo *var_1,
   var_1->transp.msb_right == var_2->transp.msb_right;
 }
 
+static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
+u8 depth)
+{
+   switch (depth) {
+   case 8:
+   var->red.offset = 0;
+   var->green.offset = 0;
+   var->blue.offset = 0;
+   var->red.length = 8; /* 8bit DAC */
+   var->green.length = 8;
+   var->blue.length = 8;
+   var->transp.offset = 0;
+   var->transp.length = 0;
+   break;
+   case 15:
+   var->red.offset = 10;
+   var->green.offset = 5;
+   var->blue.offset = 0;
+   var->red.length = 5;
+   var->green.length = 5;
+   var->blue.length = 5;
+   var->transp.offset = 15;
+   var->transp.length = 1;
+   break;
+   case 16:
+   var->red.offset = 11;
+   var->green.offset = 5;
+   var->blue.offset = 0;
+   var->red.length = 5;
+   var->green.length = 6;
+   var->blue.length = 5;
+   var->transp.offset = 0;
+   break;
+   case 24:
+   var->red.offset = 16;
+   var->green.offset = 8;
+   var->blue.offset = 0;
+   var->red.length = 8;
+   var->green.length = 8;
+   var->blue.length = 8;
+   var->transp.offset = 0;
+   var->transp.length = 0;
+   break;
+   case 32:
+   var->red.offset = 16;
+   var->green.offset = 8;
+   var->blue.offset = 0;
+   var->red.length = 8;
+   var->green.length = 8;
+   var->blue.length = 8;
+   var->transp.offset = 24;
+   var->transp.length = 8;
+   break;
+   default:
+   break;
+   }
+}
+
 /**
  * drm_fb_helper_check_var - implementation for _ops.fb_check_var
  * @var: screeninfo to check
@@ -1654,6 +1712,40 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
*var,
return -EINVAL;
}
 
+   /*
+* Workaround for SDL 1.2, which is known to be setting all pixel format
+* fields values to zero in some cases. We treat this situation as a
+* kind of "use some reasonable autodetected values".
+

[PATCH v1 2/2] drm/fb-helper: Ignore the value of fb_var_screeninfo.pixclock

[Ivan Mironov]

Strict requirement of pixclock to be zero breaks support of SDL 1.2
which contains hardcoded table of supported video modes with non-zero
pixclock values[1].

To better understand which pixclock values are considered valid and how
driver should handle these values, I briefly examined few existing fbdev
drivers and documentation in Documentation/fb/. And it looks like there
are no strict rules on that and actual behaviour varies:

* some drivers treat (pixclock == 0) as "use defaults" (uvesafb.c);
* some treat (pixclock == 0) as invalid value which leads to
  -EINVAL (clps711x-fb.c);
* some pass converted pixclock value to hardware (uvesafb.c);
* some are trying to find nearest value from predefined table
  (vga16fb.c, video_gx.c).

Given this, I believe that it should be safe to just ignore this value if
changing is not supported. It seems that any portable fbdev application
which was not written only for one specific device working under one
specific kernel version should not rely on any particular behaviour of
pixclock anyway.

However, while enabling SDL1 applications to work out of the box when
there is no /etc/fb.modes with valid settings, this change affects the
video mode choosing logic in SDL. Depending on current screen
resolution, contents of /etc/fb.modes and resolution requested by
application, this may lead to user-visible difference (not always):
image will be displayed in a right way, but it will be aligned to the
left instead of center. There is no "right behaviour" here as well, as
emulated fbdev, opposing to old fbdev drivers, simply ignores any
requsts of video mode changes with resolutions smaller than current.

Feel free to NAK this patch if you think that it causes breakage of
user-space =).

The easiest way to reproduce this problem is to install sdl-sopwith[2],
remove /etc/fb.modes file if it exists, and then try to run sopwith
from console without X. At least in Fedora 29, sopwith may be simply
installed from standard repositories.

[1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c, vesa_timings
[2] http://sdl-sopwith.sourceforge.net/

Signed-off-by: Ivan Mironov 
---
 drivers/gpu/drm/drm_fb_helper.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index aff576c3c4fb..b95a0c23c7c8 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1690,9 +1690,14 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
*var,
struct drm_fb_helper *fb_helper = info->par;
struct drm_framebuffer *fb = fb_helper->fb;
 
-   if (var->pixclock != 0 || in_dbg_master())
+   if (in_dbg_master())
return -EINVAL;
 
+   if (var->pixclock != 0) {
+   DRM_DEBUG("fbdev emulation doesn't support changing the pixel 
clock, value of pixclock is ignored\n");
+   var->pixclock = 0;
+   }
+
if ((drm_format_info_block_width(fb->format, 0) > 1) ||
(drm_format_info_block_height(fb->format, 0) > 1))
return -EINVAL;
-- 
2.20.1

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

Re: [PATCH v2 1/3] dt-bindings: display: bridge: fork out ti, ds90c185 from lvds-transmitter

[Peter Rosin]

On 2018-12-27 22:27, Rob Herring wrote:
> On Wed, Dec 19, 2018 at 02:04:47PM +0100, Peter Rosin wrote:
>> From: Peter Rosin 
>>
>> DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
>> binding, which is meant to be generic.
>>
>> The sister chip DS90C187 is similar to DS90C185, describe it here as well.
>>
>> Signed-off-by: Peter Rosin 
>> ---
>>  .../bindings/display/bridge/lvds-transmitter.txt   |  8 +---
>>  .../bindings/display/bridge/ti,ds90c185.txt| 55 
>> ++
>>  2 files changed, 56 insertions(+), 7 deletions(-)
>>  create mode 100644 
>> Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
>> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
>> index 50220190c203..fd39ad34c383 100644
>> --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
>> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
>> @@ -22,13 +22,7 @@ among others.
>>  
>>  Required properties:
>>  
>> -- compatible: Must be one or more of the following
>> -  - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
>> -  - "lvds-encoder" for a generic LVDS encoder device
>> -
>> -  When compatible with the generic version, nodes must list the
>> -  device-specific version corresponding to the device first
>> -  followed by the generic version.
>> +- compatible: Must be "lvds-encoder"
>>  
>>  Required nodes:
>>  
>> diff --git 
>> a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt 
>> b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
>> new file mode 100644
>> index ..a13e778503e6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
>> @@ -0,0 +1,55 @@
>> +Texas Instruments FPD-Link (LVDS) Serializer
>> +
>> +
>> +The DS90C185 and DS90C187 are low-power serializers for portable
>> +battery-powered applications that reduces the size of the RGB
>> +interface between the host GPU and the display.
>> +
>> +Required properties:
>> +
>> +- compatible: Should be
>> +  "ti,ds90c185", "lvds-encoder"  for the TI DS90C185 FPD-Link Serializer
>> +  "ti,ds90c187", "lvds-encoder"  for the TI DS90C187 FPD-Link Serializer
>> +
>> +Optional properties:
>> +
>> +- pwdn-gpios: Power down control GPIO (the PDB pin, active-low)
> 
> powerdown-gpios is the standard name.

The lvds-encoder driver handles this binding, and that driver incidentally
also implements the thine,thc63lvdm83d binding which already has a
pwdn-gpios property. Should the thine,thc63lvdm83d binding be updated and
the driver be made to support both properties?

Since the lvds-encoder driver never had support for the pwdn-gpios (at least
not upstream) I suppose there is also the option to simply go with
powerdown-gpios as you suggest and not bother with support for the
pwdn-gpios property.

I'm quite willing to send an updated series, but I don't know what is
preferred, and am in need of guidance.

Cheers,
Peter

>> +
>> +Required nodes:
>> +
>> +The devices have two video ports. Their connections are modeled using the OF
>> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
>> +
>> +- Video port 0 for parallel input
>> +- Video port 1 for LVDS output
>> +
>> +
>> +Example
>> +---
>> +
>> +lvds-encoder {
>> +compatible = "ti,ds90c185", "lvds-encoder";
>> +
>> +pwdn-gpios = < 17 GPIO_ACTIVE_LOW>;
>> +
>> +ports {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +port@0 {
>> +reg = <0>;
>> +
>> +lvds_enc_in: endpoint {
>> +remote-endpoint = <_out_rgb>;
>> +};
>> +};
>> +
>> +port@1 {
>> +reg = <1>;
>> +
>> +lvds_enc_out: endpoint {
>> +remote-endpoint = <_panel_in>;
>> +};
>> +};
>> +};
>> +};
>> -- 
>> 2.11.0
>>

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

Re: [PATCH] drm/intel_dsi_vbt: Remove duplicate header

[Jani Nikula]

On Tue, 25 Dec 2018, Brajeswar Ghosh  wrote:
> Remove video/mipi_display.h which is included more than once
>
> Signed-off-by: Brajeswar Ghosh 

Pushed to drm-intel-next-queued, thanks for the patch.

BR,
Jani.

> ---
>  drivers/gpu/drm/i915/intel_dsi_vbt.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
> b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> index ac83d6b89ae0..40a5efa33c3d 100644
> --- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
> +++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
> @@ -32,7 +32,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "i915_drv.h"
>  #include "intel_drv.h"
>  #include "intel_dsi.h"

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS

[james qian wang (Arm Technology China)]

On Thu, Dec 27, 2018 at 10:31:52PM +0800, Liviu Dudau wrote:
> On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology 
> China) wrote:
> > On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology 
> > > China) wrote:
> > > > Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> > > >   CRTC: according to the komeda_pipeline
> > > >   PLANE: according to komeda_layer (layer input pipeline)
> > > >   PRIVATE_OBJS: komeda_pipeline/component all will be treat as 
> > > > private_objs
> > > > 
> > > > komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> > > > kms object properties according to the komeda_dev, and pass/convert 
> > > > KMS's
> > > > requirement to komeda_dev.
> > > > 
> > > > Changes in v3:
> > > > - Fixed style problem found by checkpatch.pl --strict.
> > > > 
> > > > Changes in v2:
> > > > - Unified abbreviation of "pipeline" to "pipe".
> > > > 
> > > > Signed-off-by: James (Qian) Wang 
> > > > ---
> > > >  drivers/gpu/drm/arm/display/komeda/Makefile   |   6 +-
> > > >  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 106 +++
> > > >  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  19 +-
> > > >  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 169 ++
> > > >  .../gpu/drm/arm/display/komeda/komeda_kms.h   | 113 
> > > >  .../drm/arm/display/komeda/komeda_pipeline.h  |   3 +
> > > >  .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> > > >  .../arm/display/komeda/komeda_private_obj.c   |  88 +
> > > >  8 files changed, 608 insertions(+), 5 deletions(-)
> > > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> > > >  create mode 100644 
> > > > drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> > > > 
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> > > > b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > > index 25beae900ed2..1b875e5dc0f6 100644
> > > > --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > > @@ -9,7 +9,11 @@ komeda-y := \
> > > > komeda_dev.o \
> > > > komeda_format_caps.o \
> > > > komeda_pipeline.o \
> > > > -   komeda_framebuffer.o
> > > > +   komeda_framebuffer.o \
> > > > +   komeda_kms.o \
> > > > +   komeda_crtc.o \
> > > > +   komeda_plane.o \
> > > > +   komeda_private_obj.o
> > > >  
> > > >  komeda-y += \
> > > > d71/d71_dev.o
> > > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > > new file mode 100644
> > > > index ..5bb5a55f6b31
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > > @@ -0,0 +1,106 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > > > + * Author: James.Qian.Wang 
> > > > + *
> > > > + */
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include "komeda_dev.h"
> > > > +#include "komeda_kms.h"
> > > > +
> > > > +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> > > > +};
> > > > +
> > > > +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> > > > +};
> > > > +
> > > > +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> > > > +  struct komeda_dev *mdev)
> > > > +{
> > > > +   struct komeda_crtc *crtc;
> > > > +   struct komeda_pipeline *master;
> > > > +   char str[16];
> > > > +   int i;
> > > > +
> > > > +   kms->n_crtcs = 0;
> > > > +
> > > > +   for (i = 0; i < mdev->n_pipelines; i++) {
> > > > +   crtc = >crtcs[kms->n_crtcs];
> > > > +   master = mdev->pipelines[i];
> > > > +
> > > > +   crtc->master = master;
> > > > +   crtc->slave  = NULL;
> > > > +
> > > > +   if (crtc->slave)
> > > > +   sprintf(str, "pipe-%d", crtc->slave->id);
> > > > +   else
> > > > +   sprintf(str, "None");
> > > > +
> > > > +   DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: 
> > > > %s.\n",
> > > > +kms->n_crtcs, master->id, str,
> > > > +master->of_output_dev ?
> > > > +master->of_output_dev->full_name : "None");
> > > > +
> > > > +   kms->n_crtcs++;
> > > > +   }
> > > > +
> > > > +   return 0;
> > > > +}
> > > > +
> > > > +static struct drm_plane *
> > > > +get_crtc_primary(struct komeda_kms_dev *kms, struct 

[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)

[bugzilla-daemon]

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

anode@gmail.com changed:

   What|Removed |Added

 CC||anode@gmail.com

--- Comment #22 from anode@gmail.com ---
> amdgpu: [powerplay] Failed to retrieve minimum clocks. 
Confirmed, I started getting this error and entire black screen from 4.19.4 and
all latest kernels

product: Lexa PRO [Radeon RX 550/550X]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]

-- 
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 v3 2/3] drm: Add CRTC background color property (v3)

[Eric Anholt]

Brian Starkey  writes:

> Hi Matt,
>
> On Thu, Nov 15, 2018 at 02:13:45PM -0800, Matt Roper wrote:
>>Some display controllers can be programmed to present non-black colors
>>for pixels not covered by any plane (or pixels covered by the
>>transparent regions of higher planes).  Compositors that want a UI with
>>a solid color background can potentially save memory bandwidth by
>>setting the CRTC background property and using smaller planes to display
>>the rest of the content.
>>
>>To avoid confusion between different ways of encoding RGB data, we
>>define a standard 64-bit format that should be used for this property's
>>value.  Helper functions and macros are provided to generate and dissect
>>values in this standard format with varying component precision values.
>>
>>v2:
>> - Swap internal representation's blue and red bits to make it easier
>>   to read if printed out.  (Ville)
>> - Document bgcolor property in drm_blend.c.  (Sean Paul)
>> - s/background_color/bgcolor/ for consistency between property name and
>>   value storage field.  (Sean Paul)
>> - Add a convenience function to attach property to a given crtc.
>>
>>v3:
>> - Restructure ARGB component extraction macros to be easier to
>>   understand and enclose the parameters in () to avoid calculations
>>   if expressions are passed.  (Sean Paul)
>> - s/rgba/argb/ in helper function/macro names.  Even though the idea is
>>   to not worry about the internal representation of the u64, it can
>>   still be confusing to look at code that uses 'rgba' terminology, but
>>   stores values with argb ordering.  (Ville)
>>
>>Cc: dri-devel@lists.freedesktop.org
>>Cc: wei.c...@intel.com
>>Cc: harish.krupo@intel.com
>>Cc: Ville Syrjälä 
>>Cc: Sean Paul 
>>Signed-off-by: Matt Roper 
>>Reviewed-by(v2): Sean Paul 
>>---

>
>>+ *   Background color is setup with drm_crtc_add_bgcolor_property().  It
>>+ *   controls the RGB color of a full-screen, fully-opaque layer that exists
>>+ *   below all planes.  This color will be used for pixels not covered by
>>+ *   any plane and may also be blended with plane contents as allowed by a
>>+ *   plane's alpha values.  The background color defaults to black, and is
>>+ *   assumed to be black for drivers that do not expose this property.
>
> Might be worth explicitly mentioning that this value is used as-is,
> without any gamma/gamut conversion before blending, i.e. it's assumed
> to already be in whatever blend-space the CRTC is using (at least I
> assume that's the case?). As we start making the color pipe more
> complicated/explicit, the details matter more.

Raspberry Pi should be able to do background color as well, but the
question of where this property is in the pipeline (particularly for CTM
and gamma) also came up for me.  My background color would apply at the
same stage as plane composition, so before gamma and CTM.

FWIW, my background color on the writeback connector (the only one where
the value would be relevant) can have alpha.


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

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

On Thu, Dec 27, 2018 at 4:45 PM Matt Roper  wrote:
>
> On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> > On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C  wrote:
> > >
> > > Matt,
> > >
> > > Is that possible for you to get some time to review 
> > > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> > >  and confirm the FROMLIST change if it looks good to you so we could move 
> > > forward?
> > >
> >
> > To be more precise, I am trying to assess what's needed before this
> > patch goes usptream, and in particular, I'd like to know if we are
> > blocked on any Chrome-side thing.
> >
> > Stéphane
> >
>
> Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
> from the ChromeOS userspace team on the ABI, plus a pointer to where the
> final, reviewed userspace patches are that correspond to it (mailing
> list link or gerrit or whatever).  I have an old gerrit link to some
> in-development chromium/ozone patches for this from November 2nd, but
> I'm not sure if there's a newer one now.

IMO from user space the ABI is good. I think the question is more
whether other hw would be fine with it. For example if we notice that
other platforms can only do black as a background color, how can we
make this API standard. Hopefully other folks can chime in here about
other hw capabilities.

Stéphane


>
> Aside from satisfying the ABI/userspace requirements, we still need all
> the patches to get reviewed by the upstream kernel devs.  An older
> version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
> been accepted yet.  Actually it looks like I never sent the latest
> version of my series that incorporates some additional feedback from
> Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
> people are still out on holiday vacation at the moment, so if necessary
> I'll start pinging IRC for reviews in a week or two when people are back
> in office.
>
>
> Matt
>
> >
> > > BTW, I've backported your kernel patch into Chrome OS and verified it 
> > > using the TEST=drm-tests/atomictest -t crtc_background_color on a Google 
> > > Pixelbook with KBL graphics.
> > >
> > > Thanks,
> > > Wei
> > >
> > > -Original Message-
> > > From: Stéphane Marchesin [mailto:marc...@chromium.org]
> > > Sent: Thursday, December 27, 2018 3:27 PM
> > > To: Roper, Matthew D 
> > > Cc: intel-gfx ; Li, Wei C 
> > > ; dri-devel 
> > > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> > >
> > > Hey,
> > >
> > > Is there anything missing on the Chrome side to move forward with this 
> > > series?
> > >
> > > Stéphane
> > >
> > > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  
> > > wrote:
> > > >
> > > > Third version of the series previously posted here:
> > > >
> > > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > > html
> > > >
> > > > This version incorporates review feedback from Ville and Sean Paul.
> > > >
> > > > The first patch here can be merged whenever it receives review approval.
> > > > The second and third patches still need to wait for opensource
> > > > userspace to be ready before merging (there's ChromeOS work underway).
> > > >
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > Cc: Wei C Li 
> > > > Cc: Sean Paul 
> > > > Cc: Ville Syrjälä 
> > > >
> > > > Matt Roper (3):
> > > >   drm/i915: Force background color to black for gen9+ (v2)
> > > >   drm: Add CRTC background color property (v2)
> > > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > > >
> > > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > > >  drivers/gpu/drm/drm_atomic_uapi.c |  5 
> > > >  drivers/gpu/drm/drm_blend.c   | 21 +---
> > > >  drivers/gpu/drm/drm_mode_config.c |  6 +
> > > >  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
> > > >  drivers/gpu/drm/i915/i915_reg.h   |  6 +
> > > >  drivers/gpu/drm/i915/intel_display.c  | 40 
> > > > +++
> > > >  include/drm/drm_blend.h   |  1 +
> > > >  include/drm/drm_crtc.h| 17 +
> > > >  include/drm/drm_mode_config.h |  5 
> > > >  include/uapi/drm/drm_mode.h   | 28 ++
> > > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > > >
> > > > --
> > > > 2.14.4
> > > >
> > > > ___
> > > > Intel-gfx mailing list
> > > > intel-...@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Matt Roper
> Graphics Software Engineer
> IoTG Platform Enabling & Development
> Intel Corporation
> (916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Matt Roper]

On Thu, Dec 27, 2018 at 04:22:28PM -0800, Stéphane Marchesin wrote:
> On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C  wrote:
> >
> > Matt,
> >
> > Is that possible for you to get some time to review 
> > https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
> >  and confirm the FROMLIST change if it looks good to you so we could move 
> > forward?
> >
> 
> To be more precise, I am trying to assess what's needed before this
> patch goes usptream, and in particular, I'd like to know if we are
> blocked on any Chrome-side thing.
> 
> Stéphane
> 

Hi Stéphane.  On the Chrome side of things, I believe we need an Ack
from the ChromeOS userspace team on the ABI, plus a pointer to where the
final, reviewed userspace patches are that correspond to it (mailing
list link or gerrit or whatever).  I have an old gerrit link to some
in-development chromium/ozone patches for this from November 2nd, but
I'm not sure if there's a newer one now.
 
Aside from satisfying the ABI/userspace requirements, we still need all
the patches to get reviewed by the upstream kernel devs.  An older
version of patch #2 has a r-b from Sean, but patches 1 and 3 haven't
been accepted yet.  Actually it looks like I never sent the latest
version of my series that incorporates some additional feedback from
Brian Starkey to the list; I'll do that tomorrow.  I think a lot of
people are still out on holiday vacation at the moment, so if necessary
I'll start pinging IRC for reviews in a week or two when people are back
in office.


Matt

> 
> > BTW, I've backported your kernel patch into Chrome OS and verified it using 
> > the TEST=drm-tests/atomictest -t crtc_background_color on a Google 
> > Pixelbook with KBL graphics.
> >
> > Thanks,
> > Wei
> >
> > -Original Message-
> > From: Stéphane Marchesin [mailto:marc...@chromium.org]
> > Sent: Thursday, December 27, 2018 3:27 PM
> > To: Roper, Matthew D 
> > Cc: intel-gfx ; Li, Wei C 
> > ; dri-devel 
> > Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
> >
> > Hey,
> >
> > Is there anything missing on the Chrome side to move forward with this 
> > series?
> >
> > Stéphane
> >
> > On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  
> > wrote:
> > >
> > > Third version of the series previously posted here:
> > >
> > > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > > html
> > >
> > > This version incorporates review feedback from Ville and Sean Paul.
> > >
> > > The first patch here can be merged whenever it receives review approval.
> > > The second and third patches still need to wait for opensource
> > > userspace to be ready before merging (there's ChromeOS work underway).
> > >
> > > Cc: dri-devel@lists.freedesktop.org
> > > Cc: Wei C Li 
> > > Cc: Sean Paul 
> > > Cc: Ville Syrjälä 
> > >
> > > Matt Roper (3):
> > >   drm/i915: Force background color to black for gen9+ (v2)
> > >   drm: Add CRTC background color property (v2)
> > >   drm/i915/gen9+: Add support for pipe background color (v3)
> > >
> > >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> > >  drivers/gpu/drm/drm_atomic_uapi.c |  5 
> > >  drivers/gpu/drm/drm_blend.c   | 21 +---
> > >  drivers/gpu/drm/drm_mode_config.c |  6 +
> > >  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
> > >  drivers/gpu/drm/i915/i915_reg.h   |  6 +
> > >  drivers/gpu/drm/i915/intel_display.c  | 40 
> > > +++
> > >  include/drm/drm_blend.h   |  1 +
> > >  include/drm/drm_crtc.h| 17 +
> > >  include/drm/drm_mode_config.h |  5 
> > >  include/uapi/drm/drm_mode.h   | 28 ++
> > >  11 files changed, 136 insertions(+), 3 deletions(-)
> > >
> > > --
> > > 2.14.4
> > >
> > > ___
> > > Intel-gfx mailing list
> > > intel-...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

On Thu, Dec 27, 2018 at 3:49 PM Li, Wei C  wrote:
>
> Matt,
>
> Is that possible for you to get some time to review 
> https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
>  and confirm the FROMLIST change if it looks good to you so we could move 
> forward?
>

To be more precise, I am trying to assess what's needed before this
patch goes usptream, and in particular, I'd like to know if we are
blocked on any Chrome-side thing.

Stéphane


> BTW, I've backported your kernel patch into Chrome OS and verified it using 
> the TEST=drm-tests/atomictest -t crtc_background_color on a Google Pixelbook 
> with KBL graphics.
>
> Thanks,
> Wei
>
> -Original Message-
> From: Stéphane Marchesin [mailto:marc...@chromium.org]
> Sent: Thursday, December 27, 2018 3:27 PM
> To: Roper, Matthew D 
> Cc: intel-gfx ; Li, Wei C 
> ; dri-devel 
> Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color
>
> Hey,
>
> Is there anything missing on the Chrome side to move forward with this series?
>
> Stéphane
>
> On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  wrote:
> >
> > Third version of the series previously posted here:
> >
> > https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> > html
> >
> > This version incorporates review feedback from Ville and Sean Paul.
> >
> > The first patch here can be merged whenever it receives review approval.
> > The second and third patches still need to wait for opensource
> > userspace to be ready before merging (there's ChromeOS work underway).
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Wei C Li 
> > Cc: Sean Paul 
> > Cc: Ville Syrjälä 
> >
> > Matt Roper (3):
> >   drm/i915: Force background color to black for gen9+ (v2)
> >   drm: Add CRTC background color property (v2)
> >   drm/i915/gen9+: Add support for pipe background color (v3)
> >
> >  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
> >  drivers/gpu/drm/drm_atomic_uapi.c |  5 
> >  drivers/gpu/drm/drm_blend.c   | 21 +---
> >  drivers/gpu/drm/drm_mode_config.c |  6 +
> >  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
> >  drivers/gpu/drm/i915/i915_reg.h   |  6 +
> >  drivers/gpu/drm/i915/intel_display.c  | 40 
> > +++
> >  include/drm/drm_blend.h   |  1 +
> >  include/drm/drm_crtc.h| 17 +
> >  include/drm/drm_mode_config.h |  5 
> >  include/uapi/drm/drm_mode.h   | 28 ++
> >  11 files changed, 136 insertions(+), 3 deletions(-)
> >
> > --
> > 2.14.4
> >
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Li, Wei C]

Matt,

Is that possible for you to get some time to review 
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1387366
 and confirm the FROMLIST change if it looks good to you so we could move 
forward?

BTW, I've backported your kernel patch into Chrome OS and verified it using the 
TEST=drm-tests/atomictest -t crtc_background_color on a Google Pixelbook with 
KBL graphics. 

Thanks,
Wei

-Original Message-
From: Stéphane Marchesin [mailto:marc...@chromium.org] 
Sent: Thursday, December 27, 2018 3:27 PM
To: Roper, Matthew D 
Cc: intel-gfx ; Li, Wei C 
; dri-devel 
Subject: Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

Hey,

Is there anything missing on the Chrome side to move forward with this series?

Stéphane

On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  wrote:
>
> Third version of the series previously posted here:
>   
> https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.
> html
>
> This version incorporates review feedback from Ville and Sean Paul.
>
> The first patch here can be merged whenever it receives review approval.
> The second and third patches still need to wait for opensource 
> userspace to be ready before merging (there's ChromeOS work underway).
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Wei C Li 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
>
> Matt Roper (3):
>   drm/i915: Force background color to black for gen9+ (v2)
>   drm: Add CRTC background color property (v2)
>   drm/i915/gen9+: Add support for pipe background color (v3)
>
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c |  5 
>  drivers/gpu/drm/drm_blend.c   | 21 +---
>  drivers/gpu/drm/drm_mode_config.c |  6 +
>  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  6 +
>  drivers/gpu/drm/i915/intel_display.c  | 40 
> +++
>  include/drm/drm_blend.h   |  1 +
>  include/drm/drm_crtc.h| 17 +
>  include/drm/drm_mode_config.h |  5 
>  include/uapi/drm/drm_mode.h   | 28 ++
>  11 files changed, 136 insertions(+), 3 deletions(-)
>
> --
> 2.14.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/vc4: Allow fb modifiers early enough to fill IN_FORMATS property

[Eric Anholt]

Paul Kocialkowski  writes:

> The KMS mode_config elements are currently configured in vc4_kms_load,
> that is called after all components are binded (component_bind_all).
> However, the CRTC component (for the Pixel Valve) needs to access the
> allow_fb_modifiers element at bind time, when initializing its planes
> through drm_universal_plane_init.
>
> This helpers checks allow_fb_modifiers to decide whether to fill the
> IN_FORMATS property. Because allow_fb_modifiers is still set to false
> at this point, the property is never filled and userspace cannot
> retrieve the combination of supported formats and modifiers.
>
> Fix this by setting allow_fb_modifiers right after calling
> drm_mode_config_init (which initializes the structure), before binding
> the components of the driver.

This makes me wonder if the flag could be removed and replaced with "did
non-NULL modifiers get supplied to plane init?"  I think I've tripped
over this flag in other KMS hacking, too.


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

Re: [Intel-gfx] [PATCH v3 0/3] CRTC background color

[Stéphane Marchesin]

Hey,

Is there anything missing on the Chrome side to move forward with this series?

Stéphane

On Thu, Nov 15, 2018 at 2:14 PM Matt Roper  wrote:
>
> Third version of the series previously posted here:
>   https://lists.freedesktop.org/archives/intel-gfx/2018-November/181777.html
>
> This version incorporates review feedback from Ville and Sean Paul.
>
> The first patch here can be merged whenever it receives review approval.
> The second and third patches still need to wait for opensource userspace
> to be ready before merging (there's ChromeOS work underway).
>
> Cc: dri-devel@lists.freedesktop.org
> Cc: Wei C Li 
> Cc: Sean Paul 
> Cc: Ville Syrjälä 
>
> Matt Roper (3):
>   drm/i915: Force background color to black for gen9+ (v2)
>   drm: Add CRTC background color property (v2)
>   drm/i915/gen9+: Add support for pipe background color (v3)
>
>  drivers/gpu/drm/drm_atomic_state_helper.c |  1 +
>  drivers/gpu/drm/drm_atomic_uapi.c |  5 
>  drivers/gpu/drm/drm_blend.c   | 21 +---
>  drivers/gpu/drm/drm_mode_config.c |  6 +
>  drivers/gpu/drm/i915/i915_debugfs.c   |  9 +++
>  drivers/gpu/drm/i915/i915_reg.h   |  6 +
>  drivers/gpu/drm/i915/intel_display.c  | 40 
> +++
>  include/drm/drm_blend.h   |  1 +
>  include/drm/drm_crtc.h| 17 +
>  include/drm/drm_mode_config.h |  5 
>  include/uapi/drm/drm_mode.h   | 28 ++
>  11 files changed, 136 insertions(+), 3 deletions(-)
>
> --
> 2.14.4
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v1 7/7] drm: remove include of drmP.h from drm_gem_cma_helper.h

[Sam Ravnborg]

Hi David.

Thanks for your comments.

On Thu, Dec 27, 2018 at 10:28:07AM -0600, David Lechner wrote:
> On 12/26/18 3:03 PM, Sam Ravnborg wrote:
> >Fix fallout in various files/drivers.
> >
> 
> What fallout is being fixed?

The removal of drmP.h from drm_gem_cma_helper.h resulted
in some build erros that is fixed by this patch.
drmP.h was removed from the header file to make it
possible to remove drmP.h on a file-by-file (or driver-by-driver)
basis for the rest of gpu/drm/*


> It would be helpful if we received the full
> patch series for context. It would also be nice to have a more detailed
> description in this commit message.

The cc: list was too long to include everyone in the cover letter.
In v2 I will make the individual commit message self explaning.

For v2 I also need to re-vist the changes as I have added include files in
some cases where a forward declaration would have been enough.

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

Re: [PATCH v1 2/7] drm: move DRM_SWITCH_POWER defines to drm_device.h

[Sam Ravnborg]

Hi Daniel.

> > +/* Used by drm_device.switch_power_state */
> > +#define DRM_SWITCH_POWER_ON 0
> > +#define DRM_SWITCH_POWER_OFF 1
> > +#define DRM_SWITCH_POWER_CHANGING 2
> > +#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
> 
> Since this isn't uapi it'd be nice to change it to an enum, which we can
> then properly kernel-doc and make your references links in the resulting
> html. Otherwise lgtm.
> 
> Would need an include stanza for drm_device.h in drm-internals.rst, plus a
> bit of kernel-doc cleanup in here I think (which iirc is why I didn't yet
> do this).

Converting to enum was easy, the documentation part not so.
I have tried to add some documentation based on what I could figure out.
There are room for improvements.

The other task was to include drm_device in the documentation.

This work resulted in the following two patches that I will post
as part of an updated series later.
Posted here to maybe get some initial feedback.

Sam

From 3bc5d6a11a1e04f20a465e2690583c87cee74ac0 Mon Sep 17 00:00:00 2001
From: Sam Ravnborg 
Date: Thu, 27 Dec 2018 23:03:12 +0100
Subject: [PATCH 1/7] drm: add drm_device.h to kernel-doc

Updated comment style to kernel-doc format

Signed-off-by: Sam Ravnborg 
---
 Documentation/gpu/drm-internals.rst |   4 +
 include/drm/drm_device.h| 157 ++--
 2 files changed, 101 insertions(+), 60 deletions(-)

diff --git a/Documentation/gpu/drm-internals.rst 
b/Documentation/gpu/drm-internals.rst
index 5ee9674fb9e9..7a677b2b0ebc 100644
--- a/Documentation/gpu/drm-internals.rst
+++ b/Documentation/gpu/drm-internals.rst
@@ -149,6 +149,10 @@ Device Instance and Driver Handling
 .. kernel-doc:: drivers/gpu/drm/drm_drv.c
:export:
 
+DRM Device
+--
+.. kernel-doc:: include/drm/drm_device.h
+
 Driver Load
 ---
 
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index 42411b3ea0c8..cd385d3fc979 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -25,24 +25,39 @@ struct pci_dev;
 struct pci_controller;
 
 /**
- * DRM device structure. This structure represent a complete card that
+ * struct drm_device - DRM device structure
+ *
+ * This structure represent a complete card that
  * may contain multiple heads.
  */
 struct drm_device {
-   struct list_head legacy_dev_list;/**< list of devices per driver for 
stealth attach cleanup */
-   int if_version; /**< Highest interface version set */
-
-   /** \name Lifetime Management */
-   /*@{ */
-   struct kref ref;/**< Object ref-count */
-   struct device *dev; /**< Device structure of bus-device */
-   struct drm_driver *driver;  /**< DRM driver managing the device */
-   void *dev_private;  /**< DRM driver private data */
-   struct drm_minor *primary;  /**< Primary node */
-   struct drm_minor *render;   /**< Render node */
+   /** @legacy_dev_list: List of devices per driver for stealth attach 
cleanup */
+   struct list_head legacy_dev_list;
+
+   /** @if_version: Highest interface version set */
+   int if_version;
+
+   /** @ref: Object ref-count */
+   struct kref ref;
+
+   /** @dev: Device structure of bus-device */
+   struct device *dev;
+
+   /** @driver: DRM driver managing the device */
+   struct drm_driver *driver;
+
+   /** @dev_private: DRM driver private data */
+   void *dev_private;
+
+   /** @primary: Primary node */
+   struct drm_minor *primary;
+
+   /** @render: Render node */
+   struct drm_minor *render;
+
bool registered;
 
-   /* currently active master for this device. Protected by master_mutex */
+   /** @master: Currently active master for this device. Protected by 
master_mutex */
struct drm_master *master;
 
/**
@@ -63,23 +78,29 @@ struct drm_device {
 */
bool unplugged;
 
-   struct inode *anon_inode;   /**< inode for private 
address-space */
-   char *unique;   /**< unique name of the device 
*/
-   /*@} */
+   /** @anon_inode: inode for private address-space */
+   struct inode *anon_inode;
+
+   /** @unique: Unique name of the device */
+   char *unique;
+
+   /** @struct_mutex: Lock for others (not drm_minor::master and 
drm_file::is_master) */
+   struct mutex struct_mutex;
+
+   /** @master_mutex: Lock for drm_minor::master and drm_file::is_master */
+   struct mutex master_mutex;
+
+   /** @open_count: Usage counter for outstanding files open, protected by 
drm_global_mutex. */
+   int open_count;
 
-   /** \name Locks */
-   /*@{ */
-   struct mutex struct_mutex;  /**< For others */
-   struct mutex master_mutex;  /**< For drm_minor::master and 
drm_file::is_master */
-   /*@} */
+   /** @buf_lock: Lock for drm_device::buf_use and a few other things. */

Re: [PATCH v6 1/2] drm/sched: Refactor ring mirror list handling.

[kbuild test robot]

Hi Andrey,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on next-20181224]
[cannot apply to v4.20]
[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/Andrey-Grodzovsky/drm-sched-Refactor-ring-mirror-list-handling/20181228-035754
reproduce: make htmldocs

All warnings (new ones prefixed by >>):

   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'rx_stats_avg.chain_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.filtered' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.retry_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.retry_count' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.lost_packets' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.last_tdls_pkt_time' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.msdu_retries' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.msdu_failed' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.last_ack' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.last_ack_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.ack_signal_filled' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'status_stats.avg_ack_signal' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'tx_stats.packets' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'tx_stats.bytes' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'tx_stats.last_rate' not described in 'sta_info'
   net/mac80211/sta_info.h:588: warning: Function parameter or member 
'tx_stats.msdu' not described in 'sta_info'
   kernel/rcu/tree.c:711: warning: Excess function parameter 'irq' description 
in 'rcu_nmi_exit'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.cb' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.poll' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_excl.active' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.cb' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.poll' not described in 'dma_buf'
   include/linux/dma-buf.h:304: warning: Function parameter or member 
'cb_shared.active' not described in 'dma_buf'
   include/linux/dma-fence-array.h:54: warning: Function parameter or member 
'work' not described in 'dma_fence_array'
   include/linux/gpio/driver.h:375: warning: Function parameter or member 
'init_valid_mask' not described in 'gpio_chip'
   include/linux/iio/hw-consumer.h:1: warning: no structured comments found
   include/linux/input/sparse-keymap.h:46: warning: Function parameter or 
member 'sw' not described in 'key_entry'
   drivers/mtd/nand/raw/nand_base.c:420: warning: Function parameter or member 
'chip' not described in 'nand_fill_oob'
   drivers/mtd/nand/raw/nand_bbt.c:173: warning: Function parameter or member 
'this' not described in 'read_bbt'
   drivers/mtd/nand/raw/nand_bbt.c:173: warning: Excess function parameter 
'chip' description in 'read_bbt'
   include/linux/regulator/machine.h:199: warning: Function parameter or member 
'max_uV_step' not described in 'regulation_constraints'
   include/linux/regulator/driver.h:228: warning: Function parameter or member 
'resume' not described in 'regulator_ops'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw0' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw1' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw2' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.esw3' not described in 'irb'
   arch/s390/include/asm/cio.h:245: warning: Function parameter or member 
'esw.eadm' not described in 'irb'
   drivers/slimbus/stream.c:1: warning: no structured comments found
   include/linux/spi/spi.h:180: warning: Function parameter or member 
'driver_override' not 

Re: [PATCH v2 2/3] dt-bindings: display: bridge: lvds-transmitter: cleanup example

[Rob Herring]

On Wed, 19 Dec 2018 14:04:48 +0100, Peter Rosin wrote:
> From: Peter Rosin 
> 
> Drop #address-cells and #size-cells from the root node in the
> example, they are unused.
> 
> Signed-off-by: Peter Rosin 
> ---
>  Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt | 2 --
>  1 file changed, 2 deletions(-)
> 

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

Re: [PATCH v2 1/3] dt-bindings: display: bridge: fork out ti,ds90c185 from lvds-transmitter

[Rob Herring]

On Wed, Dec 19, 2018 at 02:04:47PM +0100, Peter Rosin wrote:
> From: Peter Rosin 
> 
> DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
> binding, which is meant to be generic.
> 
> The sister chip DS90C187 is similar to DS90C185, describe it here as well.
> 
> Signed-off-by: Peter Rosin 
> ---
>  .../bindings/display/bridge/lvds-transmitter.txt   |  8 +---
>  .../bindings/display/bridge/ti,ds90c185.txt| 55 
> ++
>  2 files changed, 56 insertions(+), 7 deletions(-)
>  create mode 100644 
> Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt 
> b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> index 50220190c203..fd39ad34c383 100644
> --- a/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/lvds-transmitter.txt
> @@ -22,13 +22,7 @@ among others.
>  
>  Required properties:
>  
> -- compatible: Must be one or more of the following
> -  - "ti,ds90c185" for the TI DS90C185 FPD-Link Serializer
> -  - "lvds-encoder" for a generic LVDS encoder device
> -
> -  When compatible with the generic version, nodes must list the
> -  device-specific version corresponding to the device first
> -  followed by the generic version.
> +- compatible: Must be "lvds-encoder"
>  
>  Required nodes:
>  
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt 
> b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
> new file mode 100644
> index ..a13e778503e6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,ds90c185.txt
> @@ -0,0 +1,55 @@
> +Texas Instruments FPD-Link (LVDS) Serializer
> +
> +
> +The DS90C185 and DS90C187 are low-power serializers for portable
> +battery-powered applications that reduces the size of the RGB
> +interface between the host GPU and the display.
> +
> +Required properties:
> +
> +- compatible: Should be
> +  "ti,ds90c185", "lvds-encoder"  for the TI DS90C185 FPD-Link Serializer
> +  "ti,ds90c187", "lvds-encoder"  for the TI DS90C187 FPD-Link Serializer
> +
> +Optional properties:
> +
> +- pwdn-gpios: Power down control GPIO (the PDB pin, active-low)

powerdown-gpios is the standard name.

> +
> +Required nodes:
> +
> +The devices have two video ports. Their connections are modeled using the OF
> +graph bindings specified in Documentation/devicetree/bindings/graph.txt.
> +
> +- Video port 0 for parallel input
> +- Video port 1 for LVDS output
> +
> +
> +Example
> +---
> +
> +lvds-encoder {
> + compatible = "ti,ds90c185", "lvds-encoder";
> +
> + pwdn-gpios = < 17 GPIO_ACTIVE_LOW>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lvds_enc_in: endpoint {
> + remote-endpoint = <_out_rgb>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + lvds_enc_out: endpoint {
> + remote-endpoint = <_panel_in>;
> + };
> + };
> + };
> +};
> -- 
> 2.11.0
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v6 1/2] drm/sched: Refactor ring mirror list handling.

[Andrey Grodzovsky]

Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.

v2: Fix resubmission of guilty job into HW after refactoring.

v4:
Full restart for all the jobs, not only from guilty ring.
Extract karma increase into standalone function.

v5:
Rework waiting for signaled jobs without relying on the job
struct itself as those might already be freed for non 'guilty'
job's schedulers.
Expose karma increase to drivers.

v6:
Use list_for_each_entry_safe_continue and drm_sched_process_job
in case fence already signaled.
Call drm_sched_increase_karma only once for amdgpu and add documentation.

Suggested-by: Christian Koenig 
Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  20 ++-
 drivers/gpu/drm/etnaviv/etnaviv_sched.c|  11 +-
 drivers/gpu/drm/scheduler/sched_main.c | 195 +++--
 drivers/gpu/drm/v3d/v3d_sched.c|  12 +-
 include/drm/gpu_scheduler.h|   8 +-
 5 files changed, 157 insertions(+), 89 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 98df8e4..6a0601c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3298,17 +3298,15 @@ static int amdgpu_device_pre_asic_reset(struct 
amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
 
-   kthread_park(ring->sched.thread);
-
-   if (job && job->base.sched != >sched)
-   continue;
-
-   drm_sched_hw_job_reset(>sched, job ? >base : NULL);
+   drm_sched_stop(>sched, job ? >base : NULL);
 
/* after all hw jobs are reset, hw fence is meaningless, so 
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
 
+   if(job)
+   drm_sched_increase_karma(>base);
+
 
 
if (!amdgpu_sriov_vf(adev)) {
@@ -3454,14 +3452,10 @@ static void amdgpu_device_post_asic_reset(struct 
amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
 
-   /* only need recovery sched of the given job's ring
-* or all rings (in the case @job is NULL)
-* after above amdgpu_reset accomplished
-*/
-   if ((!job || job->base.sched == >sched) && 
!adev->asic_reset_res)
-   drm_sched_job_recovery(>sched);
+   if (!adev->asic_reset_res)
+   drm_sched_resubmit_jobs(>sched);
 
-   kthread_unpark(ring->sched.thread);
+   drm_sched_start(>sched, !adev->asic_reset_res);
}
 
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c 
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..6f1268f 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,19 @@ static void etnaviv_sched_timedout_job(struct 
drm_sched_job *sched_job)
}
 
/* block scheduler */
-   kthread_park(gpu->sched.thread);
-   drm_sched_hw_job_reset(>sched, sched_job);
+   drm_sched_stop(>sched, sched_job);
+
+   if(sched_job)
+   drm_sched_increase_karma(sched_job);
 
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
 
+   drm_sched_resubmit_jobs(>sched);
+
/* restart scheduler after GPU is usable again */
-   drm_sched_job_recovery(>sched);
-   kthread_unpark(gpu->sched.thread);
+   drm_sched_start(>sched, true);
 }
 
 static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..54e809b 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
 
 static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb 
*cb);
 
-static void drm_sched_expel_job_unlocked(struct drm_sched_job *s_job);
-
 /**
  * drm_sched_rq_init - initialize a given run queue struct
  *
@@ -335,6 +333,51 @@ static void drm_sched_job_timedout(struct work_struct 
*work)
spin_unlock_irqrestore(>job_list_lock, flags);
 }
 
+ /**
+  * drm_sched_increase_karma - Update sched_entity guilty flag
+  *
+  * @bad: The job guilty of time out
+  *
+  * Increment on every hang caused by the 'bad' job. If this exceeds the hang
+  * limit of the scheduler then the respective sched entity is marked guilty 
and
+  * jobs from it will not be scheduled further
+  */
+void drm_sched_increase_karma(struct drm_sched_job *bad)
+{
+   int i;
+   

[PATCH v6 2/2] drm/sched: Rework HW fence processing.

[Andrey Grodzovsky]

Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit finish_work
directly from the HW fence callback.

v2: Fix comments.
v3: Attach  hw fence cb to sched_job
v5: Rebase

Suggested-by: Christian Koenig 
Signed-off-by: Andrey Grodzovsky 
---
 drivers/gpu/drm/scheduler/sched_main.c | 59 +-
 include/drm/gpu_scheduler.h|  6 ++--
 2 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/scheduler/sched_main.c 
b/drivers/gpu/drm/scheduler/sched_main.c
index 54e809b..58bd33a 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -284,8 +284,6 @@ static void drm_sched_job_finish(struct work_struct *work)
cancel_delayed_work_sync(>work_tdr);
 
spin_lock_irqsave(>job_list_lock, flags);
-   /* remove job from ring_mirror_list */
-   list_del_init(_job->node);
/* queue TDR for next job */
drm_sched_start_timeout(sched);
spin_unlock_irqrestore(>job_list_lock, flags);
@@ -293,22 +291,11 @@ static void drm_sched_job_finish(struct work_struct *work)
sched->ops->free_job(s_job);
 }
 
-static void drm_sched_job_finish_cb(struct dma_fence *f,
-   struct dma_fence_cb *cb)
-{
-   struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
-finish_cb);
-   schedule_work(>finish_work);
-}
-
 static void drm_sched_job_begin(struct drm_sched_job *s_job)
 {
struct drm_gpu_scheduler *sched = s_job->sched;
unsigned long flags;
 
-   dma_fence_add_callback(_job->s_fence->finished, _job->finish_cb,
-  drm_sched_job_finish_cb);
-
spin_lock_irqsave(>job_list_lock, flags);
list_add_tail(_job->node, >ring_mirror_list);
drm_sched_start_timeout(sched);
@@ -405,7 +392,7 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct 
drm_sched_job *bad)
list_for_each_entry_reverse(s_job, >ring_mirror_list, node) {
if (s_job->s_fence->parent &&
dma_fence_remove_callback(s_job->s_fence->parent,
- _job->s_fence->cb)) {
+ _job->cb)) {
dma_fence_put(s_job->s_fence->parent);
s_job->s_fence->parent = NULL;
atomic_dec(>hw_rq_count);
@@ -426,11 +413,11 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, 
struct drm_sched_job *bad)
 
if (s_job->s_fence->parent) {
r = dma_fence_add_callback(s_job->s_fence->parent,
-  _job->s_fence->cb,
+  _job->cb,
   drm_sched_process_job);
if (r == -ENOENT)
drm_sched_process_job(s_job->s_fence->parent,
- _job->s_fence->cb);
+ _job->cb);
else if (r)
DRM_ERROR("fence add callback failed (%d)\n",
  r);
@@ -456,31 +443,34 @@ EXPORT_SYMBOL(drm_sched_stop);
 void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery)
 {
struct drm_sched_job *s_job, *tmp;
-   unsigned long flags;
int r;
 
if (!full_recovery)
goto unpark;
 
-   spin_lock_irqsave(>job_list_lock, flags);
+   /*
+* Locking the list is not required here as the sched thread is parked
+* so no new jobs are being pushed in to HW and in drm_sched_stop we
+* flushed all the jobs who were still in mirror list but who already
+* signaled and removed them self from the list. Also concurrent
+* GPU recovers can't run in parallel.
+*/
list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
-   struct drm_sched_fence *s_fence = s_job->s_fence;
struct dma_fence *fence = s_job->s_fence->parent;
 
if (fence) {
-   r = dma_fence_add_callback(fence, _fence->cb,
+   r = dma_fence_add_callback(fence, _job->cb,
   drm_sched_process_job);
if (r == -ENOENT)
-   drm_sched_process_job(fence, _fence->cb);
+   drm_sched_process_job(fence, _job->cb);
else if (r)
DRM_ERROR("fence add callback failed 

[v6 0/2] Add Colorspace connector property interface

[Uma Shankar]

This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scenarios, a
particular colorspace will be picked.

This will be helpful mostly to switch to higher gamut colorspaces
like BT2020 when the media content is encoded as BT2020. Thereby
giving a good visual experience to users.

The expectation from userspace is that it should parse the EDID
and get supported colorspaces. Use this property and switch to the
one supported. Kernel will not give the supported colorspaces since
this is panel dependent and our current property infrastructure is
not supporting it.

Basically the expectation from userspace is:
 - Set up CRTC DEGAMMA/CTM/GAMMA to convert to some sink
   colorspace
 - Set this new property to let the sink know what it
   converted the CRTC output to.
 - This property is just to inform sink what colorspace
   source is trying to drive.

Have tested this using xrandr by using below command:
xrandr --output HDMI2 --set "Colorspace" "BT2020_rgb"

v2: Addressed Ville and Maarten's review comments. Merged the 2nd
and 3rd patch into one common logical patch.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
default to an unset state where driver will assign the colorspace
when not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handled the default case more efficiently.

v5: Modified the colorspace property creation helper to take
platform specific enum list based on the capabilities of the
platform as suggested by Shashank. With this there is no need
for segregation between DP and HDMI.

v6: Addressed Shashank's review comments.

Uma Shankar (2):
  drm: Add colorspace connector property
  drm/i915: Attach colorspace property and enable modeset

 drivers/gpu/drm/drm_atomic_uapi.c  |  4 ++
 drivers/gpu/drm/drm_connector.c| 82 ++
 drivers/gpu/drm/i915/intel_atomic.c|  1 +
 drivers/gpu/drm/i915/intel_connector.c | 63 ++
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c  | 18 
 include/drm/drm_connector.h| 17 +++
 include/uapi/drm/drm_mode.h| 33 ++
 8 files changed, 219 insertions(+)

-- 
1.9.1

Uma Shankar (2):
  drm: Add colorspace connector property
  drm/i915: Attach colorspace property and enable modeset

 drivers/gpu/drm/drm_atomic_uapi.c  |  4 ++
 drivers/gpu/drm/drm_connector.c| 79 ++
 drivers/gpu/drm/i915/intel_atomic.c|  1 +
 drivers/gpu/drm/i915/intel_connector.c | 63 +++
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c  | 19 
 include/drm/drm_connector.h| 17 
 include/uapi/drm/drm_mode.h| 33 ++
 8 files changed, 217 insertions(+)

-- 
1.9.1

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

[v6 1/2] drm: Add colorspace connector property

[Uma Shankar]

This patch adds a colorspace connector property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.

v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colorspaces. Also, added a default option for colorspace.

v3: Removed Adobe references from enum definitions as per
Ville, Hans Verkuil and Jonas Karlman suggestions. Changed
Default to an unset state where driver will assign the colorspace
is not chosen by user, suggested by Ville and Maarten. Addressed
other misc review comments from Maarten. Split the changes to
have separate colorspace property for DP and HDMI.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard.

v5: Made the property creation helper accept enum list based on
platform capabilties as suggested by Shashank. Consolidated HDMI
and DP property creation in the common helper.

v6: Addressed Shashank's review comments.

Signed-off-by: Uma Shankar 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/drm_atomic_uapi.c |  4 ++
 drivers/gpu/drm/drm_connector.c   | 79 +++
 include/drm/drm_connector.h   | 17 +
 include/uapi/drm/drm_mode.h   | 33 
 4 files changed, 133 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_uapi.c 
b/drivers/gpu/drm/drm_atomic_uapi.c
index c408898..5e03292 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -746,6 +746,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
return -EINVAL;
}
state->content_protection = val;
+   } else if (property == connector->colorspace_property) {
+   state->colorspace = val;
} else if (property == config->writeback_fb_id_property) {
struct drm_framebuffer *fb = drm_framebuffer_lookup(dev, NULL, 
val);
int ret = drm_atomic_set_writeback_fb_for_connector(state, fb);
@@ -814,6 +816,8 @@ static int drm_atomic_connector_set_property(struct 
drm_connector *connector,
*val = state->picture_aspect_ratio;
} else if (property == config->content_type_property) {
*val = state->content_type;
+   } else if (property == connector->colorspace_property) {
+   *val = state->colorspace;
} else if (property == connector->scaling_mode_property) {
*val = state->scaling_mode;
} else if (property == connector->content_protection_property) {
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 8475396..ad1b862 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -826,6 +826,54 @@ int drm_display_info_set_bus_formats(struct 
drm_display_info *info,
 };
 DRM_ENUM_NAME_FN(drm_get_content_protection_name, drm_cp_enum_list)
 
+/* List of HDMI Colorspaces supported */
+static const struct drm_prop_enum_list hdmi_colorspaces[] = {
+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+};
+
+/* List of DP Colorspaces supported */
+static const struct drm_prop_enum_list dp_colorspaces[] = {
+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+   /* DP 

[v6 2/2] drm/i915: Attach colorspace property and enable modeset

[Uma Shankar]

This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.

Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with proper colorspace value set which
will help to enable wider color gamut like BT2020 on sink.

This patch attaches and enables HDMI colorspace, DP will be
taken care separately.

v2: Merged the changes of creating infoframe as well to this
patch as per Maarten's suggestion.

v3: Addressed review comments from Shashank. Separated HDMI
and DP colorspaces as suggested by Ville and Maarten.

v4: Addressed Chris and Ville's review comments, and created a
common colorspace property for DP and HDMI, filtered the list
based on the colorspaces supported by the respective protocol
standard. Handle the default case properly.

v5: Added Platform specific colorspace enums and called the
property creation helper using the same.

v6: Addressed Shashank's review comments.

Signed-off-by: Uma Shankar 
Reviewed-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_atomic.c|  1 +
 drivers/gpu/drm/i915/intel_connector.c | 63 ++
 drivers/gpu/drm/i915/intel_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_hdmi.c  | 19 ++
 4 files changed, 84 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index fdfc742..f5bf9db 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -125,6 +125,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_state->colorspace != old_state->colorspace ||
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)
diff --git a/drivers/gpu/drm/i915/intel_connector.c 
b/drivers/gpu/drm/i915/intel_connector.c
index 18e370f..7228d1b 100644
--- a/drivers/gpu/drm/i915/intel_connector.c
+++ b/drivers/gpu/drm/i915/intel_connector.c
@@ -31,6 +31,48 @@
 #include "intel_drv.h"
 #include "i915_drv.h"
 
+static const struct drm_prop_enum_list gen10_hdmi_colorspaces[] = {
+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
+   /* Colorimetry based on ITU-R BT.2020 */
+   { COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" },
+};
+
+static const struct drm_prop_enum_list legacy_hdmi_colorspaces[] = {
+   /* For Default case, driver will set the colorspace */
+   { COLORIMETRY_DEFAULT, "Default" },
+   /* Standard Definition Colorimetry based on CEA 861 */
+   { COLORIMETRY_ITU_601, "ITU_601" },
+   { COLORIMETRY_ITU_709, "ITU_709" },
+   /* Standard Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
+   /* High Definition Colorimetry based on IEC 61966-2-4 */
+   { COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
+   /* Colorimetry based on IEC 61966-2-1/Amendment 1 */
+   { COLORIMETRY_S_YCC_601, "S_YCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 [33] */
+   { COLORIMETRY_OPYCC_601, "opYCC_601" },
+   /* Colorimetry based on IEC 61966-2-5 */
+   { COLORIMETRY_OPRGB, "opRGB" },
+};
+
 int intel_connector_init(struct intel_connector *connector)
 {
struct intel_digital_connector_state *conn_state;
@@ -262,3 +304,24 @@ int intel_ddc_get_modes(struct drm_connector *connector,
connector->dev->mode_config.aspect_ratio_property,
DRM_MODE_PICTURE_ASPECT_NONE);
 }
+
+void
+intel_attach_colorspace_property(struct drm_connector *connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct drm_i915_private 

[Bug 109162] Bugs Bunny: Lost in Time

[bugzilla-daemon]

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

--- Comment #7 from smoki  ---

 But replaying of trace show it fine, so it isn't LLVM :D

-- 
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 109162] Bugs Bunny: Lost in Time

[bugzilla-daemon]

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

--- Comment #6 from smoki  ---

 Ah OK, that Mesa for Windows uses LLVM 6, while Debian Mesa uses LLVM 7... so
could be an LLVM regression.

-- 
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 109162] Bugs Bunny: Lost in Time

[bugzilla-daemon]

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

--- Comment #5 from smoki  ---

 And BTW forgot to mention... on AMD proprietary OpenGL driver this is fine.

-- 
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 109162] Bugs Bunny: Lost in Time

[bugzilla-daemon]

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

--- Comment #4 from smoki  ---

 I tried various MESA version overrides and R600_DEBUG variables like no2d,
notiling and such to no avail, even tried to disable DRI3 with
LIBGL_DRI3_DISABLE and nope - mess is still there.

-- 
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 109162] Bugs Bunny: Lost in Time

[bugzilla-daemon]

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

--- Comment #3 from smoki  ---

 So, software Mesa for Windows shows it correctly, while same version of
software Mesa for Linux via LIBGL_ALWAYS_SOFTWARE=true show this garbage ;)

-- 
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 v1 7/7] drm: remove include of drmP.h from drm_gem_cma_helper.h

[David Lechner]

On 12/26/18 3:03 PM, Sam Ravnborg wrote:

Fix fallout in various files/drivers.



What fallout is being fixed? It would be helpful if we received the full
patch series for context. It would also be nice to have a more detailed
description in this commit message.

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

[Bug 109162] Bugs Bunny: Lost in Time

[bugzilla-daemon]

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

--- Comment #2 from smoki  ---

 Link to the trace:

 https://www.dropbox.com/s/tk2i1j6ownzh4px/bugs-trace.7z

 Anyway, this replays fine here too. It is just when i run a game actually this
mess came by.

 I tried to run game on a CPU by using software Mesa for Windows from here:

 http://fdossena.com/?p=mesa/index.frag

 With same version of software Mesa for Windows it also plays correctly.

 So no idea what this could be really :D

-- 
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 6/6] drm/i915: drop all drmP.h includes

[Jani Nikula]

On Thu, 27 Dec 2018, Daniel Vetter  wrote:
> I guess next up would be to split up i915_drv.h and intel_drv.h and see
> how much our driver is a spaghetti mess where everything needs everything
> else :-)

In general this got me wondering how self-contained the header files
really need to be. Turns out even  isn't self-contained,
it fails on do_div() for my config if  isn't included some
other route. Didn't dig deep, but by the looks of it this is not a new
breakage (if you can call it that).

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109162] Bugs Bunny: Lost in Time

[bugzilla-daemon]

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

--- Comment #1 from smoki  ---
Created attachment 142904
  --> https://bugs.freedesktop.org/attachment.cgi?id=142904=edit
mess on the screen


 This is how it looks like. Broken presentation image i would say, as trace
shows it OK.

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

[RFC] drm: add DRM_DEBUG_CORE() and friends and use them

[Jani Nikula]

DRM_DEBUG() was intended to be used by the drm core code only, but we
weren't careful. Today, the driver usage of DRM_DEBUG() trumps drm core
usage about 10:1. It's easier to swith the core over to a new
DRM_DEBUG_CORE() macro than the drivers over to DRM_DEBUG_DRIVER().

Do the same for DRM_DEV_DEBUG() and the ratelimited ones as well.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/ati_pcigart.c |   4 +-
 drivers/gpu/drm/drm_agpsupport.c  |   6 +-
 drivers/gpu/drm/drm_auth.c|   4 +-
 drivers/gpu/drm/drm_bufs.c| 112 +++---
 drivers/gpu/drm/drm_context.c |  14 ++---
 drivers/gpu/drm/drm_dma.c |  10 ++--
 drivers/gpu/drm/drm_dp_aux_dev.c  |   6 +-
 drivers/gpu/drm/drm_drv.c |  10 ++--
 drivers/gpu/drm/drm_edid.c|  48 
 drivers/gpu/drm/drm_fb_helper.c   |  16 +++---
 drivers/gpu/drm/drm_file.c|  20 +++
 drivers/gpu/drm/drm_framebuffer.c |   2 +-
 drivers/gpu/drm/drm_hashtab.c |   4 +-
 drivers/gpu/drm/drm_ioc32.c   |  12 ++--
 drivers/gpu/drm/drm_ioctl.c   |  16 +++---
 drivers/gpu/drm/drm_irq.c |   4 +-
 drivers/gpu/drm/drm_lease.c   |   2 +-
 drivers/gpu/drm/drm_lock.c|  20 +++
 drivers/gpu/drm/drm_mode_object.c |   4 +-
 drivers/gpu/drm/drm_pci.c |  10 ++--
 drivers/gpu/drm/drm_plane.c   |  10 ++--
 drivers/gpu/drm/drm_scatter.c |  10 ++--
 drivers/gpu/drm/drm_sysfs.c   |   8 +--
 drivers/gpu/drm/drm_vblank.c  |  62 ++---
 drivers/gpu/drm/drm_vm.c  |  32 +--
 include/drm/drm_print.h   |  32 ++-
 26 files changed, 242 insertions(+), 236 deletions(-)

diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c
index 2362f07fe1fc..80af5b62154b 100644
--- a/drivers/gpu/drm/ati_pcigart.c
+++ b/drivers/gpu/drm/ati_pcigart.c
@@ -112,7 +112,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct 
drm_ati_pcigart_info *ga
}
 
if (gart_info->gart_table_location == DRM_ATI_GART_MAIN) {
-   DRM_DEBUG("PCI: no table in VRAM: using normal RAM\n");
+   DRM_DEBUG_CORE("PCI: no table in VRAM: using normal RAM\n");
 
if (pci_set_dma_mask(dev->pdev, gart_info->table_mask)) {
DRM_ERROR("fail to set dma mask to 0x%Lx\n",
@@ -133,7 +133,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct 
drm_ati_pcigart_info *ga
} else {
address = gart_info->addr;
bus_address = gart_info->bus_addr;
-   DRM_DEBUG("PCI: Gart Table: VRAM %08LX mapped at %08lX\n",
+   DRM_DEBUG_CORE("PCI: Gart Table: VRAM %08LX mapped at %08lX\n",
  (unsigned long long)bus_address,
  (unsigned long)address);
}
diff --git a/drivers/gpu/drm/drm_agpsupport.c b/drivers/gpu/drm/drm_agpsupport.c
index 737f02885c28..ab567d4e4e81 100644
--- a/drivers/gpu/drm/drm_agpsupport.c
+++ b/drivers/gpu/drm/drm_agpsupport.c
@@ -323,8 +323,8 @@ int drm_agp_bind(struct drm_device *dev, struct 
drm_agp_binding *request)
if (retcode)
return retcode;
entry->bound = dev->agp->base + (page << PAGE_SHIFT);
-   DRM_DEBUG("base = 0x%lx entry->bound = 0x%lx\n",
- dev->agp->base, entry->bound);
+   DRM_DEBUG_CORE("base = 0x%lx entry->bound = 0x%lx\n",
+  dev->agp->base, entry->bound);
return 0;
 }
 EXPORT_SYMBOL(drm_agp_bind);
@@ -476,7 +476,7 @@ drm_agp_bind_pages(struct drm_device *dev,
struct agp_memory *mem;
int ret, i;
 
-   DRM_DEBUG("\n");
+   DRM_DEBUG_CORE("\n");
 
mem = agp_allocate_memory(dev->agp->bridge, num_pages,
  type);
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 1669c42c40ed..ef46299784d8 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -70,7 +70,7 @@ int drm_getmagic(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
auth->magic = file_priv->magic;
mutex_unlock(>master_mutex);
 
-   DRM_DEBUG("%u\n", auth->magic);
+   DRM_DEBUG_CORE("%u\n", auth->magic);
 
return ret < 0 ? ret : 0;
 }
@@ -81,7 +81,7 @@ int drm_authmagic(struct drm_device *dev, void *data,
struct drm_auth *auth = data;
struct drm_file *file;
 
-   DRM_DEBUG("%u\n", auth->magic);
+   DRM_DEBUG_CORE("%u\n", auth->magic);
 
mutex_lock(>master_mutex);
file = idr_find(_priv->master->magic_map, auth->magic);
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index d7d10cabb9bb..f7d5af8604c2 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -159,8 +159,8 @@ static int drm_addmap_core(struct drm_device *dev, 
resource_size_t offset,
kfree(map);
return -EINVAL;
}
-   DRM_DEBUG("offset = 0x%08llx, size 

[Bug 109162] Bugs Bunny: Lost in Time

[bugzilla-daemon]

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

Bug ID: 109162
   Summary: Bugs Bunny: Lost in Time
   Product: Mesa
   Version: 18.2
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: smoki00...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

Current Debian Buster/Testing, Mesa 18.2.7, Kabini hardware...

 I am trying to run this near 20 years old Windows OpenGL game via WINE of
course...

 wine bugs.exe /b00 /full /skip_intro /ogl /x1920 /y1080

 But it shows half garbage as seens in picture, same is in window or whatever.

 LIBGL_ALWAYS_SOFTWARE=true shows same garbage.

 Trace actually render correctly (there are shadow bugs you could maybe ignore,
that is on Windows the same), so i am out of idea what this could be.

-- 
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 109150] "failed to set DRM interface version 1.4: Permission denied" after resume for lock screen.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #142890|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

[Bug 109150] "failed to set DRM interface version 1.4: Permission denied" after resume for lock screen.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #142891|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

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

--- Comment #4 from Michel Dänzer  ---
Looks VCE related:

Dec 24 21:12:11.223675 tom-comp kernel: [drm:amdgpu_vce_ring_test_ring
[amdgpu]] *ERROR* amdgpu: ring 12 test failed
Dec 24 21:12:11.223708 tom-comp kernel: [drm:amdgpu_device_init.cold.17
[amdgpu]] *ERROR* hw_init of IP block  failed -110

If you can live without hardware accelerated video encoding,
amdgpu.ip_block_mask=0xff on the kernel command line might serve as a
workaround.

-- 
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 6/6] drm/i915: drop all drmP.h includes

[Daniel Vetter]

On Thu, Dec 27, 2018 at 02:56:41PM +0200, Jani Nikula wrote:
> Needs just a few additional includes here and there.
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Signed-off-by: Jani Nikula 

lgtm, but didn't try to second-guess gcc :-)

Acked-by: Daniel Vetter 

I guess next up would be to split up i915_drv.h and intel_drv.h and see
how much our driver is a spaghetti mess where everything needs everything
else :-)

Cheers, Daniel
> ---
>  drivers/gpu/drm/i915/dvo.h | 1 -
>  drivers/gpu/drm/i915/i915_drv.c| 1 -
>  drivers/gpu/drm/i915/i915_drv.h| 2 +-
>  drivers/gpu/drm/i915/i915_gem.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_context.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_evict.c  | 1 -
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_fence_reg.c  | 1 -
>  drivers/gpu/drm/i915/i915_gem_gtt.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_internal.c   | 1 -
>  drivers/gpu/drm/i915/i915_gem_object.h | 3 ++-
>  drivers/gpu/drm/i915/i915_gem_shrinker.c   | 1 -
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_tiling.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_userptr.c| 1 -
>  drivers/gpu/drm/i915/i915_ioc32.c  | 1 -
>  drivers/gpu/drm/i915/i915_irq.c| 1 -
>  drivers/gpu/drm/i915/i915_suspend.c| 1 -
>  drivers/gpu/drm/i915/i915_trace.h  | 1 -
>  drivers/gpu/drm/i915/intel_acpi.c  | 1 -
>  drivers/gpu/drm/i915/intel_atomic.c| 1 -
>  drivers/gpu/drm/i915/intel_atomic_plane.c  | 1 -
>  drivers/gpu/drm/i915/intel_audio.c | 1 -
>  drivers/gpu/drm/i915/intel_bios.c  | 1 -
>  drivers/gpu/drm/i915/intel_connector.c | 1 -
>  drivers/gpu/drm/i915/intel_crt.c   | 1 -
>  drivers/gpu/drm/i915/intel_display.c   | 1 -
>  drivers/gpu/drm/i915/intel_dp.c| 1 -
>  drivers/gpu/drm/i915/intel_dp_mst.c| 1 -
>  drivers/gpu/drm/i915/intel_dsi.h   | 1 -
>  drivers/gpu/drm/i915/intel_dsi_vbt.c   | 1 -
>  drivers/gpu/drm/i915/intel_dvo.c   | 1 -
>  drivers/gpu/drm/i915/intel_fbdev.c | 1 -
>  drivers/gpu/drm/i915/intel_frontbuffer.c   | 1 -
>  drivers/gpu/drm/i915/intel_hdcp.c  | 1 -
>  drivers/gpu/drm/i915/intel_hdmi.c  | 1 -
>  drivers/gpu/drm/i915/intel_hotplug.c   | 1 -
>  drivers/gpu/drm/i915/intel_i2c.c   | 1 -
>  drivers/gpu/drm/i915/intel_lrc.c   | 1 -
>  drivers/gpu/drm/i915/intel_lvds.c  | 1 -
>  drivers/gpu/drm/i915/intel_mocs.h  | 1 -
>  drivers/gpu/drm/i915/intel_opregion.c  | 1 -
>  drivers/gpu/drm/i915/intel_overlay.c   | 1 -
>  drivers/gpu/drm/i915/intel_psr.c   | 1 -
>  drivers/gpu/drm/i915/intel_ringbuffer.c| 1 -
>  drivers/gpu/drm/i915/intel_sdvo.c  | 1 -
>  drivers/gpu/drm/i915/intel_sprite.c| 1 -
>  drivers/gpu/drm/i915/intel_tv.c| 1 -
>  drivers/gpu/drm/i915/intel_vdsc.c  | 1 -
>  drivers/gpu/drm/i915/vlv_dsi.c | 1 -
>  51 files changed, 3 insertions(+), 51 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/dvo.h b/drivers/gpu/drm/i915/dvo.h
> index 5e6a3013da49..16e0345b711f 100644
> --- a/drivers/gpu/drm/i915/dvo.h
> +++ b/drivers/gpu/drm/i915/dvo.h
> @@ -24,7 +24,6 @@
>  #define _INTEL_DVO_H
>  
>  #include 
> -#include 
>  #include 
>  #include "intel_drv.h"
>  
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index caa055ac9472..88b72a8e350f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -41,7 +41,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d44255a8655e..c314eb4cda07 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -46,7 +46,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include  /* for struct drm_dma_handle */
>  #include 
> @@ -54,6 +53,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "i915_fixed.h"
>  #include "i915_params.h"
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index d92147ab4489..da59b4211150 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -25,7 +25,6 @@
>   *
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include "i915_drv.h"
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 5905b6d8f291..5933adbe3d99 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -86,7 +86,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include "i915_drv.h"
>  #include "i915_trace.h"
> diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
> 

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #142880|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

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #142874|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

[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #142875|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 1/6] drm: include drm_device.h from drm_legacy.h

[Daniel Vetter]

On Thu, Dec 27, 2018 at 05:04:20PM +0100, Daniel Vetter wrote:
> On Thu, Dec 27, 2018 at 02:56:36PM +0200, Jani Nikula wrote:
> > Make it easier to drop drmP.h includes.
> > 
> > Cc: Sam Ravnborg 
> > Cc: Daniel Vetter 
> > Cc: Laurent Pinchart 
> > Signed-off-by: Jani Nikula 
> > ---
> >  include/drm/drm_legacy.h | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
> > index 8fad66f88e4f..743d7e70c896 100644
> > --- a/include/drm/drm_legacy.h
> > +++ b/include/drm/drm_legacy.h
> > @@ -2,6 +2,7 @@
> >  #define __DRM_DRM_LEGACY_H__
> >  
> >  #include 
> > +#include 
> 
> From a quick look, shouldn't a
> 
> struct drm_device;
> 
> forward decl be enough? You might need a pile more forward decl, but
> that's all drm_device.h seems to pull in that drm_legacy.h needs.

Reviewed-by: Daniel Vetter  with the forward decl
(assuming it all works out).
-Daniel

> -Daniel
> >  
> >  /*
> >   * Legacy driver interfaces for the Direct Rendering Manager
> > -- 
> > 2.11.0
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
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 5/6] drm: include drm_file.h from drm_syncobj.h

[Daniel Vetter]

On Thu, Dec 27, 2018 at 02:56:40PM +0200, Jani Nikula wrote:
> Make it easier to drop drmP.h includes. Switch from "" to <> includes
> while at it.
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Signed-off-by: Jani Nikula 
> ---
>  include/drm/drm_syncobj.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
> index 7c6ed845c70d..93884da3f9fe 100644
> --- a/include/drm/drm_syncobj.h
> +++ b/include/drm/drm_syncobj.h
> @@ -26,7 +26,9 @@
>  #ifndef __DRM_SYNCOBJ_H__
>  #define __DRM_SYNCOBJ_H__
>  
> -#include "linux/dma-fence.h"
> +#include 
> +
> +#include 

I think you need only a

struct drm_file;

pre-decl instead of the full include. With that:

Reviewed-by: Daniel Vetter 
>  
>  /**
>   * struct drm_syncobj - sync object.
> -- 
> 2.11.0
> 

-- 
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 4/6] drm: include types.h from drm_hdcp.h

[Daniel Vetter]

On Thu, Dec 27, 2018 at 02:56:39PM +0200, Jani Nikula wrote:
> Make it easier to drop drmP.h includes.
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Signed-off-by: Jani Nikula 

Reviewed-by: Daniel Vetter 
> ---
>  include/drm/drm_hdcp.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
> index a6de09c5e47f..d6dfef8cff6a 100644
> --- a/include/drm/drm_hdcp.h
> +++ b/include/drm/drm_hdcp.h
> @@ -9,6 +9,8 @@
>  #ifndef _DRM_HDCP_H_INCLUDED_
>  #define _DRM_HDCP_H_INCLUDED_
>  
> +#include 
> +
>  /* Period of hdcp checks (to ensure we're still authenticated) */
>  #define DRM_HDCP_CHECK_PERIOD_MS (128 * 16)
>  
> -- 
> 2.11.0
> 

-- 
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 3/6] drm: include idr.h from drm_file.h

[Daniel Vetter]

On Thu, Dec 27, 2018 at 02:56:38PM +0200, Jani Nikula wrote:
> Make it easier to drop drmP.h includes.
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Signed-off-by: Jani Nikula 
> ---
>  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 84ac79219e4c..6710b612e2f6 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -32,6 +32,7 @@
>  
>  #include 
>  #include 
> +#include 

Yup, we embed the struct idr.

Reviewed-by: Daniel Vetter 

>  
>  #include 
>  
> -- 
> 2.11.0
> 

-- 
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 2/6] drm: include kernel.h and agp_backend.h from intel-gtt.h

[Daniel Vetter]

On Thu, Dec 27, 2018 at 02:56:37PM +0200, Jani Nikula wrote:
> Make it easier to drop drmP.h includes.
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Signed-off-by: Jani Nikula 

Makes sense.

Reviewed-by: Daniel Vetter 

> ---
>  include/drm/intel-gtt.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
> index 2324c84a25c0..71d81923e6b0 100644
> --- a/include/drm/intel-gtt.h
> +++ b/include/drm/intel-gtt.h
> @@ -4,6 +4,9 @@
>  #ifndef _DRM_INTEL_GTT_H
>  #define  _DRM_INTEL_GTT_H
>  
> +#include 
> +#include 
> +
>  void intel_gtt_get(u64 *gtt_total,
>  phys_addr_t *mappable_base,
>  resource_size_t *mappable_end);
> -- 
> 2.11.0
> 

-- 
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/6] drm: include drm_device.h from drm_legacy.h

[Daniel Vetter]

On Thu, Dec 27, 2018 at 02:56:36PM +0200, Jani Nikula wrote:
> Make it easier to drop drmP.h includes.
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> Signed-off-by: Jani Nikula 
> ---
>  include/drm/drm_legacy.h | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
> index 8fad66f88e4f..743d7e70c896 100644
> --- a/include/drm/drm_legacy.h
> +++ b/include/drm/drm_legacy.h
> @@ -2,6 +2,7 @@
>  #define __DRM_DRM_LEGACY_H__
>  
>  #include 
> +#include 

From a quick look, shouldn't a

struct drm_device;

forward decl be enough? You might need a pile more forward decl, but
that's all drm_device.h seems to pull in that drm_legacy.h needs.
-Daniel
>  
>  /*
>   * Legacy driver interfaces for the Direct Rendering Manager
> -- 
> 2.11.0
> 

-- 
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 0/6] drm/i915: drmP.h include removal w/ drm prep work

[Daniel Vetter]

On Thu, Dec 27, 2018 at 02:56:35PM +0200, Jani Nikula wrote:
> First make some drm headers self-contained, removing the implicit
> dependency on a previous drmP.h include. Then remove all drmP.h includes
> from drm/i915.
> 
> Inspired by Sam's series [1]. Theres a one line trivial conflict between
> that one and this series in drm_file.h (patch 3), but I'm keeping this
> series self-contained. Should be easy enough to resolve.
> 
> I'm fine with merging the first 5 through either drm-misc or drm-intel,
> but I'd rather merge the last one through drm-intel.

Usually I'd say stuff it into drm-misc and then backmerge for the last
patch, but -rc1 is still a few weeks away I think, so not great. Probably
best if you stuff this into a topic branch in drm-intel, and then send out
pull requests to both drm-misc-next and dinq.
-Daniel

> 
> BR,
> Jani.
> 
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
> 
> 
> Jani Nikula (6):
>   drm: include drm_device.h from drm_legacy.h
>   drm: include kernel.h and agp_backend.h from intel-gtt.h
>   drm: include idr.h from drm_file.h
>   drm: include types.h from drm_hdcp.h
>   drm: include drm_file.h from drm_syncobj.h
>   drm/i915: drop all drmP.h includes
> 
>  drivers/gpu/drm/i915/dvo.h | 1 -
>  drivers/gpu/drm/i915/i915_drv.c| 1 -
>  drivers/gpu/drm/i915/i915_drv.h| 2 +-
>  drivers/gpu/drm/i915/i915_gem.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_context.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_evict.c  | 1 -
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_fence_reg.c  | 1 -
>  drivers/gpu/drm/i915/i915_gem_gtt.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_internal.c   | 1 -
>  drivers/gpu/drm/i915/i915_gem_object.h | 3 ++-
>  drivers/gpu/drm/i915/i915_gem_shrinker.c   | 1 -
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_tiling.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_userptr.c| 1 -
>  drivers/gpu/drm/i915/i915_ioc32.c  | 1 -
>  drivers/gpu/drm/i915/i915_irq.c| 1 -
>  drivers/gpu/drm/i915/i915_suspend.c| 1 -
>  drivers/gpu/drm/i915/i915_trace.h  | 1 -
>  drivers/gpu/drm/i915/intel_acpi.c  | 1 -
>  drivers/gpu/drm/i915/intel_atomic.c| 1 -
>  drivers/gpu/drm/i915/intel_atomic_plane.c  | 1 -
>  drivers/gpu/drm/i915/intel_audio.c | 1 -
>  drivers/gpu/drm/i915/intel_bios.c  | 1 -
>  drivers/gpu/drm/i915/intel_connector.c | 1 -
>  drivers/gpu/drm/i915/intel_crt.c   | 1 -
>  drivers/gpu/drm/i915/intel_display.c   | 1 -
>  drivers/gpu/drm/i915/intel_dp.c| 1 -
>  drivers/gpu/drm/i915/intel_dp_mst.c| 1 -
>  drivers/gpu/drm/i915/intel_dsi.h   | 1 -
>  drivers/gpu/drm/i915/intel_dsi_vbt.c   | 1 -
>  drivers/gpu/drm/i915/intel_dvo.c   | 1 -
>  drivers/gpu/drm/i915/intel_fbdev.c | 1 -
>  drivers/gpu/drm/i915/intel_frontbuffer.c   | 1 -
>  drivers/gpu/drm/i915/intel_hdcp.c  | 1 -
>  drivers/gpu/drm/i915/intel_hdmi.c  | 1 -
>  drivers/gpu/drm/i915/intel_hotplug.c   | 1 -
>  drivers/gpu/drm/i915/intel_i2c.c   | 1 -
>  drivers/gpu/drm/i915/intel_lrc.c   | 1 -
>  drivers/gpu/drm/i915/intel_lvds.c  | 1 -
>  drivers/gpu/drm/i915/intel_mocs.h  | 1 -
>  drivers/gpu/drm/i915/intel_opregion.c  | 1 -
>  drivers/gpu/drm/i915/intel_overlay.c   | 1 -
>  drivers/gpu/drm/i915/intel_psr.c   | 1 -
>  drivers/gpu/drm/i915/intel_ringbuffer.c| 1 -
>  drivers/gpu/drm/i915/intel_sdvo.c  | 1 -
>  drivers/gpu/drm/i915/intel_sprite.c| 1 -
>  drivers/gpu/drm/i915/intel_tv.c| 1 -
>  drivers/gpu/drm/i915/intel_vdsc.c  | 1 -
>  drivers/gpu/drm/i915/vlv_dsi.c | 1 -
>  include/drm/drm_file.h | 1 +
>  include/drm/drm_hdcp.h | 2 ++
>  include/drm/drm_legacy.h   | 1 +
>  include/drm/drm_syncobj.h  | 4 +++-
>  include/drm/intel-gtt.h| 3 +++
>  56 files changed, 13 insertions(+), 52 deletions(-)
> 
> -- 
> 2.11.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109161] Kernel crash shortly after gnome-shell login - refcount_t: increment on 0; use-after-free

[bugzilla-daemon]

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

--- Comment #2 from Yanko Kaneti  ---
I can confirm the fix.

After applying 77acd1cd912987ffd62dad6a09275a1fb406f0c2 on top of linus tip 
shell is stable, so far.

Thanks

-- 
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 109140] [KBL-G][GL] KHR-GL43.compute_shader.max test failed

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

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

-- 
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 109159] [KBL-G][vulkan] dEQP-VK.api.version_check.entry_points test failed.

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

  Component|DRM/AMDgpu  |Drivers/Vulkan/radeon
   Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
   |.org|org
Product|DRI |Mesa
 QA Contact||mesa-dev@lists.freedesktop.
   ||org
Version|XOrg git|18.3

-- 
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 109161] Kernel crash shortly after gnome-shell login - refcount_t: increment on 0; use-after-free

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer  ---
Probably introduced by
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=674e78acae0dfb4beb56132e41cbae5b60f7d662
, fixed by
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-4.21-wip=77acd1cd912987ffd62dad6a09275a1fb406f0c2
.

-- 
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: [v5 2/2] drm/i915: Attach colorspace property and enable modeset

[Shankar, Uma]

>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Sharma, Shashank
>Sent: Thursday, December 20, 2018 11:02 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org;
>dri-devel@lists.freedesktop.org
>Cc: hansv...@cisco.com; Syrjala, Ville ; Lankhorst,
>Maarten ; jo...@kwiboo.se
>Subject: Re: [v5 2/2] drm/i915: Attach colorspace property and enable modeset
>
>Regards
>
>Shashank
>
>
>On 12/11/2018 11:44 PM, Uma Shankar wrote:
>> This patch attaches the colorspace connector property to the hdmi
>> connector. Based on colorspace change, modeset will be triggered to
>> switch to new colorspace.
>>
>> Based on colorspace property value create an infoframe with
>> appropriate colorspace. This can be used to send an infoframe packet
>> with proper colorspace value set which will help to enable wider color
>> gamut like BT2020 on sink.
>>
>> This patch attaches and enables HDMI colorspace, DP will be taken care
>> separately.
>>
>> v2: Merged the changes of creating infoframe as well to this patch as
>> per Maarten's suggestion.
>>
>> v3: Addressed review comments from Shashank. Separated HDMI and DP
>> colorspaces as suggested by Ville and Maarten.
>>
>> v4: Addressed Chris and Ville's review comments, and created a common
>> colorspace property for DP and HDMI, filtered the list based on the
>> colorspaces supported by the respective protocol standard. Handle the
>> default case properly.
>>
>> v5: Added Platform specific colorspace enums and called the property
>> creation helper using the same.
>>
>> Signed-off-by: Uma Shankar 
>> ---
>>   drivers/gpu/drm/i915/intel_atomic.c|  1 +
>>   drivers/gpu/drm/i915/intel_connector.c | 63
>++
>>   drivers/gpu/drm/i915/intel_drv.h   |  1 +
>>   drivers/gpu/drm/i915/intel_hdmi.c  | 18 ++
>>   4 files changed, 83 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index a5a2c8f..35ef70a 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -125,6 +125,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_state->colorspace != old_state->colorspace ||
>>  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)
>> diff --git a/drivers/gpu/drm/i915/intel_connector.c
>> b/drivers/gpu/drm/i915/intel_connector.c
>> index 18e370f..59fa420 100644
>> --- a/drivers/gpu/drm/i915/intel_connector.c
>> +++ b/drivers/gpu/drm/i915/intel_connector.c
>> @@ -31,6 +31,48 @@
>>   #include "intel_drv.h"
>>   #include "i915_drv.h"
>>
>> +static const struct drm_prop_enum_list gen10_hdmi_colorspace[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ COLORIMETRY_ITU_601, "ITU_601" },
>> +{ COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 */
>> +{ COLORIMETRY_OPRGB, "opRGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_RGB, "BT2020_RGB" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_YCC, "BT2020_YCC" },
>> +/* Colorimetry based on ITU-R BT.2020 */
>> +{ COLORIMETRY_BT2020_CYCC, "BT2020_CYCC" }, };
>> +
>> +static const struct drm_prop_enum_list legacy_hdmi_colorspace[] = {
>> +/* For Default case, driver will set the colorspace */
>> +{ COLORIMETRY_DEFAULT, "Default" },
>> +/* Standard Definition Colorimetry based on CEA 861 */
>> +{ COLORIMETRY_ITU_601, "ITU_601" },
>> +{ COLORIMETRY_ITU_709, "ITU_709" },
>> +/* Standard Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_601, "XV_YCC_601" },
>> +/* High Definition Colorimetry based on IEC 61966-2-4 */
>> +{ COLORIMETRY_XV_YCC_709, "XV_YCC_709" },
>> +/* Colorimetry based on IEC 61966-2-1/Amendment 1 */
>> +{ COLORIMETRY_S_YCC_601, "S_YCC_601" },
>> +/* Colorimetry based on IEC 61966-2-5 [33] */
>> +{ COLORIMETRY_OPYCC_601, "opYCC_601" },
>> +/* Colorimetry 

Re: [PATCH v3 7/9] drm/komeda: Attach komeda_dev to DRM-KMS

[Liviu Dudau]

On Thu, Dec 27, 2018 at 07:09:07AM +, james qian wang (Arm Technology 
China) wrote:
> On Mon, Dec 24, 2018 at 08:32:14PM +0800, Liviu Dudau wrote:
> > On Fri, Dec 21, 2018 at 10:00:33AM +, james qian wang (Arm Technology 
> > China) wrote:
> > > Add komeda_kms abstracton to attach komeda_dev to DRM-KMS
> > >   CRTC: according to the komeda_pipeline
> > >   PLANE: according to komeda_layer (layer input pipeline)
> > >   PRIVATE_OBJS: komeda_pipeline/component all will be treat as 
> > > private_objs
> > > 
> > > komeda_kms is for connecting DRM-KMS and komeda_dev, like reporting the
> > > kms object properties according to the komeda_dev, and pass/convert KMS's
> > > requirement to komeda_dev.
> > > 
> > > Changes in v3:
> > > - Fixed style problem found by checkpatch.pl --strict.
> > > 
> > > Changes in v2:
> > > - Unified abbreviation of "pipeline" to "pipe".
> > > 
> > > Signed-off-by: James (Qian) Wang 
> > > ---
> > >  drivers/gpu/drm/arm/display/komeda/Makefile   |   6 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 106 +++
> > >  .../gpu/drm/arm/display/komeda/komeda_drv.c   |  19 +-
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.c   | 169 ++
> > >  .../gpu/drm/arm/display/komeda/komeda_kms.h   | 113 
> > >  .../drm/arm/display/komeda/komeda_pipeline.h  |   3 +
> > >  .../gpu/drm/arm/display/komeda/komeda_plane.c | 109 +++
> > >  .../arm/display/komeda/komeda_private_obj.c   |  88 +
> > >  8 files changed, 608 insertions(+), 5 deletions(-)
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_kms.h
> > >  create mode 100644 drivers/gpu/drm/arm/display/komeda/komeda_plane.c
> > >  create mode 100644 
> > > drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c
> > > 
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/Makefile 
> > > b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > index 25beae900ed2..1b875e5dc0f6 100644
> > > --- a/drivers/gpu/drm/arm/display/komeda/Makefile
> > > +++ b/drivers/gpu/drm/arm/display/komeda/Makefile
> > > @@ -9,7 +9,11 @@ komeda-y := \
> > >   komeda_dev.o \
> > >   komeda_format_caps.o \
> > >   komeda_pipeline.o \
> > > - komeda_framebuffer.o
> > > + komeda_framebuffer.o \
> > > + komeda_kms.o \
> > > + komeda_crtc.o \
> > > + komeda_plane.o \
> > > + komeda_private_obj.o
> > >  
> > >  komeda-y += \
> > >   d71/d71_dev.o
> > > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> > > b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > new file mode 100644
> > > index ..5bb5a55f6b31
> > > --- /dev/null
> > > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> > > @@ -0,0 +1,106 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * (C) COPYRIGHT 2018 ARM Limited. All rights reserved.
> > > + * Author: James.Qian.Wang 
> > > + *
> > > + */
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include "komeda_dev.h"
> > > +#include "komeda_kms.h"
> > > +
> > > +struct drm_crtc_helper_funcs komeda_crtc_helper_funcs = {
> > > +};
> > > +
> > > +static const struct drm_crtc_funcs komeda_crtc_funcs = {
> > > +};
> > > +
> > > +int komeda_kms_setup_crtcs(struct komeda_kms_dev *kms,
> > > +struct komeda_dev *mdev)
> > > +{
> > > + struct komeda_crtc *crtc;
> > > + struct komeda_pipeline *master;
> > > + char str[16];
> > > + int i;
> > > +
> > > + kms->n_crtcs = 0;
> > > +
> > > + for (i = 0; i < mdev->n_pipelines; i++) {
> > > + crtc = >crtcs[kms->n_crtcs];
> > > + master = mdev->pipelines[i];
> > > +
> > > + crtc->master = master;
> > > + crtc->slave  = NULL;
> > > +
> > > + if (crtc->slave)
> > > + sprintf(str, "pipe-%d", crtc->slave->id);
> > > + else
> > > + sprintf(str, "None");
> > > +
> > > + DRM_INFO("crtc%d: master(pipe-%d) slave(%s) output: %s.\n",
> > > +  kms->n_crtcs, master->id, str,
> > > +  master->of_output_dev ?
> > > +  master->of_output_dev->full_name : "None");
> > > +
> > > + kms->n_crtcs++;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static struct drm_plane *
> > > +get_crtc_primary(struct komeda_kms_dev *kms, struct komeda_crtc *crtc)
> > > +{
> > > + struct komeda_plane *kplane;
> > > + struct drm_plane *plane;
> > > +
> > > + drm_for_each_plane(plane, >base) {
> > > + if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> > > + continue;
> > > +
> > > + kplane = to_kplane(plane);
> > > + /* only master can be primary */
> > > + if (kplane->layer->base.pipeline == crtc->master)
> > > + return plane;
> > > + }
> > > +
> > > + return NULL;
> > > +}
> > > +
> > > +static 

[PATCH 2/6] drm: include kernel.h and agp_backend.h from intel-gtt.h

[Jani Nikula]

Make it easier to drop drmP.h includes.

Cc: Sam Ravnborg 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Signed-off-by: Jani Nikula 
---
 include/drm/intel-gtt.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/drm/intel-gtt.h b/include/drm/intel-gtt.h
index 2324c84a25c0..71d81923e6b0 100644
--- a/include/drm/intel-gtt.h
+++ b/include/drm/intel-gtt.h
@@ -4,6 +4,9 @@
 #ifndef _DRM_INTEL_GTT_H
 #define_DRM_INTEL_GTT_H
 
+#include 
+#include 
+
 void intel_gtt_get(u64 *gtt_total,
   phys_addr_t *mappable_base,
   resource_size_t *mappable_end);
-- 
2.11.0

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

[PATCH 0/6] drm/i915: drmP.h include removal w/ drm prep work

[Jani Nikula]

First make some drm headers self-contained, removing the implicit
dependency on a previous drmP.h include. Then remove all drmP.h includes
from drm/i915.

Inspired by Sam's series [1]. Theres a one line trivial conflict between
that one and this series in drm_file.h (patch 3), but I'm keeping this
series self-contained. Should be easy enough to resolve.

I'm fine with merging the first 5 through either drm-misc or drm-intel,
but I'd rather merge the last one through drm-intel.

BR,
Jani.

Cc: Sam Ravnborg 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 


Jani Nikula (6):
  drm: include drm_device.h from drm_legacy.h
  drm: include kernel.h and agp_backend.h from intel-gtt.h
  drm: include idr.h from drm_file.h
  drm: include types.h from drm_hdcp.h
  drm: include drm_file.h from drm_syncobj.h
  drm/i915: drop all drmP.h includes

 drivers/gpu/drm/i915/dvo.h | 1 -
 drivers/gpu/drm/i915/i915_drv.c| 1 -
 drivers/gpu/drm/i915/i915_drv.h| 2 +-
 drivers/gpu/drm/i915/i915_gem.c| 1 -
 drivers/gpu/drm/i915/i915_gem_context.c| 1 -
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 -
 drivers/gpu/drm/i915/i915_gem_evict.c  | 1 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 -
 drivers/gpu/drm/i915/i915_gem_fence_reg.c  | 1 -
 drivers/gpu/drm/i915/i915_gem_gtt.c| 1 -
 drivers/gpu/drm/i915/i915_gem_internal.c   | 1 -
 drivers/gpu/drm/i915/i915_gem_object.h | 3 ++-
 drivers/gpu/drm/i915/i915_gem_shrinker.c   | 1 -
 drivers/gpu/drm/i915/i915_gem_stolen.c | 1 -
 drivers/gpu/drm/i915/i915_gem_tiling.c | 1 -
 drivers/gpu/drm/i915/i915_gem_userptr.c| 1 -
 drivers/gpu/drm/i915/i915_ioc32.c  | 1 -
 drivers/gpu/drm/i915/i915_irq.c| 1 -
 drivers/gpu/drm/i915/i915_suspend.c| 1 -
 drivers/gpu/drm/i915/i915_trace.h  | 1 -
 drivers/gpu/drm/i915/intel_acpi.c  | 1 -
 drivers/gpu/drm/i915/intel_atomic.c| 1 -
 drivers/gpu/drm/i915/intel_atomic_plane.c  | 1 -
 drivers/gpu/drm/i915/intel_audio.c | 1 -
 drivers/gpu/drm/i915/intel_bios.c  | 1 -
 drivers/gpu/drm/i915/intel_connector.c | 1 -
 drivers/gpu/drm/i915/intel_crt.c   | 1 -
 drivers/gpu/drm/i915/intel_display.c   | 1 -
 drivers/gpu/drm/i915/intel_dp.c| 1 -
 drivers/gpu/drm/i915/intel_dp_mst.c| 1 -
 drivers/gpu/drm/i915/intel_dsi.h   | 1 -
 drivers/gpu/drm/i915/intel_dsi_vbt.c   | 1 -
 drivers/gpu/drm/i915/intel_dvo.c   | 1 -
 drivers/gpu/drm/i915/intel_fbdev.c | 1 -
 drivers/gpu/drm/i915/intel_frontbuffer.c   | 1 -
 drivers/gpu/drm/i915/intel_hdcp.c  | 1 -
 drivers/gpu/drm/i915/intel_hdmi.c  | 1 -
 drivers/gpu/drm/i915/intel_hotplug.c   | 1 -
 drivers/gpu/drm/i915/intel_i2c.c   | 1 -
 drivers/gpu/drm/i915/intel_lrc.c   | 1 -
 drivers/gpu/drm/i915/intel_lvds.c  | 1 -
 drivers/gpu/drm/i915/intel_mocs.h  | 1 -
 drivers/gpu/drm/i915/intel_opregion.c  | 1 -
 drivers/gpu/drm/i915/intel_overlay.c   | 1 -
 drivers/gpu/drm/i915/intel_psr.c   | 1 -
 drivers/gpu/drm/i915/intel_ringbuffer.c| 1 -
 drivers/gpu/drm/i915/intel_sdvo.c  | 1 -
 drivers/gpu/drm/i915/intel_sprite.c| 1 -
 drivers/gpu/drm/i915/intel_tv.c| 1 -
 drivers/gpu/drm/i915/intel_vdsc.c  | 1 -
 drivers/gpu/drm/i915/vlv_dsi.c | 1 -
 include/drm/drm_file.h | 1 +
 include/drm/drm_hdcp.h | 2 ++
 include/drm/drm_legacy.h   | 1 +
 include/drm/drm_syncobj.h  | 4 +++-
 include/drm/intel-gtt.h| 3 +++
 56 files changed, 13 insertions(+), 52 deletions(-)

-- 
2.11.0

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

[PATCH 6/6] drm/i915: drop all drmP.h includes

[Jani Nikula]

Needs just a few additional includes here and there.

Cc: Sam Ravnborg 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/dvo.h | 1 -
 drivers/gpu/drm/i915/i915_drv.c| 1 -
 drivers/gpu/drm/i915/i915_drv.h| 2 +-
 drivers/gpu/drm/i915/i915_gem.c| 1 -
 drivers/gpu/drm/i915/i915_gem_context.c| 1 -
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 -
 drivers/gpu/drm/i915/i915_gem_evict.c  | 1 -
 drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 -
 drivers/gpu/drm/i915/i915_gem_fence_reg.c  | 1 -
 drivers/gpu/drm/i915/i915_gem_gtt.c| 1 -
 drivers/gpu/drm/i915/i915_gem_internal.c   | 1 -
 drivers/gpu/drm/i915/i915_gem_object.h | 3 ++-
 drivers/gpu/drm/i915/i915_gem_shrinker.c   | 1 -
 drivers/gpu/drm/i915/i915_gem_stolen.c | 1 -
 drivers/gpu/drm/i915/i915_gem_tiling.c | 1 -
 drivers/gpu/drm/i915/i915_gem_userptr.c| 1 -
 drivers/gpu/drm/i915/i915_ioc32.c  | 1 -
 drivers/gpu/drm/i915/i915_irq.c| 1 -
 drivers/gpu/drm/i915/i915_suspend.c| 1 -
 drivers/gpu/drm/i915/i915_trace.h  | 1 -
 drivers/gpu/drm/i915/intel_acpi.c  | 1 -
 drivers/gpu/drm/i915/intel_atomic.c| 1 -
 drivers/gpu/drm/i915/intel_atomic_plane.c  | 1 -
 drivers/gpu/drm/i915/intel_audio.c | 1 -
 drivers/gpu/drm/i915/intel_bios.c  | 1 -
 drivers/gpu/drm/i915/intel_connector.c | 1 -
 drivers/gpu/drm/i915/intel_crt.c   | 1 -
 drivers/gpu/drm/i915/intel_display.c   | 1 -
 drivers/gpu/drm/i915/intel_dp.c| 1 -
 drivers/gpu/drm/i915/intel_dp_mst.c| 1 -
 drivers/gpu/drm/i915/intel_dsi.h   | 1 -
 drivers/gpu/drm/i915/intel_dsi_vbt.c   | 1 -
 drivers/gpu/drm/i915/intel_dvo.c   | 1 -
 drivers/gpu/drm/i915/intel_fbdev.c | 1 -
 drivers/gpu/drm/i915/intel_frontbuffer.c   | 1 -
 drivers/gpu/drm/i915/intel_hdcp.c  | 1 -
 drivers/gpu/drm/i915/intel_hdmi.c  | 1 -
 drivers/gpu/drm/i915/intel_hotplug.c   | 1 -
 drivers/gpu/drm/i915/intel_i2c.c   | 1 -
 drivers/gpu/drm/i915/intel_lrc.c   | 1 -
 drivers/gpu/drm/i915/intel_lvds.c  | 1 -
 drivers/gpu/drm/i915/intel_mocs.h  | 1 -
 drivers/gpu/drm/i915/intel_opregion.c  | 1 -
 drivers/gpu/drm/i915/intel_overlay.c   | 1 -
 drivers/gpu/drm/i915/intel_psr.c   | 1 -
 drivers/gpu/drm/i915/intel_ringbuffer.c| 1 -
 drivers/gpu/drm/i915/intel_sdvo.c  | 1 -
 drivers/gpu/drm/i915/intel_sprite.c| 1 -
 drivers/gpu/drm/i915/intel_tv.c| 1 -
 drivers/gpu/drm/i915/intel_vdsc.c  | 1 -
 drivers/gpu/drm/i915/vlv_dsi.c | 1 -
 51 files changed, 3 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo.h b/drivers/gpu/drm/i915/dvo.h
index 5e6a3013da49..16e0345b711f 100644
--- a/drivers/gpu/drm/i915/dvo.h
+++ b/drivers/gpu/drm/i915/dvo.h
@@ -24,7 +24,6 @@
 #define _INTEL_DVO_H
 
 #include 
-#include 
 #include 
 #include "intel_drv.h"
 
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index caa055ac9472..88b72a8e350f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -41,7 +41,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d44255a8655e..c314eb4cda07 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -46,7 +46,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include  /* for struct drm_dma_handle */
 #include 
@@ -54,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "i915_fixed.h"
 #include "i915_params.h"
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d92147ab4489..da59b4211150 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -25,7 +25,6 @@
  *
  */
 
-#include 
 #include 
 #include 
 #include "i915_drv.h"
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5905b6d8f291..5933adbe3d99 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -86,7 +86,6 @@
  */
 
 #include 
-#include 
 #include 
 #include "i915_drv.h"
 #include "i915_trace.h"
diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 82e2ca17a441..02f7298bfe57 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 
-#include 
 
 #include "i915_drv.h"
 
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index 02b83a5ed96c..f6855401f247 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -26,7 +26,6 @@
  *
  */
 
-#include 
 #include 
 
 #include "i915_drv.h"
diff --git 

[PATCH 3/6] drm: include idr.h from drm_file.h

[Jani Nikula]

Make it easier to drop drmP.h includes.

Cc: Sam Ravnborg 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Signed-off-by: Jani Nikula 
---
 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 84ac79219e4c..6710b612e2f6 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -32,6 +32,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
-- 
2.11.0

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

[PATCH 5/6] drm: include drm_file.h from drm_syncobj.h

[Jani Nikula]

Make it easier to drop drmP.h includes. Switch from "" to <> includes
while at it.

Cc: Sam Ravnborg 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Signed-off-by: Jani Nikula 
---
 include/drm/drm_syncobj.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 7c6ed845c70d..93884da3f9fe 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -26,7 +26,9 @@
 #ifndef __DRM_SYNCOBJ_H__
 #define __DRM_SYNCOBJ_H__
 
-#include "linux/dma-fence.h"
+#include 
+
+#include 
 
 /**
  * struct drm_syncobj - sync object.
-- 
2.11.0

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

[PATCH 4/6] drm: include types.h from drm_hdcp.h

[Jani Nikula]

Make it easier to drop drmP.h includes.

Cc: Sam Ravnborg 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Signed-off-by: Jani Nikula 
---
 include/drm/drm_hdcp.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h
index a6de09c5e47f..d6dfef8cff6a 100644
--- a/include/drm/drm_hdcp.h
+++ b/include/drm/drm_hdcp.h
@@ -9,6 +9,8 @@
 #ifndef _DRM_HDCP_H_INCLUDED_
 #define _DRM_HDCP_H_INCLUDED_
 
+#include 
+
 /* Period of hdcp checks (to ensure we're still authenticated) */
 #define DRM_HDCP_CHECK_PERIOD_MS   (128 * 16)
 
-- 
2.11.0

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

[PATCH 1/6] drm: include drm_device.h from drm_legacy.h

[Jani Nikula]

Make it easier to drop drmP.h includes.

Cc: Sam Ravnborg 
Cc: Daniel Vetter 
Cc: Laurent Pinchart 
Signed-off-by: Jani Nikula 
---
 include/drm/drm_legacy.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/drm/drm_legacy.h b/include/drm/drm_legacy.h
index 8fad66f88e4f..743d7e70c896 100644
--- a/include/drm/drm_legacy.h
+++ b/include/drm/drm_legacy.h
@@ -2,6 +2,7 @@
 #define __DRM_DRM_LEGACY_H__
 
 #include 
+#include 
 
 /*
  * Legacy driver interfaces for the Direct Rendering Manager
-- 
2.11.0

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

Re: [PATCH 0/6] drm/i915: drmP.h include removal w/ drm prep work

[Jani Nikula]

On Thu, 27 Dec 2018, Jani Nikula  wrote:
> First make some drm headers self-contained, removing the implicit
> dependency on a previous drmP.h include. Then remove all drmP.h includes
> from drm/i915.
>
> Inspired by Sam's series [1]. Theres a one line trivial conflict between
> that one and this series in drm_file.h (patch 3), but I'm keeping this
> series self-contained. Should be easy enough to resolve.

[1] https://patchwork.freedesktop.org/series/54464/

>
> I'm fine with merging the first 5 through either drm-misc or drm-intel,
> but I'd rather merge the last one through drm-intel.
>
> BR,
> Jani.
>
> Cc: Sam Ravnborg 
> Cc: Daniel Vetter 
> Cc: Laurent Pinchart 
>
>
> Jani Nikula (6):
>   drm: include drm_device.h from drm_legacy.h
>   drm: include kernel.h and agp_backend.h from intel-gtt.h
>   drm: include idr.h from drm_file.h
>   drm: include types.h from drm_hdcp.h
>   drm: include drm_file.h from drm_syncobj.h
>   drm/i915: drop all drmP.h includes
>
>  drivers/gpu/drm/i915/dvo.h | 1 -
>  drivers/gpu/drm/i915/i915_drv.c| 1 -
>  drivers/gpu/drm/i915/i915_drv.h| 2 +-
>  drivers/gpu/drm/i915/i915_gem.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_context.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_evict.c  | 1 -
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_fence_reg.c  | 1 -
>  drivers/gpu/drm/i915/i915_gem_gtt.c| 1 -
>  drivers/gpu/drm/i915/i915_gem_internal.c   | 1 -
>  drivers/gpu/drm/i915/i915_gem_object.h | 3 ++-
>  drivers/gpu/drm/i915/i915_gem_shrinker.c   | 1 -
>  drivers/gpu/drm/i915/i915_gem_stolen.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_tiling.c | 1 -
>  drivers/gpu/drm/i915/i915_gem_userptr.c| 1 -
>  drivers/gpu/drm/i915/i915_ioc32.c  | 1 -
>  drivers/gpu/drm/i915/i915_irq.c| 1 -
>  drivers/gpu/drm/i915/i915_suspend.c| 1 -
>  drivers/gpu/drm/i915/i915_trace.h  | 1 -
>  drivers/gpu/drm/i915/intel_acpi.c  | 1 -
>  drivers/gpu/drm/i915/intel_atomic.c| 1 -
>  drivers/gpu/drm/i915/intel_atomic_plane.c  | 1 -
>  drivers/gpu/drm/i915/intel_audio.c | 1 -
>  drivers/gpu/drm/i915/intel_bios.c  | 1 -
>  drivers/gpu/drm/i915/intel_connector.c | 1 -
>  drivers/gpu/drm/i915/intel_crt.c   | 1 -
>  drivers/gpu/drm/i915/intel_display.c   | 1 -
>  drivers/gpu/drm/i915/intel_dp.c| 1 -
>  drivers/gpu/drm/i915/intel_dp_mst.c| 1 -
>  drivers/gpu/drm/i915/intel_dsi.h   | 1 -
>  drivers/gpu/drm/i915/intel_dsi_vbt.c   | 1 -
>  drivers/gpu/drm/i915/intel_dvo.c   | 1 -
>  drivers/gpu/drm/i915/intel_fbdev.c | 1 -
>  drivers/gpu/drm/i915/intel_frontbuffer.c   | 1 -
>  drivers/gpu/drm/i915/intel_hdcp.c  | 1 -
>  drivers/gpu/drm/i915/intel_hdmi.c  | 1 -
>  drivers/gpu/drm/i915/intel_hotplug.c   | 1 -
>  drivers/gpu/drm/i915/intel_i2c.c   | 1 -
>  drivers/gpu/drm/i915/intel_lrc.c   | 1 -
>  drivers/gpu/drm/i915/intel_lvds.c  | 1 -
>  drivers/gpu/drm/i915/intel_mocs.h  | 1 -
>  drivers/gpu/drm/i915/intel_opregion.c  | 1 -
>  drivers/gpu/drm/i915/intel_overlay.c   | 1 -
>  drivers/gpu/drm/i915/intel_psr.c   | 1 -
>  drivers/gpu/drm/i915/intel_ringbuffer.c| 1 -
>  drivers/gpu/drm/i915/intel_sdvo.c  | 1 -
>  drivers/gpu/drm/i915/intel_sprite.c| 1 -
>  drivers/gpu/drm/i915/intel_tv.c| 1 -
>  drivers/gpu/drm/i915/intel_vdsc.c  | 1 -
>  drivers/gpu/drm/i915/vlv_dsi.c | 1 -
>  include/drm/drm_file.h | 1 +
>  include/drm/drm_hdcp.h | 2 ++
>  include/drm/drm_legacy.h   | 1 +
>  include/drm/drm_syncobj.h  | 4 +++-
>  include/drm/intel-gtt.h| 3 +++
>  56 files changed, 13 insertions(+), 52 deletions(-)

-- 
Jani Nikula, Intel Open Source Graphics Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/i915_request.h: Remove duplicate header

[Chris Wilson]

Quoting Brajeswar Ghosh (2018-12-25 13:23:40)
> Remove i915_scheduler.h which is included more than once
> 
> Signed-off-by: Brajeswar Ghosh 

Thanks for the patch, pushed to dinq.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109161] Kernel crash shortly after gnome-shell login - refcount_t: increment on 0; use-after-free

[bugzilla-daemon]

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

Bug ID: 109161
   Summary: Kernel crash shortly after gnome-shell login -
refcount_t: increment on 0; use-after-free
   Product: DRI
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: yan...@declera.com

Fedora rawhide
4.21.0-0.rc0.git1.1.fc30.x86_64 ~= linus a5f2bd479f58

[   12.777868] [drm] initializing kernel modesetting (POLARIS11 0x1002:0x67EF
0x1682:0x9460 0xCF).

[   68.593291] amdgpu :0a:00.0: 38144057 unpin not necessary
[   68.795444] [ cut here ]
[   68.800304] refcount_t: increment on 0; use-after-free.
[   68.805649] WARNING: CPU: 12 PID: 1907 at lib/refcount.c:153
refcount_inc_checked+0x26/0x30
[   68.814053] Modules linked in: nfsv3 nfs_acl nfs lockd grace fscache pppoe
pppox ppp_synctty ppp_async ppp_generic slhc fuse iptable_mangle xt_CHECKSUM
iptable_nat ipt_MASQUERADE nf_nat_ipv4 nf_nat xt_conntrack nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 tun bridge stp llc ebtable_filter ebtables
ip6table_filter ip6_tables ib_isert iscsi_target_mod ib_srpt target_core_mod
ib_srp scsi_transport_srp rpcrdma rdma_ucm ib_iser rdma_cm ib_umad ib_ipoib
iw_cm libiscsi ib_cm scsi_transport_iscsi mlx4_ib ib_uverbs ib_core mlx4_en
it87 hwmon_vid sunrpc btrfs xor zstd_compress raid6_pq libcrc32c
zstd_decompress xxhash vfat fat edac_mce_amd kvm_amd kvm irqbypass pl2303
joydev snd_hda_codec_realtek ftdi_sio snd_hda_codec_generic ledtrig_audio
snd_hda_codec_hdmi snd_hda_intel snd_hda_codec ppdev snd_hda_core snd_hwdep
snd_seq crct10dif_pclmul raid1 snd_seq_device mlx4_core crc32_pclmul snd_pcm
wmi_bmof snd_timer ghash_clmulni_intel parport_serial mxm_wmi snd igb
parport_pc sp5100_tco devlink soundcore
[   68.814090]  ccp parport k10temp i2c_piix4 atlantic dca gpio_amdpt
gpio_generic amdgpu hid_logitech_hidpp chash amd_iommu_v2 gpu_sched
i2c_algo_bit ttm drm_kms_helper drm crc32c_intel nvme hid_logitech_dj nvme_core
wmi pinctrl_amd i2c_dev
[   68.903020] CPU: 12 PID: 1907 Comm: gnome-shell Not tainted
4.21.0-0.rc0.git1.1.fc30.x86_64 #1
[   68.903021] Hardware name: Gigabyte Technology Co., Ltd. X470 AORUS ULTRA
GAMING/X470 AORUS ULTRA GAMING-CF, BIOS F3g 05/10/2018
[   68.903023] RIP: 0010:refcount_inc_checked+0x26/0x30
[   68.903024] Code: 0f 1f 40 00 e8 ab ff ff ff 84 c0 74 01 c3 80 3d 74 62 3b
01 00 75 f6 48 c7 c7 38 32 35 a9 c6 05 64 62 3b 01 01 e8 7e 4d b9 ff <0f> 0b c3
0f 1f 80 00 00 00 00 8b 06 83 f8 ff 74 20 31 c9 39 f8 89
[   68.903025] RSP: 0018:adf1c8b8bb10 EFLAGS: 00010282
[   68.903026] RAX:  RBX: 98d381b58050 RCX:

[   68.903027] RDX: 98d3be7ddc40 RSI: 98d3be7d6c28 RDI:
98d3be7d6c28
[   68.903028] RBP: 98d381b5807c R08: 0002 R09:

[   68.903029] R10:  R11:  R12:
98d3a9fa2d08
[   68.903030] R13: 98d381b580f8 R14: 98d381b588f8 R15:
98d3a9fa3160
[   68.903035] FS:  7f05a5b04d00() GS:98d3be60()
knlGS:
[   68.903036] CS:  0010 DS:  ES:  CR0: 80050033
[   68.903037] CR2: 7f0538b3b00c CR3: 0007f465c000 CR4:
003406e0
[   68.903037] Call Trace:
[   68.903042]  ttm_bo_add_to_lru+0xab/0x160 [ttm]
[   68.903047]  ttm_eu_backoff_reservation+0x4e/0xe0 [ttm]
[   69.044521]  amdgpu_gem_object_close+0xf3/0x1e0 [amdgpu]
[   69.044540]  drm_gem_object_release_handle+0x7b/0xc0 [drm]
[   69.055515]  drm_gem_handle_delete+0x61/0x90 [drm]
[   69.055523]  ? drm_mode_destroy_dumb+0x40/0x40 [drm]
[   69.065443]  drm_ioctl_kernel+0xa9/0xf0 [drm]
[   69.065452]  drm_ioctl+0x201/0x3a0 [drm]
[   69.073783]  ? drm_mode_destroy_dumb+0x40/0x40 [drm]
[   69.073787]  ? sched_clock+0x5/0x10
[   69.082443]  ? sched_clock_cpu+0xc/0xb0
[   69.086349]  ? lockdep_hardirqs_on+0xed/0x180
[   69.086379]  amdgpu_drm_ioctl+0x49/0x80 [amdgpu]
[   69.086384]  do_vfs_ioctl+0xa5/0x6f0
[   69.099131]  ksys_ioctl+0x60/0x90
[   69.099135]  __x64_sys_ioctl+0x16/0x20
[   69.106318]  do_syscall_64+0x60/0x1f0
[   69.110043]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[   69.115181] RIP: 0033:0x7f05a965c2fb
[   69.118817] Code: 0f 1e fa 48 8b 05 8d 9b 0c 00 64 c7 00 26 00 00 00 48 c7
c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01
f0 ff ff 73 01 c3 48 8b 0d 5d 9b 0c 00 f7 d8 64 89 01 48
[   69.118818] RSP: 002b:7ffd2a76dea8 EFLAGS: 0246 ORIG_RAX:
0010
[   69.118819] RAX: ffda RBX: 5627173c6080 RCX:
7f05a965c2fb
[   69.118820] RDX: 7ffd2a76dee4 RSI: c00464b4 RDI:
000b
[   69.118820] RBP: 7ffd2a76dee4 R08: 562717496a20 R09:
0005
[   69.118821] R10: 0011 R11: 0246 R12:

Re: [PATCH] drm: rcar-du: Remove inclusion of drmP.h

[Daniel Vetter]

On Thu, Dec 27, 2018 at 12:12:06PM +0200, Laurent Pinchart wrote:
> The DRM kernel API used to be defined in a handful of headers, pulled in
> through drmP.h. It has since been split in multiple headers for the
> different DRM components, and drmP.h turned into a legacy header that
> just pulls in most of the DRM kernel API (and a large number of other
> miscellaneous kernel headers).
> 
> In order to speed up compilation, replace inclusion of drmP.h with only
> the required headers. It turns out that the rcar-du-drm driver already
> includes most of the necessary headers, so the change is simple.
> 
> While at it, remove unneeder inclusion of other headers, and unneeded
> forward declarations of structures.
> 
> Signed-off-by: Laurent Pinchart 

Nice, first driver where all that header cleanup work finally lead
somewhere useful!

Acked-by: Daniel Vetter 
> ---
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +
>  drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 --
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_plane.c   | 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_plane.h   | 3 +--
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 -
>  drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 3 +--
>  11 files changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index 40b7f17159b0..771b460c7216 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> index ec47f164e69b..bcb35b0b7612 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> @@ -14,7 +14,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  
>  #include 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> index eef86c48edad..d1f305694367 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> @@ -17,7 +17,6 @@
>  #include 
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> index 752617c73c73..6c187d0bf7c2 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
> @@ -20,6 +20,7 @@
>  struct clk;
>  struct device;
>  struct drm_device;
> +struct drm_property;
>  struct rcar_du_device;
>  
>  #define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK   BIT(0)  /* Per-CRTC IRQ and 
> clock */
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> index a123c28ea6ed..f16209499117 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
> @@ -9,7 +9,6 @@
>  
>  #include 
>  
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> index ce3cbc85695e..552f2a02e5b5 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
> @@ -10,10 +10,8 @@
>  #ifndef __RCAR_DU_ENCODER_H__
>  #define __RCAR_DU_ENCODER_H__
>  
> -#include 
>  #include 
>  
> -struct drm_panel;
>  struct rcar_du_device;
>  
>  struct rcar_du_encoder {
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index d8ef3a86b0b2..e4b248e368d6 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -7,7 +7,6 @@
>   * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 39d5ae3fdf72..fa6b9aabc832 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -7,7 +7,6 @@
>   * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
>   */
>  
> -#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> index 2f223a4c1d33..81bbf207ad0e 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
> @@ -10,8 +10,7 @@
>  #ifndef __RCAR_DU_PLANE_H__
>  #define __RCAR_DU_PLANE_H__
>  
> -#include 
> -#include 
> +#include 
>  
>  struct rcar_du_format_info;
>  struct rcar_du_group;
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
> 

Re: [PATCH v1 3/7] drm: move drm_can_sleep() to drm_util.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:49PM +0100, Sam Ravnborg wrote:
> Move drm_can_sleep() out of drmP.h to allow users
> to get rid of the drmP.h include.
> 
> There was no header file that was a good match for this helper function.
> So add this to drm_util with the relevant includes.
> 
> Add include of drm_util.h to all users.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Alex Deucher 
> Cc: "Christian König" 
> Cc: "David (ChunMing) Zhou" 
> Cc: Gerd Hoffmann 
> Cc: Rob Clark 
> Cc: Tomi Valkeinen 
> Cc: Eric Anholt 
> ---
>  drivers/gpu/drm/amd/amdgpu/atom.c   |  2 ++
>  drivers/gpu/drm/ast/ast_fb.c|  1 +
>  drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  1 +
>  drivers/gpu/drm/drm_flip_work.c |  1 +
>  drivers/gpu/drm/mgag200/mgag200_fb.c|  1 +
>  drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c|  1 +
>  drivers/gpu/drm/omapdrm/omap_fbdev.c|  1 +
>  drivers/gpu/drm/qxl/qxl_cmd.c   |  2 ++
>  drivers/gpu/drm/radeon/atom.c   |  2 ++
>  drivers/gpu/drm/radeon/radeon_legacy_encoders.c |  1 +
>  drivers/gpu/drm/vc4/vc4_drv.h   |  1 +
>  include/drm/drmP.h  |  8 
>  include/drm/drm_util.h  | 13 +
>  13 files changed, 27 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c 
> b/drivers/gpu/drm/amd/amdgpu/atom.c
> index e9934de1b9cf..dd30f4e61a8c 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atom.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atom.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ATOM_DEBUG
>  
>  #include "atom.h"
> diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
> index de26df0c6044..fb56fe848e81 100644
> --- a/drivers/gpu/drm/ast/ast_fb.c
> +++ b/drivers/gpu/drm/ast/ast_fb.c
> @@ -38,6 +38,7 @@
>  
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "ast_drv.h"
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c 
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 68ab1821e15b..1544fa55d1ff 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -10,6 +10,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/drm_flip_work.c b/drivers/gpu/drm/drm_flip_work.c
> index 12dea16f22a8..3da3bf5af405 100644
> --- a/drivers/gpu/drm/drm_flip_work.c
> +++ b/drivers/gpu/drm/drm_flip_work.c
> @@ -22,6 +22,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  /**
> diff --git a/drivers/gpu/drm/mgag200/mgag200_fb.c 
> b/drivers/gpu/drm/mgag200/mgag200_fb.c
> index 30726c9fe28c..6893934b26c0 100644
> --- a/drivers/gpu/drm/mgag200/mgag200_fb.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_fb.c
> @@ -12,6 +12,7 @@
>   */
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c 
> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> index 96c2b828dba4..fa2d1d8995ee 100644
> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_smp.c
> @@ -16,6 +16,7 @@
>   * this program.  If not, see .
>   */
>  
> +#include 
>  
>  #include "mdp5_kms.h"
>  #include "mdp5_smp.h"
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c 
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> index aee99194499f..851c59f07eb1 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -16,6 +16,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  
>  #include "omap_drv.h"
> diff --git a/drivers/gpu/drm/qxl/qxl_cmd.c b/drivers/gpu/drm/qxl/qxl_cmd.c
> index 208af9f37914..d17676824377 100644
> --- a/drivers/gpu/drm/qxl/qxl_cmd.c
> +++ b/drivers/gpu/drm/qxl/qxl_cmd.c
> @@ -25,6 +25,8 @@
>  
>  /* QXL cmd/ring handling */
>  
> +#include 
> +
>  #include "qxl_drv.h"
>  #include "qxl_object.h"
>  
> diff --git a/drivers/gpu/drm/radeon/atom.c b/drivers/gpu/drm/radeon/atom.c
> index e55cbeee7a53..ac98ad561870 100644
> --- a/drivers/gpu/drm/radeon/atom.c
> +++ b/drivers/gpu/drm/radeon/atom.c
> @@ -27,6 +27,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #define ATOM_DEBUG
>  
>  #include "atom.h"
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c 
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 222a1fa41d7c..7e3257e8fd56 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -24,6 +24,7 @@
>   *  Alex Deucher
>   */
>  #include 
> +#include 
>  #include 
>  #include 
>  #include "radeon.h"
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index bd6ef1f31822..79c6bcc4f509 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -9,6 +9,7 

Re: [PATCH v1 2/7] drm: move DRM_SWITCH_POWER defines to drm_device.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:48PM +0100, Sam Ravnborg wrote:
> Move DRM_SWITCH_POWER out of drmP.h to allow users
> to get rid of the drmP include.
> 
> DRM_SWITCH_POWER defines are used in combination
> with drm_device.switch_power_state.
> 
> Move the DRM_SWITCH_POWER defines to the file where
> drm_device.switch_power_state is defined.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> ---
>  include/drm/drmP.h   | 5 -
>  include/drm/drm_device.h | 9 +
>  2 files changed, 9 insertions(+), 5 deletions(-)
> 
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index b6b8436b5123..2ba786820052 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -95,11 +95,6 @@ struct dma_buf_attachment;
>  struct pci_dev;
>  struct pci_controller;
>  
> -#define DRM_SWITCH_POWER_ON 0
> -#define DRM_SWITCH_POWER_OFF 1
> -#define DRM_SWITCH_POWER_CHANGING 2
> -#define DRM_SWITCH_POWER_DYNAMIC_OFF 3
> -
>  /* returns true if currently okay to sleep */
>  static inline bool drm_can_sleep(void)
>  {
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index 42411b3ea0c8..c3da194d25f9 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -24,6 +24,13 @@ struct inode;
>  struct pci_dev;
>  struct pci_controller;
>  
> +
> +/* Used by drm_device.switch_power_state */
> +#define DRM_SWITCH_POWER_ON 0
> +#define DRM_SWITCH_POWER_OFF 1
> +#define DRM_SWITCH_POWER_CHANGING 2
> +#define DRM_SWITCH_POWER_DYNAMIC_OFF 3

Since this isn't uapi it'd be nice to change it to an enum, which we can
then properly kernel-doc and make your references links in the resulting
html. Otherwise lgtm.

Would need an include stanza for drm_device.h in drm-internals.rst, plus a
bit of kernel-doc cleanup in here I think (which iirc is why I didn't yet
do this).
-Daniel

> +
>  /**
>   * DRM device structure. This structure represent a complete card that
>   * may contain multiple heads.
> @@ -222,6 +229,8 @@ struct drm_device {
>   struct idr object_name_idr;
>   struct drm_vma_offset_manager *vma_offset_manager;
>   /*@} */
> +
> + /* See DRM_SWITCH_POWER defines */
>   int switch_power_state;
>  
>   /**
> -- 
> 2.12.0
> 

-- 
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 v1 1/7] drm: move DRM_IF_VERSION to drm_internal.h

[Daniel Vetter]

On Wed, Dec 26, 2018 at 10:03:47PM +0100, Sam Ravnborg wrote:
> Move DRM_IF_VERSION out of drmP.h to allow users
> to get rid of the drmP include.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: David Airlie 
> Cc: Daniel Vetter 

Applied to drm-misc-next, thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_internal.h | 2 ++
>  include/drm/drmP.h | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 51e06defc8d8..e9374cd43610 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -26,6 +26,8 @@
>  #define DRM_IF_MAJOR 1
>  #define DRM_IF_MINOR 4
>  
> +#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
> +
>  struct drm_prime_file_private;
>  struct dma_buf;
>  
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 05350424a4d3..b6b8436b5123 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -95,8 +95,6 @@ struct dma_buf_attachment;
>  struct pci_dev;
>  struct pci_controller;
>  
> -#define DRM_IF_VERSION(maj, min) (maj << 16 | min)
> -
>  #define DRM_SWITCH_POWER_ON 0
>  #define DRM_SWITCH_POWER_OFF 1
>  #define DRM_SWITCH_POWER_CHANGING 2
> -- 
> 2.12.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 109122] blank screen on rx580 starting with kernel 4.19.9

[bugzilla-daemon]

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

--- Comment #3 from Matej Lach  ---
I can confirm this bug is indeed present. 
Worth noting that the screen is only blank on the laptop built-in display,
(after KMS), external monitors work fine. 

Adding `amdgpu.dc=0` to the kernel parameters resolves the issue for me, but
this was not necessary before kernel 4.19.9, so it seems like a regression. [1]
seems related.

1 - https://bugzilla.kernel.org/show_bug.cgi?id=200695

-- 
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: [RFC PATCH 1/2] drm/fb-helper: Bring back workaround for bugs of SDL 1.2

[Daniel Vetter]

On Wed, Dec 26, 2018 at 05:11:23PM +0500, Ivan Mironov wrote:
> SDL 1.2 sets all fields related to the pixel format to zero in some
> cases[1]. Prior to commit db05c48197759 ("drm: fb-helper: Reject all
> pixel format changing requests"), there was an unintentional workaround
> for this that existed for more than a decade. First in device-specific DRM
> drivers, then here in drm_fb_helper.c.
> 
> Previous code containing this workaround just ignores pixel format fields
> from userspace code. Not a good thing either, as this way, driver may
> silently use pixel format different from what client actually requested,
> and this in turn will lead to displaying garbage on the screen. I think
> that returning EINVAL to userspace in this particular case is the right
> option, so I decided to left code from problematic commit untouched
> instead of just reverting it entirely.
> 
> [1] SDL 1.2.15 source code, src/video/fbcon/SDL_fbvideo.c,
> FB_SetVideoMode()
> 
> Reported-by: saahriktu 
> Suggested-by: saahriktu 
> Fixes: db05c48197759 ("drm: fb-helper: Reject all pixel format changing 
> requests")
> Signed-off-by: Ivan Mironov 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 146 
>  1 file changed, 93 insertions(+), 53 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index d3af098b0922..aff576c3c4fb 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1621,6 +1621,64 @@ static bool drm_fb_pixel_format_equal(const struct 
> fb_var_screeninfo *var_1,
>  var_1->transp.msb_right == var_2->transp.msb_right;
>  }
>  
> +static void drm_fb_helper_fill_pixel_fmt(struct fb_var_screeninfo *var,
> +  u8 depth)
> +{
> + switch (depth) {
> + case 8:
> + var->red.offset = 0;
> + var->green.offset = 0;
> + var->blue.offset = 0;
> + var->red.length = 8; /* 8bit DAC */
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 15:
> + var->red.offset = 10;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 5;
> + var->blue.length = 5;
> + var->transp.offset = 15;
> + var->transp.length = 1;
> + break;
> + case 16:
> + var->red.offset = 11;
> + var->green.offset = 5;
> + var->blue.offset = 0;
> + var->red.length = 5;
> + var->green.length = 6;
> + var->blue.length = 5;
> + var->transp.offset = 0;
> + break;
> + case 24:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 0;
> + var->transp.length = 0;
> + break;
> + case 32:
> + var->red.offset = 16;
> + var->green.offset = 8;
> + var->blue.offset = 0;
> + var->red.length = 8;
> + var->green.length = 8;
> + var->blue.length = 8;
> + var->transp.offset = 24;
> + var->transp.length = 8;
> + break;
> + default:
> + break;
> + }
> +}
> +
>  /**
>   * drm_fb_helper_check_var - implementation for _ops.fb_check_var
>   * @var: screeninfo to check
> @@ -1654,6 +1712,40 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo 
> *var,
>   return -EINVAL;
>   }
>  
> + /*
> +  * Workaround for SDL 1.2, which is known to be setting all pixel format
> +  * fields values to zero in some cases. We treat this situation as a
> +  * kind of "use some reasonable autodetected values".
> +  */
> + if (!var->red.offset && !var->green.offset&&
> + !var->blue.offset&& !var->transp.offset   &&
> + !var->red.length && !var->green.length&&
> + !var->blue.length&& !var->transp.length   &&
> + !var->red.msb_right  && !var->green.msb_right &&
> + !var->blue.msb_right && !var->transp.msb_right) {
> + u8 depth;
> +
> + /*
> +  * There is no way to guess the right value for depth when
> +  * bpp is 16 or 32. So we just restore the behaviour previously
> +  * introduced here by commit 785b93ef8c309. In fact, this was
> +  * implemented even earlier in various device drivers.
> +  */
> + switch (var->bits_per_pixel) {
> + case 16:
> + depth = 15;
> + break;
> + case 32:
> +  

Re: [PATCH] drm: Put damage blob when destroy plane state

[Daniel Vetter]

On Wed, Dec 26, 2018 at 09:50:44AM -0800, Deepak Singh Rawat wrote:
> On Tue, 2018-12-25 at 07:01 -0800, Thomas Hellstrom wrote:
> > On Mon, 2018-12-24 at 11:49 +0100, Daniel Vetter wrote:
> > > On Fri, Dec 21, 2018 at 8:56 PM Thomas Hellstrom <
> > > thellst...@vmware.com> wrote:
> > > > Reviewed-by: Thomas Hellstrom 
> > > > 
> > > > Daniel, Dave, could you help try to get this patch in -next
> > > > before
> > > > the
> > > > merge window. Otherwise people will start to experience random
> > > > kernel
> > > > crashes. I figure we don't want to wait until first -fixes pull
> > > > with
> > > > this.
> > > 
> > > Afaiui this will only blow up with new userspace on new kernels,
> > > that
> > > doesn't feel like rushing an updated -next out the door material to
> > > me.
> > 
> > Hmm, this was discovered when the drm-read igt test hit an OOPS, 
> > I guess when damage_clips is unintentionally Non-Null.
> > 
> > 
> > >  More concerning is why this fell through the cracks:
> > 
> > I agree. Sinc I'm on vacation a very quick answer. Will investigate
> > more thogroughly when we get back.
> > 
> > > - We have an igt, do those testcases not hit this bug?
> > 
> > The drm-read igt intermittently hit the bug.
> > 
> > 
> > > - Were the tests not run before you've sent out the pull?
> > 
> > No, and I guess that't the main culprit. The igt doesn't work well
> > with
> > vmwgfx, mostly because many tests are assuming gem functionality,
> > there
> > fore we doesn't run them regularly, but mostly a pre-commit testsuite
> > that focuses more on rendering correctness than modesetting
> > functionality. That said, Deepak has over time put quite an effort
> > into
> > making at least part of that test suite run well with vmwgfx, but I
> > didn't consider it for this pull request. Will make sure we do in the
> > future for core drm changes.
> > 
> > > - The merged version doesn't seem to match any of the versions I've
> > > found on dri-devel, I guess should have been resend when there was
> > > conflicts?
> > 
> > Yes, I think there was at least one trivial merge conflict and a
> > couple
> > of minor checkpatch.pl fixups in the pull request. Typically for
> > vmwgfx
> > we don't resend the resulting patches if there are minor changes like
> > that and they are reviewed internally. Need to get back to you about
> > exactly where in the process we failed here.
> 
> I did ran igt after rebasing with upstream drm-next but only kms tests
> and didn't saw any problem. We have glretrace running continuously with
> rebooting VM's every time it runs and it too didn't failed so didn't
> suspected anything wrong with what I sent. Unfortunately we don't run
> igt continuously so I guess that is what we should work on.
> 
> I am yet to investigate why only drm_read failed. Although from stack
> trace I can see it is failing when set_config is called from vmwgfx
> fb_dev driver.

Yeah, drm_read failing isn't really the testcase I expected to blow up at
all here. Sounds like an intriguing story at least on what exactly is
going wrong here ...
-Daniel

> 
> > 
> > Thanks,
> > Thomas
> > 
> > 
> > 
> > > - Some other crack in the matrix?
> > > 
> > > > Thanks,
> > > > Thomas
> > > > 
> > > > 
> > > > On Fri, 2018-12-21 at 11:35 -0800, Deepak Rawat wrote:
> > > > > Somehow the code to put the damage blob on destroy plane state
> > > > > and
> > > > > set
> > > > > the blob to NULL when duplicate plane state was not merged. May
> > > > > be
> > > > > because the files are refactored since the patch was written.
> > > > > With
> > > > > this
> > > > > fix add those.
> > > > > 
> > > > > Cc: Daniel Vetter 
> > > > > Signed-off-by: Deepak Rawat 
> > > 
> > > Needs a Fixes: tag referencing the broken commit, pls remember to
> > > add
> > > these anytime you fix an issue with a commit. I'll add that and
> > > push
> > > it to drm-misc-next-fixes.
> 
> Thanks Daniel for this. Will make sure in future.
> 
> > > 
> > > Thanks, Daniel
> > > 
> > > > > ---
> > > > >  drivers/gpu/drm/drm_atomic_state_helper.c | 3 +++
> > > > >  1 file changed, 3 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
> > > > > b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > > > index 3ba996069d69..709355c6bac6 100644
> > > > > --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> > > > > +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> > > > > @@ -241,6 +241,7 @@ void
> > > > > __drm_atomic_helper_plane_duplicate_state(struct drm_plane
> > > > > *plane,
> > > > > 
> > > > >   state->fence = NULL;
> > > > >   state->commit = NULL;
> > > > > + state->fb_damage_clips = NULL;
> > > > >  }
> > > > >  EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state);
> > > > > 
> > > > > @@ -285,6 +286,8 @@ void
> > > > > __drm_atomic_helper_plane_destroy_state(struct drm_plane_state
> > > > > *state)
> > > > > 
> > > > >   if (state->commit)
> > > > >   drm_crtc_commit_put(state->commit);
> > > > > +
> > > > > + 

Re: [PATCH 2/3] drm/amd: validate user pitch alignment

[Michel Dänzer]

On 2018-12-23 10:44 p.m., Yu Zhao wrote:
> On Fri, Dec 21, 2018 at 10:07:26AM +0100, Michel Dänzer wrote:
>> On 2018-12-21 4:10 a.m., Yu Zhao wrote:
>>> Userspace may request pitch alignment that is not supported by GPU.
>>> Some requests 32, but GPU ignores it and uses default 64 when cpp is
>>> 4. If GEM object is allocated based on the smaller alignment, GPU
>>> DMA will go out of bound.
>>>
>>> For GPU that does frame buffer compression, DMA writing out of bound
>>> memory will cause memory corruption.
>>>
>>> Signed-off-by: Yu Zhao 
>>> ---
>>>  drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 9 +
>>>  1 file changed, 9 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c 
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> index e309d26170db..755daa332f8a 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_display.c
>>> @@ -527,6 +527,15 @@ amdgpu_display_user_framebuffer_create(struct 
>>> drm_device *dev,
>>> struct drm_gem_object *obj;
>>> struct amdgpu_framebuffer *amdgpu_fb;
>>> int ret;
>>> +   struct amdgpu_device *adev = dev->dev_private;
>>> +   int cpp = drm_format_plane_cpp(mode_cmd->pixel_format, 0);
>>> +   int pitch = amdgpu_align_pitch(adev, mode_cmd->width, cpp, false);
>>
>> Also, this needs to use mode_cmd->pitches[0] instead of mode_cmd->width,
>> otherwise it'll spuriously fail for larger but well-aligned pitches.
> 
> Actually mode_cmd->pitches[0] is aligned mode_cmd->width multiplied
> by cpp. So we can't just use mode_cmd->pitches[0].

Use mode_cmd->pitches[0] / cpp then?


> And I'm not sure if the hardware works with larger alignment

It does.

> (it certainly ignores smaller alignment).

Yeah, pitch must be >= width. Maybe this patch could check that as well.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/drm_drv.c: Remove duplicate header

[Daniel Vetter]

On Mon, Dec 24, 2018 at 08:06:36PM +0530, Brajeswar Ghosh wrote:
> Remove drm_crtc_internal.h which is included more than once
> 
> Signed-off-by: Brajeswar Ghosh 

Applied, thanks for your patch.
-Daniel

> ---
>  drivers/gpu/drm/drm_drv.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 4126bb6e1a4a..75f4e6bf67ca 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -41,7 +41,6 @@
>  #include "drm_crtc_internal.h"
>  #include "drm_legacy.h"
>  #include "drm_internal.h"
> -#include "drm_crtc_internal.h"
>  
>  /*
>   * drm_debug: Enable debug output.
> -- 
> 2.17.1
> 
> ___
> 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] drm: rcar-du: Remove inclusion of drmP.h

[Laurent Pinchart]

The DRM kernel API used to be defined in a handful of headers, pulled in
through drmP.h. It has since been split in multiple headers for the
different DRM components, and drmP.h turned into a legacy header that
just pulls in most of the DRM kernel API (and a large number of other
miscellaneous kernel headers).

In order to speed up compilation, replace inclusion of drmP.h with only
the required headers. It turns out that the rcar-du-drm driver already
includes most of the necessary headers, so the change is simple.

While at it, remove unneeder inclusion of other headers, and unneeded
forward declarations of structures.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c| 1 -
 drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 1 -
 drivers/gpu/drm/rcar-du/rcar_du_drv.c | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_drv.h | 1 +
 drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 --
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.c   | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_plane.h   | 3 +--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 1 -
 drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 3 +--
 11 files changed, 3 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 40b7f17159b0..771b460c7216 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index ec47f164e69b..bcb35b0b7612 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -14,7 +14,6 @@
 #include 
 #include 
 
-#include 
 #include 
 
 #include 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index eef86c48edad..d1f305694367 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h 
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 752617c73c73..6c187d0bf7c2 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -20,6 +20,7 @@
 struct clk;
 struct device;
 struct drm_device;
+struct drm_property;
 struct rcar_du_device;
 
 #define RCAR_DU_FEATURE_CRTC_IRQ_CLOCK BIT(0)  /* Per-CRTC IRQ and clock */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index a123c28ea6ed..f16209499117 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -9,7 +9,6 @@
 
 #include 
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h 
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index ce3cbc85695e..552f2a02e5b5 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -10,10 +10,8 @@
 #ifndef __RCAR_DU_ENCODER_H__
 #define __RCAR_DU_ENCODER_H__
 
-#include 
 #include 
 
-struct drm_panel;
 struct rcar_du_device;
 
 struct rcar_du_encoder {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index d8ef3a86b0b2..e4b248e368d6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -7,7 +7,6 @@
  * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 39d5ae3fdf72..fa6b9aabc832 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -7,7 +7,6 @@
  * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index 2f223a4c1d33..81bbf207ad0e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -10,8 +10,7 @@
 #ifndef __RCAR_DU_PLANE_H__
 #define __RCAR_DU_PLANE_H__
 
-#include 
-#include 
+#include 
 
 struct rcar_du_format_info;
 struct rcar_du_group;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 4576119e..dec314a687e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -7,7 +7,6 @@
  * Contact: Laurent Pinchart (laurent.pinch...@ideasonboard.com)
  */
 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index e8c14dc5cb93..db232037f24a 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h

Re: [PATCH v1 6/7] drm: remove include of drmP.h from drm_modeset_helper.h

[Laurent Pinchart]

Hi Sam,

Thank you for the patch.

On Wednesday, 26 December 2018 23:03:52 EET Sam Ravnborg wrote:
> Fix fallout in various files/drivers by adding missing include files.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Alexey Brodkin 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: Maarten Lankhorst 
> Cc: Maxime Ripard 
> Cc: Sean Paul 
> Cc: Kieran Bingham 
> ---
>  drivers/gpu/drm/arc/arcpgu_sim.c | 1 +
>  drivers/gpu/drm/bridge/cdns-dsi.c| 2 ++
>  drivers/gpu/drm/drm_modeset_helper.c | 2 ++
>  drivers/gpu/drm/rcar-du/rcar_lvds.c  | 1 +
>  include/drm/drm_modeset_helper.h | 2 --
>  5 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c
> b/drivers/gpu/drm/arc/arcpgu_sim.c index 68629e614990..3b7556f62230 100644
> --- a/drivers/gpu/drm/arc/arcpgu_sim.c
> +++ b/drivers/gpu/drm/arc/arcpgu_sim.c
> @@ -14,6 +14,7 @@
>   *
>   */
> 
> +#include 
>  #include 
>  #include 
> 
> diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c
> b/drivers/gpu/drm/bridge/cdns-dsi.c index ce9496d13986..4b73d0969468 100644
> --- a/drivers/gpu/drm/bridge/cdns-dsi.c
> +++ b/drivers/gpu/drm/bridge/cdns-dsi.c
> @@ -8,11 +8,13 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/drivers/gpu/drm/drm_modeset_helper.c
> b/drivers/gpu/drm/drm_modeset_helper.c index f1c24ab0ef09..680cb6a5978c
> 100644
> --- a/drivers/gpu/drm/drm_modeset_helper.c
> +++ b/drivers/gpu/drm/drm_modeset_helper.c
> @@ -23,8 +23,10 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> 
>  /**
>   * DOC: aux kms helpers
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c index 173d7ad0b991..f1043458cbd8
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -10,6 +10,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> diff --git a/include/drm/drm_modeset_helper.h
> b/include/drm/drm_modeset_helper.h index efa337f03129..82ead67dfa36 100644
> --- a/include/drm/drm_modeset_helper.h
> +++ b/include/drm/drm_modeset_helper.h
> @@ -23,8 +23,6 @@
>  #ifndef __DRM_KMS_HELPER_H__
>  #define __DRM_KMS_HELPER_H__
> 
> -#include 

Please add forward declarations for all structures used as pointers in this 
file. We shouldn't rely on the files including drm_modeset_helper.h to provide 
definitions or declarations for those structures.

With that fixed,

Reviewed-by: Laurent Pinchart 

>  void drm_helper_move_panel_connectors_to_head(struct drm_device *);
> 
>  void drm_helper_mode_fill_fb_struct(struct drm_device *dev,

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH v1 4/7] drm: remove include of drmP.h from bridge/dw_hdmi.h

[Laurent Pinchart]

Hi Sam,

Thank you for the patch.

On Wednesday, 26 December 2018 23:03:50 EET Sam Ravnborg wrote:
> Add missing includes in dw_hdmi.h and
> fix fallout in drivers.
> 
> Signed-off-by: Sam Ravnborg 
> Cc: Archit Taneja 
> Cc: Andrzej Hajda 
> Cc: Laurent Pinchart 
> Cc: David Airlie 
> Cc: Daniel Vetter 
> Cc: Kieran Bingham 
> Cc: Fabio Estevam 
> Cc: Neil Armstrong 
> Cc: Maxime Ripard 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 4 
>  drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c  | 1 +
>  include/drm/bridge/dw_hdmi.h| 5 -
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index
> 8f9c8a6b46de..c61ec4caaa84 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c
> @@ -8,6 +8,10 @@
>   * it under the terms of the GNU General Public License version 2 as
>   * published by the Free Software Foundation.
>   */
> +
> +#include 
> +#include 
> +
>  #include 
> 
>  #include 
> diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c index 75490a3e0a2a..f5b07a2e3f59
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
> @@ -8,6 +8,7 @@
>   */
> 
>  #include 
> +#include 

Nitpicking, _ comes before u.

>  #include 
> 
>  #include 
> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index ccb5aa8468e0..b0218ee75a65 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -10,7 +10,10 @@
>  #ifndef __DW_HDMI__
>  #define __DW_HDMI__
> 
> -#include 
> +#include 

I think you can replace this with a forward declaration of struct 
platform_device. You will likely need to handle more fallout.

> +#include 
> +#include 

Please add forward definitions for structures used in this file and not 
defined in the above headers. I'm thinking about struct regmap and struct 
drm_encoder. They may be defined in headers included from the above three, or 
from headers included from files including dw_hdmi.h, but we shouldn't rely on 
that as it may change.

With this fixed,

Reviewed-by: Laurent Pinchart 

>  struct dw_hdmi;

-- 
Regards,

Laurent Pinchart



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

Re: [PATCH] backlight: (adp8870) fix a missing check for adp8870_write

[Sam Ravnborg]

Hi Kangjie

> adp8870_write() may fail. This fix checks if adp8870_write fails, and if
> so, returns its error code.
> 
> Signed-off-by: Kangjie Lu 
> ---
>  drivers/video/backlight/adp8870_bl.c | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/backlight/adp8870_bl.c 
> b/drivers/video/backlight/adp8870_bl.c
> index 8d50e0299578..79901fb4fcd1 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -811,9 +811,14 @@ static ssize_t 
> adp8870_bl_ambient_light_zone_store(struct device *dev,
>   if (!ret) {
>   reg_val &= ~(CFGR_BLV_MASK << CFGR_BLV_SHIFT);
>   reg_val |= (val - 1) << CFGR_BLV_SHIFT;
> - adp8870_write(data->client, ADP8870_CFGR, reg_val);
> - }
> - mutex_unlock(>lock);
> + ret = adp8870_write(data->client,
> + ADP8870_CFGR, reg_val);
> + if (ret) {
> + mutex_unlock(>lock);
> + return ret;
> + }
> + }   else
> + mutex_unlock(>lock);
>   }

Something looks wrong with the indent.
If you have braces around first part of if () then use
barces also after else. Then it is easier to follow the code.
In this case please consider another approach where you
have only a single mutex_unlock() both in the good and
in the error case.

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

答复: [PATCH] gpu: drm: fix an improper check of amdgpu_bo_create_kernel

[Qu, Jim]

Comments in line.

Thanks
JimQu

发件人: amd-gfx  代表 Kangjie Lu 

发送时间: 2018年12月26日 14:23
收件人: k...@umn.edu
抄送: Zhou, David(ChunMing); David Airlie; Xu, Feifei; Francis, David; 
linux-ker...@vger.kernel.org; amd-...@lists.freedesktop.org; Huang, Ray; 
dri-devel@lists.freedesktop.org; Daniel Vetter; pakki...@umn.edu; Deucher, 
Alexander; Gao, Likun; Zhu, Rex; Koenig, Christian; Zhang, Hawking
主题: [PATCH] gpu: drm: fix an improper check of amdgpu_bo_create_kernel

adev->firmware.fw_buf being not NULL may not indicate kernel buffer is
created successful. A better way is to check the status (return value)
of it. The fix does so.

Signed-off-by: Kangjie Lu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
index 7b33867036e7..ba3c1cfb2c35 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ucode.c
@@ -422,13 +422,19 @@ static int amdgpu_ucode_patch_jt(struct 
amdgpu_firmware_info *ucode,

 int amdgpu_ucode_create_bo(struct amdgpu_device *adev)
 {
+   int ret;
+
if (adev->firmware.load_type != AMDGPU_FW_LOAD_DIRECT) {
-   amdgpu_bo_create_kernel(adev, adev->firmware.fw_size, PAGE_SIZE,
-   amdgpu_sriov_vf(adev) ? AMDGPU_GEM_DOMAIN_VRAM : 
AMDGPU_GEM_DOMAIN_GTT,
-   >firmware.fw_buf,
-   >firmware.fw_buf_mc,
-   >firmware.fw_buf_ptr);
-   if (!adev->firmware.fw_buf) {
+   ret =
+   amdgpu_bo_create_kernel(adev,
+ adev->firmware.fw_size,
+ PAGE_SIZE,
+ amdgpu_sriov_vf(adev) ? AMDGPU_GEM_DOMAIN_VRAM :
+   AMDGPU_GEM_DOMAIN_GTT,
+ >firmware.fw_buf,
+ >firmware.fw_buf_mc,
+   >firmware.fw_buf_ptr);
+   if (ret) {

JimQu: Look into amdgpu_bo_create_kernel(), new bo will be created only if 
*bo_ptr = NULL, So if you encounter the issue the adev->firmware.fw_buf != NULL 
but new bo is not created, the only problem I can see are:

1. there is bug in amdgpu_bo_create_kernel()
2. adev->firmware.fw_buf != NULL before it is transferred into 
amdgpu_bo_create_kernel().

Could you commit what is environment you encounter the issue?

Thanks
JimQu 
dev_err(adev->dev, "failed to create kernel buffer for 
firmware.fw_buf\n");
return -ENOMEM;
} else if (amdgpu_sriov_vf(adev)) {
--
2.17.2 (Apple Git-113)

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

[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)

[bugzilla-daemon]

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

--- Comment #38 from Shmerl  ---
(In reply to Jerry Zuo from comment #30)
> Please try the patch, and see if you can see reg_wait timeout
> dce110_stream_encoder_dp_blank()

Do you plan to backport at least this patch to 4.20.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

Re: [PATCH 15/18] drm/mediatek: add RDMA1 fifo size into RDMA private data

[CK Hu]

Hi, Yongqiang:

On Mon, 2018-12-24 at 16:08 +0800, Yongqiang Niu wrote:
> This patch add RDMA1 fifo size into RDMA private data
> 
> Signed-off-by: Yongqiang Niu 
> ---
>  drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c 
> b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> index b0a5cff..3f9b4d4 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_rdma.c
> @@ -53,12 +53,14 @@
>  #define RDMA_FIFO_PSEUDO_SIZE(bytes) (((bytes) / 16) << 16)
>  #define RDMA_OUTPUT_VALID_FIFO_THRESHOLD(bytes)  ((bytes) / 16)
>  #define RDMA_FIFO_SIZE(rdma) ((rdma)->data->fifo_size)
> +#define RDMA_FIFO_SIZE1(rdma)
> ((rdma)->data->fifo_size1)
>  #define DISP_RDMA_MEM_START_ADDR 0x0f00
>  
>  #define RDMA_MEM_GMC 0x40402020
>  
>  struct mtk_disp_rdma_data {
>   unsigned int fifo_size;
> + unsigned int fifo_size1;
>  };
>  
>  /**
> @@ -137,11 +139,17 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
> unsigned int width,
>  {
>   unsigned int threshold;
>   unsigned int reg;
> + unsigned int rdma_fifo_size;
>   struct mtk_disp_rdma *rdma = comp_to_rdma(comp);
>  
>   rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_0, 0xfff, width);
>   rdma_update_bits(comp, DISP_REG_RDMA_SIZE_CON_1, 0xf, height);
>  
> + if (comp->id == DDP_COMPONENT_RDMA1)
> + rdma_fifo_size = RDMA_FIFO_SIZE1(rdma);
> + else
> + rdma_fifo_size = RDMA_FIFO_SIZE(rdma);
> +

It looks like that mt81830-rdma0 and mt8183-rdma1 are different in
hardware, so I think fifo_size should be decided by something from
device tree rather than from its name. Maybe add a property 'FIFO_SIZE'
in rdma device node or create an additional compatible string for
mt8183-rdma1.

Regards,
CK

>   /*
>* Enable FIFO underflow since DSI and DPI can't be blocked.
>* Keep the FIFO pseudo size reset default of 8 KiB. Set the
> @@ -149,8 +157,12 @@ static void mtk_rdma_config(struct mtk_ddp_comp *comp, 
> unsigned int width,
>* account for blanking, and with a pixel depth of 4 bytes:
>*/
>   threshold = width * height * vrefresh * 4 * 7 / 100;
> +
> + if (threshold > rdma_fifo_size)
> + threshold = rdma_fifo_size;
> +
>   reg = RDMA_FIFO_UNDERFLOW_EN |
> -   RDMA_FIFO_PSEUDO_SIZE(RDMA_FIFO_SIZE(rdma)) |
> +   RDMA_FIFO_PSEUDO_SIZE(rdma_fifo_size) |
> RDMA_OUTPUT_VALID_FIFO_THRESHOLD(threshold);
>   writel(reg, comp->regs + DISP_REG_RDMA_FIFO_CON);
>  }
> @@ -330,10 +342,12 @@ static int mtk_disp_rdma_remove(struct platform_device 
> *pdev)
>  
>  static const struct mtk_disp_rdma_data mt2701_rdma_driver_data = {
>   .fifo_size = SZ_4K,
> + .fifo_size1 = SZ_4K,
>  };
>  
>  static const struct mtk_disp_rdma_data mt8173_rdma_driver_data = {
>   .fifo_size = SZ_8K,
> + .fifo_size1 = SZ_8K,
>  };
>  
>  static const struct of_device_id mtk_disp_rdma_driver_dt_match[] = {


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