[Bug 103681] Complete graphic hang when playing specific game

[bugzilla-daemon]

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

--- Comment #1 from vdragon  ---
How to reproduce:
Any kind of real gameplay will cause the crash.
One way i found to do it quickly is to go to training mode, switch to pharah
quickly (may already be crashed at that point), and then shoot the first
training robot in range.

-- 
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 103681] Complete graphic hang when playing specific game

[bugzilla-daemon]

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

Bug ID: 103681
   Summary: Complete graphic hang when playing specific game
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: vdrago...@gmail.com

Created attachment 135389
  --> https://bugs.freedesktop.org/attachment.cgi?id=135389=edit
dmesg log when encountering issue

When running the game 'Overwatch' through wine, I am encountering a complete
graphic freeze (the system appear to run correctly in the background, but the
display is completely frozen on all screens), after which if i try to shutdown
the system, it appears to become unresponsive (at least to ssh access) and I
manually shut it down via a long press of the power button. All the time the
graphics are frozen, all the 'tachyometer' leds on the gpu are on.

System setup is:
GPU: rx Vega 64
System: Archlinux
Kernel: amd-staging 4.13.0 at commit e16e1739c334c1e3a180402c7e30391f6de8ddf2
locally compiled via archlinux aur tools
Mesa : git version d48492074a51045e443d8cab2baf944d7349b7ba locally compiled
with the following options passed to autogen.sh:
   --prefix=/usr \
   --sysconfdir=/etc \
   --with-dri-driverdir=/usr/lib/xorg/modules/dri \
  
--with-gallium-drivers=i915,r300,r600,radeonsi,nouveau,svga,swrast,virgl \
   --with-dri-drivers=i915,i965,r200,radeon,nouveau,swrast \
   --with-platforms=x11,drm,wayland \
   --with-vulkan-drivers=intel,radeon \
   --enable-texture-float \
   --enable-gallium-osmesa \
   --enable-xa \
   --enable-nine \
   --disable-xvmc \
   --enable-vdpau \
   --enable-omx-bellagio \
   --enable-opencl \
   --enable-opencl-icd \
   --enable-glx-tls \
   --enable-libglvnd
   (copied from mesa-git aur package)

Attached is the system log after waiting some time then sending the shutdown
command.

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

[PATCH 1/3] drm: add connector info/property for non-desktop displays [v2]

[Keith Packard]

From: Dave Airlie 

This adds the infrastructure needed to quirk displays
using edid and to mark them a non-desktop.

A non-desktop display is one which shouldn't normally be included
as a part of a desktop environment.

This is meant to cover head mounted devices like HTC Vive.

v2: Change description from non-standard to non-desktop

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_connector.c | 13 +
 drivers/gpu/drm/drm_edid.c  |  8 ++--
 include/drm/drm_connector.h |  5 +
 include/drm/drm_mode_config.h   |  7 +++
 4 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 704fc8934616..f9d3538c9588 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -234,6 +234,10 @@ int drm_connector_init(struct drm_device *dev,
   config->link_status_property,
   0);
 
+   drm_object_attach_property(>base,
+  config->non_desktop_property,
+  0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}
@@ -811,6 +815,11 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.link_status_property = prop;
 
+   prop = drm_property_create_bool(dev, DRM_MODE_PROP_IMMUTABLE, 
"non-desktop");
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.non_desktop_property = prop;
+
return 0;
 }
 
@@ -1194,6 +1203,10 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
if (edid)
size = EDID_LENGTH * (1 + edid->extensions);
 
+   drm_object_property_set_value(>base,
+ dev->mode_config.non_desktop_property,
+ connector->display_info.non_desktop);
+
ret = drm_property_replace_global_blob(dev,
   >edid_blob_ptr,
   size,
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 00ddabfbf980..1e24d5d9d659 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -82,6 +82,8 @@
 #define EDID_QUIRK_FORCE_6BPC  (1 << 10)
 /* Force 10bpc */
 #define EDID_QUIRK_FORCE_10BPC (1 << 11)
+/* Non desktop display (i.e. HMD) */
+#define EDID_QUIRK_NON_DESKTOP (1 << 12)
 
 struct detailed_mode_closure {
struct drm_connector *connector;
@@ -4393,7 +4395,7 @@ static void drm_parse_cea_ext(struct drm_connector 
*connector,
 }
 
 static void drm_add_display_info(struct drm_connector *connector,
-struct edid *edid)
+struct edid *edid, u32 quirks)
 {
struct drm_display_info *info = >display_info;
 
@@ -4407,6 +4409,8 @@ static void drm_add_display_info(struct drm_connector 
*connector,
info->max_tmds_clock = 0;
info->dvi_dual = false;
 
+   info->non_desktop = !!(quirks & EDID_QUIRK_NON_DESKTOP);
+
if (edid->revision < 3)
return;
 
@@ -4627,7 +4631,7 @@ int drm_add_edid_modes(struct drm_connector *connector, 
struct edid *edid)
 * To avoid multiple parsing of same block, lets parse that map
 * from sink info, before parsing CEA modes.
 */
-   drm_add_display_info(connector, edid);
+   drm_add_display_info(connector, edid, quirks);
 
/*
 * EDID spec says modes should be preferred in this order:
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 7a7140543012..df9807a3caae 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -284,6 +284,11 @@ struct drm_display_info {
 * @hdmi: advance features of a HDMI sink.
 */
struct drm_hdmi_info hdmi;
+
+   /**
+* @non_desktop: Non desktop display (HMD).
+*/
+   bool non_desktop;
 };
 
 int drm_display_info_set_bus_formats(struct drm_display_info *info,
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 0b4ac2ebc610..b21e827c5c78 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -728,6 +728,13 @@ struct drm_mode_config {
 */
struct drm_property *suggested_y_property;
 
+   /**
+* @non_desktop_property: Optional connector property with a hint
+* that device isn't a standard display, and the console/desktop,
+* should not be displayed on it.
+*/
+   struct drm_property *non_desktop_property;
+
/* dumb ioctl parameters */
uint32_t preferred_depth, prefer_shadow;
 
-- 
2.15.0.rc0

[PATCH 2/3] drm/fb: add support for not enabling fbcon on non-desktop displays [v2]

[Keith Packard]

From: Dave Airlie 

We don't want fbcon to get used on non-desktop dislays,
don't pass them as enabled connectors to the fb helper setup.

This prevents my HMD from getting disorted fbcon, and from
affecting other displays console.

v2: Change description from non-standard to non-desktop

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_fb_helper.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 116d1f1337c7..07374008f146 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2033,6 +2033,9 @@ static bool drm_connector_enabled(struct drm_connector 
*connector, bool strict)
 {
bool enable;
 
+   if (connector->display_info.non_desktop)
+   return false;
+
if (strict)
enable = connector->status == connector_status_connected;
else
@@ -2052,7 +2055,8 @@ static void drm_enable_connectors(struct drm_fb_helper 
*fb_helper,
connector = fb_helper->connector_info[i]->connector;
enabled[i] = drm_connector_enabled(connector, true);
DRM_DEBUG_KMS("connector %d enabled? %s\n", connector->base.id,
- enabled[i] ? "yes" : "no");
+ connector->display_info.non_desktop ? "non 
desktop" : enabled[i] ? "yes" : "no");
+
any_enabled |= enabled[i];
}
 
-- 
2.15.0.rc0

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

[PATCH 0/3] drm: Add connector info/property for non-desktop [v2]

[Keith Packard]

This is the same as the series for non-standard displays but uses the
phrase 'non-desktop' instead. No functional changes.

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

[PATCH 3/3] drm/edid: quirk HTC vive headset as non-desktop. [v2]

[Keith Packard]

From: Dave Airlie 

This uses the EDID info from my HTC Vive to mark it as
non-desktop.

v2: Change description from non-standard to non-desktop

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1e24d5d9d659..2e8fb51282ef 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -159,6 +159,9 @@ static const struct edid_quirk {
 
/* Rotel RSX-1058 forwards sink's EDID but only does HDMI 1.1*/
{ "ETR", 13896, EDID_QUIRK_FORCE_8BPC },
+
+   /* HTC Vive VR Headset */
+   { "HVR", 0xaa01, EDID_QUIRK_NON_DESKTOP },
 };
 
 /*
-- 
2.15.0.rc0

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

Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Andrey Grodzovsky]

On 11/10/2017 10:48 AM, Christian König wrote:

Am 10.11.2017 um 16:36 schrieb Andrey Grodzovsky:



On 11/10/2017 07:17 AM, Christian König wrote:

Series is Acked-by: Christian König .

Please note that I think your OOM killer test shows quite a bug we 
currently have in the kernel driver.


A single allocation of 1TB shouldn't trigger the OOM killer, but 
rather be reacted immediately.


Maybe we should add a second test which does incremental 1GB 
allocations but still keep this tests ? With this test  i get a 
callstack as bellow + crash of the test suite
with general protection fault - As normal behavior I would have 
expected just some errno returning from the amdgpu_bo_alloc which we 
could check in the test.


Yeah, totally agree. And when this works correctly we should really 
enable this test case by default as well.


When I implemented scattered eviction I completely removed the check 
which limited the BO size. That was probably a bit to extreme.


We still need to check the size here so that we don't create a BO 
larger than what makes sense for the domain it should be stored in.


Patch attached, tested with the DRM tester, call stack is gone but I 
still get SIGSEV and tester crashes, attaching debugger shows SIGSEV 
recived when the tester is still in the IOCTL -

r = drmCommandWriteRead(dev->fd, DRM_AMDGPU_GEM_CREATE,
, sizeof(args));

dmesg

[  104.608664 <   16.227791>] [drm:amdgpu_bo_do_create [amdgpu]] *ERROR* 
BO size 1 > total memory in domain: 1073741824
[  104.608911 <0.000247>] [drm:amdgpu_bo_do_create [amdgpu]] *ERROR* 
BO size 1 > total memory in domain: 3221225472
[  104.609168 <0.000257>] [drm:amdgpu_gem_object_create [amdgpu]] 
*ERROR* Failed to allocate GEM object (1, 6, 4096, -12)
[  104.609301 <0.000133>] traps: lt-amdgpu_test[1142] general 
protection ip:7f21c9ed6007 sp:7ffe08ae1e30 error:0 in 
libdrm_amdgpu.so.1.0.0[7f21c9ed2000+b000]



Thanks,
Andrey



Regards,
Christian.



Thanks,
Andrey

[169053.128981 <72032.811683>] [ cut here ]
[169053.129006 <0.25>] WARNING: CPU: 0 PID: 22883 at 
mm/page_alloc.c:3883 __alloc_pages_slowpath+0xf03/0x14e0
[169053.129007 <0.01>] Modules linked in: amdgpu chash ttm 
drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect 
sysimgblt edac_mce_amd kvm_amd kvm irqbypass crct10dif_pclmul 
crc32_pclmul snd_hda_codec_realtek ghash_clmulni_intel 
snd_hda_codec_generic pcbc snd_hda_codec_hdmi snd_hda_intel 
aesni_intel snd_hda_codec aes_x86_64 snd_hda_core crypto_simd 
glue_helper snd_hwdep rfkill_gpio cryptd snd_pcm snd_seq_midi 
snd_seq_midi_event serio_raw snd_rawmidi snd_seq cdc_ether usbnet 
snd_seq_device joydev fam15h_power k10temp r8152 snd_timer mii 
i2c_piix4 rtsx_pci_ms snd memstick soundcore shpchp 8250_dw 
i2c_designware_platform i2c_designware_core mac_hid binfmt_misc nfsd 
auth_rpcgss nfs_acl lockd grace sunrpc parport_pc ppdev lp parport 
autofs4 rtsx_pci_sdmmc psmouse rtsx_pci sdhci_pci ahci sdhci libahci

[169053.129084 <0.77>]  video i2c_hid hid_generic usbhid hid
[169053.129096 <0.12>] CPU: 0 PID: 22883 Comm: lt-amdgpu_test 
Tainted: GW   4.14.0-rc3+ #1
[169053.129097 <0.01>] Hardware name: AMD Gardenia/Gardenia, 
BIOS RGA1101C 07/20/2015
[169053.129099 <0.02>] task: 880048803d80 task.stack: 
880064688000
[169053.129103 <0.04>] RIP: 
0010:__alloc_pages_slowpath+0xf03/0x14e0
[169053.129105 <0.02>] RSP: 0018:88006468f108 EFLAGS: 
00010246
[169053.129108 <0.03>] RAX:  RBX: 
014000c0 RCX: 81279065
[169053.129109 <0.01>] RDX: dc00 RSI: 
000f RDI: 82609000
[169053.129111 <0.02>] RBP: 88006468f328 R08: 
 R09: 8576
[169053.129113 <0.02>] R10: 5c2044e7 R11: 
 R12: 88006468f3d8
[169053.129114 <0.01>] R13: 880048803d80 R14: 
0140c0c0 R15: 000f
[169053.129117 <0.03>] FS:  7f707863b700() 
GS:88006ce0() knlGS:
[169053.129119 <0.02>] CS:  0010 DS:  ES:  CR0: 
80050033
[169053.129120 <0.01>] CR2: 0125 CR3: 
644cf000 CR4: 001406f0

[169053.129122 <0.02>] Call Trace:
[169053.129131 <0.09>]  ? __module_address+0x145/0x190
[169053.129135 <0.04>]  ? is_bpf_text_address+0xe/0x20
[169053.129140 <0.05>]  ? __kernel_text_address+0x12/0x40
[169053.129144 <0.04>]  ? unwind_get_return_address+0x36/0x50
[169053.129150 <0.06>]  ? memcmp+0x5b/0x90
[169053.129152 <0.02>]  ? warn_alloc+0x250/0x250
[169053.129156 <0.04>]  ? get_page_from_freelist+0x147/0x10f0
[169053.129160 <0.04>]  ? save_stack_trace+0x1b/0x20
[169053.129164 <0.04>]  ? kasan_kmalloc+0xad/0xe0
[169053.129186 

Re: [PATCH 0/5] drm: drm_plane_helper_check_state() related stuff

[Sinclair Yeh]

Sorry this took so long.

The vmwgfx part:  Reviewed-by: Sinclair Yeh 

I've done some testing and the vmwgfx part looks good.  Has Daniel
already taken these or should I put them in my next request?

Sinclair

On Wed, Nov 01, 2017 at 08:29:15PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä 
> 
> While trawling the tree I spotted some issues with the way vmwgfx
> uses drm_plane_helper_check_state(). Here's my attempt at fixing it.
> Do note that I haven't actually tested the resulting code at all,
> but it does build at least.
> 
> And while touching that general area I took up Daniel's suggestion from
> long ago that drm_plane_helper_check_state() should be renamed and
> relocated to better reflect its status.
> 
> Here's a branch with the entire series:
> git://github.com/vsyrjala/linux.git atomic_helper_plane_stuff
> 
> Cc: VMware Graphics 
> Cc: Sinclair Yeh 
> Cc: Thomas Hellstrom 
> Cc: Daniel Vetter 
> 
> Ville Syrjälä (5):
>   drm/vmwgfx: Remove bogus crtc coords vs fb size check
>   drm/vmwgfx: Use drm_plane_helper_check_state()
>   drm/vmwgfx: Try to fix plane clipping
>   drm: Check crtc_state->enable rather than crtc->enabled in
> drm_plane_helper_check_state()
>   drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c
> 
>  drivers/gpu/drm/arm/hdlcd_crtc.c|   8 +-
>  drivers/gpu/drm/arm/malidp_planes.c |   3 +-
>  drivers/gpu/drm/drm_atomic_helper.c |  95 
>  drivers/gpu/drm/drm_plane_helper.c  | 111 
> +++-
>  drivers/gpu/drm/drm_simple_kms_helper.c |   9 ++-
>  drivers/gpu/drm/i915/intel_display.c|  20 ++---
>  drivers/gpu/drm/imx/ipuv3-plane.c   |   8 +-
>  drivers/gpu/drm/mediatek/mtk_drm_plane.c|   8 +-
>  drivers/gpu/drm/meson/meson_plane.c |   8 +-
>  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   5 +-
>  drivers/gpu/drm/nouveau/nv50_display.c  |  18 +++--
>  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
>  drivers/gpu/drm/tegra/dc.c  |   4 +-
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  40 --
>  drivers/gpu/drm/zte/zx_plane.c  |  15 ++--
>  include/drm/drm_atomic_helper.h |   7 ++
>  include/drm/drm_plane_helper.h  |   5 --
>  17 files changed, 187 insertions(+), 183 deletions(-)
> 
> -- 
> 2.13.6
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 197841] lg 25um58-P monitor wrong refresh rate with rx 460

[bugzilla-daemon]

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

habbosuperb...@gmail.com changed:

   What|Removed |Added

  Component|Video(AGP)  |Video(DRI - non Intel)

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

[Bug 197841] lg 25um58-P monitor wrong refresh rate with rx 460

[bugzilla-daemon]

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

habbosuperb...@gmail.com changed:

   What|Removed |Added

  Component|Video(DRI - non Intel)  |Video(AGP)

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

[Bug 197841] New: lg 25um58-P monitor wrong refresh rate with rx 460

[bugzilla-daemon]

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

Bug ID: 197841
   Summary: lg 25um58-P monitor wrong refresh rate with rx 460
   Product: Drivers
   Version: 2.5
Kernel Version: 4.13.11
  Hardware: Intel
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-...@kernel-bugs.osdl.org
  Reporter: habbosuperb...@gmail.com
Regression: No

I have a lg 25um58-P monitor, but the gpu driver recognize with wrong refresh
rate(75hz), but correctly refresh rate is 60hz, my monitor supports 75hz in
lower resolutions, but in max resolution(2560x1080) doesn't support. I can't
use in cli mode, only with X.org started

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

[Bug 103678] gdm couldn't start with Vega RX 56 video card

[bugzilla-daemon]

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

--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 135387
  --> https://bugs.freedesktop.org/attachment.cgi?id=135387=edit
dmesg

-- 
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 103678] gdm couldn't start with Vega RX 56 video card

[bugzilla-daemon]

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

--- Comment #1 from mikhail.v.gavri...@gmail.com ---
Created attachment 135385
  --> https://bugs.freedesktop.org/attachment.cgi?id=135385=edit
journalctl

-- 
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 103678] gdm couldn't start with Vega RX 56 video card

[bugzilla-daemon]

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

--- Comment #2 from mikhail.v.gavri...@gmail.com ---
Created attachment 135386
  --> https://bugs.freedesktop.org/attachment.cgi?id=135386=edit
Xorg,0.log

-- 
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 103678] gdm couldn't start with Vega RX 56 video card

[bugzilla-daemon]

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

Bug ID: 103678
   Summary: gdm couldn't start with Vega RX 56 video card
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: mikhail.v.gavri...@gmail.com

Created attachment 135384
  --> https://bugs.freedesktop.org/attachment.cgi?id=135384=edit
lspci

-- 
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 0/5] drm: drm_plane_helper_check_state() related stuff

[Ville Syrjälä]

On Fri, Nov 10, 2017 at 01:26:47PM -0800, Sinclair Yeh wrote:
> Sorry this took so long.

No worries.

> 
> The vmwgfx part:  Reviewed-by: Sinclair Yeh 
> 
> I've done some testing and the vmwgfx part looks good.  Has Daniel
> already taken these or should I put them in my next request?

You can take them, or I can push them to drm-misc-next. Whatever
works best for you.

And I'll want to revisit this topic soonish and move the clip
handling into the helper as discussed with Daniel. But that can
wait a bit until we get this round merged somewhere.

> 
> Sinclair
> 
> On Wed, Nov 01, 2017 at 08:29:15PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä 
> > 
> > While trawling the tree I spotted some issues with the way vmwgfx
> > uses drm_plane_helper_check_state(). Here's my attempt at fixing it.
> > Do note that I haven't actually tested the resulting code at all,
> > but it does build at least.
> > 
> > And while touching that general area I took up Daniel's suggestion from
> > long ago that drm_plane_helper_check_state() should be renamed and
> > relocated to better reflect its status.
> > 
> > Here's a branch with the entire series:
> > git://github.com/vsyrjala/linux.git atomic_helper_plane_stuff
> > 
> > Cc: VMware Graphics 
> > Cc: Sinclair Yeh 
> > Cc: Thomas Hellstrom 
> > Cc: Daniel Vetter 
> > 
> > Ville Syrjälä (5):
> >   drm/vmwgfx: Remove bogus crtc coords vs fb size check
> >   drm/vmwgfx: Use drm_plane_helper_check_state()
> >   drm/vmwgfx: Try to fix plane clipping
> >   drm: Check crtc_state->enable rather than crtc->enabled in
> > drm_plane_helper_check_state()
> >   drm: Move drm_plane_helper_check_state() into drm_atomic_helper.c
> > 
> >  drivers/gpu/drm/arm/hdlcd_crtc.c|   8 +-
> >  drivers/gpu/drm/arm/malidp_planes.c |   3 +-
> >  drivers/gpu/drm/drm_atomic_helper.c |  95 
> >  drivers/gpu/drm/drm_plane_helper.c  | 111 
> > +++-
> >  drivers/gpu/drm/drm_simple_kms_helper.c |   9 ++-
> >  drivers/gpu/drm/i915/intel_display.c|  20 ++---
> >  drivers/gpu/drm/imx/ipuv3-plane.c   |   8 +-
> >  drivers/gpu/drm/mediatek/mtk_drm_plane.c|   8 +-
> >  drivers/gpu/drm/meson/meson_plane.c |   8 +-
> >  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |   5 +-
> >  drivers/gpu/drm/nouveau/nv50_display.c  |  18 +++--
> >  drivers/gpu/drm/rockchip/rockchip_drm_vop.c |   6 +-
> >  drivers/gpu/drm/tegra/dc.c  |   4 +-
> >  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  40 --
> >  drivers/gpu/drm/zte/zx_plane.c  |  15 ++--
> >  include/drm/drm_atomic_helper.h |   7 ++
> >  include/drm/drm_plane_helper.h  |   5 --
> >  17 files changed, 187 insertions(+), 183 deletions(-)
> > 
> > -- 
> > 2.13.6
> > 

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103653] Unreal segfault since gallium/u_threaded: avoid syncs for get_query_result

[bugzilla-daemon]

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #1 from Andy Furniss  ---
OK now

https://cgit.freedesktop.org/mesa/mesa/commit/?id=ee880e91ccf06fbf7cdea35c75b7dfd83bbc02b5

-- 
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 1/2] dt-bindings: Add binding for Ilitek ILI9225 display panels

[Rob Herring]

On Tue, Nov 07, 2017 at 09:52:15PM -0600, David Lechner wrote:
> This adds a new binding for display panels that use an Ilitek ILI9225
> controller.
> 
> The "generic,2.2in-176x220-ili9225-tft" device listed has no identification
> markings whatsoever and an hour of googling turned up nothing, hence the use
> of "generic".

Just use ilitek then. I would do "ilitek,ili9225-2.2in-176x220" and 
hopefully there aren't others that size. I'm guessing you would have 
found them if so.

Otherwise, looks fine.

> An example of this nameless device can be found at:
> https://github.com/Nkawu/TFT_22_ILI9225
> 
> Signed-off-by: David Lechner 
> ---
>  .../devicetree/bindings/display/ilitek,ili9225.txt | 25 
> ++
>  1 file changed, 25 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/ilitek,ili9225.txt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] display: panel: Add Tianma tm070rvhg71 display support (800x480)

[Rob Herring]

On Tue, Nov 07, 2017 at 04:30:58PM +0100, Lukasz Majewski wrote:
> Signed-off-by: Lukasz Majewski 
> 
> ---
> Changes for v2:
> - Provide more detailed ./Documentation/devicetree/bindings/display/panel
>   entry to describe this panel device.
> ---
>  .../bindings/display/panel/tianma,tm070rvhg71.txt  | 29 
> ++
>  drivers/gpu/drm/panel/panel-simple.c   | 27 
>  2 files changed, 56 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/tianma,tm070rvhg71.txt

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

Re: [PATCH v2 4/6] drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume()

[Noralf Trønnes]

Den 10.11.2017 19.06, skrev Noralf Trønnes:


Den 10.11.2017 17.39, skrev Stefan Agner:

On 2017-11-09 17:49, Noralf Trønnes wrote:

Den 09.11.2017 15.34, skrev Stefan Agner:

On 2017-11-06 20:18, Noralf Trønnes wrote:
Replace driver's code with the generic helpers that do the same 
thing.

Tested using:
echo devices > /sys/power/pm_test
echo freeze > /sys/power/state


Note, currently I do get, but even without this patches, so this is
something else:

[  930.992433] [ cut here ]
[  930.992494] WARNING: CPU: 0 PID: 361 at
drivers/gpu/drm/drm_atomic_helper.c:1249
drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
[  930.992502] [CRTC:28:crtc-0] vblank wait timed out

I resolved that issue and another related to suspend/resume for the DCU
driver:
https://patchwork.freedesktop.org/series/33616/

Suspend/resume is not supported for the platform (Vybrid) I usually test
on, so that is why I did not catch this earlier.

This two patches are now on-top of your changes. How can we make sure
this goes through smoothly? For which merge window are you targeting
your changes?


drm-misc is always open so I'm planning to apply it this weekend or 
maybe monday.


s/drm-misc/drm-misc-next/


This means it will go into 4.16. Maybe you need to fix it before that?

Could you help me out by acking the tinydrm patch in this series?

Noralf.


--
Stefan



Tested-by: Stefan Agner 
Acked-by: Stefan Agner 

Will you take the patch through drm-misc?

Yes if that's fine with you, thanks for testing.

Noralf.


--
Stefan




Cc: Stefan Agner 
Cc: Alison Wang 
Signed-off-by: Noralf Trønnes 
---
   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 24 
++--

   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 -
   2 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 58e9e0601a61..1a9ee657bbac 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -27,6 +27,7 @@
   #include 
   #include 
   #include 
+#include 
 #include "fsl_dcu_drm_crtc.h"
   #include "fsl_dcu_drm_drv.h"
@@ -188,26 +189,17 @@ static struct drm_driver fsl_dcu_drm_driver = {
   static int fsl_dcu_drm_pm_suspend(struct device *dev)
   {
   struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
+    int ret;
 if (!fsl_dev)
   return 0;
 disable_irq(fsl_dev->irq);
-    drm_kms_helper_poll_disable(fsl_dev->drm);
   -    console_lock();
-    drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
-    console_unlock();
-
-    fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
-    if (IS_ERR(fsl_dev->state)) {
-    console_lock();
-    drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-    console_unlock();
-
-    drm_kms_helper_poll_enable(fsl_dev->drm);
+    ret = drm_mode_config_helper_suspend(fsl_dev->drm);
+    if (ret) {
   enable_irq(fsl_dev->irq);
-    return PTR_ERR(fsl_dev->state);
+    return ret;
   }
 clk_disable_unprepare(fsl_dev->pix_clk);
@@ -233,13 +225,9 @@ static int fsl_dcu_drm_pm_resume(struct 
device *dev)

   if (fsl_dev->tcon)
   fsl_tcon_bypass_enable(fsl_dev->tcon);
   fsl_dcu_drm_init_planes(fsl_dev->drm);
-    drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
   -    console_lock();
-    drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-    console_unlock();
+    drm_mode_config_helper_resume(fsl_dev->drm);
   -    drm_kms_helper_poll_enable(fsl_dev->drm);
   enable_irq(fsl_dev->irq);
 return 0;
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index da9bfd432ca6..93bfb98012d4 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -196,7 +196,6 @@ struct fsl_dcu_drm_device {
   struct drm_encoder encoder;
   struct fsl_dcu_drm_connector connector;
   const struct fsl_dcu_soc_data *soc;
-    struct drm_atomic_state *state;
   };
 int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device 
*fsl_dev);


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



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

Re: [PATCH v1 2/2] drm/tinydrm: add driver for ILI9225 panels

[Noralf Trønnes]

Den 08.11.2017 04.52, skrev David Lechner:

This adds a new driver for display panels based on the Ilitek ILI9225
controller.

This was developed for a no-name panel with a red PCB that is commonly
marketed for Arduino. See .

I really did try very hard to find a make and model for this panel, but
there doesn't seem to be one, so the best I can do is offer the picture
in the link above for identification.

Signed-off-by: David Lechner 
---
  MAINTAINERS   |   6 +
  drivers/gpu/drm/tinydrm/Kconfig   |  10 +
  drivers/gpu/drm/tinydrm/Makefile  |   1 +
  drivers/gpu/drm/tinydrm/ili9225.c | 547 ++
  4 files changed, 564 insertions(+)
  create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0d77f22..72404f3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4372,6 +4372,12 @@ T:   git git://anongit.freedesktop.org/drm/drm-misc
  S:Maintained
  F:drivers/gpu/drm/tve200/
  
+DRM DRIVER FOR ILITEK ILI9225 PANELS

+M: David Lechner 
+S: Maintained
+F: drivers/gpu/drm/tinydrm/ili9225.c
+F: Documentation/devicetree/bindings/display/ili9225.txt
+
  DRM DRIVER FOR INTEL I810 VIDEO CARDS
  S:Orphan / Obsolete
  F:drivers/gpu/drm/i810/
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index 2e790e7..90c5bd5 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -12,6 +12,16 @@ menuconfig DRM_TINYDRM
  config TINYDRM_MIPI_DBI
tristate
  
+config TINYDRM_ILI9225

+   tristate "DRM support for ILI9225 display panels"
+   depends on DRM_TINYDRM && SPI
+   select TINYDRM_MIPI_DBI
+   help
+ DRM driver for the following Ilitek ILI9225 panels:
+ * No-name 2.2" color screen module
+
+ If M is selected the module will be called ili9225.
+
  config TINYDRM_MI0283QT
tristate "DRM support for MI0283QT"
depends on DRM_TINYDRM && SPI
diff --git a/drivers/gpu/drm/tinydrm/Makefile b/drivers/gpu/drm/tinydrm/Makefile
index 0c184bd..8aeee53 100644
--- a/drivers/gpu/drm/tinydrm/Makefile
+++ b/drivers/gpu/drm/tinydrm/Makefile
@@ -4,6 +4,7 @@ obj-$(CONFIG_DRM_TINYDRM)   += core/
  obj-$(CONFIG_TINYDRM_MIPI_DBI)+= mipi-dbi.o
  
  # Displays

+obj-$(CONFIG_TINYDRM_ILI9225)  += ili9225.o
  obj-$(CONFIG_TINYDRM_MI0283QT)+= mi0283qt.o
  obj-$(CONFIG_TINYDRM_REPAPER) += repaper.o
  obj-$(CONFIG_TINYDRM_ST7586)  += st7586.o
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c 
b/drivers/gpu/drm/tinydrm/ili9225.c
new file mode 100644
index 000..07e1b8b
--- /dev/null
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -0,0 +1,547 @@
+/*
+ * DRM driver for Ilitek ILI9225 panels
+ *
+ * Copyright 2017 David Lechner 
+ *
+ * Lots of code copied from mipi-dbi.c
+ * Copyright 2016 Noralf Trønnes
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#define ILI9225_DRIVER_READ_CODE   0x00
+#define ILI9225_DRIVER_OUTPUT_CONTROL  0x01
+#define ILI9225_LCD_AC_DRIVING_CONTROL 0x02
+#define ILI9225_ENTRY_MODE 0x03
+#define ILI9225_DISPLAY_CONTROL_1  0x07
+#define ILI9225_BLANK_PERIOD_CONTROL_1 0x08
+#define ILI9225_FRAME_CYCLE_CONTROL0x0b
+#define ILI9225_INTERFACE_CONTROL  0x0c
+#define ILI9225_OSCILLATION_CONTROL0x0f
+#define ILI9225_POWER_CONTROL_10x10
+#define ILI9225_POWER_CONTROL_20x11
+#define ILI9225_POWER_CONTROL_30x12
+#define ILI9225_POWER_CONTROL_40x13
+#define ILI9225_POWER_CONTROL_50x14
+#define ILI9225_VCI_RECYCLING  0x15
+#define ILI9225_RAM_ADDRESS_SET_1  0x20
+#define ILI9225_RAM_ADDRESS_SET_2  0x21
+#define ILI9225_WRITE_DATA_TO_GRAM 0x22
+#define ILI9225_SOFTWARE_RESET 0x28
+#define ILI9225_GATE_SCAN_CONTROL  0x30
+#define ILI9225_VERTICAL_SCROLL_1  0x31
+#define ILI9225_VERTICAL_SCROLL_2  0x32
+#define ILI9225_VERTICAL_SCROLL_3  0x33
+#define ILI9225_PARTIAL_DRIVING_POS_1  0x34
+#define ILI9225_PARTIAL_DRIVING_POS_2  0x35
+#define ILI9225_HORIZ_WINDOW_ADDR_10x36
+#define ILI9225_HORIZ_WINDOW_ADDR_20x37
+#define ILI9225_VERT_WINDOW_ADDR_1 0x38
+#define ILI9225_VERT_WINDOW_ADDR_2 0x39
+#define ILI9225_GAMMA_CONTROL_10x50
+#define ILI9225_GAMMA_CONTROL_20x51
+#define ILI9225_GAMMA_CONTROL_30x52
+#define ILI9225_GAMMA_CONTROL_40x53
+#define ILI9225_GAMMA_CONTROL_5   

Re: [PATCH 00/22] drm/cma-helper: Remove drm_fbdev_cma* functions

[Noralf Trønnes]

Den 04.11.2017 14.03, skrev Noralf Trønnes:

This patchset adds drm_fb_cma_fbdev_init/fini() functions that replaces
drm_fbdev_cma_init/fini(). The reason for doing so is to get rid of
struct drm_fbdev_cma and it's wrapper functions. The final piece will
happen when tinydrm moves away from the cma helper and we can remove the
struct.


This patchset is broken on anything but tinydrm, will resend a new version.

This is the fix:
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c

index 0c73957d7aad..6abb0ab4e7ca 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -294,7 +294,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
    fbi->screen_size = size;
    fbi->fix.smem_len = size;

-   if (fbdev_cma->fb_funcs->dirty) {
+   if (fb->funcs->dirty) {
    ret = drm_fbdev_cma_defio_init(fbi, obj);
    if (ret)
    goto err_cma_destroy;


Sorry about this. I was certain I had tested it on vc4, but clearly I 
hadn't :/


Noralf.


Note:
Patches 19-22 depends on patchset:
drm/: Add simple modeset suspend/resume helpers

Noralf.

Noralf Trønnes (22):
   drm/gem-fb-helper: drm_gem_fbdev_fb_create() make funcs optional
   drm/cma-helper: Add drm_fb_cma_fbdev_init/fini()
   drm/arc: Use drm_fb_cma_fbdev_init/fini()
   drm/arm/hdlcd: Use drm_fb_cma_fbdev_init/fini()
   drm/atmel-hlcdc: Use drm_fb_cma_fbdev_init/fini()
   drm/hisilicon/kirin: Use drm_fb_cma_fbdev_init/fini()
   drm/imx: Use drm_fb_cma_fbdev_init/fini()
   drm/meson: Use drm_fb_cma_fbdev_init/fini()
   drm/mxsfb: Use drm_fb_cma_fbdev_init/fini()
   drm/pl111: Use drm_fb_cma_fbdev_init/fini()
   drm/rcar-du: Use drm_fb_cma_fbdev_init/fini()
   drm/sti: Use drm_fb_cma_fbdev_init/fini()
   drm/stm: Use drm_fb_cma_fbdev_init/fini()
   drm/sun4i: Use drm_fb_cma_fbdev_init/fini()
   drm/tilcdc: Use drm_fb_cma_fbdev_init/fini()
   drm/tve200: Use drm_fb_cma_fbdev_init/fini()
   drm/vc4: Use drm_fb_cma_fbdev_init/fini()
   drm/zte: Use drm_fb_cma_fbdev_init/fini()
   drm/arm/mali: Use drm_fb_cma_fbdev_init/fini()
   drm/fsl-dcu: Use drm_fb_cma_fbdev_init/fini()
   drm/tinydrm: Use drm_fb_cma_fbdev_init_with_funcs/fini()
   drm/cma-helper: Remove drm_fbdev_cma* functions

  Documentation/gpu/todo.rst  |   5 -
  drivers/gpu/drm/arc/arcpgu.h|   4 -
  drivers/gpu/drm/arc/arcpgu_drv.c|  36 +
  drivers/gpu/drm/arm/hdlcd_drv.c |  37 +
  drivers/gpu/drm/arm/hdlcd_drv.h |   1 -
  drivers/gpu/drm/arm/malidp_drv.c|  39 +
  drivers/gpu/drm/arm/malidp_drv.h|   1 -
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c|  26 +---
  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.h|   2 +-
  drivers/gpu/drm/drm_fb_cma_helper.c | 188 +---
  drivers/gpu/drm/drm_gem_framebuffer_helper.c|   6 +-
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c   |  26 +---
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h   |   1 -
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c |  35 +
  drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h |   4 -
  drivers/gpu/drm/imx/imx-drm-core.c  |  33 +
  drivers/gpu/drm/imx/imx-drm.h   |   1 -
  drivers/gpu/drm/meson/meson_drv.c   |  20 +--
  drivers/gpu/drm/meson/meson_drv.h   |   1 -
  drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  21 +--
  drivers/gpu/drm/mxsfb/mxsfb_drv.h   |   1 -
  drivers/gpu/drm/pl111/pl111_drm.h   |   1 -
  drivers/gpu/drm/pl111/pl111_drv.c   |  16 +-
  drivers/gpu/drm/rcar-du/rcar_du_drv.c   |  13 +-
  drivers/gpu/drm/rcar-du/rcar_du_drv.h   |   2 -
  drivers/gpu/drm/rcar-du/rcar_du_kms.c   |  20 +--
  drivers/gpu/drm/sti/sti_drv.c   |  25 +---
  drivers/gpu/drm/sti/sti_drv.h   |   1 -
  drivers/gpu/drm/stm/drv.c   |  37 +
  drivers/gpu/drm/stm/ltdc.h  |   1 -
  drivers/gpu/drm/sun4i/sun4i_drv.c   |  14 +-
  drivers/gpu/drm/sun4i/sun4i_drv.h   |   2 -
  drivers/gpu/drm/sun4i/sun4i_framebuffer.c   |  18 +--
  drivers/gpu/drm/sun4i/sun4i_framebuffer.h   |   2 +-
  drivers/gpu/drm/tilcdc/tilcdc_drv.c |  26 +---
  drivers/gpu/drm/tilcdc/tilcdc_drv.h |   2 -
  drivers/gpu/drm/tinydrm/core/tinydrm-core.c |  37 +
  drivers/gpu/drm/tinydrm/mi0283qt.c  |   3 +-
  drivers/gpu/drm/tinydrm/st7586.c|   3 +-
  drivers/gpu/drm/tve200/tve200_drm.h |   1 -
  drivers/gpu/drm/tve200/tve200_drv.c |  16 +-
  drivers/gpu/drm/vc4/vc4_drv.c   |  13 +-
  drivers/gpu/drm/vc4/vc4_drv.h   |   2 -
  drivers/gpu/drm/vc4/vc4_kms.c   |  18 +--
  drivers/gpu/drm/zte/zx_drm_drv.c|  48 +-
 

Re: [PATCH 1/2] drm/fsl-dcu: avoid disabling pixel clock twice on suspend

[Noralf Trønnes]

Den 10.11.2017 17.25, skrev Stefan Agner:

With commit 0a70c998d0c5 ("drm/fsl-dcu: enable pixel clock when
enabling CRTC") the pixel clock is controlled by the CRTC code.
Disabling the pixel clock in suspend leads to a warning due to
the second clk_disable_unprepare call:
   WARNING: CPU: 0 PID: 359 at drivers/clk/clk.c:594 clk_core_disable+0x8c/0x90

Remove clk_disable_unprepare call for pixel clock to avoid
unbalanced clock disable on suspend.

Fixes: 0a70c998d0c5 ("drm/fsl-dcu: enable pixel clock when enabling CRTC")
Signed-off-by: Stefan Agner 
---
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 1a9ee657bbac..24f234902646 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -202,7 +202,6 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
return ret;
}
  
-	clk_disable_unprepare(fsl_dev->pix_clk);

clk_disable_unprepare(fsl_dev->clk);
  
  	return 0;


Acked-by: Noralf Trønnes 

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

Re: [PATCH 2/2] drm/fsl-dcu: enable IRQ before drm_atomic_helper_resume()

[Noralf Trønnes]

Den 10.11.2017 17.25, skrev Stefan Agner:

The resume helpers wait for a vblank to occurre hence IRQ need
to be enabled. This avoids a warning as follows during resume:
   WARNING: CPU: 0 PID: 314 at drivers/gpu/drm/drm_atomic_helper.c:1249 
drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
   [CRTC:28:crtc-0] vblank wait timed out

Signed-off-by: Stefan Agner 
---
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 24f234902646..aeeaf0bcf646 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -225,9 +225,8 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
  
-	drm_mode_config_helper_resume(fsl_dev->drm);

-
enable_irq(fsl_dev->irq);
+   drm_mode_config_helper_resume(fsl_dev->drm);
  
  	return 0;

  }


Acked-by: Noralf Trønnes 

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

Re: [PATCH v2 4/6] drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume()

[Noralf Trønnes]

Den 10.11.2017 17.39, skrev Stefan Agner:

On 2017-11-09 17:49, Noralf Trønnes wrote:

Den 09.11.2017 15.34, skrev Stefan Agner:

On 2017-11-06 20:18, Noralf Trønnes wrote:

Replace driver's code with the generic helpers that do the same thing.

Tested using:
echo devices > /sys/power/pm_test
echo freeze > /sys/power/state


Note, currently I do get, but even without this patches, so this is
something else:

[  930.992433] [ cut here ]
[  930.992494] WARNING: CPU: 0 PID: 361 at
drivers/gpu/drm/drm_atomic_helper.c:1249
drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
[  930.992502] [CRTC:28:crtc-0] vblank wait timed out

I resolved that issue and another related to suspend/resume for the DCU
driver:
https://patchwork.freedesktop.org/series/33616/

Suspend/resume is not supported for the platform (Vybrid) I usually test
on, so that is why I did not catch this earlier.

This two patches are now on-top of your changes. How can we make sure
this goes through smoothly? For which merge window are you targeting
your changes?


drm-misc is always open so I'm planning to apply it this weekend or 
maybe monday.

This means it will go into 4.16. Maybe you need to fix it before that?

Could you help me out by acking the tinydrm patch in this series?

Noralf.


--
Stefan



Tested-by: Stefan Agner 
Acked-by: Stefan Agner 

Will you take the patch through drm-misc?

Yes if that's fine with you, thanks for testing.

Noralf.


--
Stefan




Cc: Stefan Agner 
Cc: Alison Wang 
Signed-off-by: Noralf Trønnes 
---
   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 24 ++--
   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 -
   2 files changed, 6 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 58e9e0601a61..1a9ee657bbac 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -27,6 +27,7 @@
   #include 
   #include 
   #include 
+#include 
 #include "fsl_dcu_drm_crtc.h"
   #include "fsl_dcu_drm_drv.h"
@@ -188,26 +189,17 @@ static struct drm_driver fsl_dcu_drm_driver = {
   static int fsl_dcu_drm_pm_suspend(struct device *dev)
   {
struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
+   int ret;
if (!fsl_dev)
return 0;
disable_irq(fsl_dev->irq);
-   drm_kms_helper_poll_disable(fsl_dev->drm);
   -console_lock();
-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
-   console_unlock();
-
-   fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
-   if (IS_ERR(fsl_dev->state)) {
-   console_lock();
-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-   console_unlock();
-
-   drm_kms_helper_poll_enable(fsl_dev->drm);
+   ret = drm_mode_config_helper_suspend(fsl_dev->drm);
+   if (ret) {
enable_irq(fsl_dev->irq);
-   return PTR_ERR(fsl_dev->state);
+   return ret;
}
clk_disable_unprepare(fsl_dev->pix_clk);
@@ -233,13 +225,9 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
if (fsl_dev->tcon)
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
-   drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
   -console_lock();
-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-   console_unlock();
+   drm_mode_config_helper_resume(fsl_dev->drm);
   -drm_kms_helper_poll_enable(fsl_dev->drm);
enable_irq(fsl_dev->irq);
return 0;
diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index da9bfd432ca6..93bfb98012d4 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -196,7 +196,6 @@ struct fsl_dcu_drm_device {
struct drm_encoder encoder;
struct fsl_dcu_drm_connector connector;
const struct fsl_dcu_soc_data *soc;
-   struct drm_atomic_state *state;
   };
 int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev);


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

Re: [PATCH 20/22] drm/fsl-dcu: Use drm_fb_cma_fbdev_init/fini()

[Noralf Trønnes]

Den 10.11.2017 18.01, skrev Stefan Agner:

On 2017-11-04 14:04, Noralf Trønnes wrote:

Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
the fact that drm_device holds a pointer to the drm_fb_helper structure.
This means that the driver doesn't have to keep track of that.
Also use the drm_fb_helper functions directly.

With the suspend/resume helper and this patchset applied I get:

[0.788177] Unable to handle kernel NULL pointer dereference at
virtual address 0008


Sorry about this, Benjamin caught this as well. I will send a new 
version this

weekend.

This is the solution:
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c 
b/drivers/gpu/drm/drm_fb_cma_helper.c

index 0c73957d7aad..6abb0ab4e7ca 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -294,7 +294,7 @@ drm_fbdev_cma_create(struct drm_fb_helper *helper,
    fbi->screen_size = size;
    fbi->fix.smem_len = size;

-   if (fbdev_cma->fb_funcs->dirty) {
+   if (fb->funcs->dirty) {
    ret = drm_fbdev_cma_defio_init(fbi, obj);
    if (ret)
    goto err_cma_destroy;




[0.796341] pgd = 80004000
[0.799074] [0008] *pgd=
[0.802687] Internal error: Oops: 5 [#1] ARM
[0.806981] Modules linked in:
[0.810070] CPU: 0 PID: 1 Comm: swapper Not tainted
4.14.0-rc3-00048-gea604dafe5ec-dirty #732
[0.818635] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
[0.825100] task: 8e444000 task.stack: 8e442000
[0.829673] PC is at drm_fbdev_cma_create+0x148/0x268
[0.834747] LR is at 0x10
[0.837388] pc : [<804867b4>]lr : [<0010>]psr: 8053
[0.843678] sp : 8e443b98  ip :   fp : 8e443bd4
[0.848926] r10: 8e620400  r9 : 8e623a00  r8 : 8e617240
[0.854179] r7 : 8e617180  r6 : 000e1000  r5 : 8e443bd8  r4 :
8e620c00
[0.860733] r3 :   r2 : 8ed0  r1 :   r0 :
0003
[0.867288] Flags: Nzcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM
Segment none
[0.874549] Control: 10c5387d  Table: 80004059  DAC: 0051
[0.880318] Process swapper (pid: 1, stack limit = 0x8e442208)
[0.886177] Stack: (0x8e443b98 to 0x8e444000)
[0.890560] 3b80:
    0018
[0.898782] 3ba0: 8e625240 0003 80c39ecc 8e617180 0018
8e620400 80c20428 0001
[0.907009] 3bc0: 8e6250a8  8e443c1c 8e443bd8 80485c00
80486678 0280 01e0
[0.915235] 3be0: 0280 01e0 0018 0018 8e617210
8e617180 0018 
[0.923463] 3c00: 8e617180  8e618700  8e443c34
8e443c20 80485e18 80485a30
[0.931690] 3c20: 0018 8e620400 8e443cfc 8e443c38 80486518
80485de8  
[0.939915] 3c40:     
  
[0.948133] 3c60:     
  
[0.956352] 3c80:     
  
[0.964570] 3ca0:     
  
[0.972790] 3cc0:     
 8e443d0c 8e620400
[0.981018] 3ce0: 80c20878 8e61c810 80c208d8  8e443d0c
8e443d00 8048654c 8048637c
[0.989245] 3d00: 8e443d2c 8e443d10 804ae0f4 80486544 8e620400
  80c208d8
[0.997472] 3d20: 8e443d64 8e443d30 8048da94 804ae070 
809b0410 8e443d64 8e443d48
[1.005699] 3d40: 8e61c810 8e4b7a10 8e4b7a00 8e620400 
809b0410 8e443dcc 8e443d68
[1.013925] 3d60: 804ae350 8048d960 9004e054  0008
0010  0001
[1.022153] 3d80: 30756364 7669645f 7869705f 8e443d00 802417c8
8023ded4 8e4b7a10 
[1.030380] 3da0: 8e4b7a18 8e4b7a10 ffed 80c2088c fdfb
80c2088c  
[1.038607] 3dc0: 8e443dec 8e443dd0 804b90b4 804ae178 8e4b7a10
80c5b410 80c5b414 
[1.046835] 3de0: 8e443e1c 8e443df0 804b7578 804b9068 
8e4b7a10 80c2088c 8e4b7a44
[1.055061] 3e00:  00c2 80b0061c 0007 8e443e3c
8e443e20 804b76b0 804b730c
[1.063289] 3e20:  80c2088c 804b75f0  8e443e64
8e443e40 804b5878 804b75fc
[1.071516] 3e40: 8e403f4c 8e4b63b0 8e6128b4 80c2088c 8e612880
80c20ee8 8e443e74 8e443e68
[1.079743] 3e60: 804b6eb8 804b5814 8e443e9c 8e443e78 804b6930
804b6ea0 809b9bcc 8e443e88
[1.087970] 3e80: 80c2088c 80b1b304  80b2d830 8e443eb4
8e443ea0 804b802c 804b6834
[1.096197] 3ea0: 80c20ee8 80b1b304 8e443ecc 8e443eb8 804b9010
804b7fb8 e000 80b1b304
[1.104424] 3ec0: 8e443edc 8e443ed0 80b1b320 804b8fd4 8e443f4c
8e443ee0 8010190c 80b1b310
[1.112651] 3ee0: 8e443f4c 8e443ef0 80134300 80b00628 8096fbd0
8096fbb0 8096fbfc 8096fb88
[1.120878] 3f00: 80977cc4 0006 0006  80a351fc
809cdb30 8fdffc04 8fdffc0d
[1.129105] 3f20:  80c37800 80c37800 80c37800 80c37800
80b38adc 00c2 80b0061c
[1.137332] 3f40: 

[PATCH] video: fbdev: sm501fb: fix potential null pointer dereference on fbi

[Colin King]

From: Colin Ian King 

The pointer fbi is dereferenced with par = fbi->par before there is a
null check on fbi, hence there is a potential null pointer dereference
on a null par.  Fix this by moving the dereference after the null
pointer check.

Detected by CoverityScan, CID#1461301 ("Dereference before null check")

Signed-off-by: Colin Ian King 
---
 drivers/video/fbdev/sm501fb.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index 8d4fdb373299..6f0a19501c6a 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -2100,11 +2100,12 @@ static int sm501fb_suspend_fb(struct sm501fb_info *info,
  enum sm501_controller head)
 {
struct fb_info *fbi = info->fb[head];
-   struct sm501fb_par *par = fbi->par;
+   struct sm501fb_par *par;
 
if (!fbi)
return 0;
 
+   par = fbi->par;
if (par->screen.size == 0)
return 0;
 
@@ -2150,11 +2151,12 @@ static void sm501fb_resume_fb(struct sm501fb_info *info,
  enum sm501_controller head)
 {
struct fb_info *fbi = info->fb[head];
-   struct sm501fb_par *par = fbi->par;
+   struct sm501fb_par *par;
 
if (!fbi)
return;
 
+   par = fbi->par;
if (par->screen.size == 0)
return;
 
-- 
2.14.1

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

Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Christian König]

Am 10.11.2017 um 16:36 schrieb Andrey Grodzovsky:



On 11/10/2017 07:17 AM, Christian König wrote:

Series is Acked-by: Christian König .

Please note that I think your OOM killer test shows quite a bug we 
currently have in the kernel driver.


A single allocation of 1TB shouldn't trigger the OOM killer, but 
rather be reacted immediately.


Maybe we should add a second test which does incremental 1GB 
allocations but still keep this tests ? With this test  i get a 
callstack as bellow + crash of the test suite
with general protection fault - As normal behavior I would have 
expected just some errno returning from the amdgpu_bo_alloc which we 
could check in the test.


Yeah, totally agree. And when this works correctly we should really 
enable this test case by default as well.


When I implemented scattered eviction I completely removed the check 
which limited the BO size. That was probably a bit to extreme.


We still need to check the size here so that we don't create a BO larger 
than what makes sense for the domain it should be stored in.


Regards,
Christian.



Thanks,
Andrey

[169053.128981 <72032.811683>] [ cut here ]
[169053.129006 <    0.25>] WARNING: CPU: 0 PID: 22883 at 
mm/page_alloc.c:3883 __alloc_pages_slowpath+0xf03/0x14e0
[169053.129007 <    0.01>] Modules linked in: amdgpu chash ttm 
drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect 
sysimgblt edac_mce_amd kvm_amd kvm irqbypass crct10dif_pclmul 
crc32_pclmul snd_hda_codec_realtek ghash_clmulni_intel 
snd_hda_codec_generic pcbc snd_hda_codec_hdmi snd_hda_intel 
aesni_intel snd_hda_codec aes_x86_64 snd_hda_core crypto_simd 
glue_helper snd_hwdep rfkill_gpio cryptd snd_pcm snd_seq_midi 
snd_seq_midi_event serio_raw snd_rawmidi snd_seq cdc_ether usbnet 
snd_seq_device joydev fam15h_power k10temp r8152 snd_timer mii 
i2c_piix4 rtsx_pci_ms snd memstick soundcore shpchp 8250_dw 
i2c_designware_platform i2c_designware_core mac_hid binfmt_misc nfsd 
auth_rpcgss nfs_acl lockd grace sunrpc parport_pc ppdev lp parport 
autofs4 rtsx_pci_sdmmc psmouse rtsx_pci sdhci_pci ahci sdhci libahci

[169053.129084 <    0.77>]  video i2c_hid hid_generic usbhid hid
[169053.129096 <    0.12>] CPU: 0 PID: 22883 Comm: lt-amdgpu_test 
Tainted: G    W   4.14.0-rc3+ #1
[169053.129097 <    0.01>] Hardware name: AMD Gardenia/Gardenia, 
BIOS RGA1101C 07/20/2015
[169053.129099 <    0.02>] task: 880048803d80 task.stack: 
880064688000
[169053.129103 <    0.04>] RIP: 
0010:__alloc_pages_slowpath+0xf03/0x14e0
[169053.129105 <    0.02>] RSP: 0018:88006468f108 EFLAGS: 
00010246
[169053.129108 <    0.03>] RAX:  RBX: 
014000c0 RCX: 81279065
[169053.129109 <    0.01>] RDX: dc00 RSI: 
000f RDI: 82609000
[169053.129111 <    0.02>] RBP: 88006468f328 R08: 
 R09: 8576
[169053.129113 <    0.02>] R10: 5c2044e7 R11: 
 R12: 88006468f3d8
[169053.129114 <    0.01>] R13: 880048803d80 R14: 
0140c0c0 R15: 000f
[169053.129117 <    0.03>] FS:  7f707863b700() 
GS:88006ce0() knlGS:
[169053.129119 <    0.02>] CS:  0010 DS:  ES:  CR0: 
80050033
[169053.129120 <    0.01>] CR2: 0125 CR3: 
644cf000 CR4: 001406f0

[169053.129122 <    0.02>] Call Trace:
[169053.129131 <    0.09>]  ? __module_address+0x145/0x190
[169053.129135 <    0.04>]  ? is_bpf_text_address+0xe/0x20
[169053.129140 <    0.05>]  ? __kernel_text_address+0x12/0x40
[169053.129144 <    0.04>]  ? unwind_get_return_address+0x36/0x50
[169053.129150 <    0.06>]  ? memcmp+0x5b/0x90
[169053.129152 <    0.02>]  ? warn_alloc+0x250/0x250
[169053.129156 <    0.04>]  ? get_page_from_freelist+0x147/0x10f0
[169053.129160 <    0.04>]  ? save_stack_trace+0x1b/0x20
[169053.129164 <    0.04>]  ? kasan_kmalloc+0xad/0xe0
[169053.129186 <    0.22>]  ? ttm_bo_mem_space+0x79/0x6b0 [ttm]
[169053.129196 <    0.10>]  ? ttm_bo_validate+0x178/0x220 [ttm]
[169053.129200 <    0.04>] __alloc_pages_nodemask+0x3c4/0x400
[169053.129203 <    0.03>]  ? __alloc_pages_slowpath+0x14e0/0x14e0
[169053.129205 <    0.02>]  ? __save_stack_trace+0x66/0xd0
[169053.129209 <    0.04>]  ? rb_insert_color+0x32/0x3e0
[169053.129213 <    0.04>]  ? do_syscall_64+0xea/0x280
[169053.129217 <    0.04>] alloc_pages_current+0x75/0x110
[169053.129221 <    0.04>]  kmalloc_order+0x1f/0x80
[169053.129223 <    0.02>] kmalloc_order_trace+0x24/0xa0
[169053.129226 <    0.03>]  __kmalloc+0x264/0x280
[169053.129383 <    0.000157>] amdgpu_vram_mgr_new+0x11b/0x3b0 [amdgpu]
[169053.129391 <    0.08>]  ? 
reservation_object_reserve_shared+0x64/0xf0

[169053.129401 <    0.10>]  ttm_bo_mem_space+0x196/0x6b0 [ttm]
[169053.129478 <    0.77>]  

Re: [PATCH 20/22] drm/fsl-dcu: Use drm_fb_cma_fbdev_init/fini()

[Stefan Agner]

On 2017-11-04 14:04, Noralf Trønnes wrote:
> Use drm_fb_cma_fbdev_init() and drm_fb_cma_fbdev_fini() which relies on
> the fact that drm_device holds a pointer to the drm_fb_helper structure.
> This means that the driver doesn't have to keep track of that.
> Also use the drm_fb_helper functions directly.

With the suspend/resume helper and this patchset applied I get:

[0.788177] Unable to handle kernel NULL pointer dereference at
virtual address 0008
[0.796341] pgd = 80004000
[0.799074] [0008] *pgd=
[0.802687] Internal error: Oops: 5 [#1] ARM
[0.806981] Modules linked in:
[0.810070] CPU: 0 PID: 1 Comm: swapper Not tainted
4.14.0-rc3-00048-gea604dafe5ec-dirty #732
[0.818635] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
[0.825100] task: 8e444000 task.stack: 8e442000
[0.829673] PC is at drm_fbdev_cma_create+0x148/0x268
[0.834747] LR is at 0x10
[0.837388] pc : [<804867b4>]lr : [<0010>]psr: 8053
[0.843678] sp : 8e443b98  ip :   fp : 8e443bd4
[0.848926] r10: 8e620400  r9 : 8e623a00  r8 : 8e617240
[0.854179] r7 : 8e617180  r6 : 000e1000  r5 : 8e443bd8  r4 :
8e620c00
[0.860733] r3 :   r2 : 8ed0  r1 :   r0 :
0003
[0.867288] Flags: Nzcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM 
Segment none
[0.874549] Control: 10c5387d  Table: 80004059  DAC: 0051
[0.880318] Process swapper (pid: 1, stack limit = 0x8e442208)
[0.886177] Stack: (0x8e443b98 to 0x8e444000)
[0.890560] 3b80:
   0018
[0.898782] 3ba0: 8e625240 0003 80c39ecc 8e617180 0018
8e620400 80c20428 0001
[0.907009] 3bc0: 8e6250a8  8e443c1c 8e443bd8 80485c00
80486678 0280 01e0
[0.915235] 3be0: 0280 01e0 0018 0018 8e617210
8e617180 0018 
[0.923463] 3c00: 8e617180  8e618700  8e443c34
8e443c20 80485e18 80485a30
[0.931690] 3c20: 0018 8e620400 8e443cfc 8e443c38 80486518
80485de8  
[0.939915] 3c40:     
  
[0.948133] 3c60:     
  
[0.956352] 3c80:     
  
[0.964570] 3ca0:     
  
[0.972790] 3cc0:     
 8e443d0c 8e620400
[0.981018] 3ce0: 80c20878 8e61c810 80c208d8  8e443d0c
8e443d00 8048654c 8048637c
[0.989245] 3d00: 8e443d2c 8e443d10 804ae0f4 80486544 8e620400
  80c208d8
[0.997472] 3d20: 8e443d64 8e443d30 8048da94 804ae070 
809b0410 8e443d64 8e443d48
[1.005699] 3d40: 8e61c810 8e4b7a10 8e4b7a00 8e620400 
809b0410 8e443dcc 8e443d68
[1.013925] 3d60: 804ae350 8048d960 9004e054  0008
0010  0001
[1.022153] 3d80: 30756364 7669645f 7869705f 8e443d00 802417c8
8023ded4 8e4b7a10 
[1.030380] 3da0: 8e4b7a18 8e4b7a10 ffed 80c2088c fdfb
80c2088c  
[1.038607] 3dc0: 8e443dec 8e443dd0 804b90b4 804ae178 8e4b7a10
80c5b410 80c5b414 
[1.046835] 3de0: 8e443e1c 8e443df0 804b7578 804b9068 
8e4b7a10 80c2088c 8e4b7a44
[1.055061] 3e00:  00c2 80b0061c 0007 8e443e3c
8e443e20 804b76b0 804b730c
[1.063289] 3e20:  80c2088c 804b75f0  8e443e64
8e443e40 804b5878 804b75fc
[1.071516] 3e40: 8e403f4c 8e4b63b0 8e6128b4 80c2088c 8e612880
80c20ee8 8e443e74 8e443e68
[1.079743] 3e60: 804b6eb8 804b5814 8e443e9c 8e443e78 804b6930
804b6ea0 809b9bcc 8e443e88
[1.087970] 3e80: 80c2088c 80b1b304  80b2d830 8e443eb4
8e443ea0 804b802c 804b6834
[1.096197] 3ea0: 80c20ee8 80b1b304 8e443ecc 8e443eb8 804b9010
804b7fb8 e000 80b1b304
[1.104424] 3ec0: 8e443edc 8e443ed0 80b1b320 804b8fd4 8e443f4c
8e443ee0 8010190c 80b1b310
[1.112651] 3ee0: 8e443f4c 8e443ef0 80134300 80b00628 8096fbd0
8096fbb0 8096fbfc 8096fb88
[1.120878] 3f00: 80977cc4 0006 0006  80a351fc
809cdb30 8fdffc04 8fdffc0d
[1.129105] 3f20:  80c37800 80c37800 80c37800 80c37800
80b38adc 00c2 80b0061c
[1.137332] 3f40: 8e443f94 8e443f50 80b00e88 801018cc 0006
0006  80b0061c
[1.145558] 3f60:  80a351fc   80792c48
  
[1.153777] 3f80:   8e443fac 8e443f98 80792c58
80b00d5c  80792c48
[1.162004] 3fa0:  8e443fb0 80107cb0 80792c54 
  
[1.170230] 3fc0:     
  
[1.178449] 3fe0:     0013
 5aef 7deefbff
[1.186662] Backtrace:
[1.189151] [<8048666c>] (drm_fbdev_cma_create) from [<80485c00>]

Re: [PATCH v2 4/6] drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume()

[Stefan Agner]

On 2017-11-09 17:49, Noralf Trønnes wrote:
> Den 09.11.2017 15.34, skrev Stefan Agner:
>> On 2017-11-06 20:18, Noralf Trønnes wrote:
>>> Replace driver's code with the generic helpers that do the same thing.
>> Tested using:
>> echo devices > /sys/power/pm_test
>> echo freeze > /sys/power/state
>>
>>
>> Note, currently I do get, but even without this patches, so this is
>> something else:
>>
>> [  930.992433] [ cut here ]
>> [  930.992494] WARNING: CPU: 0 PID: 361 at
>> drivers/gpu/drm/drm_atomic_helper.c:1249
>> drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
>> [  930.992502] [CRTC:28:crtc-0] vblank wait timed out

I resolved that issue and another related to suspend/resume for the DCU
driver:
https://patchwork.freedesktop.org/series/33616/

Suspend/resume is not supported for the platform (Vybrid) I usually test
on, so that is why I did not catch this earlier.

This two patches are now on-top of your changes. How can we make sure
this goes through smoothly? For which merge window are you targeting
your changes? 

--
Stefan

>>
>>
>> Tested-by: Stefan Agner 
>> Acked-by: Stefan Agner 
>>
>> Will you take the patch through drm-misc?
> 
> Yes if that's fine with you, thanks for testing.
> 
> Noralf.
> 
>> --
>> Stefan
>>
>>
>>
>>> Cc: Stefan Agner 
>>> Cc: Alison Wang 
>>> Signed-off-by: Noralf Trønnes 
>>> ---
>>>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 24 ++--
>>>   drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 -
>>>   2 files changed, 6 insertions(+), 19 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>>> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>>> index 58e9e0601a61..1a9ee657bbac 100644
>>> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
>>> @@ -27,6 +27,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>> #include "fsl_dcu_drm_crtc.h"
>>>   #include "fsl_dcu_drm_drv.h"
>>> @@ -188,26 +189,17 @@ static struct drm_driver fsl_dcu_drm_driver = {
>>>   static int fsl_dcu_drm_pm_suspend(struct device *dev)
>>>   {
>>> struct fsl_dcu_drm_device *fsl_dev = dev_get_drvdata(dev);
>>> +   int ret;
>>> if (!fsl_dev)
>>> return 0;
>>> disable_irq(fsl_dev->irq);
>>> -   drm_kms_helper_poll_disable(fsl_dev->drm);
>>>   - console_lock();
>>> -   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
>>> -   console_unlock();
>>> -
>>> -   fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
>>> -   if (IS_ERR(fsl_dev->state)) {
>>> -   console_lock();
>>> -   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
>>> -   console_unlock();
>>> -
>>> -   drm_kms_helper_poll_enable(fsl_dev->drm);
>>> +   ret = drm_mode_config_helper_suspend(fsl_dev->drm);
>>> +   if (ret) {
>>> enable_irq(fsl_dev->irq);
>>> -   return PTR_ERR(fsl_dev->state);
>>> +   return ret;
>>> }
>>> clk_disable_unprepare(fsl_dev->pix_clk);
>>> @@ -233,13 +225,9 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
>>> if (fsl_dev->tcon)
>>> fsl_tcon_bypass_enable(fsl_dev->tcon);
>>> fsl_dcu_drm_init_planes(fsl_dev->drm);
>>> -   drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
>>>   - console_lock();
>>> -   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
>>> -   console_unlock();
>>> +   drm_mode_config_helper_resume(fsl_dev->drm);
>>>   - drm_kms_helper_poll_enable(fsl_dev->drm);
>>> enable_irq(fsl_dev->irq);
>>> return 0;
>>> diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>>> b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>>> index da9bfd432ca6..93bfb98012d4 100644
>>> --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>>> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
>>> @@ -196,7 +196,6 @@ struct fsl_dcu_drm_device {
>>> struct drm_encoder encoder;
>>> struct fsl_dcu_drm_connector connector;
>>> const struct fsl_dcu_soc_data *soc;
>>> -   struct drm_atomic_state *state;
>>>   };
>>> int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm/fsl-dcu: Don't set connector DPMS property

[Stefan Agner]

From: Laurent Pinchart 

Since commit 4a97a3da420b ("drm: Don't update property values for atomic
drivers") atomic drivers must not update property values as properties
are read from the state instead. To catch remaining users, the
drm_object_property_set_value() function now throws a warning when
called by atomic drivers on non-immutable properties, and we hit that
warning when creating connectors.

The easy fix is to just remove the drm_object_property_set_value() as it
is used here to set the initial value of the connector's DPMS property
to OFF. The DPMS property applies on top of the connector's state crtc
pointer (initialized to NULL) that is the main connector on/off control,
and should thus default to ON.

Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers")
Cc: sta...@vger.kernel.org
Signed-off-by: Laurent Pinchart 
Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
index edd7d8127d19..c54806d08dd7 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c
@@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device 
*fsl_dev,
 {
struct drm_encoder *encoder = _dev->encoder;
struct drm_connector *connector = _dev->connector.base;
-   struct drm_mode_config *mode_config = _dev->drm->mode_config;
int ret;
 
fsl_dev->connector.encoder = encoder;
@@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device 
*fsl_dev,
if (ret < 0)
goto err_sysfs;
 
-   drm_object_property_set_value(>base,
- mode_config->dpms_property,
- DRM_MODE_DPMS_OFF);
-
ret = drm_panel_attach(panel, connector);
if (ret) {
dev_err(fsl_dev->dev, "failed to attach panel\n");
-- 
2.14.2

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

[PATCH 1/2] drm/fsl-dcu: avoid disabling pixel clock twice on suspend

[Stefan Agner]

With commit 0a70c998d0c5 ("drm/fsl-dcu: enable pixel clock when
enabling CRTC") the pixel clock is controlled by the CRTC code.
Disabling the pixel clock in suspend leads to a warning due to
the second clk_disable_unprepare call:
  WARNING: CPU: 0 PID: 359 at drivers/clk/clk.c:594 clk_core_disable+0x8c/0x90

Remove clk_disable_unprepare call for pixel clock to avoid
unbalanced clock disable on suspend.

Fixes: 0a70c998d0c5 ("drm/fsl-dcu: enable pixel clock when enabling CRTC")
Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 1a9ee657bbac..24f234902646 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -202,7 +202,6 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
return ret;
}
 
-   clk_disable_unprepare(fsl_dev->pix_clk);
clk_disable_unprepare(fsl_dev->clk);
 
return 0;
-- 
2.14.2

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

[PATCH 2/2] drm/fsl-dcu: enable IRQ before drm_atomic_helper_resume()

[Stefan Agner]

The resume helpers wait for a vblank to occurre hence IRQ need
to be enabled. This avoids a warning as follows during resume:
  WARNING: CPU: 0 PID: 314 at drivers/gpu/drm/drm_atomic_helper.c:1249 
drm_atomic_helper_wait_for_vblanks.part.1+0x284/0x288
  [CRTC:28:crtc-0] vblank wait timed out

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 24f234902646..aeeaf0bcf646 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -225,9 +225,8 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
 
-   drm_mode_config_helper_resume(fsl_dev->drm);
-
enable_irq(fsl_dev->irq);
+   drm_mode_config_helper_resume(fsl_dev->drm);
 
return 0;
 }
-- 
2.14.2

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

Re: [PATCH 4/7] drm/ttm: user reservation object wrappers

[Michel Dänzer]

On 09/11/17 06:13 PM, Christian König wrote:
> Am 09.11.2017 um 17:50 schrieb Michel Dänzer:
>> On 09/11/17 09:59 AM, Christian König wrote:
>>> Consistently use the reservation object wrappers instead of accessing
>>> the ww_mutex directly.
>>>
>>> Additional to that use the reservation object wrappers directly
>>> instead of
>>> calling __ttm_bo_reserve with fixed parameters.
>>>
>>> Signed-off-by: Christian König 
>> [...]
>>
>>> @@ -1823,7 +1823,9 @@ int ttm_bo_wait_unreserved(struct
>>> ttm_buffer_object *bo)
>>>   return -ERESTARTSYS;
>>>   if (!ww_mutex_is_locked(>resv->lock))
>>>   goto out_unlock;
>>> -    ret = __ttm_bo_reserve(bo, true, false, NULL);
>>> +    ret = reservation_object_lock_interruptible(bo->resv, NULL);
>>> +    if (ret = -EINTR)
>>> +    ret = -ERESTARTSYS;
>> Typo in the test, must be
>>
>>  if (ret == -EINTR)
>>
>>
>> This bug caused the Xorg process to hang for me when trying to run
>> glxgears, requiring a hard reboot. Did you accidentally send an untested
>> version of this patch?
> Yeah, just stumbled over this as well. I accidentally merged the fix for
> this into a later patch which I didn't send out yet.
> 
> Consider it fixed,

Thanks. With that, patches 1-6 are

Reviewed-and-Tested-by: Michel Dänzer 


I sent another comment on patch 7.


-- 
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/stm: ltdc: add clut mode support

[Philippe CORNU]

Hi Peter,

On 11/07/2017 05:34 PM, Peter Rosin wrote:
> On 2017-11-07 16:53, Philippe CORNU wrote:
>> + Peter
>>
>> Hi Peter,
>>
>> CLUT support on STM32 has been removed thanks to your clean up patch
> 
> Support is a bit strong for what I thought was a dead function, or
> are you saying that it used to work before my series? Really sorry
> if that is the case!

As I wrote in the previous related thread 
(https://lists.freedesktop.org/archives/dri-devel/2017-June/145070.html), 
STM32 chipsets supports 8-bit CLUT mode but this driver version does not 
support it "yet"...

So, no worry regarding your clean up, I gave you an "acked-by" for that : )

> 
> Anyway, the function I removed seemed to indicate that the hardware
> could handle a separate clut for each layer, but your new version
> does not. Why is that?

Yes I confirm the clut support is available for each layer... but I 
thought the gamma_lut was only at the crtc level, not at layer level... 
Maybe I am wrong.
Moreover, small test applications I used play only with clut at crtc 
level...

Anyway, could you please help me to "find" a per-layer clut 
implementation because when I read "crtc->state->gamma_lut->data" it 
looks like gamma_lut is per crtc, not per plane...? or maybe I have to 
add extra properties for that...

Many thanks,
Philippe :-)

> 
> Cheers,
> peda
> 
>> named "drm: stm: remove dead code and pointless local lut storage"
>> (https://patchwork.freedesktop.org/patch/166898/)
>>
>> This below patch puts back the clut mode support using the new drm gamma
>> api.
>>
>> May I ask you please a short review on this patch?
>>
>> Many thanks,
>> Philippe :-)
>>
>>
>> On 10/26/2017 01:17 PM, Philippe Cornu wrote:
>>> Add the 8-bit clut mode support at crtc level.
>>> Useful for low memory footprint user interfaces but also for
>>> 8-bit old games (including color shifting visual effects).
>>> Tested with fbdev FBIOPUTCMAP & drm DRM_IOCTL_MODE_SETGAMMA
>>> ioctls.
>>>
>>> Signed-off-by: Philippe Cornu 
>>> ---
>>>drivers/gpu/drm/stm/ltdc.c | 30 ++
>>>1 file changed, 30 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
>>> index 7be6710..d5c8a42 100644
>>> --- a/drivers/gpu/drm/stm/ltdc.c
>>> +++ b/drivers/gpu/drm/stm/ltdc.c
>>> @@ -174,6 +174,8 @@
>>>
>>>#define LXCFBLNR_CFBLN   GENMASK(10, 0)  /* Color Frame Buffer Line 
>>> Number */
>>>
>>> +#define CLUT_SIZE  256
>>> +
>>>#define CONSTA_MAX   0xFF/* CONSTant Alpha MAX= 1.0 */
>>>#define BF1_PAXCA0x600   /* Pixel Alpha x Constant Alpha 
>>> */
>>>#define BF1_CA   0x400   /* Constant Alpha */
>>> @@ -362,6 +364,28 @@ static irqreturn_t ltdc_irq(int irq, void *arg)
>>> * DRM_CRTC
>>> */
>>>
>>> +static void ltdc_crtc_update_clut(struct drm_crtc *crtc)
>>> +{
>>> +   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>>> +   struct drm_color_lut *lut;
>>> +   u32 val;
>>> +   int i;
>>> +
>>> +   if (!crtc || !crtc->state)
>>> +   return;
>>> +
>>> +   if (!crtc->state->color_mgmt_changed || !crtc->state->gamma_lut)
>>> +   return;
>>> +
>>> +   lut = (struct drm_color_lut *)crtc->state->gamma_lut->data;
>>> +
>>> +   for (i = 0; i < CLUT_SIZE; i++, lut++) {
>>> +   val = ((lut->red << 8) & 0xff) | (lut->green & 0xff00) |
>>> +   (lut->blue >> 8) | (i << 24);
>>> +   reg_write(ldev->regs, LTDC_L1CLUTWR, val);
>>> +   }
>>> +}
>>> +
>>>static void ltdc_crtc_atomic_enable(struct drm_crtc *crtc,
>>> struct drm_crtc_state *old_state)
>>>{
>>> @@ -485,6 +509,8 @@ static void ltdc_crtc_atomic_flush(struct drm_crtc 
>>> *crtc,
>>>
>>> DRM_DEBUG_ATOMIC("\n");
>>>
>>> +   ltdc_crtc_update_clut(crtc);
>>> +
>>> /* Commit shadow registers = update planes at next vblank */
>>> reg_set(ldev->regs, LTDC_SRCR, SRCR_VBR);
>>>
>>> @@ -532,6 +558,7 @@ void ltdc_crtc_disable_vblank(struct drm_device *ddev, 
>>> unsigned int pipe)
>>> .reset = drm_atomic_helper_crtc_reset,
>>> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
>>> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
>>> +   .gamma_set = drm_atomic_helper_legacy_gamma_set,
>>>};
>>>
>>>/*
>>> @@ -764,6 +791,9 @@ static int ltdc_crtc_init(struct drm_device *ddev, 
>>> struct drm_crtc *crtc)
>>>
>>> drm_crtc_helper_add(crtc, _crtc_helper_funcs);
>>>
>>> +   drm_mode_crtc_set_gamma_size(crtc, CLUT_SIZE);
>>> +   drm_crtc_enable_color_mgmt(crtc, 0, false, CLUT_SIZE);
>>> +
>>> DRM_DEBUG_DRIVER("CRTC:%d created\n", crtc->base.id);
>>>
>>> /* Add planes. Note : the first layer is used by primary plane */
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 1/4] gpu: ipu-v3: pre: add tiled prefetch support

[Lucas Stach]

This configures the TPR unit, using the DRM format modifier. For now only
the single buffer modifiers are supported, as split buffer needs more
configuration for the required cropping.

Signed-off-by: Lucas Stach 
[p.za...@pengutronix.de: rebased after ERR009624 workaround]
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-pre.c | 29 ++---
 drivers/gpu/ipu-v3/ipu-prg.c |  2 +-
 drivers/gpu/ipu-v3/ipu-prv.h |  4 ++--
 3 files changed, 29 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index c860a7997cb5..f1cec3d70498 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -49,6 +49,10 @@
 #define IPU_PRE_TPR_CTRL   0x070
 #define  IPU_PRE_TPR_CTRL_TILE_FORMAT(v)   ((v & 0xff) << 0)
 #define  IPU_PRE_TPR_CTRL_TILE_FORMAT_MASK 0xff
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_16_BIT   (1 << 0)
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_SPLIT_BUF(1 << 4)
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_SINGLE_BUF   (1 << 5)
+#define  IPU_PRE_TPR_CTRL_TILE_FORMAT_SUPER_TILED  (1 << 6)
 
 #define IPU_PRE_PREFETCH_ENG_CTRL  0x080
 #define  IPU_PRE_PREF_ENG_CTRL_PREFETCH_EN (1 << 0)
@@ -147,7 +151,7 @@ int ipu_pre_get(struct ipu_pre *pre)
val = IPU_PRE_CTRL_HANDSHAKE_ABORT_SKIP_EN |
  IPU_PRE_CTRL_HANDSHAKE_EN |
  IPU_PRE_CTRL_TPR_REST_SEL |
- IPU_PRE_CTRL_BLOCK_16 | IPU_PRE_CTRL_SDW_UPDATE;
+ IPU_PRE_CTRL_SDW_UPDATE;
writel(val, pre->regs + IPU_PRE_CTRL);
 
pre->in_use = true;
@@ -163,14 +167,17 @@ void ipu_pre_put(struct ipu_pre *pre)
 
 void ipu_pre_configure(struct ipu_pre *pre, unsigned int width,
   unsigned int height, unsigned int stride, u32 format,
-  unsigned int bufaddr)
+  uint64_t modifier, unsigned int bufaddr)
 {
const struct drm_format_info *info = drm_format_info(format);
u32 active_bpp = info->cpp[0] >> 1;
u32 val;
 
/* calculate safe window for ctrl register updates */
-   pre->safe_window_end = height - 2;
+   if (modifier == DRM_FORMAT_MOD_LINEAR)
+   pre->safe_window_end = height - 2;
+   else
+   pre->safe_window_end = DIV_ROUND_UP(height, 4) - 1;
 
writel(bufaddr, pre->regs + IPU_PRE_CUR_BUF);
writel(bufaddr, pre->regs + IPU_PRE_NEXT_BUF);
@@ -203,9 +210,25 @@ void ipu_pre_configure(struct ipu_pre *pre, unsigned int 
width,
 
writel(pre->buffer_paddr, pre->regs + IPU_PRE_STORE_ENG_ADDR);
 
+   val = readl(pre->regs + IPU_PRE_TPR_CTRL);
+   val &= ~IPU_PRE_TPR_CTRL_TILE_FORMAT_MASK;
+   if (modifier != DRM_FORMAT_MOD_LINEAR) {
+   /* only support single buffer formats for now */
+   val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_SINGLE_BUF;
+   if (modifier == DRM_FORMAT_MOD_VIVANTE_SUPER_TILED)
+   val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_SUPER_TILED;
+   if (info->cpp[0] == 2)
+   val |= IPU_PRE_TPR_CTRL_TILE_FORMAT_16_BIT;
+   }
+   writel(val, pre->regs + IPU_PRE_TPR_CTRL);
+
val = readl(pre->regs + IPU_PRE_CTRL);
val |= IPU_PRE_CTRL_EN_REPEAT | IPU_PRE_CTRL_ENABLE |
   IPU_PRE_CTRL_SDW_UPDATE;
+   if (modifier == DRM_FORMAT_MOD_LINEAR)
+   val &= ~IPU_PRE_CTRL_BLOCK_EN;
+   else
+   val |= IPU_PRE_CTRL_BLOCK_EN;
writel(val, pre->regs + IPU_PRE_CTRL);
 }
 
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index fd98f48e8a08..1a4d3a635d1d 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -287,7 +287,7 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
*ipu_chan,
return ret;
 
ipu_pre_configure(prg->pres[chan->used_pre],
- width, height, stride, format, *eba);
+ width, height, stride, format, 0, *eba);
 
 
pm_runtime_get_sync(prg->dev);
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index ac4b8d658500..d6beee99b6b8 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -269,8 +269,8 @@ int ipu_pre_get(struct ipu_pre *pre);
 void ipu_pre_put(struct ipu_pre *pre);
 u32 ipu_pre_get_baddr(struct ipu_pre *pre);
 void ipu_pre_configure(struct ipu_pre *pre, unsigned int width,
-  unsigned int height,
-  unsigned int stride, u32 format, unsigned int bufaddr);
+  unsigned int height, unsigned int stride, u32 format,
+  uint64_t modifier, unsigned int bufaddr);
 void ipu_pre_update(struct ipu_pre *pre, unsigned int bufaddr);
 
 struct ipu_prg *ipu_prg_lookup_by_phandle(struct device *dev, const char *name,

[PATCH v2 3/4] drm/imx: add FB modifier support

[Lucas Stach]

This adds FB modifier support for the Vivante single buffer tiled formats,
when the PRG/PRE engines are present.

Signed-off-by: Lucas Stach 
---
v2: Use drm_atomic_add_affected_planes(9 to pull in all planes into
the atomic update, when assigning PREs.
---
 drivers/gpu/drm/imx/imx-drm-core.c |  1 +
 drivers/gpu/drm/imx/ipuv3-plane.c  | 65 ++
 2 files changed, 60 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 93c7e3f9b4a8..f52fb04ace22 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -265,6 +265,7 @@ static int imx_drm_bind(struct device *dev)
drm->mode_config.max_height = 4096;
drm->mode_config.funcs = _drm_mode_config_funcs;
drm->mode_config.helper_private = _drm_mode_config_helpers;
+   drm->mode_config.allow_fb_modifiers = true;
 
drm_mode_config_init(drm);
 
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 091393cb9659..32a6debf7107 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -551,7 +551,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
  drm_rect_width(>src) >> 16,
  drm_rect_height(>src) >> 16,
  fb->pitches[0], fb->format->format,
- 0, );
+ fb->modifier, );
}
 
if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
@@ -700,18 +700,71 @@ static const struct drm_plane_helper_funcs 
ipu_plane_helper_funcs = {
 int ipu_planes_assign_pre(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
+   struct drm_crtc_state *old_crtc_state, *crtc_state;
struct drm_plane_state *plane_state;
+   struct ipu_plane_state *ipu_state;
+   struct ipu_plane *ipu_plane;
struct drm_plane *plane;
+   struct drm_crtc *crtc;
int available_pres = ipu_prg_max_active_channels();
-   int i;
+   int ret, i;
+
+   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, crtc_state, 
i) {
+   ret = drm_atomic_add_affected_planes(state, crtc);
+   if (ret)
+   return ret;
+   }
+
+   /*
+* We are going over the planes in 2 passes: first we assign PREs to
+* planes with a tiling modifier, which need the PREs to resolve into
+* linear. Any failure to assign a PRE there is fatal. In the second
+* pass we try to assign PREs to linear FBs, to improve memory access
+* patterns for them. Failure at this point is non-fatal, as we can
+* scan out linear FBs without a PRE.
+*/
+   for_each_new_plane_in_state(state, plane, plane_state, i) {
+   ipu_state = to_ipu_plane_state(plane_state);
+   ipu_plane = to_ipu_plane(plane);
+
+   if (!plane_state->fb) {
+   ipu_state->use_pre = false;
+   continue;
+   }
+
+   if (!(plane_state->fb->flags & DRM_MODE_FB_MODIFIERS) ||
+   plane_state->fb->modifier == DRM_FORMAT_MOD_LINEAR)
+   continue;
+
+   if (!ipu_prg_present(ipu_plane->ipu) || !available_pres)
+   return -EINVAL;
+
+   if (!ipu_prg_format_supported(ipu_plane->ipu,
+ plane_state->fb->format->format,
+ plane_state->fb->modifier))
+   return -EINVAL;
+
+   ipu_state->use_pre = true;
+   available_pres--;
+   }
 
for_each_new_plane_in_state(state, plane, plane_state, i) {
-   struct ipu_plane_state *ipu_state =
-   to_ipu_plane_state(plane_state);
-   struct ipu_plane *ipu_plane = to_ipu_plane(plane);
+   ipu_state = to_ipu_plane_state(plane_state);
+   ipu_plane = to_ipu_plane(plane);
+
+   if (!plane_state->fb) {
+   ipu_state->use_pre = false;
+   continue;
+   }
+
+   if ((plane_state->fb->flags & DRM_MODE_FB_MODIFIERS) &&
+   plane_state->fb->modifier != DRM_FORMAT_MOD_LINEAR)
+   continue;
+
+   /* make sure that modifier is initialized */
+   plane_state->fb->modifier = DRM_FORMAT_MOD_LINEAR;
 
if (ipu_prg_present(ipu_plane->ipu) && available_pres &&
-   plane_state->fb &&
ipu_prg_format_supported(ipu_plane->ipu,
 plane_state->fb->format->format,
  

[PATCH v2 4/4] drm/imx: advertise supported plane format modifiers

[Lucas Stach]

Let userspace know about the supported modifiers, to make automatic
selection of a proper modifier possible.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/ipuv3-plane.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 32a6debf7107..849f4bde2a1a 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -77,6 +77,18 @@ static const uint32_t ipu_plane_formats[] = {
DRM_FORMAT_BGRX_A8,
 };
 
+static const uint64_t ipu_format_modifiers[] = {
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
+static const uint64_t pre_format_modifiers[] = {
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_VIVANTE_TILED,
+   DRM_FORMAT_MOD_VIVANTE_SUPER_TILED,
+   DRM_FORMAT_MOD_INVALID
+};
+
 int ipu_plane_irq(struct ipu_plane *ipu_plane)
 {
return ipu_idmac_channel_irq(ipu_plane->ipu, ipu_plane->ipu_ch,
@@ -303,6 +315,22 @@ void ipu_plane_destroy_state(struct drm_plane *plane,
kfree(ipu_state);
 }
 
+static bool ipu_plane_format_mod_supported(struct drm_plane *plane,
+  uint32_t format, uint64_t modifier)
+{
+   struct ipu_soc *ipu = to_ipu_plane(plane)->ipu;
+
+   /* linear is supported for all planes and formats */
+   if (modifier == DRM_FORMAT_MOD_LINEAR)
+   return true;
+
+   /* without a PRG there are no supported modifiers */
+   if (!ipu_prg_present(ipu))
+   return false;
+
+   return ipu_prg_format_supported(ipu, format, modifier);
+}
+
 static const struct drm_plane_funcs ipu_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
@@ -310,6 +338,7 @@ static const struct drm_plane_funcs ipu_plane_funcs = {
.reset  = ipu_plane_state_reset,
.atomic_duplicate_state = ipu_plane_duplicate_state,
.atomic_destroy_state   = ipu_plane_destroy_state,
+   .format_mod_supported = ipu_plane_format_mod_supported,
 };
 
 static int ipu_plane_atomic_check(struct drm_plane *plane,
@@ -784,6 +813,7 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, 
struct ipu_soc *ipu,
 enum drm_plane_type type)
 {
struct ipu_plane *ipu_plane;
+   const uint64_t *modifiers = ipu_format_modifiers;
int ret;
 
DRM_DEBUG_KMS("channel %d, dp flow %d, possible_crtcs=0x%x\n",
@@ -799,10 +829,13 @@ struct ipu_plane *ipu_plane_init(struct drm_device *dev, 
struct ipu_soc *ipu,
ipu_plane->dma = dma;
ipu_plane->dp_flow = dp;
 
+   if (ipu_prg_present(ipu))
+   modifiers = pre_format_modifiers;
+
ret = drm_universal_plane_init(dev, _plane->base, possible_crtcs,
   _plane_funcs, ipu_plane_formats,
   ARRAY_SIZE(ipu_plane_formats),
-  NULL, type, NULL);
+  modifiers, type, NULL);
if (ret) {
DRM_ERROR("failed to initialize plane\n");
kfree(ipu_plane);
-- 
2.11.0

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

[PATCH v2 2/4] gpu: ipu-v3: prg: add modifier support

[Lucas Stach]

Allow to pass through the modifier to the PRE unit and extend the
format check with the supported modifiers.

Signed-off-by: Lucas Stach 
---
 drivers/gpu/drm/imx/ipuv3-plane.c |  4 ++--
 drivers/gpu/ipu-v3/ipu-prg.c  | 13 ++---
 include/video/imx-ipu-v3.h|  2 +-
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c 
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 247c60e6bed2..091393cb9659 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -550,8 +550,8 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
ipu_prg_channel_configure(ipu_plane->ipu_ch, axi_id,
  drm_rect_width(>src) >> 16,
  drm_rect_height(>src) >> 16,
- fb->pitches[0],
- fb->format->format, );
+ fb->pitches[0], fb->format->format,
+ 0, );
}
 
if (old_state->fb && !drm_atomic_crtc_needs_modeset(crtc_state)) {
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 1a4d3a635d1d..067365c733c6 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -133,7 +133,14 @@ bool ipu_prg_format_supported(struct ipu_soc *ipu, 
uint32_t format,
if (info->num_planes != 1)
return false;
 
-   return true;
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case DRM_FORMAT_MOD_VIVANTE_TILED:
+   case DRM_FORMAT_MOD_VIVANTE_SUPER_TILED:
+   return true;
+   default:
+   return false;
+   }
 }
 EXPORT_SYMBOL_GPL(ipu_prg_format_supported);
 
@@ -266,7 +273,7 @@ EXPORT_SYMBOL_GPL(ipu_prg_channel_disable);
 int ipu_prg_channel_configure(struct ipuv3_channel *ipu_chan,
  unsigned int axi_id, unsigned int width,
  unsigned int height, unsigned int stride,
- u32 format, unsigned long *eba)
+ u32 format, uint64_t modifier, unsigned long *eba)
 {
int prg_chan = ipu_prg_ipu_to_prg_chan(ipu_chan->num);
struct ipu_prg *prg = ipu_chan->ipu->prg_priv;
@@ -287,7 +294,7 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
*ipu_chan,
return ret;
 
ipu_pre_configure(prg->pres[chan->used_pre],
- width, height, stride, format, 0, *eba);
+ width, height, stride, format, modifier, *eba);
 
 
pm_runtime_get_sync(prg->dev);
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index ce4c07688b13..abbad94e14a1 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -344,7 +344,7 @@ void ipu_prg_channel_disable(struct ipuv3_channel 
*ipu_chan);
 int ipu_prg_channel_configure(struct ipuv3_channel *ipu_chan,
  unsigned int axi_id,  unsigned int width,
  unsigned int height, unsigned int stride,
- u32 format, unsigned long *eba);
+ u32 format, uint64_t modifier, unsigned long 
*eba);
 
 /*
  * IPU CMOS Sensor Interface (csi) functions
-- 
2.11.0

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

[PATCH] gpu: ipu-v3: prg: switch to runtime PM

[Lucas Stach]

Instead of open-coding the clk enable/disable in all of the callers
move this to the RPM suspend/resume functions.

Signed-off-by: Lucas Stach 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-prg.c | 71 +++-
 1 file changed, 50 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 0013ca9f72c8..fd98f48e8a08 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -139,21 +140,11 @@ EXPORT_SYMBOL_GPL(ipu_prg_format_supported);
 int ipu_prg_enable(struct ipu_soc *ipu)
 {
struct ipu_prg *prg = ipu->prg_priv;
-   int ret;
 
if (!prg)
return 0;
 
-   ret = clk_prepare_enable(prg->clk_axi);
-   if (ret)
-   goto fail_disable_ipg;
-
-   return 0;
-
-fail_disable_ipg:
-   clk_disable_unprepare(prg->clk_ipg);
-
-   return ret;
+   return pm_runtime_get_sync(prg->dev);
 }
 EXPORT_SYMBOL_GPL(ipu_prg_enable);
 
@@ -164,7 +155,7 @@ void ipu_prg_disable(struct ipu_soc *ipu)
if (!prg)
return;
 
-   clk_disable_unprepare(prg->clk_axi);
+   pm_runtime_put(prg->dev);
 }
 EXPORT_SYMBOL_GPL(ipu_prg_disable);
 
@@ -255,7 +246,7 @@ void ipu_prg_channel_disable(struct ipuv3_channel *ipu_chan)
if (!chan->enabled || prg_chan < 0)
return;
 
-   clk_prepare_enable(prg->clk_ipg);
+   pm_runtime_get_sync(prg->dev);
 
val = readl(prg->regs + IPU_PRG_CTL);
val |= IPU_PRG_CTL_BYPASS(prg_chan);
@@ -264,7 +255,7 @@ void ipu_prg_channel_disable(struct ipuv3_channel *ipu_chan)
val = IPU_PRG_REG_UPDATE_REG_UPDATE;
writel(val, prg->regs + IPU_PRG_REG_UPDATE);
 
-   clk_disable_unprepare(prg->clk_ipg);
+   pm_runtime_put(prg->dev);
 
ipu_prg_put_pre(prg, prg_chan);
 
@@ -299,11 +290,7 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
*ipu_chan,
  width, height, stride, format, *eba);
 
 
-   ret = clk_prepare_enable(prg->clk_ipg);
-   if (ret) {
-   ipu_prg_put_pre(prg, prg_chan);
-   return ret;
-   }
+   pm_runtime_get_sync(prg->dev);
 
val = (stride - 1) & IPU_PRG_STRIDE_STRIDE_MASK;
writel(val, prg->regs + IPU_PRG_STRIDE(prg_chan));
@@ -336,7 +323,7 @@ int ipu_prg_channel_configure(struct ipuv3_channel 
*ipu_chan,
   (val & IPU_PRG_STATUS_BUFFER1_READY(prg_chan)),
   5, 1000);
 
-   clk_disable_unprepare(prg->clk_ipg);
+   pm_runtime_put(prg->dev);
 
chan->enabled = true;
return 0;
@@ -384,6 +371,12 @@ static int ipu_prg_probe(struct platform_device *pdev)
if (ret)
return ret;
 
+   ret = clk_prepare_enable(prg->clk_axi);
+   if (ret) {
+   clk_disable_unprepare(prg->clk_ipg);
+   return ret;
+   }
+
/* init to free running mode */
val = readl(prg->regs + IPU_PRG_CTL);
val |= IPU_PRG_CTL_SHADOW_EN;
@@ -392,7 +385,8 @@ static int ipu_prg_probe(struct platform_device *pdev)
/* disable address threshold */
writel(0x, prg->regs + IPU_PRG_THD);
 
-   clk_disable_unprepare(prg->clk_ipg);
+   pm_runtime_set_active(dev);
+   pm_runtime_enable(dev);
 
prg->dev = dev;
platform_set_drvdata(pdev, prg);
@@ -414,6 +408,40 @@ static int ipu_prg_remove(struct platform_device *pdev)
return 0;
 }
 
+#ifdef CONFIG_PM
+static int prg_suspend(struct device *dev)
+{
+   struct ipu_prg *prg = dev_get_drvdata(dev);
+
+   clk_disable_unprepare(prg->clk_axi);
+   clk_disable_unprepare(prg->clk_ipg);
+
+   return 0;
+}
+
+static int prg_resume(struct device *dev)
+{
+   struct ipu_prg *prg = dev_get_drvdata(dev);
+   int ret;
+
+   ret = clk_prepare_enable(prg->clk_ipg);
+   if (ret)
+   return ret;
+
+   ret = clk_prepare_enable(prg->clk_axi);
+   if (ret) {
+   clk_disable_unprepare(prg->clk_ipg);
+   return ret;
+   }
+
+   return 0;
+}
+#endif
+
+static const struct dev_pm_ops prg_pm_ops = {
+   SET_RUNTIME_PM_OPS(prg_suspend, prg_resume, NULL)
+};
+
 static const struct of_device_id ipu_prg_dt_ids[] = {
{ .compatible = "fsl,imx6qp-prg", },
{ /* sentinel */ },
@@ -424,6 +452,7 @@ struct platform_driver ipu_prg_drv = {
.remove = ipu_prg_remove,
.driver = {
.name   = "imx-ipu-prg",
+   .pm = _pm_ops,
.of_match_table = ipu_prg_dt_ids,
},
 };
-- 
2.11.0

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

Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Andrey Grodzovsky]

On 11/10/2017 07:17 AM, Christian König wrote:

Series is Acked-by: Christian König .

Please note that I think your OOM killer test shows quite a bug we 
currently have in the kernel driver.


A single allocation of 1TB shouldn't trigger the OOM killer, but 
rather be reacted immediately.


Maybe we should add a second test which does incremental 1GB allocations 
but still keep this tests ? With this test  i get a callstack as bellow 
+ crash of the test suite
with general protection fault - As normal behavior I would have expected 
just some errno returning from the amdgpu_bo_alloc which we could check 
in the test.


Thanks,
Andrey

[169053.128981 <72032.811683>] [ cut here ]
[169053.129006 <0.25>] WARNING: CPU: 0 PID: 22883 at 
mm/page_alloc.c:3883 __alloc_pages_slowpath+0xf03/0x14e0
[169053.129007 <0.01>] Modules linked in: amdgpu chash ttm 
drm_kms_helper drm i2c_algo_bit fb_sys_fops syscopyarea sysfillrect 
sysimgblt edac_mce_amd kvm_amd kvm irqbypass crct10dif_pclmul 
crc32_pclmul snd_hda_codec_realtek ghash_clmulni_intel 
snd_hda_codec_generic pcbc snd_hda_codec_hdmi snd_hda_intel aesni_intel 
snd_hda_codec aes_x86_64 snd_hda_core crypto_simd glue_helper snd_hwdep 
rfkill_gpio cryptd snd_pcm snd_seq_midi snd_seq_midi_event serio_raw 
snd_rawmidi snd_seq cdc_ether usbnet snd_seq_device joydev fam15h_power 
k10temp r8152 snd_timer mii i2c_piix4 rtsx_pci_ms snd memstick soundcore 
shpchp 8250_dw i2c_designware_platform i2c_designware_core mac_hid 
binfmt_misc nfsd auth_rpcgss nfs_acl lockd grace sunrpc parport_pc ppdev 
lp parport autofs4 rtsx_pci_sdmmc psmouse rtsx_pci sdhci_pci ahci sdhci 
libahci

[169053.129084 <0.77>]  video i2c_hid hid_generic usbhid hid
[169053.129096 <0.12>] CPU: 0 PID: 22883 Comm: lt-amdgpu_test 
Tainted: GW   4.14.0-rc3+ #1
[169053.129097 <0.01>] Hardware name: AMD Gardenia/Gardenia, 
BIOS RGA1101C 07/20/2015
[169053.129099 <0.02>] task: 880048803d80 task.stack: 
880064688000

[169053.129103 <0.04>] RIP: 0010:__alloc_pages_slowpath+0xf03/0x14e0
[169053.129105 <0.02>] RSP: 0018:88006468f108 EFLAGS: 00010246
[169053.129108 <0.03>] RAX:  RBX: 
014000c0 RCX: 81279065
[169053.129109 <0.01>] RDX: dc00 RSI: 
000f RDI: 82609000
[169053.129111 <0.02>] RBP: 88006468f328 R08: 
 R09: 8576
[169053.129113 <0.02>] R10: 5c2044e7 R11: 
 R12: 88006468f3d8
[169053.129114 <0.01>] R13: 880048803d80 R14: 
0140c0c0 R15: 000f
[169053.129117 <0.03>] FS:  7f707863b700() 
GS:88006ce0() knlGS:
[169053.129119 <0.02>] CS:  0010 DS:  ES:  CR0: 
80050033
[169053.129120 <0.01>] CR2: 0125 CR3: 
644cf000 CR4: 001406f0

[169053.129122 <0.02>] Call Trace:
[169053.129131 <0.09>]  ? __module_address+0x145/0x190
[169053.129135 <0.04>]  ? is_bpf_text_address+0xe/0x20
[169053.129140 <0.05>]  ? __kernel_text_address+0x12/0x40
[169053.129144 <0.04>]  ? unwind_get_return_address+0x36/0x50
[169053.129150 <0.06>]  ? memcmp+0x5b/0x90
[169053.129152 <0.02>]  ? warn_alloc+0x250/0x250
[169053.129156 <0.04>]  ? get_page_from_freelist+0x147/0x10f0
[169053.129160 <0.04>]  ? save_stack_trace+0x1b/0x20
[169053.129164 <0.04>]  ? kasan_kmalloc+0xad/0xe0
[169053.129186 <0.22>]  ? ttm_bo_mem_space+0x79/0x6b0 [ttm]
[169053.129196 <0.10>]  ? ttm_bo_validate+0x178/0x220 [ttm]
[169053.129200 <0.04>] __alloc_pages_nodemask+0x3c4/0x400
[169053.129203 <0.03>]  ? __alloc_pages_slowpath+0x14e0/0x14e0
[169053.129205 <0.02>]  ? __save_stack_trace+0x66/0xd0
[169053.129209 <0.04>]  ? rb_insert_color+0x32/0x3e0
[169053.129213 <0.04>]  ? do_syscall_64+0xea/0x280
[169053.129217 <0.04>]  alloc_pages_current+0x75/0x110
[169053.129221 <0.04>]  kmalloc_order+0x1f/0x80
[169053.129223 <0.02>]  kmalloc_order_trace+0x24/0xa0
[169053.129226 <0.03>]  __kmalloc+0x264/0x280
[169053.129383 <0.000157>] amdgpu_vram_mgr_new+0x11b/0x3b0 [amdgpu]
[169053.129391 <0.08>]  ? 
reservation_object_reserve_shared+0x64/0xf0

[169053.129401 <0.10>]  ttm_bo_mem_space+0x196/0x6b0 [ttm]
[169053.129478 <0.77>]  ? add_hole+0x20a/0x220 [drm]
[169053.129489 <0.11>]  ttm_bo_validate+0x178/0x220 [ttm]
[169053.129498 <0.09>]  ? ttm_bo_evict_mm+0x70/0x70 [ttm]
[169053.129508 <0.10>]  ? ttm_check_swapping+0xf6/0x110 [ttm]
[169053.129541 <0.33>]  ? drm_vma_offset_add+0x5b/0x80 [drm]
[169053.129572 <0.31>]  ? drm_vma_offset_add+0x68/0x80 [drm]
[169053.129584 <0.12>] ttm_bo_init_reserved+0x546/0x630 [ttm]
[169053.129716 <

Re: [PATCH] video: fbdev: Convert timers to use timer_setup()

[Bartlomiej Zolnierkiewicz]

On Thursday, November 09, 2017 10:40:13 AM Kees Cook wrote:
> On Thu, Nov 9, 2017 at 9:08 AM, Bartlomiej Zolnierkiewicz

[...]

> > [ Please compile these timer changes with PXA3XX_GCU_DEBUG and
> >   PXA3XX_GCU_DEBUG_TIMER defined. ]
> 
> Hm, these appear to be manual knobs? What do you think about wiring
> these up to a Kconfig so build tests for things like "make
> allmodconfig" would enable it? This would allow for much greater build
> coverage.

This is a good idea, care to send a patch?

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [PATCH] video: fbdev: pxa3xx_gcu: Convert timers to use timer_setup()

[Bartlomiej Zolnierkiewicz]

On Thursday, November 09, 2017 10:48:40 AM Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
> 
> This also fixes the use of the "priv" variable in QERROR(), since it was
> pointing to struct timer_list, not struct pxa3xx_gcu_priv.
> 
> Cc: Bartlomiej Zolnierkiewicz 
> Cc: "Gustavo A. R. Silva" 
> Cc: Himanshu Jha 
> Cc: dri-devel@lists.freedesktop.org
> Cc: linux-fb...@vger.kernel.org
> Signed-off-by: Kees Cook 
> ---
> If you can take this for v4.15, please do. Otherwise, I can carry it in the
> timers tree in late rc1. Thanks!

Thanks, I queued this for v4.15 with a trivial fix for:

>  #else
> -static inline void pxa3xx_gcu_init_debug_timer(void) {}
> +static inline void pxa3xx_gcu_init_debug_timer(struct pxa3xx_gcu_priv *) {}
>  #endif

which caused:

drivers/video/fbdev/pxa3xx-gcu.c: In function ‘pxa3xx_gcu_init_debug_timer’:
drivers/video/fbdev/pxa3xx-gcu.c:534:133: error: parameter name omitted
make[3]: *** [drivers/video/fbdev/pxa3xx-gcu.o] Error 1
make[3]: *** Waiting for unfinished jobs

for the non-debug case.

I also queued the original fbdev conversion patch on top of this one.

Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics

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

Re: [Intel-gfx] [PATCH] i915: pm: Be less agressive with clockfreq changes on Bay Trail

[Hans de Goede]

Hi,

On 10-11-17 15:56, Chris Wilson wrote:

Quoting Hans de Goede (2017-11-09 18:51:01)

Bay Trail devices are known to hang when changing the frequency often,
this is discussed in great length in:
https://bugzilla.kernel.org/show_bug.cgi?id=109051

Commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds
on Baytrail v3") is an attempt to workaround this. Several users in
bko109051 report that an earlier version of this patch, v1:
https://bugzilla.kernel.org/attachment.cgi?id=251471

Works better for them and they still see hangs with the merged v3.

Comparing the 2 versions shows that they are indeed not equivalent,
v1 not only skips writing the GEN6_RP* registers from valleyview_set_rps,
as v3 does. It also contained these modifications to i915_irq.c:

  if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
  if (!vlv_c0_above(dev_priv,
_priv->rps.down_ei, ,
-  dev_priv->rps.down_threshold))
+  VLV_RP_DOWN_EI_THRESHOLD))
  events |= GEN6_PM_RP_DOWN_THRESHOLD;
  dev_priv->rps.down_ei = now;
  }

  if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
  if (vlv_c0_above(dev_priv,
   _priv->rps.up_ei, ,
- dev_priv->rps.up_threshold))
+ VLV_RP_UP_EI_THRESHOLD))
  events |= GEN6_PM_RP_UP_THRESHOLD;
  dev_priv->rps.up_ei = now;
  }

Which use less aggressive up/down thresholds, which results in less
GEN6_PM_RP_*_THRESHOLD events and thus in less calls to intel_set_rps() ->
valleyview_set_rps() -> vlv_punit_write(PUNIT_REG_GPU_FREQ_REQ).
With the last call being the likely cause of the hang.

This commit hardcodes the threshold_up and _down values for Bay Trail to
less aggressive values, reducing the amount of clock frequency changes,
thus avoiding the hangs some people are still seeing with the merged fix.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=109051
Signed-off-by: Hans de Goede 
---
  drivers/gpu/drm/i915/i915_reg.h | 3 +++
  drivers/gpu/drm/i915/intel_pm.c | 5 -
  2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..2561af075ebb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1355,6 +1355,9 @@ enum i915_power_well_id {
  #defineVLV_BIAS_CPU_125_SOC_875 (6 << 2)
  #defineCHV_BIAS_CPU_50_SOC_50 (3 << 2)
  
+#define VLV_RP_UP_EI_THRESHOLD 90

+#define VLV_RP_DOWN_EI_THRESHOLD   70
+
  /* vlv2 north clock has */
  #define CCK_FUSE_REG   0x8
  #define  CCK_FUSE_HPLL_FREQ_MASK   0x3
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 01966b89be14..177b6caa0a38 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6096,8 +6096,11 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
 /* When byt can survive without system hang with dynamic
  * sw freq adjustments, this restriction can be lifted.
  */
-   if (IS_VALLEYVIEW(dev_priv))
+   if (IS_VALLEYVIEW(dev_priv)) {
+   threshold_up = VLV_RP_UP_EI_THRESHOLD;
+   threshold_down = VLV_RP_DOWN_EI_THRESHOLD;


Basically you want a limit on the frequency of ... pcode access?
As presented, you ultimately do not trust any write and the only
solution is to disable all writes. No RPS whatsoever, run at max and
hope rc6 works (maybe even decrease the rc6 threshold).

One of the ideas we floated was moving the pcode access to a worker and
ratelimiting the updates.


Yes ratelimiting the amount of vlv_punit_write(PUNIT_REG_GPU_FREQ_REQ)
calls is also something which came to my mind as an alternative solution.

As I tried to explain in the commit message my main inspiration for this
patch was that people were reporting different success rates with v1
and v3 of the Commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation 
thresholds
on Baytrail v3") patch.

Regards,

Hans




-Chris


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

Re: [Intel-gfx] [PATCH] i915: pm: Be less agressive with clockfreq changes on Bay Trail

[Chris Wilson]

Quoting Hans de Goede (2017-11-09 18:51:01)
> Bay Trail devices are known to hang when changing the frequency often,
> this is discussed in great length in:
> https://bugzilla.kernel.org/show_bug.cgi?id=109051
> 
> Commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds
> on Baytrail v3") is an attempt to workaround this. Several users in
> bko109051 report that an earlier version of this patch, v1:
> https://bugzilla.kernel.org/attachment.cgi?id=251471
> 
> Works better for them and they still see hangs with the merged v3.
> 
> Comparing the 2 versions shows that they are indeed not equivalent,
> v1 not only skips writing the GEN6_RP* registers from valleyview_set_rps,
> as v3 does. It also contained these modifications to i915_irq.c:
> 
>  if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
>  if (!vlv_c0_above(dev_priv,
>_priv->rps.down_ei, ,
> -  dev_priv->rps.down_threshold))
> +  VLV_RP_DOWN_EI_THRESHOLD))
>  events |= GEN6_PM_RP_DOWN_THRESHOLD;
>  dev_priv->rps.down_ei = now;
>  }
> 
>  if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
>  if (vlv_c0_above(dev_priv,
>   _priv->rps.up_ei, ,
> - dev_priv->rps.up_threshold))
> + VLV_RP_UP_EI_THRESHOLD))
>  events |= GEN6_PM_RP_UP_THRESHOLD;
>  dev_priv->rps.up_ei = now;
>  }
> 
> Which use less aggressive up/down thresholds, which results in less
> GEN6_PM_RP_*_THRESHOLD events and thus in less calls to intel_set_rps() ->
> valleyview_set_rps() -> vlv_punit_write(PUNIT_REG_GPU_FREQ_REQ).
> With the last call being the likely cause of the hang.
> 
> This commit hardcodes the threshold_up and _down values for Bay Trail to
> less aggressive values, reducing the amount of clock frequency changes,
> thus avoiding the hangs some people are still seeing with the merged fix.
> 
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=109051
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/i915/i915_reg.h | 3 +++
>  drivers/gpu/drm/i915/intel_pm.c | 5 -
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 68a58cce6ab1..2561af075ebb 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1355,6 +1355,9 @@ enum i915_power_well_id {
>  #defineVLV_BIAS_CPU_125_SOC_875 (6 << 2)
>  #defineCHV_BIAS_CPU_50_SOC_50 (3 << 2)
>  
> +#define VLV_RP_UP_EI_THRESHOLD 90
> +#define VLV_RP_DOWN_EI_THRESHOLD   70
> +
>  /* vlv2 north clock has */
>  #define CCK_FUSE_REG   0x8
>  #define  CCK_FUSE_HPLL_FREQ_MASK   0x3
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 01966b89be14..177b6caa0a38 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -6096,8 +6096,11 @@ static void gen6_set_rps_thresholds(struct 
> drm_i915_private *dev_priv, u8 val)
> /* When byt can survive without system hang with dynamic
>  * sw freq adjustments, this restriction can be lifted.
>  */
> -   if (IS_VALLEYVIEW(dev_priv))
> +   if (IS_VALLEYVIEW(dev_priv)) {
> +   threshold_up = VLV_RP_UP_EI_THRESHOLD;
> +   threshold_down = VLV_RP_DOWN_EI_THRESHOLD;

Basically you want a limit on the frequency of ... pcode access?
As presented, you ultimately do not trust any write and the only
solution is to disable all writes. No RPS whatsoever, run at max and
hope rc6 works (maybe even decrease the rc6 threshold).

One of the ideas we floated was moving the pcode access to a worker and
ratelimiting the updates.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: gem_cma_helper.c: Allow importing of contiguous scatterlists with nents > 1

[Liviu Dudau]

drm_gem_cma_prime_import_sg_table() will fail if the number of entries
in the sg_table > 1. However, you can have a device that uses an IOMMU
engine and can map a discontiguous buffer with multiple entries that
have consecutive sg_dma_addresses, effectively making it contiguous.
Allow for that scenario by testing the entries in the sg_table for
contiguous coverage.

Reviewed-by: Laurent Pinchart 
Signed-off-by: Liviu Dudau 
---

Laurent,

Thanks for the review! I would like to ask for one more favour: if you
are OK with this version, can you pull this patch through the drm-misc tree?

Many thanks,
Liviu

 drivers/gpu/drm/drm_gem_cma_helper.c | 22 --
 include/drm/drm_gem_cma_helper.h |  4 +++-
 2 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c 
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 020e7668dfaba..43b179212052d 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -482,8 +482,26 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
 {
struct drm_gem_cma_object *cma_obj;
 
-   if (sgt->nents != 1)
-   return ERR_PTR(-EINVAL);
+   if (sgt->nents != 1) {
+   /* check if the entries in the sg_table are contiguous */
+   dma_addr_t next_addr = sg_dma_address(sgt->sgl);
+   struct scatterlist *s;
+   unsigned int i;
+
+   for_each_sg(sgt->sgl, s, sgt->nents, i) {
+   /*
+* sg_dma_address(s) is only valid for entries
+* that have sg_dma_len(s) != 0
+*/
+   if (!sg_dma_len(s))
+   continue;
+
+   if (sg_dma_address(s) != next_addr)
+   return ERR_PTR(-EINVAL);
+
+   next_addr = sg_dma_address(s) + sg_dma_len(s);
+   }
+   }
 
/* Create a CMA GEM buffer. */
cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
diff --git a/include/drm/drm_gem_cma_helper.h b/include/drm/drm_gem_cma_helper.h
index 58a739bf15f1f..214aa85adc8d5 100644
--- a/include/drm/drm_gem_cma_helper.h
+++ b/include/drm/drm_gem_cma_helper.h
@@ -8,7 +8,9 @@
  * struct drm_gem_cma_object - GEM object backed by CMA memory allocations
  * @base: base GEM object
  * @paddr: physical address of the backing memory
- * @sgt: scatter/gather table for imported PRIME buffers
+ * @sgt: scatter/gather table for imported PRIME buffers. The table can have
+ *   more than one entry but they are guaranteed to have contiguous
+ *   DMA addresses.
  * @vaddr: kernel virtual address of the backing memory
  */
 struct drm_gem_cma_object {
-- 
2.14.3

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

[PULL] drm-intel-next-fixes

[Jani Nikula]

Hi Dave, the first batch of i915 fixes for drm-next/v4.15.

BR,
Jani.

The following changes since commit 8a6fb5b5823d863b07f670dc9e791d4622d5b7e9:

  Merge branch 'drm-next-4.15' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-11-06 16:18:59 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2017-11-10

for you to fetch changes up to e8c49fa96838101435b9e4884d49b30da7a4e0c6:

  drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCU 
(2017-11-09 16:18:37 +0200)


drm/i915 fixes for v4.15


Chris Wilson (6):
  drm/i915: Filter out spurious execlists context-switch interrupts
  drm/i915/execlists: Remove the priority "optimisation"
  drm/i915: Lock llist_del_first() vs llist_del_all()
  drm/i915: Idle the GPU before shinking everything
  drm/i915: Prune the reservation shared fence array
  drm/i915: Reorder context-close to avoid calling i915_vma_close() under 
RCU

Joonas Lahtinen (1):
  drm/i915: Disable lazy PPGTT page table optimization for vGPU

Maarten Lankhorst (1):
  drm/i915: Calculate ironlake intermediate watermarks correctly, v2.

Ville Syrjälä (1):
  drm/i915: Move init_clock_gating() back to where it was

 drivers/gpu/drm/i915/i915_gem.c|  8 -
 drivers/gpu/drm/i915/i915_gem_context.c| 12 +++
 drivers/gpu/drm/i915/i915_gem_gtt.c|  2 +-
 drivers/gpu/drm/i915/i915_gem_shrinker.c   | 12 +++
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 ++
 drivers/gpu/drm/i915/i915_irq.c|  6 ++--
 drivers/gpu/drm/i915/i915_vma.c|  7 
 drivers/gpu/drm/i915/intel_display.c   | 14 ++--
 drivers/gpu/drm/i915/intel_engine_cs.c |  5 +--
 drivers/gpu/drm/i915/intel_lrc.c   | 29 +++-
 drivers/gpu/drm/i915/intel_pm.c| 53 +++---
 drivers/gpu/drm/i915/intel_ringbuffer.h| 34 +--
 12 files changed, 133 insertions(+), 52 deletions(-)

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

Re: [PATCH] drm/vgem: Fix vgem_init to get drm device avaliable.

[Emil Velikov]

On 9 November 2017 at 23:46, Sharma, Deepak  wrote:

>>>
>>> Modify vgem_init to take platform dev as parent in drm_dev_init.
>>> This will make drm device available at "/sys/devices/platform/vgem"
>>> in x86 chromebook.
>>>
>> Shouldn't one update the drm_dev_init/drm_dev_alloc documentation while 
>> doing this?
>> But more importantly, this will change the "unique" string (see 
>> drm_dev_set_unique).
>
> Sorry I did not get your comment about updating drm_dev_init/drm_dev_alloc 
> documentation
> for this change. Do you see any issue if this "unique string " is changed
>
VGEM is unlike other DRM drivers and I'm not sure if there is any
userspace that depends on the exact value.
If there's none - great.

I'd still recommend updating the two functions' documentation, ideally
coupled with enforcing for *parent to be non NULL.
Could be code as follow-up though.

>> The topic around it rather convoluted and messy, so please check this change 
>> doesn't cause subtle regressions.
>> There's a doc hunk in drm_ioctl.c to begin with, plus userspace such as IGT 
>> [1] might rely on the current behaviour.
>>
>> HTH
>> Emil
>
> [1] https://cgit.freedesktop.org/drm/igt-gpu-tools/
>
> I did run vgem test from IGT to check for regression , do you suspect 
> regression in other tests ?
>
There are two vgem only and a handful of others. Quick grep shows:

tests/amdgpu/amd_prime.c
tests/gem_concurrent_all.c
tests/gem_exec_await.c
tests/gem_exec_fence.c
tests/gem_exec_latency.c
tests/gem_exec_schedule.c
tests/gem_ringfill.c
tests/gem_wait.c
tests/prime_vgem.c
tests/vgem_basic.c
tests/vgem_slow.c

Most of which use i915 <> vgem. If you don't have the HW to test, one
can use the Intel GFX trybot.
Just keep [1] in the To/CC list and you'll get a report with the results.

HTH
Emil

[1] intel-gfx-try...@lists.freedesktop.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Christian König]

Am 10.11.2017 um 13:17 schrieb Christian König:

Series is Acked-by: Christian König .

Please note that I think your OOM killer test shows quite a bug we 
currently have in the kernel driver.


A single allocation of 1TB shouldn't trigger the OOM killer, but 
rather be reacted immediately.


Typo: "rejected immediately".

Christian.



Instead I expected that we need to do multiple 1GB allocations to 
trigger the next problem that our TTM code doesn't imply a global limit.


Regards,
Christian.

Am 10.11.2017 um 05:29 schrieb Andrey Grodzovsky:

THe following  patch series intoroduce dynamic tests dusabling/enabling
in amdgpu  tester using Cunit API. Today test suits that
don't apply to specific HW just return success w/o executing while
single tests that can't be executed properly are commented out.

Suits are diasbled based on hooks they provide (e.g incompatible
ASIC or missing blocks) while single tests are diasbled explicitly 
since this is
usually due to some bug preventing from the tester  or the system  to 
handle

the test w/o crashing or killing the tester.

Inside this series also a minor cleanup and new test for memory over 
allocation.


Andrey Grodzovsky (4):
   amdgpu: Add functions to disable suites and tests.
   amdgpu: Use new suite/test disabling functionality.
   amdgpu: Move memory alloc tests in bo suite.
   amdgpu: Add memory over allocation test.

  tests/amdgpu/amdgpu_test.c    | 169 
+-

  tests/amdgpu/amdgpu_test.h    |  46 
  tests/amdgpu/basic_tests.c    |  49 
  tests/amdgpu/bo_tests.c   |  69 +
  tests/amdgpu/deadlock_tests.c |   8 +-
  tests/amdgpu/uvd_enc_tests.c  |  81 
  tests/amdgpu/vce_tests.c  |  65 
  tests/amdgpu/vcn_tests.c  |  74 --
  8 files changed, 363 insertions(+), 198 deletions(-)



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



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

Re: [PATCH v1 0/2] DRM driver for ILI9225 display panels

[Noralf Trønnes]

Hi David, nice to see a new driver.

Den 08.11.2017 04.52, skrev David Lechner:

This is a new driver for ILI9225 based display panels.

There are a couple of things that stand out:

1.  Despite my best efforts, I could not find a name for this display[1], so I
 have made up a generic name for it. If someone recognizes this and has a
 name for it, please speak up. The best documentation I could find was
 here[2].

2.  There is quite a bit of one-off code copied from mipi-dbi.c. Based on the
 feedback from a previous patch series, I'm guessing that we don't want to
 modify mipi-dbi.c to accommodate the ILI9225 controller because the ILI9225
 controller does not use standard MIPI commands. ILI9225 has it's own
 non-standard command set, but other than that, it pretty much matches the
 generic mipi-dbi driver in all regards.


Yes you're right, I don't want non MIPI code in mipi-dbi, but we can
try and make it flexible for usage with DBI like interfaces.


 Code that could be easily shared:

 a.  ili9225_buf_copy() is exactly the same as mipi_dbi_buf_copy()
 - ili9225_buf_copy() is used in ili9225_fb_dirty()
 - mipi_dbi_buf_copy() is static in mipi-dbi.c


You can export mipi_dbi_buf_copy().


 b.  ili9225_spi_cmd_max_speed() is exactly the same as
 mipi_dbi_spi_cmd_max_speed()
 - ili9225_spi_cmd_max_speed() is used in ili9225_command() below, so
   would not need to be copied if mipi_dbi_typec3_command() could be
   shared
 - mipi_dbi_spi_cmd_max_speed() is static in mipi-dbi.c


Same here, you can export the function.


 c.  ili9225_command() is nearly the same as mipi_dbi_typec3_command()
 - a few unused lines were removed so I didn't have to copy even more
   code, but these would not be an issue if code was shared
 - cmd == ILI9225_WRITE_DATA_TO_GRAM instead of
   cmd == MIPI_DCS_WRITE_MEMORY_START

 d.  ili9225_spi_init() is nearly the same as mipi_dbi_spi_init()
 - a few unused lines were removed so I didn't have to copy even more
   code, but these would not be an issue if code was shared
 - mipi->command = ili9225_command instead of
   mipi->command = mipi_dbi_typec3_command
 - this function would not need to be copied if 
mipi_dbi_typec3_command()
   was modified to work with the ILI9225 command set too


Looks like you can use mipi_dbi_spi_init() and reassign afterwards:
    mipi_dbi_spi_init();
    mipi->command = ili9225_command;


 e.  ili9225_init() is nearly the same as mipi_dbi_init()
 - only difference is ili9225_fb_funcs instead of mipi_dbi_fb_funcs


When we get framebuffer flushing trough atomic modeset, we'll use a generic
fb_dirty and at that point it will be possible to use mipi_dbi_init().
The actual flushing will happen in the update callback I guess.


3.  I haven't tried it, but I believe that it is possible to implement
 DRM_FORMAT_RGB888 directly instead of simulating DRM_FORMAT_XRGB.
 I don't know if there would be any real benefit to doing this. I am not
 familiar enough with userspace programs/libraries to know if this mode is
 universally used. And, it will only physically be 18-bit color instead of
 24-bit but will increase the amount of data transferred by 50% (3 bytes per
 pixel instead of 2). Implementing this would have a side effect of making
 the one-off shared code (described above) more than one-off though.


I have tried it on a display and I couldn't really tell the difference
between 16-bit and 18-bit colors, with X windows at least. And as you
say it's terrible for the framerate.

I'll look closer through the driver later today and see if I have more
comments.

Side note:
This controller can also do something called 24-bit 4 wire SPI. It uses a
Start byte the same way that the (only) SPI mode on ILI9320 and ILI9325 do.
I did a test implementation for ILI9325 where I used regmap as the register
abstraction: https://github.com/notro/tinydrm/blob/master/tinydrm-ili9325.c

Noralf.


[1]: https://github.com/Nkawu/TFT_22_ILI9225
[2]: http://www.hotmcu.com/22-176x220-tft-lcd-with-spi-interface-p-316.html

David Lechner (2):
   dt-bindings: Add binding for Ilitek ILI9225 display panels
   drm/tinydrm: add driver for ILI9225 panels

  .../devicetree/bindings/display/ilitek,ili9225.txt |  25 +
  MAINTAINERS|   6 +
  drivers/gpu/drm/tinydrm/Kconfig|  10 +
  drivers/gpu/drm/tinydrm/Makefile   |   1 +
  drivers/gpu/drm/tinydrm/ili9225.c  | 547 +
  5 files changed, 589 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/display/ilitek,ili9225.txt
  create mode 100644 drivers/gpu/drm/tinydrm/ili9225.c

--
2.7.4



___
dri-devel mailing list
dri-devel@lists.freedesktop.org

Re: [PATCH libdrm 0/4] Dynamicly disable suites and tets.

[Christian König]

Series is Acked-by: Christian König .

Please note that I think your OOM killer test shows quite a bug we 
currently have in the kernel driver.


A single allocation of 1TB shouldn't trigger the OOM killer, but rather 
be reacted immediately.


Instead I expected that we need to do multiple 1GB allocations to 
trigger the next problem that our TTM code doesn't imply a global limit.


Regards,
Christian.

Am 10.11.2017 um 05:29 schrieb Andrey Grodzovsky:

THe following  patch series intoroduce  dynamic tests dusabling/enabling
in amdgpu  tester using Cunit API. Today test suits that
don't apply to specific HW just return success w/o executing while
single tests that can't be executed properly are commented out.

Suits are diasbled based on hooks they provide (e.g incompatible
ASIC or missing blocks) while single tests are diasbled explicitly since this is
usually due to some bug preventing from the tester  or the system  to handle
the test w/o crashing or killing the tester.

Inside this series also a minor cleanup and new test for memory over allocation.

Andrey Grodzovsky (4):
   amdgpu: Add functions to disable suites and tests.
   amdgpu: Use new suite/test disabling functionality.
   amdgpu: Move memory alloc tests in bo suite.
   amdgpu: Add memory over allocation test.

  tests/amdgpu/amdgpu_test.c| 169 +-
  tests/amdgpu/amdgpu_test.h|  46 
  tests/amdgpu/basic_tests.c|  49 
  tests/amdgpu/bo_tests.c   |  69 +
  tests/amdgpu/deadlock_tests.c |   8 +-
  tests/amdgpu/uvd_enc_tests.c  |  81 
  tests/amdgpu/vce_tests.c  |  65 
  tests/amdgpu/vcn_tests.c  |  74 --
  8 files changed, 363 insertions(+), 198 deletions(-)



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

Re: [PATCH v6 00/10] rockchip: kevin: Enable edp display

[Enric Balletbo Serra]

Dear all,

2017-11-01 20:33 GMT+01:00 Sean Paul :
> On Tue, Oct 31, 2017 at 12:37:43PM +0800, JeffyChen wrote:
>> Hi Heiko,
>>
>> On 10/31/2017 07:01 AM, Heiko Stuebner wrote:
>> > As I was just looking at the edp dts change in patch1 again, does this
>> > series also contain a fix for the issue below [0] ?
>> >
>> > I'm still seeing this on 4.14-rc6 with the most recent drm tree merged in.
>> >
>> i saw that too, it should due to our psr code...i think Zain has solved
>> these in chromeos kernel, i will ask Zain if he have time to upstream them,
>> or maybe i'll try to upstream them.
>
> You need the patchset where I've refactored the psr locking/workers. I have a
> version of it based on Heiko's tree at
> https://cgit.freedesktop.org/~seanpaul/dogwood/log/?h=rk3399-display
>
> With this kernel, the backlight comes on, but I don't have anything on the
> display (which is why I didn't post it). I'll try putting this set on top and
> see what happens.
>

There is a patch in the ML sent by Emil [1], similar to the Sean
patch, that solves the issue.

And I can confirm that the Jeffy's patches + Emil patch makes the
display work on kevin or current rc8

[1] https://patchwork.kernel.org/patch/9985237/

Enric

> Sean
>
>> >
>> > Heiko
>> >
>> > [0]
>> >
>> > [   27.960120] BUG: scheduling while atomic: kworker/1:1/68/0x0002
>> > [   27.974429] Modules linked in: rockchipdrm dw_hdmi analogix_dp 
>> > drm_kms_helper panel_simple crc32_ce drm crct10dif_ce rockchip_saradc 
>> > pwm_bl pwm_cros_ec rockchip_thermal ip_tables x_tabl
>> > es ipv6 smsc95xx smsc75xx ax88179_178a asix usbnet phy_rockchip_pcie 
>> > pcie_rockchip
>> > [   28.008769] CPU: 1 PID: 68 Comm: kworker/1:1 Tainted: GW   
>> > 4.14.0-rc7-03201-g12490811b353 #559
>> > [   28.008774] Hardware name: Google Kevin (DT)
>> > [   28.008825] Workqueue: events analogix_dp_psr_work [rockchipdrm]
>> > [   28.008828] Call trace:
>> > [   28.008838] [] dump_backtrace+0x0/0x378
>> > [   28.008842] [] show_stack+0x14/0x20
>> > [   28.008847] [] dump_stack+0x9c/0xbc
>> > [   28.008852] [] __schedule_bug+0x4c/0x70
>> > [   28.008856] [] __schedule+0x558/0x5e8
>> > [   28.008859] [] schedule+0x38/0xa0
>> > [   28.008864] [] 
>> > schedule_hrtimeout_range_clock+0x84/0xe8
>> > [   28.008867] [] schedule_hrtimeout_range+0x10/0x18
>> > [   28.008870] [] usleep_range+0x64/0x78
>> > [   28.008882] [] analogix_dp_transfer+0x16c/0xa88 
>> > [analogix_dp]
>> > [   28.008891] [] analogix_dpaux_transfer+0x10/0x18 
>> > [analogix_dp]
>> > [   28.008950] [] drm_dp_dpcd_access+0x4c/0xf8 
>> > [drm_kms_helper]
>> > [   28.008994] [] drm_dp_dpcd_write+0x1c/0x28 
>> > [drm_kms_helper]
>> > [   28.009002] [] analogix_dp_disable_psr+0x60/0xb0 
>> > [analogix_dp]
>> > [   28.009036] [] analogix_dp_psr_work+0x4c/0xc0 
>> > [rockchipdrm]
>> > [   28.009040] [] process_one_work+0x1d4/0x348
>> > [   28.009043] [] worker_thread+0x48/0x470
>> > [   28.009048] [] kthread+0x12c/0x130
>> > [   28.009052] [] ret_from_fork+0x10/0x18
>> >
>> >
>> >
>> >
>>
>>
>
> --
> Sean Paul, Software Engineer, Google / Chromium OS
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH libdrm 0/6] drm-next header syncing

[Emil Velikov]

On 9 November 2017 at 08:28, Daniel Vetter  wrote:
> On Wed, Nov 08, 2017 at 11:34:41AM -0800, Eric Anholt wrote:
>> I wanted to update the vc4 header so that I could land some igt
>> testcases (though I'd much rather just be importing the header into
>> igt and ditching libdrm).  In the process, I cleaned up some other
>> header deltas to the kernel so that there's less diff for the next
>> person to look at.
>
> I'm mildly tempted to just pull a mesa in igt too and put the headers in
> directly. To avoid the need for way too many libdrm releases when hacking
> on tests we atm add all the uapi stuff with a local_ prefix, but that's
> kinda silly.
>
> Maybe start a thread with vc4 as example converted (I guess we need to
> make sure the include order is right) to get this started.

That shouldn't be an obstacle to merging Eric's patches, right?

I went through the series and it looks good. For the lot
Reviewed-by: Emil Velikov 

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

Re: [Intel-gfx] [PATCH v2] drm/printer: Add drm_vprintf()

[Daniel Vetter]

On Fri, Nov 10, 2017 at 09:52:26AM +, Chris Wilson wrote:
> Simple va_args equivalent to the existing drm_printf() for use with the
> drm_printer.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Daniel Vetter 

I guess you want an ack from Dave for merging through drm-intel, pls ping
him for that since I'm vacationing next week. Or offload to the drm-intel
maintainers :-)

Cheers, Daniel
> ---
>  drivers/gpu/drm/drm_print.c |  5 +
>  include/drm/drm_print.h | 14 ++
>  2 files changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
> index 82ff327eb2df..781518fd88e3 100644
> --- a/drivers/gpu/drm/drm_print.c
> +++ b/drivers/gpu/drm/drm_print.c
> @@ -55,13 +55,10 @@ EXPORT_SYMBOL(__drm_printfn_debug);
>   */
>  void drm_printf(struct drm_printer *p, const char *f, ...)
>  {
> - struct va_format vaf;
>   va_list args;
>  
>   va_start(args, f);
> - vaf.fmt = f;
> - vaf.va = 
> - p->printfn(p, );
> + drm_vprintf(p, f, );
>   va_end(args);
>  }
>  EXPORT_SYMBOL(drm_printf);
> diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
> index edcea83a5050..d8789b123cda 100644
> --- a/include/drm/drm_print.h
> +++ b/include/drm/drm_print.h
> @@ -80,6 +80,20 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
> va_format *vaf);
>  __printf(2, 3)
>  void drm_printf(struct drm_printer *p, const char *f, ...);
>  
> +/**
> + * drm_vprintf - print to a _printer stream
> + * @p: the _printer
> + * @f: format string
> + * @args: the va_list
> + */
> +__printf(2, 0)
> +static inline void
> +drm_vprintf(struct drm_printer *p, const char *fmt, va_list *va)
> +{
> + struct va_format vaf = { .fmt = fmt, .va = va };
> +
> + p->printfn(p, );
> +}
>  
>  /**
>   * drm_seq_file_printer - construct a _printer that outputs to _file
> -- 
> 2.15.0
> 
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH 2/2] drm/i915: sync dp link status checks against atomic commmits

[Daniel Vetter]

Two bits:
- check actual atomic state, the legacy stuff can only be looked at
  from within the atomic_commit_tail function, since it's only
  protected by ordering and not by any locks.

- Make sure we don't wreak the work an ongoing nonblocking commit is
  doing.

v2: We need the crtc lock too, because a plane update might change it
without having to acquire the connection_mutex (Maarten). Use
Maarten's changes for this locking, while keeping the logic that uses
the connection->commit->hw_done signal for syncing with nonblocking
commits.

v3: The initial state objects from the hw state readout do not have a
commit object. Check for that (spotted by CI).

Cc: Manasi Navare 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
References: https://bugs.freedesktop.org/show_bug.cgi?id=103336
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99272
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_dp.c | 57 -
 1 file changed, 51 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index cddd96b24878..59189cdee3db 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4319,6 +4319,8 @@ static void
 intel_dp_check_link_status(struct intel_dp *intel_dp)
 {
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
+   struct drm_connector_state *conn_state =
+   intel_dp->attached_connector->base.state;
struct drm_device *dev = intel_dp_to_dev(intel_dp);
u8 link_status[DP_LINK_STATUS_SIZE];
 
@@ -4329,10 +4331,16 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
return;
}
 
-   if (!intel_encoder->base.crtc)
+   if (!conn_state->crtc)
return;
 
-   if (!to_intel_crtc(intel_encoder->base.crtc)->active)
+   WARN_ON(!drm_modeset_is_locked(_state->crtc->mutex));
+
+   if (!conn_state->crtc->state->active)
+   return;
+
+   if (conn_state->commit &&
+   !try_wait_for_completion(_state->commit->hw_done))
return;
 
/*
@@ -4368,7 +4376,6 @@ intel_dp_check_link_status(struct intel_dp *intel_dp)
 static bool
 intel_dp_short_pulse(struct intel_dp *intel_dp)
 {
-   struct drm_device *dev = intel_dp_to_dev(intel_dp);
struct intel_encoder *intel_encoder = _to_dig_port(intel_dp)->base;
u8 sink_irq_vector = 0;
u8 old_sink_count = intel_dp->sink_count;
@@ -4408,9 +4415,8 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
DRM_DEBUG_DRIVER("CP or sink specific irq unhandled\n");
}
 
-   drm_modeset_lock(>mode_config.connection_mutex, NULL);
intel_dp_check_link_status(intel_dp);
-   drm_modeset_unlock(>mode_config.connection_mutex);
+
if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) {
DRM_DEBUG_KMS("Link Training Compliance Test requested\n");
/* Send a Hotplug Uevent to userspace to start modeset */
@@ -4860,8 +4866,19 @@ intel_dp_detect(struct drm_connector *connector,
  connector->base.id, connector->name);
 
/* If full detect is not performed yet, do a full detect */
-   if (!intel_dp->detect_done)
+   if (!intel_dp->detect_done) {
+   struct drm_crtc *crtc;
+   int ret;
+
+   crtc = connector->state->crtc;
+   if (crtc) {
+   ret = drm_modeset_lock(>mutex, ctx);
+   if (ret)
+   return ret;
+   }
+
status = intel_dp_long_pulse(intel_dp->attached_connector);
+   }
 
intel_dp->detect_done = false;
 
@@ -5146,10 +5163,38 @@ intel_dp_hpd_pulse(struct intel_digital_port 
*intel_dig_port, bool long_hpd)
}
 
if (!intel_dp->is_mst) {
+   struct drm_modeset_acquire_ctx ctx;
+   struct drm_connector *connector = 
_dp->attached_connector->base;
+   struct drm_crtc *crtc;
+   int iret;
+
+   drm_modeset_acquire_init(, 0);
+retry:
+   iret = drm_modeset_lock(>mode_config.connection_mutex, 
);
+   if (iret)
+   goto err;
+
+   crtc = connector->state->crtc;
+   if (crtc) {
+   iret = drm_modeset_lock(>mutex, );
+   if (iret)
+   goto err;
+   }
+
if (!intel_dp_short_pulse(intel_dp)) {
intel_dp->detect_done = false;
goto put_power;
}
+
+err:
+   if (iret == -EDEADLK) {
+   drm_modeset_backoff();
+   goto retry;
+   }
+
+   

[PATCH 1/2] drm/atomic-helper: always track connector commits, too

[Daniel Vetter]

It's useful for syncing async connector work like link retraining.

v2: Make it work (Manasi)

Cc: Manasi Navare 
Cc: Maarten Lankhorst 
Cc: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c18c271e7508..ced1ac8e68a0 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1793,11 +1793,8 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,

!try_wait_for_completion(_conn_state->commit->flip_done))
return -EBUSY;
 
-   /* commit tracked through new_crtc_state->commit, no need to do 
it explicitly */
-   if (new_conn_state->crtc)
-   continue;
-
-   commit = crtc_or_fake_commit(state, old_conn_state->crtc);
+   /* Always track connectors explicitly for e.g. link retraining. 
*/
+   commit = crtc_or_fake_commit(state, new_conn_state->crtc ?: 
old_conn_state->crtc);
if (!commit)
return -ENOMEM;
 
@@ -1811,10 +1808,7 @@ int drm_atomic_helper_setup_commit(struct 
drm_atomic_state *state,

!try_wait_for_completion(_plane_state->commit->flip_done))
return -EBUSY;
 
-   /*
-* Unlike connectors, always track planes explicitly for
-* async pageflip support.
-*/
+   /* Always track planes explicitly for async pageflip support. */
commit = crtc_or_fake_commit(state, new_plane_state->crtc ?: 
old_plane_state->crtc);
if (!commit)
return -ENOMEM;
-- 
2.15.0

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

RE: [PATCH 3/4] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

[He, Roger]

Please see comments inline

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Wednesday, November 08, 2017 11:00 PM
To: He, Roger ; amd-...@lists.freedesktop.org; 
dri-devel@lists.freedesktop.org
Subject: [PATCH 3/4] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

Needed for the next patch.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 52 
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
6f55310a9d09..d23592cfe42e 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -486,20 +486,21 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)  }
 
 /**
- * function ttm_bo_cleanup_refs_and_unlock
+ * function ttm_bo_cleanup_refs
  * If bo idle, remove from delayed- and lru lists, and unref.
  * If not idle, do nothing.
  *
  * Must be called with lru_lock and reservation held, this function
- * will drop both before returning.
+ * will drop the lru lock and optionally the reservation lock before returning.
  *
  * @interruptible Any sleeps should occur interruptibly.
  * @no_wait_gpu   Never wait for gpu. Return -EBUSY instead.
+ * @unlock_resv   Unlock the reservation lock as well.
  */
 
-static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo,
- bool interruptible,
- bool no_wait_gpu)
+static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
+  bool interruptible, bool no_wait_gpu,
+  bool unlock_resv)
 {
struct ttm_bo_global *glob = bo->glob;
struct reservation_object *resv;
@@ -518,7 +519,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
if (ret && !no_wait_gpu) {
long lret;
 
-   reservation_object_unlock(bo->resv);
+   if (unlock_resv)
+   reservation_object_unlock(bo->resv);
spin_unlock(>lru_lock);
 
lret = reservation_object_wait_timeout_rcu(resv, true, @@ 
-531,19 +533,22 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return -EBUSY;
 
spin_lock(>lru_lock);
-   ret = __ttm_bo_reserve(bo, false, true, NULL);
-
-   /*
-* We raced, and lost, someone else holds the reservation now,
-* and is probably busy in ttm_bo_cleanup_memtype_use.
-*
-* Even if it's not the case, because we finished waiting any
-* delayed destruction would succeed, so just return success
-* here.
-*/
-   if (ret) {
-   spin_unlock(>lru_lock);
-   return 0;
+   if (unlock_resv) {
+   ret = __ttm_bo_reserve(bo, false, true, NULL);
+   /*
+* We raced, and lost, someone else holds the 
reservation now,
+* and is probably busy in ttm_bo_cleanup_memtype_use.
+*
+* Even if it's not the case, because we finished 
waiting any
+* delayed destruction would succeed, so just return 
success
+* here.
+*/
+   if (ret) {
+   spin_unlock(>lru_lock);
+   return 0;
+   }
+   } else {
+   ret = 0;
}
}

[Roger]: 
//Looks like we also need the condition adjudge here.  Otherwise, it 
will unlock the vm root bo reservation that is not what we want here I think.
if (unlock_resv) //need this condition here
reservation_object_unlock(bo->resv);

return 0;
}

 
@@ -600,8 +605,8 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
}
 
if (!ret)
-   ret = ttm_bo_cleanup_refs_and_unlock(entry, false,
-!remove_all);
+   ret = ttm_bo_cleanup_refs(entry, false, !remove_all,
+ true);
else
spin_unlock(>lru_lock);
 
@@ -770,8 +775,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
kref_get(>list_kref);
 
if (!list_empty(>ddestroy)) {
-   ret = ttm_bo_cleanup_refs_and_unlock(bo, interruptible,
-no_wait_gpu);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, 

RE: [PATCH 6/7] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

[He, Roger]

static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
   bool interruptible, bool no_wait_gpu,
   bool unlock_resv)
{
..
ttm_bo_del_from_lru(bo);
list_del_init(>ddestroy);
kref_put(>list_kref, ttm_bo_ref_bug);

spin_unlock(>lru_lock);
ttm_bo_cleanup_memtype_use(bo);

if (unlock_resv)
  //[Roger]: not sure we should add condition here as well. If not, for 
per-vm-bo, eviction would unlock the VM root BO resv obj which is not we want I 
think.
reservation_object_unlock(bo->resv);

return 0;
}


Thanks
Roger(Hongbo.He)

-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com] 
Sent: Thursday, November 09, 2017 4:59 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; He, Roger 
; mic...@daenzer.net
Subject: [PATCH 6/7] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

Needed for the next patch.

Signed-off-by: Christian König 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 52 
 1 file changed, 28 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 
6f5d18366e6e..50a678b504f3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -486,20 +486,21 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)  }
 
 /**
- * function ttm_bo_cleanup_refs_and_unlock
+ * function ttm_bo_cleanup_refs
  * If bo idle, remove from delayed- and lru lists, and unref.
  * If not idle, do nothing.
  *
  * Must be called with lru_lock and reservation held, this function
- * will drop both before returning.
+ * will drop the lru lock and optionally the reservation lock before returning.
  *
  * @interruptible Any sleeps should occur interruptibly.
  * @no_wait_gpu   Never wait for gpu. Return -EBUSY instead.
+ * @unlock_resv   Unlock the reservation lock as well.
  */
 
-static int ttm_bo_cleanup_refs_and_unlock(struct ttm_buffer_object *bo,
- bool interruptible,
- bool no_wait_gpu)
+static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo,
+  bool interruptible, bool no_wait_gpu,
+  bool unlock_resv)
 {
struct ttm_bo_global *glob = bo->glob;
struct reservation_object *resv;
@@ -518,7 +519,8 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
if (ret && !no_wait_gpu) {
long lret;
 
-   reservation_object_unlock(bo->resv);
+   if (unlock_resv)
+   reservation_object_unlock(bo->resv);
spin_unlock(>lru_lock);
 
lret = reservation_object_wait_timeout_rcu(resv, true, @@ 
-531,19 +533,22 @@ static int ttm_bo_cleanup_refs_and_unlock(struct 
ttm_buffer_object *bo,
return -EBUSY;
 
spin_lock(>lru_lock);
-   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
-
-   /*
-* We raced, and lost, someone else holds the reservation now,
-* and is probably busy in ttm_bo_cleanup_memtype_use.
-*
-* Even if it's not the case, because we finished waiting any
-* delayed destruction would succeed, so just return success
-* here.
-*/
-   if (ret) {
-   spin_unlock(>lru_lock);
-   return 0;
+   if (unlock_resv) {
+   ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
+   /*
+* We raced, and lost, someone else holds the 
reservation now,
+* and is probably busy in ttm_bo_cleanup_memtype_use.
+*
+* Even if it's not the case, because we finished 
waiting any
+* delayed destruction would succeed, so just return 
success
+* here.
+*/
+   if (ret) {
+   spin_unlock(>lru_lock);
+   return 0;
+   }
+   } else {
+   ret = 0;
}
}
 
@@ -600,8 +605,8 @@ static int ttm_bo_delayed_delete(struct ttm_bo_device 
*bdev, bool remove_all)
}
 
if (!ret)
-   ret = ttm_bo_cleanup_refs_and_unlock(entry, false,
-!remove_all);
+   ret = ttm_bo_cleanup_refs(entry, false, !remove_all,
+

[PATCH v2] drm/printer: Add drm_vprintf()

[Chris Wilson]

Simple va_args equivalent to the existing drm_printf() for use with the
drm_printer.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_print.c |  5 +
 include/drm/drm_print.h | 14 ++
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/drm_print.c
index 82ff327eb2df..781518fd88e3 100644
--- a/drivers/gpu/drm/drm_print.c
+++ b/drivers/gpu/drm/drm_print.c
@@ -55,13 +55,10 @@ EXPORT_SYMBOL(__drm_printfn_debug);
  */
 void drm_printf(struct drm_printer *p, const char *f, ...)
 {
-   struct va_format vaf;
va_list args;
 
va_start(args, f);
-   vaf.fmt = f;
-   vaf.va = 
-   p->printfn(p, );
+   drm_vprintf(p, f, );
va_end(args);
 }
 EXPORT_SYMBOL(drm_printf);
diff --git a/include/drm/drm_print.h b/include/drm/drm_print.h
index edcea83a5050..d8789b123cda 100644
--- a/include/drm/drm_print.h
+++ b/include/drm/drm_print.h
@@ -80,6 +80,20 @@ void __drm_printfn_debug(struct drm_printer *p, struct 
va_format *vaf);
 __printf(2, 3)
 void drm_printf(struct drm_printer *p, const char *f, ...);
 
+/**
+ * drm_vprintf - print to a _printer stream
+ * @p: the _printer
+ * @f: format string
+ * @args: the va_list
+ */
+__printf(2, 0)
+static inline void
+drm_vprintf(struct drm_printer *p, const char *fmt, va_list *va)
+{
+   struct va_format vaf = { .fmt = fmt, .va = va };
+
+   p->printfn(p, );
+}
 
 /**
  * drm_seq_file_printer - construct a _printer that outputs to _file
-- 
2.15.0

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

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Jani Nikula]

On Thu, 09 Nov 2017, Russell King - ARM Linux  wrote:
> On Thu, Nov 09, 2017 at 02:12:45PM +0200, Jani Nikula wrote:
>> And as I said elsewhere in the thread, Russell's patch may be relevant
>> for current Linus' master and stable. We just need to reconciliate how
>> the two things should work together in drm-next and v4.15 and on.
>
> Exactly, the patch is intended for current kernels.  The hint is that
> (a) it's a bug fix, (b) it says "fix" in the title, and (c) it has the
> stable attributation which says "apply me to previous kernels".
>
> Daniel's response effectively says "no, we're not going to accept the
> patch, work on a fix with some development code."

Please don't turn a technical discussion into an unnecessary
altercation. Focusing on finding the best solution instead would be much
appreciated.

> So, unless someone wants to tell me that it's acceptable to develop bug
> fixes against Linus' tree _for_ Linus' tree and accept this patch, or
> show some other solution that can be applied to Linus' current tree and
> backported to stable trees, I'm just not going to bother in future -
> someone else can end up doing the work.

I also don't want non-regression fixes merged to Linus' tree if they're
known to regress much wider impact work queued to Linus' tree for the
next merge window. And it's not just some development code, it's been in
drm-next and linux-next for more than 1½ months now. So I want to figure
this out first.

Luís, can you try try drm-next *with* Russell's patch, please?


BR,
Jani.

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

Recall: [PATCH 3/4] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

[He, Roger]

He, Roger would like to recall the message, "[PATCH 3/4] drm/ttm: make 
unlocking in ttm_bo_cleanup_refs optional".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Recall: [PATCH 3/4] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

[He, Roger]

He, Roger would like to recall the message, "[PATCH 3/4] drm/ttm: make 
unlocking in ttm_bo_cleanup_refs optional".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Recall: [PATCH 3/4] drm/ttm: make unlocking in ttm_bo_cleanup_refs optional

[He, Roger]

He, Roger would like to recall the message, "[PATCH 3/4] drm/ttm: make 
unlocking in ttm_bo_cleanup_refs optional".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 7/7] drm/ttm: optimize ttm_mem_evict_first v2

[Chunming Zhou]

On 2017年11月09日 16:59, Christian König wrote:

Deleted BOs with the same reservation object can be reaped even if they
can't be reserved.

v2: rebase and we still need to remove/add the BO from/to the LRU.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 39 +++
  1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 50a678b504f3..6545c4344684 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -735,20 +735,37 @@ bool ttm_bo_eviction_valuable(struct ttm_buffer_object 
*bo,
  EXPORT_SYMBOL(ttm_bo_eviction_valuable);
  
  static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

-   uint32_t mem_type,
-   const struct ttm_place *place,
-   bool interruptible,
-   bool no_wait_gpu)
+  struct reservation_object *resv,
+  uint32_t mem_type,
+  const struct ttm_place *place,
+  bool interruptible,
+  bool no_wait_gpu)
  {
struct ttm_bo_global *glob = bdev->glob;
struct ttm_mem_type_manager *man = >man[mem_type];
struct ttm_buffer_object *bo;
int ret = -EBUSY;
+   bool locked;
unsigned i;
  
  	spin_lock(>lru_lock);

for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
list_for_each_entry(bo, >lru[i], lru) {
+   if (bo->resv == resv) {
+   if (list_empty(>ddestroy))
+   continue;
I don't think only destroying BO can be evicted under per-vm-bo case, 
but also normal BO should as well.

I'd give an example:
1. vm-A allocates all vram;
2. vm-B also try to allocate full vram, so the BOs of vram in vm-A will 
be evicted to GTT.
3. vm-A is trying to allocate all GTT, if we don't allow eviction or 
swap, then will fail here.


As above, we shouldn't disallow eviction and swap during allocation, we 
aren't able to predict what case happen.
For over limit allocation, at worst, they will be returned with failed 
status while doing its CS.
If you think the allocation shouldn't be over limitation of memory, we 
can add the checking condition before allocation every time, but not 
disallow eviction and swap in allocation, which really breaks the used TTM.


Regards,
David Zhou


+
+   if (place &&
+   !bdev->driver->eviction_valuable(bo, place))
+   continue;
+
+   ttm_bo_del_from_lru(bo);
+
+   ret = 0;
+   locked = false;
+   break;
+   }
+
ret = reservation_object_trylock(bo->resv) ? 0 : -EBUSY;
if (ret)
continue;
@@ -760,6 +777,7 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
continue;
}
  
+			locked = true;

break;
}
  
@@ -775,7 +793,8 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,

kref_get(>list_kref);
  
  	if (!list_empty(>ddestroy)) {

-   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu, true);
+   ret = ttm_bo_cleanup_refs(bo, interruptible, no_wait_gpu,
+ locked);
kref_put(>list_kref, ttm_bo_release_list);
return ret;
}
@@ -786,7 +805,10 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
BUG_ON(ret != 0);
  
  	ret = ttm_bo_evict(bo, interruptible, no_wait_gpu);

-   ttm_bo_unreserve(bo);
+   if (locked)
+   ttm_bo_unreserve(bo);
+   else
+   ttm_bo_add_to_lru(bo);
  
  	kref_put(>list_kref, ttm_bo_release_list);

return ret;
@@ -850,7 +872,7 @@ static int ttm_bo_mem_force_space(struct ttm_buffer_object 
*bo,
return ret;
if (mem->mm_node)
break;
-   ret = ttm_mem_evict_first(bdev, mem_type, place,
+   ret = ttm_mem_evict_first(bdev, bo->resv, mem_type, place,
  interruptible, no_wait_gpu);
if (unlikely(ret != 0))
return ret;
@@ -1353,7 +1375,8 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
for (i = 0; i < TTM_MAX_BO_PRIORITY; ++i) {
while (!list_empty(>lru[i])) {
spin_unlock(>lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, NULL, false, 
false);
+   ret 

[PATCH] video: fbdev: pxa3xx_gcu: Convert timers to use timer_setup()

[Kees Cook]

In preparation for unconditionally passing the struct timer_list pointer to
all timer callbacks, switch to using the new timer_setup() and from_timer()
to pass the timer pointer explicitly.

This also fixes the use of the "priv" variable in QERROR(), since it was
pointing to struct timer_list, not struct pxa3xx_gcu_priv.

Cc: Bartlomiej Zolnierkiewicz 
Cc: "Gustavo A. R. Silva" 
Cc: Himanshu Jha 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Kees Cook 
---
If you can take this for v4.15, please do. Otherwise, I can carry it in the
timers tree in late rc1. Thanks!
---
 drivers/video/fbdev/pxa3xx-gcu.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 164fb524744a..208cd5a5e15c 100644
--- a/drivers/video/fbdev/pxa3xx-gcu.c
+++ b/drivers/video/fbdev/pxa3xx-gcu.c
@@ -512,24 +512,26 @@ pxa3xx_gcu_mmap(struct file *file, struct vm_area_struct 
*vma)
 
 #ifdef PXA3XX_GCU_DEBUG_TIMER
 static struct timer_list pxa3xx_gcu_debug_timer;
+static struct pxa3xx_gcu_priv *debug_timer_priv;
 
-static void pxa3xx_gcu_debug_timedout(unsigned long ptr)
+static void pxa3xx_gcu_debug_timedout(struct timer_list *unused)
 {
-   struct pxa3xx_gcu_priv *priv = (struct pxa3xx_gcu_priv *) ptr;
+   struct pxa3xx_gcu_priv *priv = debug_timer_priv;
 
QERROR("Timer DUMP");
 
-   /* init the timer structure */
-   setup_timer(_gcu_debug_timer, pxa3xx_gcu_debug_timedout, ptr);
mod_timer(_gcu_debug_timer, jiffies + 5 * HZ);
 }
 
-static void pxa3xx_gcu_init_debug_timer(void)
+static void pxa3xx_gcu_init_debug_timer(struct pxa3xx_gcu_priv *priv)
 {
-   pxa3xx_gcu_debug_timedout((unsigned long) _gcu_debug_timer);
+   /* init the timer structure */
+   debug_timer_priv = priv;
+   timer_setup(_gcu_debug_timer, pxa3xx_gcu_debug_timedout, 0);
+   pxa3xx_gcu_debug_timedout(NULL);
 }
 #else
-static inline void pxa3xx_gcu_init_debug_timer(void) {}
+static inline void pxa3xx_gcu_init_debug_timer(struct pxa3xx_gcu_priv *) {}
 #endif
 
 static int
@@ -666,7 +668,7 @@ static int pxa3xx_gcu_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, priv);
priv->resource_mem = r;
pxa3xx_gcu_reset(priv);
-   pxa3xx_gcu_init_debug_timer();
+   pxa3xx_gcu_init_debug_timer(priv);
 
dev_info(dev, "registered @0x%p, DMA 0x%p (%d bytes), IRQ %d\n",
(void *) r->start, (void *) priv->shared_phys,
-- 
2.7.4


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

[PATCH] i915: pm: Be less agressive with clockfreq changes on Bay Trail

[Hans de Goede]

Bay Trail devices are known to hang when changing the frequency often,
this is discussed in great length in:
https://bugzilla.kernel.org/show_bug.cgi?id=109051

Commit 6067a27d1f01 ("drm/i915: Avoid tweaking evaluation thresholds
on Baytrail v3") is an attempt to workaround this. Several users in
bko109051 report that an earlier version of this patch, v1:
https://bugzilla.kernel.org/attachment.cgi?id=251471

Works better for them and they still see hangs with the merged v3.

Comparing the 2 versions shows that they are indeed not equivalent,
v1 not only skips writing the GEN6_RP* registers from valleyview_set_rps,
as v3 does. It also contained these modifications to i915_irq.c:

 if (pm_iir & GEN6_PM_RP_DOWN_EI_EXPIRED) {
 if (!vlv_c0_above(dev_priv,
   _priv->rps.down_ei, ,
-  dev_priv->rps.down_threshold))
+  VLV_RP_DOWN_EI_THRESHOLD))
 events |= GEN6_PM_RP_DOWN_THRESHOLD;
 dev_priv->rps.down_ei = now;
 }

 if (pm_iir & GEN6_PM_RP_UP_EI_EXPIRED) {
 if (vlv_c0_above(dev_priv,
  _priv->rps.up_ei, ,
- dev_priv->rps.up_threshold))
+ VLV_RP_UP_EI_THRESHOLD))
 events |= GEN6_PM_RP_UP_THRESHOLD;
 dev_priv->rps.up_ei = now;
 }

Which use less aggressive up/down thresholds, which results in less
GEN6_PM_RP_*_THRESHOLD events and thus in less calls to intel_set_rps() ->
valleyview_set_rps() -> vlv_punit_write(PUNIT_REG_GPU_FREQ_REQ).
With the last call being the likely cause of the hang.

This commit hardcodes the threshold_up and _down values for Bay Trail to
less aggressive values, reducing the amount of clock frequency changes,
thus avoiding the hangs some people are still seeing with the merged fix.

Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=109051
Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_pm.c | 5 -
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 68a58cce6ab1..2561af075ebb 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1355,6 +1355,9 @@ enum i915_power_well_id {
 #defineVLV_BIAS_CPU_125_SOC_875 (6 << 2)
 #defineCHV_BIAS_CPU_50_SOC_50 (3 << 2)
 
+#define VLV_RP_UP_EI_THRESHOLD 90
+#define VLV_RP_DOWN_EI_THRESHOLD   70
+
 /* vlv2 north clock has */
 #define CCK_FUSE_REG   0x8
 #define  CCK_FUSE_HPLL_FREQ_MASK   0x3
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 01966b89be14..177b6caa0a38 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -6096,8 +6096,11 @@ static void gen6_set_rps_thresholds(struct 
drm_i915_private *dev_priv, u8 val)
/* When byt can survive without system hang with dynamic
 * sw freq adjustments, this restriction can be lifted.
 */
-   if (IS_VALLEYVIEW(dev_priv))
+   if (IS_VALLEYVIEW(dev_priv)) {
+   threshold_up = VLV_RP_UP_EI_THRESHOLD;
+   threshold_down = VLV_RP_DOWN_EI_THRESHOLD;
goto skip_hw_write;
+   }
 
I915_WRITE(GEN6_RP_UP_EI,
   GT_INTERVAL_FROM_US(dev_priv, ei_up));
-- 
2.14.3

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

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Russell King - ARM Linux]

On Thu, Nov 09, 2017 at 09:23:18AM +0100, Daniel Vetter wrote:
> On Tue, Nov 07, 2017 at 11:27:21AM +, Russell King wrote:
> > Parsing the EDID for HDMI and audio information in the get_modes()
> > callback is incorrect - this only parses the EDID read from the
> > connector, not any override or firmware provided EDID.
> > 
> > The correct place to parse the EDID for these parameters is the
> > fill_modes() callback, after we've called the helper.  Move the parsing
> > there.  This caused problems for Luís Mendes.
> > 
> > Cc: 
> > Reported-by: Luís Mendes 
> > Tested-by: Luís Mendes 
> > Signed-off-by: Russell King 
> > ---
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28 
> >  1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index 9fe407f49986..2516a1c18a10 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -1905,10 +1905,7 @@ static int dw_hdmi_connector_get_modes(struct 
> > drm_connector *connector)
> > dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
> > edid->width_cm, edid->height_cm);
> >  
> > -   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> > -   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> > drm_mode_connector_update_edid_property(connector, edid);
> > -   cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
> > ret = drm_add_edid_modes(connector, edid);
> > /* Store the ELD */
> > drm_edid_to_eld(connector, edid);
> > @@ -1920,6 +1917,29 @@ static int dw_hdmi_connector_get_modes(struct 
> > drm_connector *connector)
> > return ret;
> >  }
> >  
> > +static int dw_hdmi_connector_fill_modes(struct drm_connector *connector,
> > +   uint32_t maxX, uint32_t maxY)
> > +{
> > +   struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> > +   connector);
> > +   int ret;
> > +
> > +   ret = drm_helper_probe_single_connector_modes(connector, maxX, maxY);
> > +
> > +   if (connector->edid_blob_ptr) {
> > +   struct edid *edid = (void *)connector->edid_blob_ptr->data;
> > +
> > +   hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> > +   hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> > +   cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier, edid);
> > +   } else {
> > +   hdmi->sink_is_hdmi = false;
> > +   hdmi->sink_has_audio = false;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> >  static void dw_hdmi_connector_force(struct drm_connector *connector)
> >  {
> > struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> > @@ -1933,7 +1953,7 @@ static void dw_hdmi_connector_force(struct 
> > drm_connector *connector)
> >  }
> >  
> >  static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
> > -   .fill_modes = drm_helper_probe_single_connector_modes,
> > +   .fill_modes = dw_hdmi_connector_fill_modes,
> 
> Papering over helper functions shouldn't be necessary, except the helper
> functions not handling the override edid is a known issue. Jani Nikula is
> working on a proper fix, please coordinate with him.

So, what you're basically saying is that fixing real bugs that affect
users is not something that DRM people want.  That's fine, I'll ignore
people who come to me for help with DRM bugs in future then because
it's obviously a dead loss.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Luís Mendes]

Complementing my previous email information with better dmesg output
(I had booted with my TV monitor off in my previous email):
[8.687907] [drm] Initialized etnaviv 1.1.0 20151214 for
gpu-subsystem on minor 0
[8.689356] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[8.689370] [drm] No driver support for vblank timestamp query.
[8.690733] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
ipu_crtc_ops [imxdrm])
[8.691023] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
ipu_crtc_ops [imxdrm])
[8.691264] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops
ipu_crtc_ops [imxdrm])
[8.691507] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops
ipu_crtc_ops [imxdrm])
[8.693485] dwhdmi-imx 12.hdmi: Detected HDMI TX controller
v1.30a with HDCP (DWC HDMI 3D TX PHY)
[8.698677] imx-spdif sound-spdif: snd-soc-dummy-dai <->
2004000.spdif mapping ok
[8.705511] hdmi_set_clk_regenerator:521: dwhdmi-imx 12.hdmi:
hdmi_set_clk_regenerator: fs=48000Hz ftdms=74.250MHz N=6144 cts=74250
[8.706051] dw_hdmi_irq:2146: dwhdmi-imx 12.hdmi: EVENT=plugin
[8.707851] imx-drm display-subsystem: bound 12.hdmi (ops
dw_hdmi_imx_ops [dw_hdmi_imx])
[8.713970] dw_hdmi_connector_get_modes:1917: dwhdmi-imx
12.hdmi: failed to get edid
[8.777150] dw_hdmi_setup:1679: dwhdmi-imx 12.hdmi: Non-CEA
mode used in HDMI
[8.777179] hdmi_av_composer:1495: dwhdmi-imx 12.hdmi: final
pixclk = 173106000
[8.777237] dw_hdmi_phy_power_off:1096: dwhdmi-imx 12.hdmi: PHY
powered down in 0 iterations
[8.817180] dw_hdmi_phy_power_on:1133: dwhdmi-imx 12.hdmi: PHY
PLL locked 1 iterations
[8.817214] dw_hdmi_phy_power_off:1096: dwhdmi-imx 12.hdmi: PHY
powered down in 0 iterations
[8.830554] fsl-asoc-card sound: sgtl5000 <-> 2028000.ssi mapping ok
[8.846647] dw_hdmi_phy_power_on:1133: dwhdmi-imx 12.hdmi: PHY
PLL locked 1 iterations
[8.846701] dw_hdmi_setup:1744: dwhdmi-imx 12.hdmi:
dw_hdmi_setup DVI mode
[8.872936] Console: switching to colour frame buffer device 240x67
[8.959468] imx-drm display-subsystem: fb0:  frame buffer device
[9.042175] [drm] Initialized imx-drm 1.0.0 20120507 for
display-subsystem on minor 1
[   10.078736] dw_hdmi_connector_get_modes:1917: dwhdmi-imx
12.hdmi: failed to get edid
[   11.603962] fec 2188000.ethernet eth0: Link is Up - 1Gbps/Full -
flow control rx/tx
[   11.604795] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   13.690715] dw_hdmi_connector_get_modes:1917: dwhdmi-imx
12.hdmi: failed to get edid
[   13.691803] dw_hdmi_connector_get_modes:1917: dwhdmi-imx
12.hdmi: failed to get edid
[   13.728314] dw_hdmi_phy_power_off:1096: dwhdmi-imx 12.hdmi: PHY
powered down in 0 iterations
[   13.736954] dw_hdmi_setup:1679: dwhdmi-imx 12.hdmi: Non-CEA
mode used in HDMI
[   13.736975] hdmi_av_composer:1495: dwhdmi-imx 12.hdmi: final
pixclk = 6500
[   13.737021] dw_hdmi_phy_power_off:1096: dwhdmi-imx 12.hdmi: PHY
powered down in 0 iterations
[   13.748240] dw_hdmi_phy_power_on:1133: dwhdmi-imx 12.hdmi: PHY
PLL locked 1 iterations
[   13.748269] dw_hdmi_phy_power_off:1096: dwhdmi-imx 12.hdmi: PHY
powered down in 0 iterations
[   13.759760] dw_hdmi_phy_power_on:1133: dwhdmi-imx 12.hdmi: PHY
PLL locked 1 iterations
[   13.759841] dw_hdmi_setup:1744: dwhdmi-imx 12.hdmi:
dw_hdmi_setup DVI mode

On Thu, Nov 9, 2017 at 10:52 AM, Luís Mendes  wrote:
> Hi,
>
> I've just applied the referred individual patch to kernel-4.14-rc5 and
> the EDID isn't loaded. dw-hdmi gets no firmware at all.
>
> #cat /proc/cmdline
> console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M@60
> drm.edid_firmware=edid/ktc_edid.bin dw_hdmi.dyndbg=+pfl cma=128M
>
> #zcat /proc/config.gz  | grep EDID
> CONFIG_DRM_LOAD_EDID_FIRMWARE=y
> # CONFIG_FIRMWARE_EDID is not set
>
> #cat /sys/class/drm/card1-HDMI-A-1/edid
> 
>
> #dmesg
> ...
> [8.815238] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
> ipu_crtc_ops [imxdrm])
> [8.81] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
> ipu_crtc_ops [imxdrm])
> [8.815832] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops
> ipu_crtc_ops [imxdrm])
> [8.816073] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops
> ipu_crtc_ops [imxdrm])
> [8.818243] dwhdmi-imx 12.hdmi: Detected HDMI TX controller
> v1.30a with HDCP (DWC HDMI 3D TX PHY)
> [8.821780] hdmi_set_clk_regenerator:521: dwhdmi-imx 12.hdmi:
> hdmi_set_clk_regenerator: fs=48000Hz ftdms=74.250MHz N=6144 cts=74250
> [8.831034] imx-drm display-subsystem: bound 12.hdmi (ops
> dw_hdmi_imx_ops [dw_hdmi_imx])
> [8.832218] [drm] Cannot find any crtc or sizes
> [8.839807] [drm] Initialized imx-drm 1.0.0 20120507 for
> display-subsystem on minor 1
>
> Regards,
> Luís Mendes
>
> On Thu, Nov 9, 2017 at 9:51 AM, Luís Mendes  wrote:
>> Hi everyone,
>>

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Russell King - ARM Linux]

On Thu, Nov 09, 2017 at 02:12:45PM +0200, Jani Nikula wrote:
> And as I said elsewhere in the thread, Russell's patch may be relevant
> for current Linus' master and stable. We just need to reconciliate how
> the two things should work together in drm-next and v4.15 and on.

Exactly, the patch is intended for current kernels.  The hint is that
(a) it's a bug fix, (b) it says "fix" in the title, and (c) it has the
stable attributation which says "apply me to previous kernels".

Daniel's response effectively says "no, we're not going to accept the
patch, work on a fix with some development code."

So, unless someone wants to tell me that it's acceptable to develop bug
fixes against Linus' tree _for_ Linus' tree and accept this patch, or
show some other solution that can be applied to Linus' current tree and
backported to stable trees, I'm just not going to bother in future -
someone else can end up doing the work.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Luís Mendes]

I've verified that dw_hdmi tracks when there is a monitor connected or
not and reacts to it, there are logs that are generated when the
TV/Monitor goes into standby and this is true even if DDC cannot be
read.
My original problem is that if the EDID data cannot be read then
dw_hdmi will enter DVI mode confiuration, with which I cannot get
sound, other than that the driver works properly.

On Thu, Nov 9, 2017 at 4:28 PM, Russell King - ARM Linux
 wrote:
> On Thu, Nov 09, 2017 at 05:01:35PM +0200, Jani Nikula wrote:
>> On Thu, 09 Nov 2017, Luís Mendes  wrote:
>> > Hi Jani,
>> >
>> > I tried:
>> > git clone git://people.freedesktop.org/~airlied/linux -b drm-next
>> > --depth=1 --single-branch
>> >
>> > I got this:
>> > EDID isn't loaded from file
>> >
>> > # cat /proc/cmdline
>> > console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M@60
>> > drm.edid_firmware=edid/ktc_edid.bin dw_hdmi.dyndbg=+pfl cma=128M
>>
>> Please try adding D at the end of your video= parameter to force
>> connector on. Otherwise it'll do a ddc probe which apparently fails with
>> your display.
>
> I do hope you're not converting dw-hdmi to use DDC probing and having it
> ignore the hotplug signal.  dw-hdmi has to work with AV setups, which
> include an AV receiver, and that includes the AV receiver modifying the
> HDMI data when:
>
> (a) the TV is turned off or on.
> (b) the AV receiver is placed into or out of standby
>
> and it informs sources by pulsing the HDMI HPD signal, as per the HDMI
> specification.  Proving the presence of DDC as a means of detection
> won't pick up on these changes, and will cause a regression in the
> driver.
>
> --
> RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
> According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Russell King - ARM Linux]

On Thu, Nov 09, 2017 at 05:01:35PM +0200, Jani Nikula wrote:
> On Thu, 09 Nov 2017, Luís Mendes  wrote:
> > Hi Jani,
> >
> > I tried:
> > git clone git://people.freedesktop.org/~airlied/linux -b drm-next
> > --depth=1 --single-branch
> >
> > I got this:
> > EDID isn't loaded from file
> >
> > # cat /proc/cmdline
> > console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M@60
> > drm.edid_firmware=edid/ktc_edid.bin dw_hdmi.dyndbg=+pfl cma=128M
> 
> Please try adding D at the end of your video= parameter to force
> connector on. Otherwise it'll do a ddc probe which apparently fails with
> your display.

I do hope you're not converting dw-hdmi to use DDC probing and having it
ignore the hotplug signal.  dw-hdmi has to work with AV setups, which
include an AV receiver, and that includes the AV receiver modifying the
HDMI data when:

(a) the TV is turned off or on.
(b) the AV receiver is placed into or out of standby

and it informs sources by pulsing the HDMI HPD signal, as per the HDMI
specification.  Proving the presence of DDC as a means of detection
won't pick up on these changes, and will cause a regression in the
driver.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Luís Mendes]

Hi,

I've just applied the referred individual patch to kernel-4.14-rc5 and
the EDID isn't loaded. dw-hdmi gets no firmware at all.

#cat /proc/cmdline
console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M@60
drm.edid_firmware=edid/ktc_edid.bin dw_hdmi.dyndbg=+pfl cma=128M

#zcat /proc/config.gz  | grep EDID
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
# CONFIG_FIRMWARE_EDID is not set

#cat /sys/class/drm/card1-HDMI-A-1/edid


#dmesg
...
[8.815238] imx-drm display-subsystem: bound imx-ipuv3-crtc.2 (ops
ipu_crtc_ops [imxdrm])
[8.81] imx-drm display-subsystem: bound imx-ipuv3-crtc.3 (ops
ipu_crtc_ops [imxdrm])
[8.815832] imx-drm display-subsystem: bound imx-ipuv3-crtc.6 (ops
ipu_crtc_ops [imxdrm])
[8.816073] imx-drm display-subsystem: bound imx-ipuv3-crtc.7 (ops
ipu_crtc_ops [imxdrm])
[8.818243] dwhdmi-imx 12.hdmi: Detected HDMI TX controller
v1.30a with HDCP (DWC HDMI 3D TX PHY)
[8.821780] hdmi_set_clk_regenerator:521: dwhdmi-imx 12.hdmi:
hdmi_set_clk_regenerator: fs=48000Hz ftdms=74.250MHz N=6144 cts=74250
[8.831034] imx-drm display-subsystem: bound 12.hdmi (ops
dw_hdmi_imx_ops [dw_hdmi_imx])
[8.832218] [drm] Cannot find any crtc or sizes
[8.839807] [drm] Initialized imx-drm 1.0.0 20120507 for
display-subsystem on minor 1

Regards,
Luís Mendes

On Thu, Nov 9, 2017 at 9:51 AM, Luís Mendes  wrote:
> Hi everyone,
>
> I can try that patch and see if it fixes the problem.
> Give me a moment so that I can check how it goes.
>
> Luís
>
>
>
> On Thu, Nov 9, 2017 at 9:49 AM, Jani Nikula 
> wrote:
>>
>> On Thu, 09 Nov 2017, Russell King - ARM Linux 
>> wrote:
>> > On Thu, Nov 09, 2017 at 09:23:18AM +0100, Daniel Vetter wrote:
>> >> On Tue, Nov 07, 2017 at 11:27:21AM +, Russell King wrote:
>> >> > Parsing the EDID for HDMI and audio information in the get_modes()
>> >> > callback is incorrect - this only parses the EDID read from the
>> >> > connector, not any override or firmware provided EDID.
>> >> >
>> >> > The correct place to parse the EDID for these parameters is the
>> >> > fill_modes() callback, after we've called the helper.  Move the
>> >> > parsing
>> >> > there.  This caused problems for Luís Mendes.
>> >> >
>> >> > Cc: 
>> >> > Reported-by: Luís Mendes 
>> >> > Tested-by: Luís Mendes 
>> >> > Signed-off-by: Russell King 
>> >> > ---
>> >> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28
>> >> > 
>> >> >  1 file changed, 24 insertions(+), 4 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> >> > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> >> > index 9fe407f49986..2516a1c18a10 100644
>> >> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> >> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> >> > @@ -1905,10 +1905,7 @@ static int dw_hdmi_connector_get_modes(struct
>> >> > drm_connector *connector)
>> >> >dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
>> >> >edid->width_cm, edid->height_cm);
>> >> >
>> >> > -  hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
>> >> > -  hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>> >> >drm_mode_connector_update_edid_property(connector, edid);
>> >> > -  cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,
>> >> > edid);
>> >> >ret = drm_add_edid_modes(connector, edid);
>> >> >/* Store the ELD */
>> >> >drm_edid_to_eld(connector, edid);
>> >> > @@ -1920,6 +1917,29 @@ static int dw_hdmi_connector_get_modes(struct
>> >> > drm_connector *connector)
>> >> >return ret;
>> >> >  }
>> >> >
>> >> > +static int dw_hdmi_connector_fill_modes(struct drm_connector
>> >> > *connector,
>> >> > +  uint32_t maxX, uint32_t maxY)
>> >> > +{
>> >> > +  struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
>> >> > +  connector);
>> >> > +  int ret;
>> >> > +
>> >> > +  ret = drm_helper_probe_single_connector_modes(connector, maxX,
>> >> > maxY);
>> >> > +
>> >> > +  if (connector->edid_blob_ptr) {
>> >> > +  struct edid *edid = (void
>> >> > *)connector->edid_blob_ptr->data;
>> >> > +
>> >> > +  hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
>> >> > +  hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
>> >> > +  cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,
>> >> > edid);
>> >> > +  } else {
>> >> > +  hdmi->sink_is_hdmi = false;
>> >> > +  hdmi->sink_has_audio = false;
>> >> > +  }
>> >> > +
>> >> > +  return ret;
>> >> > +}
>> >> > +
>> >> >  static void dw_hdmi_connector_force(struct drm_connector *connector)
>> >> >  {
>> >> >struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
>> >> > @@ -1933,7 

Re: [linux-sunxi] Re: [PATCH v2 00/10] Allwinner H3/H5/A64(DE2) SimpleFB support

[Chris Obbard]

Hi Everyone,

What's the status of HDMI/SimpleFB driver for H5?

I don't see anything related to HDMI in linux-next dts files:

arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts  (example board)
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi
arch/arm/boot/dts/sunxi-h3-h5.dtsi

On 6 November 2017 at 08:40, Daniel Vetter  wrote:

> On Thu, Nov 02, 2017 at 04:44:47PM +0100, Maxime Ripard wrote:
> > On Thu, Nov 02, 2017 at 04:51:29PM +0800, Icenowy Zheng wrote:
> > > 在 2017-10-27 23:06，Icenowy Zheng 写道：
> > > > This patchset adds support for the SimpleFB on Allwinner SoCs with
> > > > "Display Engine 2.0".
> > > >
> > > > PATCH 1 to PATCH 3 are DE2 CCU fixes for H3/H5 SoCs.
> > > >
> > > > PATCH 4 adds the pipeline strings for DE2 SimpleFB.
> > > >
> > > > PATCH 5 to 7 adds necessary device tree nodes (DE2 CCU and SimpleFB)
> > > > for H3/H5 SoCs.
> > > >
> > > > PATCH 8 to 10 are for Allwinner A64 SoC to enable SimpleFB.
> > > >
> > > > Icenowy Zheng (10):
> > > >   dt-bindings: fix the binding of Allwinner DE2 CCU of A83T and H3
> > > >   clk: sunxi-ng: add support for Allwinner H3 DE2 CCU
> > > >   clk: sunxi-ng: fix the A64/H5 clock description of DE2 CCU
> > > >   dt-bindings: simplefb-sunxi: add pipelines for DE2
> > > >   ARM: sun8i: h3/h5: add DE2 CCU device node for H3
> > > >   arm64: allwinner: h5: add compatible string for DE2 CCU
> > > >   ARM: sunxi: h3/h5: add simplefb nodes
> > > >   dt-bindings: add binding for A64 DE2 CCU SRAM
> > > >   arm64: allwinner: a64: add DE2 CCU for A64 SoC
> > > >   arm64: allwinner: a64: add simplefb for A64 SoC
> > >
> > > Maxime, could you review and, if possible, apply the H3/5
> > > part of this patchset?
> >
> > This came a bit late, we're too close from the merge window
> > now. Please resend them after -rc1 is out.
>
> Just dropping here that drm-misc is open all the time, making for a much
> better process for contributors :-)
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Luís Mendes]

Hi everyone,

I can try that patch and see if it fixes the problem.
Give me a moment so that I can check how it goes.

Luís



On Thu, Nov 9, 2017 at 9:49 AM, Jani Nikula 
wrote:

> On Thu, 09 Nov 2017, Russell King - ARM Linux 
> wrote:
> > On Thu, Nov 09, 2017 at 09:23:18AM +0100, Daniel Vetter wrote:
> >> On Tue, Nov 07, 2017 at 11:27:21AM +, Russell King wrote:
> >> > Parsing the EDID for HDMI and audio information in the get_modes()
> >> > callback is incorrect - this only parses the EDID read from the
> >> > connector, not any override or firmware provided EDID.
> >> >
> >> > The correct place to parse the EDID for these parameters is the
> >> > fill_modes() callback, after we've called the helper.  Move the
> parsing
> >> > there.  This caused problems for Luís Mendes.
> >> >
> >> > Cc: 
> >> > Reported-by: Luís Mendes 
> >> > Tested-by: Luís Mendes 
> >> > Signed-off-by: Russell King 
> >> > ---
> >> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 28
> 
> >> >  1 file changed, 24 insertions(+), 4 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> > index 9fe407f49986..2516a1c18a10 100644
> >> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> >> > @@ -1905,10 +1905,7 @@ static int dw_hdmi_connector_get_modes(struct
> drm_connector *connector)
> >> >dev_dbg(hdmi->dev, "got edid: width[%d] x height[%d]\n",
> >> >edid->width_cm, edid->height_cm);
> >> >
> >> > -  hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> >> > -  hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> >> >drm_mode_connector_update_edid_property(connector, edid);
> >> > -  cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,
> edid);
> >> >ret = drm_add_edid_modes(connector, edid);
> >> >/* Store the ELD */
> >> >drm_edid_to_eld(connector, edid);
> >> > @@ -1920,6 +1917,29 @@ static int dw_hdmi_connector_get_modes(struct
> drm_connector *connector)
> >> >return ret;
> >> >  }
> >> >
> >> > +static int dw_hdmi_connector_fill_modes(struct drm_connector
> *connector,
> >> > +  uint32_t maxX, uint32_t maxY)
> >> > +{
> >> > +  struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> >> > +  connector);
> >> > +  int ret;
> >> > +
> >> > +  ret = drm_helper_probe_single_connector_modes(connector, maxX,
> maxY);
> >> > +
> >> > +  if (connector->edid_blob_ptr) {
> >> > +  struct edid *edid = (void *)connector->edid_blob_ptr->
> data;
> >> > +
> >> > +  hdmi->sink_is_hdmi = drm_detect_hdmi_monitor(edid);
> >> > +  hdmi->sink_has_audio = drm_detect_monitor_audio(edid);
> >> > +  cec_notifier_set_phys_addr_from_edid(hdmi->cec_notifier,
> edid);
> >> > +  } else {
> >> > +  hdmi->sink_is_hdmi = false;
> >> > +  hdmi->sink_has_audio = false;
> >> > +  }
> >> > +
> >> > +  return ret;
> >> > +}
> >> > +
> >> >  static void dw_hdmi_connector_force(struct drm_connector *connector)
> >> >  {
> >> >struct dw_hdmi *hdmi = container_of(connector, struct dw_hdmi,
> >> > @@ -1933,7 +1953,7 @@ static void dw_hdmi_connector_force(struct
> drm_connector *connector)
> >> >  }
> >> >
> >> >  static const struct drm_connector_funcs dw_hdmi_connector_funcs = {
> >> > -  .fill_modes = drm_helper_probe_single_connector_modes,
> >> > +  .fill_modes = dw_hdmi_connector_fill_modes,
> >>
> >> Papering over helper functions shouldn't be necessary, except the helper
> >> functions not handling the override edid is a known issue. Jani Nikula
> is
> >> working on a proper fix, please coordinate with him.
> >
> > So, what you're basically saying is that fixing real bugs that affect
> > users is not something that DRM people want.  That's fine, I'll ignore
> > people who come to me for help with DRM bugs in future then because
> > it's obviously a dead loss.
>
> We may already have fixed the bug in drm-next at the proper
> layer. Please see my other mail.
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Technology Center
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] video: fbdev: Convert timers to use timer_setup()

[Kees Cook]

On Thu, Nov 9, 2017 at 9:08 AM, Bartlomiej Zolnierkiewicz
 wrote:
> On Tuesday, October 24, 2017 08:20:26 AM Kees Cook wrote:
>
>> diff --git a/drivers/video/fbdev/pxa3xx-gcu.c 
>> b/drivers/video/fbdev/pxa3xx-gcu.c
>> index 933619da1a94..e88447eac32c 100644
>> --- a/drivers/video/fbdev/pxa3xx-gcu.c
>> +++ b/drivers/video/fbdev/pxa3xx-gcu.c
>> @@ -513,16 +513,10 @@ pxa3xx_gcu_mmap(struct file *file, struct 
>> vm_area_struct *vma)
>>  #ifdef PXA3XX_GCU_DEBUG_TIMER
>>  static struct timer_list pxa3xx_gcu_debug_timer;
>>
>> -static void pxa3xx_gcu_debug_timedout(unsigned long ptr)
>> +static void pxa3xx_gcu_debug_timedout(struct timer_list *unused)
>>  {
>> - struct pxa3xx_gcu_priv *priv = (struct pxa3xx_gcu_priv *) ptr;
>> -
>>   QERROR("Timer DUMP");
>
> QERROR() macro is using priv so this code now fails to build.

Ah, yes, I see. However, in looking at this, I don't think it ever
worked. The existing code does:

static void pxa3xx_gcu_init_debug_timer(void)
{
pxa3xx_gcu_debug_timedout((unsigned long) _gcu_debug_timer);
}
...
static void pxa3xx_gcu_debug_timedout(unsigned long ptr)
{
struct pxa3xx_gcu_priv *priv = (struct pxa3xx_gcu_priv *) ptr;

QERROR("Timer DUMP");
...

But pxa3xx_gcu_debug_timer is not a struct pxa3xx_gcu_priv, so
QERROR() will be reporting garbage.

I will send a patch that fixes this and switches to timer_setup(),
though it might make more sense to just remove the debug timer
entirely.

> [ Please compile these timer changes with PXA3XX_GCU_DEBUG and
>   PXA3XX_GCU_DEBUG_TIMER defined. ]

Hm, these appear to be manual knobs? What do you think about wiring
these up to a Kconfig so build tests for things like "make
allmodconfig" would enable it? This would allow for much greater build
coverage.

> Also please port your changes over fbdvev-for-next tree as
> currently this patch doesn't apply (fbdev tree contains
> "video: fbdev: pxa3xx_gcu: Use setup_timer and mod_timer"
> cleanup).

Sure thing, thanks!

-Kees

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

Re: [PATCH] drm/bridge: dw-hdmi: fix EDID parsing

[Luís Mendes]

Hi Jani,

I tried:
git clone git://people.freedesktop.org/~airlied/linux -b drm-next
--depth=1 --single-branch

I got this:
EDID isn't loaded from file

# cat /proc/cmdline
console=ttymxc0,115200 root=/dev/sda2 rw video=HDMI-A-1:1920x1080M@60
drm.edid_firmware=edid/ktc_edid.bin dw_hdmi.dyndbg=+pfl cma=128M

#zcat /proc/config.gz  | grep EDID
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
# CONFIG_FIRMWARE_EDID is not set

#cat /sys/class/drm/card1-HDMI-A-1/edid


dmesg output follows below...

Regards,
Luís Mendes

[7.381500] dwhdmi-imx 12.hdmi: Detected HDMI TX controller
v1.30a with HDCP (DWC HDMI 3D TX PHY)
[7.409108] hdmi_set_clk_regenerator:521: dwhdmi-imx 12.hdmi:
hdmi_set_clk_regenerator: fs=48000Hz ftdms=74.250MHz N=6144 cts=74250
[7.411001] dw_hdmi_irq:2146: dwhdmi-imx 12.hdmi: EVENT=plugin
[7.421524] imx-drm display-subsystem: bound 12.hdmi (ops
dw_hdmi_imx_ops [dw_hdmi_imx])
[7.481948] dw_hdmi_connector_get_modes:1917: dwhdmi-imx
12.hdmi: failed to get edid
[7.537018] fsl-asoc-card sound: sgtl5000 <-> 2028000.ssi mapping ok
[7.549254] [ cut here ]
[7.549303] WARNING: CPU: 2 PID: 219 at
drivers/gpu/drm/drm_vblank.c:303
drm_crtc_accurate_vblank_count+0x80/0x84
[7.549308] This function requires support for accurate vblank timestamps.
[7.549312] Modules linked in: snd_soc_imx_spdif(+)
snd_soc_fsl_asoc_card(+) snd_ac97_codec coda videobuf2_dma_contig
imx_vdoa v4l2_mem2mem videobuf2_vmalloc videobuf2_memops dw_hdmi_imx
imxdrm(+) dw_hdmi cec etnaviv imx_ipu_v3 binfmt_misc parport_pc ppdev
lp parport
[7.549396] CPU: 2 PID: 219 Comm: systemd-udevd Tainted: GW
  4.14.0-rc7-gd65d313-dirty #1
[7.549401] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[7.549405] Backtrace:
[7.549427] [] (dump_backtrace) from []
(show_stack+0x18/0x1c)
[7.549436]  r7:c106eed0 r6: r5:600d0193 r4:c106eed0
[7.549465] [] (show_stack) from []
(dump_stack+0xac/0xd8)
[7.549486] [] (dump_stack) from [] (__warn+0xec/0x104)
[7.549496]  r10:edf56e00 r9:c0527bd8 r8:012f r7:0009
r6:c0d4fc08 r5:
[7.549501]  r4:edd15688 r3:
[7.549514] [] (__warn) from []
(warn_slowpath_fmt+0x40/0x48)
[7.549523]  r9:edc2f3e0 r8:0001 r7:edc2f000 r6:
r5:edc2f000 r4:c0d50064
[7.549535] [] (warn_slowpath_fmt) from []
(drm_crtc_accurate_vblank_count+0x80/0x84)
[7.549540]  r3: r2:c0d50064
[7.549544]  r4:edc2f000
[7.549553] [] (drm_crtc_accurate_vblank_count) from
[] (drm_crtc_arm_vblank_event+0x30/0x64)
[7.549560]  r7:edc2f000 r6:0001 r5:edc2f000 r4:eeb3e400
[7.549614] [] (drm_crtc_arm_vblank_event) from
[] (ipu_crtc_atomic_begin+0x50/0x80 [imxdrm])
[7.549620]  r5:eeb3e680 r4:edc2b018
[7.549653] [] (ipu_crtc_atomic_begin [imxdrm]) from
[] (drm_atomic_helper_commit_planes+0x8c/0x2a8)
[7.549660]  r5:eeb3e680 r4:0018
[7.549682] [] (drm_atomic_helper_commit_planes) from
[] (imx_drm_atomic_commit_tail+0x30/0x144 [imxdrm])
[7.549691]  r10:edf56e00 r9:edc2f3e0 r8:edfafdf8 r7:edc2f000
r6:eeb3e680 r5:bf0ab088
[7.549695]  r4:eeb3e680
[7.549723] [] (imx_drm_atomic_commit_tail [imxdrm]) from
[] (commit_tail+0x48/0x8c)
[7.549732]  r10:edf56e00 r9:edc2f3e0 r8:edfafdf8 r7:edc2f000
r6: r5:bf0ab088
[7.549737]  r4:eeb3e680 r3:bf0a8174
[7.549762] [] (commit_tail) from []
(drm_atomic_helper_commit+0x140/0x148)
[7.549780]  r5: r4:eeb3e680
[7.549820] [] (drm_atomic_helper_commit) from
[] (drm_atomic_commit+0x54/0x60)
[7.549843]  r7:eeb3e680 r6:edc2f000 r5:eeb3e680 r4:
[7.549865] [] (drm_atomic_commit) from []
(restore_fbdev_mode_atomic+0x19c/0x1f8)
[7.549874]  r7:eeb3e680 r6:0001 r5:003f r4:00a0
[7.549886] [] (restore_fbdev_mode_atomic) from
[] (restore_fbdev_mode+0x30/0x168)
[7.549895]  r10:edf57800 r9:c17e5a70 r8: r7:edf56e00
r6:c17e5bc8 r5:edf56ed0
[7.549899]  r4:edf56e00
[7.549914] [] (restore_fbdev_mode) from []
(drm_fb_helper_restore_fbdev_mode_unlocked.part.8+0x28/0x7c)
[7.549925]  r10:edf57800 r9:c17e5a70 r8: r7:c1022ed8
r6:c17e5bc8 r5:edf56ed0
[7.549931]  r4:edf56e00
[7.549943] []
(drm_fb_helper_restore_fbdev_mode_unlocked.part.8) from []
(drm_fb_helper_set_par+0x5c/0x8c)
[7.549950]  r7:c1022ed8 r6:c17e5bc8 r5:edfe3400 r4:
[7.549972] [] (drm_fb_helper_set_par) from []
(fbcon_init+0x564/0x5b0)
[7.549977]  r5:edfe3400 r4:ee808c00
[7.549992] [] (fbcon_init) from []
(visual_init+0xcc/0x114)
[7.550001]  r10:0001 r9:ee808c00 r8:c17ebfb4 r7:
r6:ee808e08 r5:
[7.550005]  r4:ee808c00
[7.550016] [] (visual_init) from []
(do_bind_con_driver+0x1b4/0x394)
[7.550023]  r7: r6: r5:c17ebea0 r4:c0b3e0dc
[7.550033] [] (do_bind_con_driver) from []
(do_take_over_console+0x15c/0x1c4)
[7.550041]  r10:0001 r9:003e r8: r7:c17ebeb0
r6: 

RE: [Intel-gfx] [PATCH 0/7] Add Plane Color Properties

[Shankar, Uma]

>-Original Message-
>From: Daniel Stone [mailto:dan...@fooishbar.org]
>Sent: Tuesday, November 7, 2017 9:44 PM
>To: Shankar, Uma 
>Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Syrjala, Ville ; 
>Lankhorst,
>Maarten 
>Subject: Re: [Intel-gfx] [PATCH 0/7] Add Plane Color Properties
>
>Hi Uma,
>
>On 7 November 2017 at 12:06, Uma Shankar  wrote:
>> This patch series adds properties for plane color features. It adds
>> properties for degamma used to linearize data, CSC used for gamut
>> conversion, and gamma used to again non-linearize data as per panel
>> supported color space. These can be utilize by user space to convert
>> planes from one format to another, one color space to another etc.
>>
>> Usersapce can take smart blending decisions and utilize these hardware
>> supported plane color features to get accurate color profile. The same
>> can help in consistent color quality from source to panel taking
>> advantage of advanced color features in hardware.
>>
>> These patches just add the property interfaces and enable helper functions.
>
>This is missing documentation on how plane colour management interacts with
>CRTC colour management. Is it a step before CRTC colour management is
>applied, or does it bypass CRTC colour management, or ... ?
>

We can have color correction at 2 places in the Display hardware pipeline
1. At plane level (before blending)
2. At pipe level (after blending)

Both can be used and function independently of each other. Typical use case can 
be:

2 Layers planes/overlays with different color space and formats. These can be 
converted to one
common color space using the plane level color correction, then blended 
together. If needed 
pipe color correction can be applied on the blended output (based on use case 
and scenarios)

Regards,
Uma Shankar


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