[PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Russell King - ARM Linux]

On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
> Struct mutex is here because this code is from the V3D series, with the
> in-kernel BO cache ripped out (it turns out that the CMA allocator is
> slow, and you can't just userspace cache since we have to do allocations
> within the kernel to the tune of a couple per draw and that's too much).

The CMA allocator is fast until you have pinned pages in its region,
where it becomes _very_ slow to do allocations, sometimes getting up
to the order of seconds.

The main culpret of this are GFP_HIGHUSER_MOVABLE allocations which
then pin the page.  It doesn't take many of those to make CMA really
inefficient.

The problem is that CMA doesn't get any information back from the
internal page migration about which pages couldn't be moved, so it
dumbly just tries incrementing the allocation by one page (subject
to alignment constraints) and retrying again - repeating over the
entire CMA region.  The bigger the region, the more time this takes.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

i915/kasan: out of bounds access in i915_cmd_parser_init_ring

[Dave Jones]

I finally got around to playing with kasan. It didn't end well.

I added some debugging to validate_cmds_sorted to print out the table
sizes right before the stack traces.

Dave

validate_cmds_sorted: table:a1fb4220 cmd_table_count:3
validate_cmds_sorted: table:a1fb4220 table->count:12
validate_cmds_sorted: table:a1fb4230 table->count:20
validate_cmds_sorted: table:a1fb4230 table->count:20
validate_cmds_sorted: table:a1fb4240 table->count:18
validate_cmds_sorted: table:a1fb41e0 cmd_table_count:2
validate_cmds_sorted: table:a1fb41e0 table->count:12
validate_cmds_sorted: table:a1fb41f0 table->count:7
validate_cmds_sorted: table:a1fb4100 cmd_table_count:3
validate_cmds_sorted: table:a1fb4100 table->count:12
validate_cmds_sorted: table:a1fb4110 table->count:6
==
BUG: KASan: out of bounds access in i915_cmd_parser_init_ring+0x66b/0x760 at 
addr a1fb4374
Read of size 4 by task swapper/0/1
Address belongs to variable hsw_blt_cmds+0xb4/0xe0
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6-firewall+ #4
 0002 8801d6baf478 a1c0b4fb 0032
 8801d6baf510 8801d6baf4f8 a123198f 8801d6baf5a8
 ed003ad75e9b 0246 a1fb4110 1000
Call Trace:
 [] dump_stack+0x4f/0x7b
 [] kasan_report_error+0x3bf/0x3f0
 [] kasan_report+0x3b/0x40
 [] ? i915_cmd_parser_init_ring+0x66b/0x760
 [] __asan_load4+0x66/0xa0
 [] i915_cmd_parser_init_ring+0x66b/0x760
 [] intel_init_ring_buffer+0x449/0x680
 [] intel_init_blt_ring_buffer+0x38e/0x520
 [] i915_gem_init_rings+0x74/0x220
 [] i915_gem_init+0x1e2/0x320
 [] i915_driver_load+0x1571/0x2310
 [] ? debug_lockdep_rcu_enabled+0x4e/0x70
 [] ? __lock_acquire+0x97e/0x2710
 [] ? debug_smp_processor_id+0x17/0x20
 [] ? debug_show_all_locks+0x280/0x280
 [] ? __mutex_unlock_slowpath+0x11b/0x1e0
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] ? i915_getparam+0x390/0x390
 [] ? mark_held_locks+0xa4/0xd0
 [] ? _raw_spin_unlock_irqrestore+0x58/0x70
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] ? preempt_count_sub+0xc1/0x130
 [] ? _raw_spin_unlock_irqrestore+0x43/0x70
 [] drm_dev_register+0xd1/0x170
 [] drm_get_pci_dev+0xf1/0x350
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] i915_pci_probe+0x83/0xb0
 [] pci_device_probe+0xcf/0x130
 [] driver_probe_device+0x1e1/0x410
 [] ? driver_probe_device+0x410/0x410
 [] ? driver_probe_device+0x410/0x410
 [] __driver_attach+0xd6/0xe0
 [] bus_for_each_dev+0xf5/0x160
 [] ? bus_remove_file+0xa0/0xa0
 [] ? do_raw_spin_unlock+0xa4/0x140
 [] ? preempt_count_sub+0xc1/0x130
 [] driver_attach+0x30/0x40
 [] bus_add_driver+0x2b1/0x330
 [] driver_register+0xde/0x1b0
 [] __pci_register_driver+0xbc/0xd0
 [] drm_pci_init+0x1e7/0x210
 [] ? do_one_initcall+0x108/0x242
 [] ? do_one_initcall+0x108/0x242
 [] i915_init+0xdb/0xe3
 [] ? mipi_dsi_bus_init+0x12/0x12
 [] do_one_initcall+0x227/0x242
 [] ? start_kernel+0x4ed/0x4ed
 [] ? parse_args+0x5b/0x4f0
 [] kernel_init_freeable+0x290/0x321
 [] ? rest_init+0x150/0x150
 [] kernel_init+0x14/0x100
 [] ? rest_init+0x150/0x150
 [] ret_from_fork+0x3f/0x70
 [] ? rest_init+0x150/0x150
Memory state around the buggy address:
 a1fb4200: fa fa fa fa 00 00 00 00 00 00 fa fa fa fa fa fa
 a1fb4280: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00 00
>a1fb4300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 fa fa
 ^
 a1fb4380: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00
 a1fb4400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
==
==
BUG: KASan: out of bounds access in i915_cmd_parser_init_ring+0x67e/0x760 at 
addr a1fb4378
Read of size 4 by task swapper/0/1
Address belongs to variable hsw_blt_cmds+0xb8/0xe0
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc6-firewall+ #4
 0002 8801d6baf478 a1c0b4fb 0032
 8801d6baf510 8801d6baf4f8 a123198f 0010
 ed00 0246 fbfff43f686e 66201000
Call Trace:
 [] dump_stack+0x4f/0x7b
 [] kasan_report_error+0x3bf/0x3f0
 [] kasan_report+0x3b/0x40
 [] ? i915_cmd_parser_init_ring+0x67e/0x760
 [] __asan_load4+0x66/0xa0
 [] i915_cmd_parser_init_ring+0x67e/0x760
 [] intel_init_ring_buffer+0x449/0x680
 [] intel_init_blt_ring_buffer+0x38e/0x520
 [] i915_gem_init_rings+0x74/0x220
 [] i915_gem_init+0x1e2/0x320
 [] i915_driver_load+0x1571/0x2310
 [] ? debug_lockdep_rcu_enabled+0x4e/0x70
 [] ? __lock_acquire+0x97e/0x2710
 [] ? debug_smp_processor_id+0x17/0x20
 [] ? debug_show_all_locks+0x280/0x280
 [] ? __mutex_unlock_slowpath+0x11b/0x1e0
 [] ? trace_hardirqs_on_caller+0x192/0x2a0
 [] ? i915_getparam+0x390/0x390
 [] ? mark_held_locks+0xa4/0xd0
 [] ? 

[PATCH 0/4] Add support for Hyperlinks and Markup on kernel-doc

[Danilo Cesar Lemes de Paula]

On 07/23/2015 05:29 PM, Jonathan Corbet wrote:
> On Thu, 23 Jul 2015 15:16:23 -0300
> Danilo Cesar Lemes de Paula  wrote:
> 
>> This series add supports for hyperlink cross-references on Docbooks and
>> an optional markup syntax for in-source Documentation.
> 
> I like the idea; just be warned that it's likely to be a week or two and
> one more ocean crossing before I can take a serious look at this...
> 
> Thanks,

Hey,

Did you find time to take a look on this?

I understand that there's some discussion behind the curtains regarding
the markdown support, but the cross-reference-hyperlink patch is also in
the same patch series. It doesn't change any text in the docbook unless
there's really a cross-reference link to it. Different from the markdown
support (when people start to use markdown to write docs it will be hard
to go back), the cross-link stuff doesn't require/create any change to
current documentation, it is pretty safe to use.

Would you mind to share your plans about this?

Thanks,

Danilo Cesar

[Bug 102831] Some flashbased videoplayers cause GPU lockups on radeon.

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #3 from Jon Arne Jørgensen  ---
When the lockup fails to crash the kernel, I end up with an unusable system
with this filling my dmesg buffer:
[...snip...]
[ 1196.506527] radeon :02:00.0: ring 5 stalled for more than 232970msec
[ 1196.506535] radeon :02:00.0: GPU lockup (current fence id
0x0006 last fence id 0x0007 on ring 5)
[ 1197.007312] radeon :02:00.0: ring 5 stalled for more than 233471msec
[ 1197.007319] radeon :02:00.0: GPU lockup (current fence id
0x0006 last fence id 0x0007 on ring 5)
[ 1197.508102] radeon :02:00.0: ring 5 stalled for more than 233972msec
[ 1197.508110] radeon :02:00.0: GPU lockup (current fence id
0x0006 last fence id 0x0007 on ring 5)
[ 1198.008887] radeon :02:00.0: ring 5 stalled for more than 234473msec
[ 1198.008896] radeon :02:00.0: GPU lockup (current fence id
0x0006 last fence id 0x0007 on ring 5)
[ 1198.509671] radeon :02:00.0: ring 5 stalled for more than 234974msec
[ 1198.509679] radeon :02:00.0: GPU lockup (current fence id
0x0006 last fence id 0x0007 on ring 5)
[ 1199.010474] radeon :02:00.0: ring 5 stalled for more than 235475msec
[ 1199.010482] radeon :02:00.0: GPU lockup (current fence id
0x0006 last fence id 0x0007 on ring 5)
[ 1199.511267] radeon :02:00.0: ring 5 stalled for more than 235976msec
[ 1199.511274] radeon :02:00.0: GPU lockup (current fence id
0x0006 last fence id 0x0007 on ring 5)
[...snip...]

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102831] Some flashbased videoplayers cause GPU lockups on radeon.

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #2 from Jon Arne Jørgensen  ---
I wrote PANIC_ON_HANG, that should be: CONFIG_BOOTPARAM_HUNG_TASK_PANIC

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102831] Some flashbased videoplayers cause GPU lockups on radeon.

[bugzilla-dae...@bugzilla.kernel.org]

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

Jon Arne Jørgensen  changed:

   What|Removed |Added

 Attachment #184861|application/octet-stream|text/plain
  mime type||

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102831] Some flashbased videoplayers cause GPU lockups on radeon.

[bugzilla-dae...@bugzilla.kernel.org]

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

--- Comment #1 from Jon Arne Jørgensen  ---
Created attachment 184861
  --> https://bugzilla.kernel.org/attachment.cgi?id=184861=edit
Full dmesg

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 102831] New: Some flashbased videoplayers cause GPU lockups on radeon.

[bugzilla-dae...@bugzilla.kernel.org]

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

Bug ID: 102831
   Summary: Some flashbased videoplayers cause GPU lockups on
radeon.
   Product: Drivers
   Version: 2.5
Kernel Version: 4.2-rc6
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: jonjon.arnearne at gmail.com
Regression: No

Created attachment 184851
  --> https://bugzilla.kernel.org/attachment.cgi?id=184851=edit
Complete Xorg.log

When trying to play videos from allmyvideos.net in Chromium, the GPU will
lockup. And my computer will be left in an unusable state.

This lockup seems to be related to specific flash players, as I have tried
several other sites with flash players that don't cause the lockups.

The specific lockup from dmesg:
[  380.103559] radeon :02:00.0: ring 0 stalled for more than 10037msec
[  380.103568] radeon :02:00.0: GPU lockup (current fence id
0x6078 last fence id 0x61d4 on ring 0)
[  380.103668] radeon :02:00.0: failed to get a new IB (-35)
[  380.103713] [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to get ib !
[  380.109844] radeon :02:00.0: failed to get a new IB (-35)
[  380.109882] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD
(-35)!
[  380.125967] radeon :02:00.0: Saved 11161 dwords of commands on ring 0.
[  380.125977] radeon :02:00.0: GPU softreset: 0x0008
[  380.125979] radeon :02:00.0:   R_008010_GRBM_STATUS  = 0xA0003028
[  380.125981] radeon :02:00.0:   R_008014_GRBM_STATUS2 = 0x0002
[  380.125983] radeon :02:00.0:   R_000E50_SRBM_STATUS  = 0x200028C0
[  380.125985] radeon :02:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[  380.125986] radeon :02:00.0:   R_008678_CP_STALLED_STAT2 = 0x00010002
[  380.125988] radeon :02:00.0:   R_00867C_CP_BUSY_STAT = 0x0086
[  380.125990] radeon :02:00.0:   R_008680_CP_STAT  = 0x80018647
[  380.125992] radeon :02:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[  380.189434] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x4001
[  380.189488] radeon :02:00.0: SRBM_SOFT_RESET=0x0100
[  380.191628] radeon :02:00.0:   R_008010_GRBM_STATUS  = 0x3028
[  380.191630] radeon :02:00.0:   R_008014_GRBM_STATUS2 = 0x0002
[  380.191631] radeon :02:00.0:   R_000E50_SRBM_STATUS  = 0x20C0
[  380.191633] radeon :02:00.0:   R_008674_CP_STALLED_STAT1 = 0x
[  380.191635] radeon :02:00.0:   R_008678_CP_STALLED_STAT2 = 0x
[  380.191637] radeon :02:00.0:   R_00867C_CP_BUSY_STAT = 0x
[  380.191638] radeon :02:00.0:   R_008680_CP_STAT  = 0x
[  380.191640] radeon :02:00.0:   R_00D034_DMA_STATUS_REG   = 0x44C83D57
[  380.191649] radeon :02:00.0: GPU reset succeeded, trying to resume
[  380.211635] [drm] enabling PCIE gen 2 link speeds, disable with
radeon.pcie_gen2=0
[  380.213937] [drm] PCIE GART of 1024M enabled (table at 0x0025E000).
[  380.213981] radeon :02:00.0: WB enabled
[  380.213984] radeon :02:00.0: fence driver on ring 0 use gpu addr
0x4c00 and cpu addr 0x880227b7cc00
[  380.213985] radeon :02:00.0: fence driver on ring 3 use gpu addr
0x4c0c and cpu addr 0x880227b7cc0c
[  380.214840] radeon :02:00.0: fence driver on ring 5 use gpu addr
0x0005c598 and cpu addr 0xc9000101c598
[  380.261529] [drm] ring test on 0 succeeded in 1 usecs
[  380.261537] [drm] ring test on 3 succeeded in 3 usecs
[  380.437798] [drm] ring test on 5 succeeded in 1 usecs
[  380.437802] [drm] UVD initialized successfully.

Sometimes when this happens I'm able to change (CTRL-ALT-F1) and get to the
virtual terminal or ssh in from my phone, while other times the computer just
locks up.

I've compiled the kernel with PANIC_ON_HANG, so i can get to kexec-kdump to get
the dmesg.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 91527] 7870 radeon crashes after kernel msg drm:radeon_mn_invalidate_range_start

[bugzilla-dae...@freedesktop.org]

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

--- Comment #6 from Christian König  ---
Well have you tested this with the current upstream kernel? E.g. 4.1 or a
recent rc of 4.2?

That's usually the first thing you should to to figure out if newer kernels are
already fixed.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/3b103564/attachment.html>

[PATCH] drm/msm/dsi: Introduce DSI configuration module

[Hai Li]

With more platforms supported, the DSI host
configuration array keeps expanding. This change
moves those to a separate dsi_cfg module.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Makefile   |   1 +
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |  92 ++
 drivers/gpu/drm/msm/dsi/dsi_cfg.h  |  44 +
 drivers/gpu/drm/msm/dsi/dsi_host.c | 186 -
 4 files changed, 177 insertions(+), 146 deletions(-)
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_cfg.c
 create mode 100644 drivers/gpu/drm/msm/dsi/dsi_cfg.h

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 89debc7..0a543eb 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -54,6 +54,7 @@ msm-$(CONFIG_DRM_MSM_FBDEV) += msm_fbdev.o
 msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o

 msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
+   dsi/dsi_cfg.o \
dsi/dsi_host.o \
dsi/dsi_manager.o \
dsi/phy/dsi_phy.o \
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
new file mode 100644
index 000..5872d5e
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -0,0 +1,92 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include "dsi_cfg.h"
+
+/* DSI v2 has not been supported by now */
+static const struct msm_dsi_config dsi_v2_cfg = {
+   .io_offset = 0,
+};
+
+static const struct msm_dsi_config msm8974_apq8084_dsi_cfg = {
+   .io_offset = DSI_6G_REG_SHIFT,
+   .reg_cfg = {
+   .num = 4,
+   .regs = {
+   {"gdsc", -1, -1, -1, -1},
+   {"vdd", 300, 300, 15, 100},
+   {"vdda", 120, 120, 10, 100},
+   {"vddio", 180, 180, 10, 100},
+   },
+   },
+};
+
+static const struct msm_dsi_config msm8916_dsi_cfg = {
+   .io_offset = DSI_6G_REG_SHIFT,
+   .reg_cfg = {
+   .num = 4,
+   .regs = {
+   {"gdsc", -1, -1, -1, -1},
+   {"vdd", 285, 285, 10, 100},
+   {"vdda", 120, 120, 10, 100},
+   {"vddio", 180, 180, 10, 100},
+   },
+   },
+};
+
+static const struct msm_dsi_config msm8994_dsi_cfg = {
+   .io_offset = DSI_6G_REG_SHIFT,
+   .reg_cfg = {
+   .num = 7,
+   .regs = {
+   {"gdsc", -1, -1, -1, -1},
+   {"vdda", 125, 125, 10, 100},
+   {"vddio", 180, 180, 10, 100},
+   {"vcca", 100, 100, 1, 100},
+   {"vdd", 180, 180, 10, 100},
+   {"lab_reg", -1, -1, -1, -1},
+   {"ibb_reg", -1, -1, -1, -1},
+   },
+   }
+};
+
+static const struct msm_dsi_cfg_handler dsi_cfg_handlers[] = {
+   {MSM_DSI_VER_MAJOR_V2, U32_MAX, _v2_cfg},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_0,
+   _apq8084_dsi_cfg},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1,
+   _apq8084_dsi_cfg},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_1_1,
+   _apq8084_dsi_cfg},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_2,
+   _apq8084_dsi_cfg},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3, _dsi_cfg},
+   {MSM_DSI_VER_MAJOR_6G, MSM_DSI_6G_VER_MINOR_V1_3_1, _dsi_cfg},
+};
+
+const struct msm_dsi_cfg_handler *msm_dsi_cfg_get(u32 major, u32 minor)
+{
+   const struct msm_dsi_cfg_handler *cfg_hnd = NULL;
+   int i;
+
+   for (i = ARRAY_SIZE(dsi_cfg_handlers) - 1; i >= 0; i--) {
+   if ((dsi_cfg_handlers[i].major == major) &&
+   (dsi_cfg_handlers[i].minor == minor)) {
+   cfg_hnd = _cfg_handlers[i];
+   break;
+   }
+   }
+
+   return cfg_hnd;
+}
+
diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.h 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
new file mode 100644
index 000..4cf8872
--- /dev/null
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.h
@@ -0,0 +1,44 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *

[PATCH libdrm 0/9] amdgpu: cleanup the exported symbols

[Emil Velikov]

On 7 August 2015 at 17:44, Emil Velikov  wrote:
> Now that the API is stabilised we can do a bit of a cleanup, and ensure
> only the symbols part of it are exported - 62 -> 34.
>
> This also gives us some ~10% is size reduction of the final binary.
>
> Android support would be nice, but it's not a show stopper :)
>
Thanks for the review guys.

I gave it a final quick test and pushed to master.

-Emil

[PATCH 5/5] drm/msm/dsi: Make each PHY type compilation independent

[Hai Li]

On a certain platform, only one type of DSI PHY is used.
This change allows the user to only compile the PHY type
which is being used.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Kconfig   | 14 ++
 drivers/gpu/drm/msm/Makefile  | 11 +++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c |  4 
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h |  8 
 4 files changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index 331b291..8e6c7c6 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -54,3 +54,17 @@ config DRM_MSM_DSI_PLL
help
  Choose this option to enable DSI PLL driver which provides DSI
  source clocks under common clock framework.
+
+config DRM_MSM_DSI_28NM_PHY
+   bool "Enable DSI 28nm PHY driver in MSM DRM"
+   depends on DRM_MSM_DSI
+   default y
+   help
+ Choose this option if the 28nm DSI PHY is used on the platform.
+
+config DRM_MSM_DSI_20NM_PHY
+   bool "Enable DSI 20nm PHY driver in MSM DRM"
+   depends on DRM_MSM_DSI
+   default y
+   help
+ Choose this option if the 20nm DSI PHY is used on the platform.
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 30f998a..89debc7 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -57,11 +57,14 @@ msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
dsi/dsi_host.o \
dsi/dsi_manager.o \
dsi/phy/dsi_phy.o \
-   dsi/phy/dsi_phy_20nm.o \
-   dsi/phy/dsi_phy_28nm.o \
mdp/mdp5/mdp5_cmd_encoder.o

-msm-$(CONFIG_DRM_MSM_DSI_PLL) += dsi/pll/dsi_pll.o \
-   dsi/pll/dsi_pll_28nm.o
+msm-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += dsi/phy/dsi_phy_28nm.o
+msm-$(CONFIG_DRM_MSM_DSI_20NM_PHY) += dsi/phy/dsi_phy_20nm.o
+
+ifeq ($(CONFIG_DRM_MSM_DSI_PLL),y)
+msm-y += dsi/pll/dsi_pll.o
+msm-$(CONFIG_DRM_MSM_DSI_28NM_PHY) += dsi/pll/dsi_pll_28nm.o
+endif

 obj-$(CONFIG_DRM_MSM)  += msm.o
diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 828a94c..401ff58 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -267,12 +267,16 @@ static void dsi_phy_disable_resource(struct msm_dsi_phy 
*phy)
 }

 static const struct of_device_id dsi_phy_dt_match[] = {
+#ifdef CONFIG_DRM_MSM_DSI_28NM_PHY
{ .compatible = "qcom,dsi-phy-28nm-hpm",
  .data = _phy_28nm_hpm_cfgs },
{ .compatible = "qcom,dsi-phy-28nm-lp",
  .data = _phy_28nm_lp_cfgs },
+#endif
+#ifdef CONFIG_DRM_MSM_DSI_20NM_PHY
{ .compatible = "qcom,dsi-phy-20nm",
  .data = _phy_20nm_cfgs },
+#endif
{}
 };

diff --git a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h 
b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
index b69df19..063caa2 100644
--- a/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
+++ b/drivers/gpu/drm/msm/dsi/pll/dsi_pll.h
@@ -83,8 +83,16 @@ void msm_dsi_pll_helper_unregister_clks(struct 
platform_device *pdev,
 /*
  * Initialization for Each PLL Type
  */
+#ifdef CONFIG_DRM_MSM_DSI_28NM_PHY
 struct msm_dsi_pll *msm_dsi_pll_28nm_init(struct platform_device *pdev,
enum msm_dsi_phy_type type, int id);
+#else
+static inline struct msm_dsi_pll *msm_dsi_pll_28nm_init(
+   struct platform_device *pdev, enum msm_dsi_phy_type type, int id)
+{
+   return ERR_PTR(-ENODEV);
+}
+#endif

 #endif /* __DSI_PLL_H__ */

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 4/5] drm/msm/dsi: Split PHY drivers to separate files

[Hai Li]

This change moves each PHY type specific code into
separate files.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/Makefile   |   6 +-
 drivers/gpu/drm/msm/dsi/dsi_phy.c  | 756 -
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 448 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |  89 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 150 ++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 166 +++
 6 files changed, 857 insertions(+), 758 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c

diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 14d167e..30f998a 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -1,5 +1,5 @@
 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/msm
-ccflags-$(CONFIG_DRM_MSM_DSI_PLL) += -Idrivers/gpu/drm/msm/dsi
+ccflags-$(CONFIG_DRM_MSM_DSI) += -Idrivers/gpu/drm/msm/dsi

 msm-y := \
adreno/adreno_device.o \
@@ -56,7 +56,9 @@ msm-$(CONFIG_COMMON_CLK) += mdp/mdp4/mdp4_lvds_pll.o
 msm-$(CONFIG_DRM_MSM_DSI) += dsi/dsi.o \
dsi/dsi_host.o \
dsi/dsi_manager.o \
-   dsi/dsi_phy.o \
+   dsi/phy/dsi_phy.o \
+   dsi/phy/dsi_phy_20nm.o \
+   dsi/phy/dsi_phy_28nm.o \
mdp/mdp5/mdp5_cmd_encoder.o

 msm-$(CONFIG_DRM_MSM_DSI_PLL) += dsi/pll/dsi_pll.o \
diff --git a/drivers/gpu/drm/msm/dsi/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/dsi_phy.c
deleted file mode 100644
index 77f1efe..000
--- a/drivers/gpu/drm/msm/dsi/dsi_phy.c
+++ /dev/null
@@ -1,756 +0,0 @@
-/*
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 and
- * only version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#include 
-#include 
-
-#include "dsi.h"
-#include "dsi.xml.h"
-
-#define dsi_phy_read(offset) msm_readl((offset))
-#define dsi_phy_write(offset, data) msm_writel((data), (offset))
-
-struct dsi_phy_ops {
-   int (*enable)(struct msm_dsi_phy *phy, int src_pll_id,
-   const unsigned long bit_rate, const unsigned long esc_rate);
-   void (*disable)(struct msm_dsi_phy *phy);
-};
-
-struct dsi_phy_cfg {
-   enum msm_dsi_phy_type type;
-   struct dsi_reg_config reg_cfg;
-   struct dsi_phy_ops ops;
-
-   /* Each cell {phy_id, pll_id} of the truth table indicates
-* if the source PLL is on the right side of the PHY.
-* Fill default H/W values in illegal cells, eg. cell {0, 1}.
-*/
-   bool src_pll_truthtable[DSI_MAX][DSI_MAX];
-};
-
-struct dsi_dphy_timing {
-   u32 clk_pre;
-   u32 clk_post;
-   u32 clk_zero;
-   u32 clk_trail;
-   u32 clk_prepare;
-   u32 hs_exit;
-   u32 hs_zero;
-   u32 hs_prepare;
-   u32 hs_trail;
-   u32 hs_rqst;
-   u32 ta_go;
-   u32 ta_sure;
-   u32 ta_get;
-};
-
-struct msm_dsi_phy {
-   struct platform_device *pdev;
-   void __iomem *base;
-   void __iomem *reg_base;
-   int id;
-
-   struct clk *ahb_clk;
-   struct regulator_bulk_data supplies[DSI_DEV_REGULATOR_MAX];
-
-   struct dsi_dphy_timing timing;
-   const struct dsi_phy_cfg *cfg;
-
-   bool regulator_ldo_mode;
-
-   struct msm_dsi_pll *pll;
-};
-
-static int dsi_phy_regulator_init(struct msm_dsi_phy *phy)
-{
-   struct regulator_bulk_data *s = phy->supplies;
-   const struct dsi_reg_entry *regs = phy->cfg->reg_cfg.regs;
-   struct device *dev = >pdev->dev;
-   int num = phy->cfg->reg_cfg.num;
-   int i, ret;
-
-   for (i = 0; i < num; i++)
-   s[i].supply = regs[i].name;
-
-   ret = devm_regulator_bulk_get(>pdev->dev, num, s);
-   if (ret < 0) {
-   dev_err(dev, "%s: failed to init regulator, ret=%d\n",
-   __func__, ret);
-   return ret;
-   }
-
-   for (i = 0; i < num; i++) {
-   if ((regs[i].min_voltage >= 0) && (regs[i].max_voltage >= 0)) {
-   ret = regulator_set_voltage(s[i].consumer,
-   regs[i].min_voltage, regs[i].max_voltage);
-   if (ret < 0) {
-   dev_err(dev,
-   "regulator %d set 

[PATCH 3/5] drm/msm/dsi: Return void from msm_dsi_phy_disable()

[Hai Li]

We are not checking the return value from msm_dsi_phy_disable().
Change the return type to void.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi.h |  2 +-
 drivers/gpu/drm/msm/dsi/dsi_phy.c | 16 +---
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 09492bf..5f5a373 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -168,7 +168,7 @@ void msm_dsi_phy_driver_register(void);
 void msm_dsi_phy_driver_unregister(void);
 int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int src_pll_id,
const unsigned long bit_rate, const unsigned long esc_rate);
-int msm_dsi_phy_disable(struct msm_dsi_phy *phy);
+void msm_dsi_phy_disable(struct msm_dsi_phy *phy);
 void msm_dsi_phy_get_clk_pre_post(struct msm_dsi_phy *phy,
u32 *clk_pre, u32 *clk_post);
 struct msm_dsi_pll *msm_dsi_phy_get_pll(struct msm_dsi_phy *phy);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/dsi_phy.c
index 799201e..77f1efe 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_phy.c
@@ -23,7 +23,7 @@
 struct dsi_phy_ops {
int (*enable)(struct msm_dsi_phy *phy, int src_pll_id,
const unsigned long bit_rate, const unsigned long esc_rate);
-   int (*disable)(struct msm_dsi_phy *phy);
+   void (*disable)(struct msm_dsi_phy *phy);
 };

 struct dsi_phy_cfg {
@@ -399,7 +399,7 @@ static int dsi_28nm_phy_enable(struct msm_dsi_phy *phy, int 
src_pll_id,
return 0;
 }

-static int dsi_28nm_phy_disable(struct msm_dsi_phy *phy)
+static void dsi_28nm_phy_disable(struct msm_dsi_phy *phy)
 {
dsi_phy_write(phy->base + REG_DSI_28nm_PHY_CTRL_0, 0);
dsi_28nm_phy_regulator_ctrl(phy, false);
@@ -409,8 +409,6 @@ static int dsi_28nm_phy_disable(struct msm_dsi_phy *phy)
 * ensure that the phy is completely disabled
 */
wmb();
-
-   return 0;
 }

 static void dsi_20nm_phy_regulator_ctrl(struct msm_dsi_phy *phy, bool enable)
@@ -515,12 +513,10 @@ static int dsi_20nm_phy_enable(struct msm_dsi_phy *phy, 
int src_pll_id,
return 0;
 }

-static int dsi_20nm_phy_disable(struct msm_dsi_phy *phy)
+static void dsi_20nm_phy_disable(struct msm_dsi_phy *phy)
 {
dsi_phy_write(phy->base + REG_DSI_20nm_PHY_CTRL_0, 0);
dsi_20nm_phy_regulator_ctrl(phy, false);
-
-   return 0;
 }

 static int dsi_phy_enable_resource(struct msm_dsi_phy *phy)
@@ -730,15 +726,13 @@ int msm_dsi_phy_enable(struct msm_dsi_phy *phy, int 
src_pll_id,
return phy->cfg->ops.enable(phy, src_pll_id, bit_rate, esc_rate);
 }

-int msm_dsi_phy_disable(struct msm_dsi_phy *phy)
+void msm_dsi_phy_disable(struct msm_dsi_phy *phy)
 {
if (!phy || !phy->cfg->ops.disable)
-   return -EINVAL;
+   return;

phy->cfg->ops.disable(phy);
dsi_phy_regulator_disable(phy);
-
-   return 0;
 }

 void msm_dsi_phy_get_clk_pre_post(struct msm_dsi_phy *phy,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 2/5] drm/msm/dsi: Specify bitmask to set source PLL

[Hai Li]

The bit position to configure source PLL will change
on new types of PHYs. The caller should pass down
this information.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi_phy.c | 16 +++-
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/dsi_phy.c
index bd37e61..799201e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_phy.c
@@ -157,17 +157,21 @@ fail:
return ret;
 }

-static void dsi_phy_set_src_pll(struct msm_dsi_phy *phy, int pll_id, u32 reg)
+static void dsi_phy_set_src_pll(struct msm_dsi_phy *phy, int pll_id, u32 reg,
+   u32 bit_mask)
 {
int phy_id = phy->id;
+   u32 val;

if ((phy_id >= DSI_MAX) || (pll_id >= DSI_MAX))
return;

+   val = dsi_phy_read(phy->base + reg);
+
if (phy->cfg->src_pll_truthtable[phy_id][pll_id])
-   dsi_phy_write(phy->base + reg, 0x01);
+   dsi_phy_write(phy->base + reg, val | bit_mask);
else
-   dsi_phy_write(phy->base + reg, 0x00);
+   dsi_phy_write(phy->base + reg, val & (~bit_mask));
 }

 #define S_DIV_ROUND_UP(n, d)   \
@@ -389,7 +393,8 @@ static int dsi_28nm_phy_enable(struct msm_dsi_phy *phy, int 
src_pll_id,

dsi_phy_write(base + REG_DSI_28nm_PHY_CTRL_0, 0x5f);

-   dsi_phy_set_src_pll(phy, src_pll_id, REG_DSI_28nm_PHY_GLBL_TEST_CTRL);
+   dsi_phy_set_src_pll(phy, src_pll_id, REG_DSI_28nm_PHY_GLBL_TEST_CTRL,
+   DSI_28nm_PHY_GLBL_TEST_CTRL_BITCLK_HS_SEL);

return 0;
 }
@@ -451,7 +456,8 @@ static int dsi_20nm_phy_enable(struct msm_dsi_phy *phy, int 
src_pll_id,

dsi_phy_write(base + REG_DSI_20nm_PHY_STRENGTH_0, 0xff);

-   dsi_phy_set_src_pll(phy, src_pll_id, REG_DSI_20nm_PHY_GLBL_TEST_CTRL);
+   dsi_phy_set_src_pll(phy, src_pll_id, REG_DSI_20nm_PHY_GLBL_TEST_CTRL,
+   DSI_20nm_PHY_GLBL_TEST_CTRL_BITCLK_HS_SEL);

for (i = 0; i < 4; i++) {
dsi_phy_write(base + REG_DSI_20nm_PHY_LN_CFG_3(i),
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 1/5] drm/msm/dsi: Update generated header file for DSI PHY

[Hai Li]

This change is to update DSI register definition changes
introduced by the following change:

rnndb/dsi: Add more bits for DSI PHY

More registers and bit fields are added for PHY timings
and bitclk source selection.

Signed-off-by: Hai Li 
---
 drivers/gpu/drm/msm/dsi/dsi.xml.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
b/drivers/gpu/drm/msm/dsi/dsi.xml.h
index 0af0981..41c6376 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
@@ -440,6 +440,9 @@ static inline uint32_t DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(enum 
dsi_lane_swap val)
 #define REG_DSI_PHY_RESET  0x0128
 #define DSI_PHY_RESET_RESET0x0001

+#define REG_DSI_T_CLK_PRE_EXTEND   0x017c
+#define DSI_T_CLK_PRE_EXTEND_INC_BY_2_BYTECLK  0x0001
+
 #define REG_DSI_RDBK_DATA_CTRL 0x01d0
 #define DSI_RDBK_DATA_CTRL_COUNT__MASK 0x00ff
 #define DSI_RDBK_DATA_CTRL_COUNT__SHIFT16
@@ -835,6 +838,7 @@ static inline uint32_t 
DSI_28nm_PHY_TIMING_CTRL_11_TRIG3_CMD(uint32_t val)
 #define REG_DSI_28nm_PHY_BIST_CTRL_5   0x01c8

 #define REG_DSI_28nm_PHY_GLBL_TEST_CTRL
0x01d4
+#define DSI_28nm_PHY_GLBL_TEST_CTRL_BITCLK_HS_SEL  0x0001

 #define REG_DSI_28nm_PHY_LDO_CNTRL 0x01dc

@@ -1161,6 +1165,7 @@ static inline uint32_t 
DSI_20nm_PHY_TIMING_CTRL_11_TRIG3_CMD(uint32_t val)
 #define REG_DSI_20nm_PHY_BIST_CTRL_5   0x01c8

 #define REG_DSI_20nm_PHY_GLBL_TEST_CTRL
0x01d4
+#define DSI_20nm_PHY_GLBL_TEST_CTRL_BITCLK_HS_SEL  0x0001

 #define REG_DSI_20nm_PHY_LDO_CNTRL 0x01dc

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH 0/5] drm/msm/dsi: Split different types of PHY drivers

[Hai Li]

The DSI PHY driver currently includes the implementation of all PHY types.
To support more types in the future, this patch series is moving each PHY
code into a separate file and making them compile independent. Some clean
up patches for DSI PHY are also included.

Hai Li (5):
  drm/msm/dsi: Update generated header file for DSI PHY
  drm/msm/dsi: Specify bitmask to set source PLL
  drm/msm/dsi: Return void from msm_dsi_phy_disable()
  drm/msm/dsi: Split PHY drivers to separate files
  drm/msm/dsi: Make each PHY type compilation independent

 drivers/gpu/drm/msm/Kconfig|  14 +
 drivers/gpu/drm/msm/Makefile   |  13 +-
 drivers/gpu/drm/msm/dsi/dsi.h  |   2 +-
 drivers/gpu/drm/msm/dsi/dsi.xml.h  |   5 +
 drivers/gpu/drm/msm/dsi/dsi_phy.c  | 756 -
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 452 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |  89 
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 150 ++
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 166 +++
 drivers/gpu/drm/msm/dsi/pll/dsi_pll.h  |   8 +
 10 files changed, 894 insertions(+), 761 deletions(-)
 delete mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy.c
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c
 create mode 100644 drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH] rnndb/dsi: Add more bits for DSI PHY

[Hai Li]

More registers and bit fields are added for PHY timings
and bitclk source selection.

Signed-off-by: Hai Li 
---
 rnndb/dsi/dsi.xml | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/rnndb/dsi/dsi.xml b/rnndb/dsi/dsi.xml
index 02cfa3b..956f3ff 100644
--- a/rnndb/dsi/dsi.xml
+++ b/rnndb/dsi/dsi.xml
@@ -217,6 +217,9 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



+   
+   
+   



@@ -437,7 +440,9 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
+   
+   
+   

 

@@ -608,7 +613,9 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/ 
rules-ng.xsd">



-   
+   
+   
+   

 

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[Bug 91527] 7870 radeon crashes after kernel msg drm:radeon_mn_invalidate_range_start

[bugzilla-dae...@freedesktop.org]

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

--- Comment #5 from JATothrim  ---
I did more research and I was able to capture full kernel crash dump.

Debugging the crashdump I found that The kernel dies at kernel version v3.18.19
in src lines: drivers/gpu/drm/radeon/radeon_mn.c:75 or
drivers/gpu/drm/radeon/radeon_mn.c:76 on to NULL ptr dereference.
At both code lines the kernel tries to lock a mutex apparently. I don't know
exactly which one fails as I'm no expert debugging x86-64 assembly.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/ceacc5e0/attachment.html>

[PATCH 0/4] Add support for Hyperlinks and Markup on kernel-doc

[Jonathan Corbet]

On Thu, 13 Aug 2015 20:09:35 -0300
Danilo Cesar Lemes de Paula  wrote:

> Did you find time to take a look on this?

No.  Just when I thought things couldn't get crazier, my laptop died.  

https://plus.google.com/+JonathanCorbet/posts/FBHp48dPb95

What spare time I had has been dedicated to recovering from that in time
to give my talk next week.

> I understand that there's some discussion behind the curtains regarding
> the markdown support, but the cross-reference-hyperlink patch is also in
> the same patch series. It doesn't change any text in the docbook unless
> there's really a cross-reference link to it. Different from the markdown
> support (when people start to use markdown to write docs it will be hard
> to go back), the cross-link stuff doesn't require/create any change to
> current documentation, it is pretty safe to use.
> 
> Would you mind to share your plans about this?

No behind-the-curtains discussions happening, or, let's say, if there
are, I've not been invited either.

I'd like to get back to the cross-reference stuff.  Last I tried, it
failed while building the media docs; have you been able to look at
that?  

Longer term, as you may know from the kernel summit discussions, I'd
really like to get rid of a lot of the XML gunk and put in something more
straightforward, be it based on Markdown or something else.  Doing that,
however, requires that I find the time to implement something that's
convincingly better.  It may happen soon, but I sure can't guarantee it.

Meanwhile, I think it would be a horrible mistake to delay useful work
because I have a gleam in my eye to do something different one of these
years, so I'll not do that.  I fully expect to merge all of the stuff
you've done, I just need to have a good look at it and test it out a
bit.  As I said before, I can't promise that for the 4.3 merge window,
but I'll try.

Apologies,

jon

[PATCH 1/5] drm: add interface to get drm devices on the system v2

[Daniel Vetter]

On Thu, Aug 13, 2015 at 11:33:41AM +0800, Jammy Zhou wrote:
> From: Emil Velikov 
> 
> For mutiple GPU support, the devices on the system should be enumerated
> to get necessary information about each device, and the drmGetDevices
> interface is added for this. Currently only PCI devices are supported for
> the enumeration.
> 
> Typical usage:
> int count;
> drmDevicePtr *foo;
> count = drmGetDevices(NULL, 0);
> foo = calloc(count, sizeof(drmDevicePtr));
> count = drmGetDevices(foo, count);
> /* find proper device, open correct device node, etc */
> drmFreeDevices(foo, count);
> free(foo);
> 
> v2: change according to feedback from Emil
> 
> Signed-off-by: Jammy Zhou 
> ---
>  xf86drm.c | 351 
> ++
>  xf86drm.h |  34 ++
>  2 files changed, 385 insertions(+)
> 
> diff --git a/xf86drm.c b/xf86drm.c
> index 5e02969..237663b 100644
> --- a/xf86drm.c
> +++ b/xf86drm.c
> @@ -55,6 +55,7 @@
>  #ifdef HAVE_SYS_MKDEV_H
>  # include  /* defines major(), minor(), and makedev() on 
> Solaris */
>  #endif
> +#include 
>  
>  /* Not all systems have MAP_FAILED defined */
>  #ifndef MAP_FAILED
> @@ -2829,3 +2830,353 @@ char *drmGetRenderDeviceNameFromFd(int fd)
>  {
>   return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
>  }
> +
> +#ifdef __linux__
> +static int drmParseSubsystemType(const char *str)
> +{
> +char link[PATH_MAX + 1] = "";
> +char *name;
> +
> +if (readlink(str, link, PATH_MAX) < 0)
> +return -EINVAL;
> +
> +name = strrchr(link, '/');
> +if (!name)
> +return -EINVAL;
> +
> +name++;
> +
> +if (strncmp(name, "pci", 3) == 0)
> +return DRM_BUS_PCI;
> +
> +return -EINVAL;
> +}
> +
> +static int drmParsePciBusInfo(const char *str, drmPciBusInfoPtr info)
> +{
> +int domain, bus, dev, func;
> +char *value;
> +
> +if (str == NULL)
> +return -EINVAL;
> +
> +value = strstr(str, "PCI_SLOT_NAME=");
> +if (value == NULL)
> +return -EINVAL;
> +
> +value += strlen("PCI_SLOT_NAME=");
> +
> +if (sscanf(value, "%04x:%02x:%02x.%1u",
> +   , , , ) != 4)
> +return -EINVAL;
> +
> +info->domain = domain;
> +info->bus = bus;
> +info->dev = dev;
> +info->func = func;
> +
> +return 0;
> +}
> +
> +static int drmSameDevice(drmDevicePtr a, drmDevicePtr b)
> +{
> +if (a->bustype != b->bustype)
> +return 0;
> +
> +switch (a->bustype) {
> +case DRM_BUS_PCI:
> +if (memcmp(a->businfo.pci, b->businfo.pci, sizeof(drmPciBusInfo)) == 
> 0)
> +return 1;
> +default:
> +break;
> +}
> +
> +return 0;
> +}
> +
> +static int drmGetNodeType(const char *name)
> +{
> +if (strncmp(name, DRM_PRIMARY_MINOR_NAME,
> +sizeof(DRM_PRIMARY_MINOR_NAME) - 1) == 0)
> +return DRM_NODE_PRIMARY;
> +
> +if (strncmp(name, DRM_CONTROL_MINOR_NAME,
> +sizeof(DRM_CONTROL_MINOR_NAME ) - 1) == 0)
> +return DRM_NODE_CONTROL;
> +
> +if (strncmp(name, DRM_RENDER_MINOR_NAME,
> +sizeof(DRM_RENDER_MINOR_NAME) - 1) == 0)
> +return DRM_NODE_RENDER;
> +
> +return -EINVAL;
> +}
> +
> +static int drmParsePciDeviceInfo(const char *config,
> + drmPciDeviceInfoPtr device)
> +{
> +if (config == NULL)
> +return -EINVAL;
> +
> +device->vendor_id = config[0] | (config[1] << 8);
> +device->device_id = config[2] | (config[3] << 8);
> +device->revision_id = config[8];
> +device->subvendor_id = config[44] | (config[45] << 8);
> +device->subdevice_id = config[46] | (config[47] << 8);

Why not reuse libpciaccess?
-Daniel

> +
> +return 0;
> +}
> +
> +static void drmFreeDevice(drmDevicePtr device)
> +{
> +int i;
> +
> +if (device == NULL)
> +return;
> +
> +if (device->nodes != NULL)
> +for (i = 0; i < DRM_NODE_MAX; i++)
> +free(device->nodes[i]);
> +
> +free(device->nodes);
> +free(device->businfo.pci);
> +free(device->deviceinfo.pci);
> +}
> +
> +void drmFreeDevices(drmDevicePtr devices[], int count)
> +{
> +int i;
> +
> +if (devices == NULL)
> +return;
> +
> +for (i = 0; i < count; i++) {
> +drmFreeDevice(devices[i]);
> +free(devices[i]);
> +devices[i] = NULL;
> +}
> +}
> +
> +/**
> + * Get drm devices on the system
> + *
> + * \param devices the array of devices with drmDevicePtr elements
> + *can be NULL to get the device number first
> + * \param max_devices the maximum number of devices for the array
> + *
> + * \return on error - negative error code,
> + * if devices is NULL - total number of devices available on the 
> system,
> + * alternatively the number of devices stored in devices[], which is
> + * capped by the max_devices.
> + */
> +int drmGetDevices(drmDevicePtr devices[], int max_devices)
> +{
> +drmDevicePtr devs = NULL;
> +drmPciBusInfoPtr pcibus 

[PATCH 2/2] drm: WARN_ON if a modeset driver uses legacy suspend/resume helpers

[Gustavo Padovan]

From: Gustavo Padovan 

Legacy s/r hooks are only used for shadow-attaching drivers, warn
when a KMS driver tries to use them.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/drm_drv.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index b7bf4ce..4e76193 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -567,6 +567,8 @@ struct drm_device *drm_dev_alloc(struct drm_driver *driver,
ret = drm_minor_alloc(dev, DRM_MINOR_CONTROL);
if (ret)
goto err_minors;
+
+   WARN_ON(driver->suspend || driver->resume);
}

if (drm_core_check_feature(dev, DRIVER_RENDER)) {
-- 
2.1.0

[PATCH 1/2] drm/exynos: remove legacy ->suspend()/resume()

[Gustavo Padovan]

From: Gustavo Padovan 

These legacy helpers should only be used by shadow-attaching drivers.
KMS drivers has its own way to handle suspend/resume and don't need to
use these two helpers.

Signed-off-by: Gustavo Padovan 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index f1d6966..9bcf679 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -280,8 +280,6 @@ static struct drm_driver exynos_drm_driver = {
.driver_features= DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
-   .suspend= exynos_drm_suspend,
-   .resume = exynos_drm_resume,
.open   = exynos_drm_open,
.preclose   = exynos_drm_preclose,
.lastclose  = exynos_drm_lastclose,
-- 
2.1.0

[Intel-gfx] [PATCH v4] mmap on the dma-buf directly

[Daniel Vetter]

On Thu, Aug 13, 2015 at 11:09:07AM -0300, Tiago Vignatti wrote:
> On 08/13/2015 08:09 AM, Thomas Hellstrom wrote:
> >Tiago,
> >
> >I take it, this is intended to be a generic interface used mostly for 2D
> >rendering.
> 
> yup. "generic" is an important point that I've actually forgot to mention in
> the description, which is probably the whole motivation for bringing this
> up.
> 
> We want avoid link any vendor-specific library to the unpriviledged process
> for security reasons, so it's a requirement to it not have access to
> driver-specific ioctls when mapping the buffers. The use-case for it is
> texturing from CPU rendered buffer, like you said, with the intention of
> passing these buffers among processes without performing any copy in the
> user-space ("zero-copy").
> 
> >In that case, using SYNC is crucial for performance of incoherent
> >architectures and I'd rather see it mandatory than an option. It could
> >perhaps be made mandatory preferrably using an error or a one-time
> >kernel warning. If nobody uses the SYNC interface, it is of little use.
> 
> hmm I'm not sure it is little use. Our hardware (the "LLC" capable) has this
> very specific case where the cache gets dirty wrt the GPU, which is when the
> same buffer is shared with the scanout device. This is not something will
> happen in Chrome OS for example, so we wouldn't need the SYNC markers there.
> 
> In any case I think that making it mandatory works for us, but I'll have to
> check with Daniel/Chris whether there are performance penalties when
> accessing it and so on.

2 more ioctls per upload should be bearable, imo we should make this
mandatory.

> >Also I think the syncing needs to be extended to two dimensions. A long
> >time ago when this was brought up people argued why we should limit it
> >to two dimensions, but I believe two dimensions addresses most
> >performance-problematic use-cases. A default implementation of
> >twodimensional sync can easily be made using the one-dimensional API.
> 
> two dimension sync? You're saying that there could be a GPU access API in
> dma-buf as well? I don't get it, what's the use-case? I'm sure I missed the
> discussions because I wasn't particularly interested in this whole thingy
> before :)

Most of the things I've seen that use subranges for up/download use linear
buffers where individual images are just packed in a queue, each with
their own stride. Adding a notion of 2d to dma-buf would be a big
departure from the "dma-buf doesn't track metadata" design. If there's a
real need I guess we can do it, but only after careful consideration, and
imo it shouldn't be in basic dma-buf mmap support.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 3/7] prime_mmap: Add basic tests to write in a bo using CPU

[Daniel Vetter]

On Thu, Aug 13, 2015 at 11:26:57AM -0300, Tiago Vignatti wrote:
> On 08/13/2015 04:01 AM, Daniel Vetter wrote:
> >On Wed, Aug 12, 2015 at 08:29:16PM -0300, Tiago Vignatti wrote:
> >>This patch adds test_correct_cpu_write, which maps the texture buffer 
> >>through a
> >>prime fd and then writes directly to it using the CPU. It stresses the 
> >>driver
> >>to guarantee cache synchronization among the different domains.
> >>
> >>This test also adds test_forked_cpu_write, which creates the GEM bo in one
> >>process and pass the prime handle of the it to another process, which in 
> >>turn
> >>uses the handle only to map and write. Grossly speaking this test simulates
> >>Chrome OS  architecture, where the Web content ("unpriviledged process") 
> >>maps
> >>and CPU-draws a buffer, which was previously allocated in the GPU process
> >>("priviledged process").
> >>
> >>This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
> >>O_RDWR during prime-handle-to-fd").
> >>
> >>Signed-off-by: Tiago Vignatti 
> >
> >Squash with previous patch?
> 
> why? if the whole point is to decrease the amount of patches, then I prefer
> to squash 2/7 with the 1/7 (although they're from different authors and
> would be nice to keep separately the changes from each). This patch here
> introduces this writing to mmap'ed dma-buf fd, a concept that is still in
> debate, requiring a kernel counter-part so that's why I preferred to keep it
> away.

Replied to the wrong patch, I meant merging patch 1&2 ofc ;-)
-Daniel

> 
> 
> >>---
> >>  lib/ioctl_wrappers.c |  5 +++-
> >>  tests/prime_mmap.c   | 65 
> >> 
> >>  2 files changed, 69 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> >>index 53bd635..941fa66 100644
> >>--- a/lib/ioctl_wrappers.c
> >>+++ b/lib/ioctl_wrappers.c
> >>@@ -1125,6 +1125,9 @@ void gem_require_ring(int fd, int ring_id)
> >>
> >>  /* prime */
> >>
> >>+#ifndef DRM_RDWR
> >>+#define DRM_RDWR O_RDWR
> >>+#endif
> >>  /**
> >>   * prime_handle_to_fd:
> >>   * @fd: open i915 drm file descriptor
> >>@@ -1142,7 +1145,7 @@ int prime_handle_to_fd(int fd, uint32_t handle)
> >>
> >>memset(, 0, sizeof(args));
> >>args.handle = handle;
> >>-   args.flags = DRM_CLOEXEC;
> >>+   args.flags = DRM_CLOEXEC | DRM_RDWR;
> >
> >This needs to be optional otherwise all the existing prime tests start
> >falling over on older kernels. Probably need a
> >prime_handle_to_fd_with_mmap, which doesn an igt_skip if it fails.
> 
> true. Thank you.
> 
> 
> >-Daniel
> >
> >>args.fd = -1;
> >>
> >>do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, );
> >>diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
> >>index dc59e8f..ad91371 100644
> >>--- a/tests/prime_mmap.c
> >>+++ b/tests/prime_mmap.c
> >>@@ -22,6 +22,7 @@
> >>   *
> >>   * Authors:
> >>   *Rob Bradford 
> >>+ *Tiago Vignatti 
> >>   *
> >>   */
> >>
> >>@@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
> >>  }
> >>
> >>  static void
> >>+fill_bo_cpu(char *ptr)
> >>+{
> >>+   memcpy(ptr, pattern, sizeof(pattern));
> >>+}
> >>+
> >>+static void
> >>  test_correct(void)
> >>  {
> >>int dma_buf_fd;
> >>@@ -180,6 +187,62 @@ test_forked(void)
> >>gem_close(fd, handle);
> >>  }
> >>
> >>+/* test CPU write. This has a rather big implication for the driver which 
> >>must
> >>+ * guarantee cache synchronization when writing the bo using CPU. */
> >>+static void
> >>+test_correct_cpu_write(void)
> >>+{
> >>+   int dma_buf_fd;
> >>+   char *ptr;
> >>+   uint32_t handle;
> >>+
> >>+   handle = gem_create(fd, BO_SIZE);
> >>+
> >>+   dma_buf_fd = prime_handle_to_fd(fd, handle);
> >>+   igt_assert(errno == 0);
> >>+
> >>+   /* Check correctness of map using write protection (PROT_WRITE) */
> >>+   ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, 
> >>dma_buf_fd, 0);
> >>+   igt_assert(ptr != MAP_FAILED);
> >>+
> >>+   /* Fill bo using CPU */
> >>+   fill_bo_cpu(ptr);
> >>+
> >>+   /* Check pattern correctness */
> >>+   igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
> >>+
> >>+   munmap(ptr, BO_SIZE);
> >>+   close(dma_buf_fd);
> >>+   gem_close(fd, handle);
> >>+}
> >>+
> >>+/* map from another process and then write using CPU */
> >>+static void
> >>+test_forked_cpu_write(void)
> >>+{
> >>+   int dma_buf_fd;
> >>+   char *ptr;
> >>+   uint32_t handle;
> >>+
> >>+   handle = gem_create(fd, BO_SIZE);
> >>+
> >>+   dma_buf_fd = prime_handle_to_fd(fd, handle);
> >>+   igt_assert(errno == 0);
> >>+
> >>+   igt_fork(childno, 1) {
> >>+   ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED, 
> >>dma_buf_fd, 0);
> >>+   igt_assert(ptr != MAP_FAILED);
> >>+   fill_bo_cpu(ptr);
> >>+
> >>+   igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
> >>+   munmap(ptr, BO_SIZE);
> >>+   close(dma_buf_fd);
> >>+   }
> >>+   close(dma_buf_fd);
> >>+   igt_waitchildren();
> >>+   

[PATCH 1/5] drm: add interface to get drm devices on the system v2

[Emil Velikov]

On 13 August 2015 at 16:07, Daniel Vetter  wrote:
> On Thu, Aug 13, 2015 at 11:33:41AM +0800, Jammy Zhou wrote:
>> From: Emil Velikov 
>>
>> For mutiple GPU support, the devices on the system should be enumerated
>> to get necessary information about each device, and the drmGetDevices
>> interface is added for this. Currently only PCI devices are supported for
>> the enumeration.
>>
>> Typical usage:
>> int count;
>> drmDevicePtr *foo;
>> count = drmGetDevices(NULL, 0);
>> foo = calloc(count, sizeof(drmDevicePtr));
>> count = drmGetDevices(foo, count);
>> /* find proper device, open correct device node, etc */
>> drmFreeDevices(foo, count);
>> free(foo);
>>
>> v2: change according to feedback from Emil
>>
>> Signed-off-by: Jammy Zhou 
>> ---
>>  xf86drm.c | 351 
>> ++
>>  xf86drm.h |  34 ++
>>  2 files changed, 385 insertions(+)
>>
>> diff --git a/xf86drm.c b/xf86drm.c
>> index 5e02969..237663b 100644
>> --- a/xf86drm.c
>> +++ b/xf86drm.c
>> @@ -55,6 +55,7 @@
>>  #ifdef HAVE_SYS_MKDEV_H
>>  # include  /* defines major(), minor(), and makedev() on 
>> Solaris */
>>  #endif
>> +#include 
>>
>>  /* Not all systems have MAP_FAILED defined */
>>  #ifndef MAP_FAILED
>> @@ -2829,3 +2830,353 @@ char *drmGetRenderDeviceNameFromFd(int fd)
>>  {
>>   return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
>>  }
>> +
>> +#ifdef __linux__
>> +static int drmParseSubsystemType(const char *str)
>> +{
>> +char link[PATH_MAX + 1] = "";
>> +char *name;
>> +
>> +if (readlink(str, link, PATH_MAX) < 0)
>> +return -EINVAL;
>> +
>> +name = strrchr(link, '/');
>> +if (!name)
>> +return -EINVAL;
>> +
>> +name++;
>> +
>> +if (strncmp(name, "pci", 3) == 0)
>> +return DRM_BUS_PCI;
>> +
>> +return -EINVAL;
>> +}
>> +
>> +static int drmParsePciBusInfo(const char *str, drmPciBusInfoPtr info)
>> +{
>> +int domain, bus, dev, func;
>> +char *value;
>> +
>> +if (str == NULL)
>> +return -EINVAL;
>> +
>> +value = strstr(str, "PCI_SLOT_NAME=");
>> +if (value == NULL)
>> +return -EINVAL;
>> +
>> +value += strlen("PCI_SLOT_NAME=");
>> +
>> +if (sscanf(value, "%04x:%02x:%02x.%1u",
>> +   , , , ) != 4)
>> +return -EINVAL;
>> +
>> +info->domain = domain;
>> +info->bus = bus;
>> +info->dev = dev;
>> +info->func = func;
>> +
>> +return 0;
>> +}
>> +
>> +static int drmSameDevice(drmDevicePtr a, drmDevicePtr b)
>> +{
>> +if (a->bustype != b->bustype)
>> +return 0;
>> +
>> +switch (a->bustype) {
>> +case DRM_BUS_PCI:
>> +if (memcmp(a->businfo.pci, b->businfo.pci, sizeof(drmPciBusInfo)) 
>> == 0)
>> +return 1;
>> +default:
>> +break;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int drmGetNodeType(const char *name)
>> +{
>> +if (strncmp(name, DRM_PRIMARY_MINOR_NAME,
>> +sizeof(DRM_PRIMARY_MINOR_NAME) - 1) == 0)
>> +return DRM_NODE_PRIMARY;
>> +
>> +if (strncmp(name, DRM_CONTROL_MINOR_NAME,
>> +sizeof(DRM_CONTROL_MINOR_NAME ) - 1) == 0)
>> +return DRM_NODE_CONTROL;
>> +
>> +if (strncmp(name, DRM_RENDER_MINOR_NAME,
>> +sizeof(DRM_RENDER_MINOR_NAME) - 1) == 0)
>> +return DRM_NODE_RENDER;
>> +
>> +return -EINVAL;
>> +}
>> +
>> +static int drmParsePciDeviceInfo(const char *config,
>> + drmPciDeviceInfoPtr device)
>> +{
>> +if (config == NULL)
>> +return -EINVAL;
>> +
>> +device->vendor_id = config[0] | (config[1] << 8);
>> +device->device_id = config[2] | (config[3] << 8);
>> +device->revision_id = config[8];
>> +device->subvendor_id = config[44] | (config[45] << 8);
>> +device->subdevice_id = config[46] | (config[47] << 8);
>
> Why not reuse libpciaccess?
I fully agree that the implementation is not pretty, although...

Adding dependencies for optional new features doesn't seem too
appealing, either. It will also save us some headaches when someone
starts shipping libpciaccess.so with their binary game/program (just
like libudev is today).

Would be great if we can use libudev but... just not yet.

If you have any other ideas/suggestions please fire away.

Thanks
Emi

[PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

Russell King - ARM Linux  writes:

> On Thu, Aug 13, 2015 at 01:44:03PM -0700, Eric Anholt wrote:
>> Struct mutex is here because this code is from the V3D series, with the
>> in-kernel BO cache ripped out (it turns out that the CMA allocator is
>> slow, and you can't just userspace cache since we have to do allocations
>> within the kernel to the tune of a couple per draw and that's too much).
>
> The CMA allocator is fast until you have pinned pages in its region,
> where it becomes _very_ slow to do allocations, sometimes getting up
> to the order of seconds.
>
> The main culpret of this are GFP_HIGHUSER_MOVABLE allocations which
> then pin the page.  It doesn't take many of those to make CMA really
> inefficient.
>
> The problem is that CMA doesn't get any information back from the
> internal page migration about which pages couldn't be moved, so it
> dumbly just tries incrementing the allocation by one page (subject
> to alignment constraints) and retrying again - repeating over the
> entire CMA region.  The bigger the region, the more time this takes.

Ouch.

Since I can workaround the allocation cost, the main problem I have
right now is that I've got a set of small allocations for 3D that all
need to have the same high 4 bits of paddr, because someone cleverly
packed some address bits in a GPU-managed structure.  Any
recommendations for ways to handle this with CMA?
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/771987cb/attachment-0001.sig>

[PATCH 0/5] some drm and amdgpu patches

[Michel Dänzer]

Hi Jammy,


On 13.08.2015 12:33, Jammy Zhou wrote:
> This series is a set of patches in my side pending for merge. And I rebased it
> with the drm_private series from Emil.
> 
> Emil Velikov (1):
>   drm: add interface to get drm devices on the system v2
> 
> Jammy Zhou (4):
>   amdgpu: improve amdgpu_vamgr_init
>   amdgpu: add flag to support 32bit VA address v3
>   amdgpu: fix one warning from previous commit
>   amdgpu: make vamgr per device v2

Please squash patch 4 (and maybe patch 5 as well?) into patch 3.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[Regression v4.2] Re: [PATCH 7/9] drm/radeon: add VCE 1.0 support v4

[Michel Dänzer]

On 13.08.2015 15:03, Lucas Stach wrote:
> Hi Christian,
> 
> this commit is causing a boot regression with v4.2-rcX on my Richland
> APU (CHIP_ARUBA) based laptop. I didn't have time yet to track down
> where exactly it is going wrong, but I bisected it down to this single
> commit.
> 
> I don't have the VCE firmware installed on this system, so from a quick
> look at the code I would expect it to drop out pretty early and just
> leave the VCE unconfigured, but otherwise keep things working as before.
> This is unfortunately not the case.

If the radeon driver is built into the kernel (or loaded from the
initrd?), the attempt to load the firmware might take a long time to
time out.

Please provide more information about the symptoms, e.g. any dmesg
output etc.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

[PATCH 08/13] drm/irq: Check for valid VBLANK before dereference

[Daniel Vetter]

On Thu, Aug 13, 2015 at 11:20:05AM +0200, Thierry Reding wrote:
> On Wed, Aug 12, 2015 at 05:40:11PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 12, 2015 at 05:00:30PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > When accessing the array of per-CRTC VBLANK structures we must always
> > > check that the index into the array is valid before dereferencing to
> > > avoid crashing.
> > > 
> > > Signed-off-by: Thierry Reding 
> > 
> > This misses vblank_reset (I guess that function is newer than your
> > patches). Can you please do a follow-up? I merged this one meanwhile.
> 
> We only have drm_crtc_vblank_reset(), in which case there's no need to
> check the index because it's obtained directly from a struct drm_crtc *
> and hence will be valid.

Right, I overlooked that.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 10/13] drm/irq: Add drm_crtc_vblank_count_and_time()

[Daniel Vetter]

On Thu, Aug 13, 2015 at 11:12:37AM +0200, Thierry Reding wrote:
> On Wed, Aug 12, 2015 at 05:35:08PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 12, 2015 at 05:00:32PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > This function is the KMS native variant of drm_vblank_count_and_time().
> > > It takes a struct drm_crtc * instead of a struct drm_device * and an
> > > index of the CRTC.
> > > 
> > > Eventually the goal is to access vblank data through the CRTC only so
> > > that the per-CRTC data can be moved to struct drm_crtc.
> > > 
> > > Signed-off-by: Thierry Reding 
> > 
> > We seem to not use this anywhere outside for drm_irq.c, so maybe just drop
> > the kerneldoc and EXPORT_SYMBOL? The actual comment starting with "Fecthes
> > the "cooked" vblank ..." should imo be kept.
> 
> There don't seem to be any users of this, so I guess we can ignore this
> for now.

I mean removing the kerneldoc /** marker plus EXPORT_SYMBOL for the
drm_vblank_count_and_time function and marking it static. Instead of this
patch here, not changing this patch here.
-Daniel

> 
> Thierry
> 
> > > ---
> > >  drivers/gpu/drm/drm_irq.c | 23 +++
> > >  include/drm/drmP.h|  2 ++
> > >  2 files changed, 25 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > > index f42459b2862d..904914d8f1f1 100644
> > > --- a/drivers/gpu/drm/drm_irq.c
> > > +++ b/drivers/gpu/drm/drm_irq.c
> > > @@ -913,6 +913,8 @@ EXPORT_SYMBOL(drm_crtc_vblank_count);
> > >   * vblank events since the system was booted, including lost events due 
> > > to
> > >   * modesetting activity. Returns corresponding system timestamp of the 
> > > time
> > >   * of the vblank interval that corresponds to the current vblank counter 
> > > value.
> > > + *
> > > + * This is the legacy version of drm_crtc_vblank_count_and_time().
> > >   */
> > >  u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> > > struct timeval *vblanktime)
> > > @@ -939,6 +941,27 @@ u32 drm_vblank_count_and_time(struct drm_device 
> > > *dev, unsigned int pipe,
> > >  }
> > >  EXPORT_SYMBOL(drm_vblank_count_and_time);
> > >  
> > > +/**
> > > + * drm_crtc_vblank_count_and_time - retrieve "cooked" vblank counter 
> > > value
> > > + * and the system timestamp corresponding to that vblank counter 
> > > value
> > > + * @crtc: which counter to retrieve
> > > + * @vblanktime: Pointer to struct timeval to receive the vblank 
> > > timestamp.
> > > + *
> > > + * Fetches the "cooked" vblank count value that represents the number of
> > > + * vblank events since the system was booted, including lost events due 
> > > to
> > > + * modesetting activity. Returns corresponding system timestamp of the 
> > > time
> > > + * of the vblank interval that corresponds to the current vblank counter 
> > > value.
> > > + *
> > > + * This is the native KMS version of drm_vblank_count_and_time().
> > > + */
> > > +u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> > > +struct timeval *vblanktime)
> > > +{
> > > + return drm_vblank_count_and_time(crtc->dev, drm_crtc_index(crtc),
> > > +  vblanktime);
> > > +}
> > > +EXPORT_SYMBOL(drm_crtc_vblank_count_and_time);
> > > +
> > >  static void send_vblank_event(struct drm_device *dev,
> > >   struct drm_pending_vblank_event *e,
> > >   unsigned long seq, struct timeval *now)
> > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > > index 020afa343dff..7cd480614035 100644
> > > --- a/include/drm/drmP.h
> > > +++ b/include/drm/drmP.h
> > > @@ -927,6 +927,8 @@ extern u32 drm_vblank_count(struct drm_device *dev, 
> > > int pipe);
> > >  extern u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
> > >  extern u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned 
> > > int pipe,
> > >struct timeval *vblanktime);
> > > +extern u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> > > +   struct timeval *vblanktime);
> > >  extern void drm_send_vblank_event(struct drm_device *dev, unsigned int 
> > > pipe,
> > > struct drm_pending_vblank_event *e);
> > >  extern void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> > > -- 
> > > 2.4.5
> > > 
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/irq: More pipe/crtc consistency cleanups

[Daniel Vetter]

On Thu, Aug 13, 2015 at 11:38:51AM +0200, Thierry Reding wrote:
> From: Thierry Reding 
> 
> Commit cc1ef118fc09 ("drm/irq: Make pipe unsigned and name consistent")
> missed a few occurrences of int pipe/crtc across various rebases. Clean
> the remaining ones up now.
> 
> Signed-off-by: Thierry Reding 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_irq.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 20cf5776ce70..3960168503f1 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -74,11 +74,11 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay, 
> int, 0600);
>  module_param_named(timestamp_precision_usec, drm_timestamp_precision, int, 
> 0600);
>  module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);
>  
> -static void store_vblank(struct drm_device *dev, int crtc,
> +static void store_vblank(struct drm_device *dev, unsigned int pipe,
>u32 vblank_count_inc,
>struct timeval *t_vblank)
>  {
> - struct drm_vblank_crtc *vblank = >vblank[crtc];
> + struct drm_vblank_crtc *vblank = >vblank[pipe];
>   u32 tslot;
>  
>   assert_spin_locked(>vblank_time_lock);
> @@ -88,7 +88,7 @@ static void store_vblank(struct drm_device *dev, int crtc,
>* the latching of vblank->count below.
>*/
>   tslot = vblank->count + vblank_count_inc;
> - vblanktimestamp(dev, crtc, tslot) = *t_vblank;
> + vblanktimestamp(dev, pipe, tslot) = *t_vblank;
>   }
>  
>   /*
> @@ -867,7 +867,7 @@ drm_get_last_vbltimestamp(struct drm_device *dev, 
> unsigned int pipe,
>   * Returns:
>   * The software vblank counter.
>   */
> -u32 drm_vblank_count(struct drm_device *dev, int pipe)
> +u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
>  {
>   struct drm_vblank_crtc *vblank = >vblank[pipe];
>  
> @@ -1292,7 +1292,7 @@ EXPORT_SYMBOL(drm_crtc_vblank_off);
>  
>  /**
>   * drm_crtc_vblank_reset - reset vblank state to off on a CRTC
> - * @drm_crtc: CRTC in question
> + * @crtc: CRTC in question
>   *
>   * Drivers can use this function to reset the vblank state to off at load 
> time.
>   * Drivers should use this together with the drm_crtc_vblank_off() and
> @@ -1300,12 +1300,12 @@ EXPORT_SYMBOL(drm_crtc_vblank_off);
>   * drm_crtc_vblank_off() is that this function doesn't save the vblank 
> counter
>   * and hence doesn't need to call any driver hooks.
>   */
> -void drm_crtc_vblank_reset(struct drm_crtc *drm_crtc)
> +void drm_crtc_vblank_reset(struct drm_crtc *crtc)
>  {
>   struct drm_device *dev = drm_crtc->dev;
>   unsigned long irqflags;
> - int crtc = drm_crtc_index(drm_crtc);
> - struct drm_vblank_crtc *vblank = >vblank[crtc];
> + unsigned int pipe = drm_crtc_index(crtc);
> + struct drm_vblank_crtc *vblank = >vblank[pipe];
>  
>   spin_lock_irqsave(>vbl_lock, irqflags);
>   /*
> -- 
> 2.4.5
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v2] drm/panel: add lg4573 driver

[Thierry Reding]

On Tue, Jun 09, 2015 at 07:51:22AM +0200, Heiko Schocher wrote:
> Add support for LG LG4573 480x800 4,3" panel. the LG4573
> is used on the LG LCD LB043WV2-SD01, an industrial 4.3" TFT
> panel with SPI control interface.
> 
> Signed-off-by: Heiko Schocher 
> 
> ---
> 
> Changes in v2:
> - add comments from Thierry Reding:
>   - fix some spelling issues
>   - remove "power-on-delay"
>   - remove display timings usage from DT, instead specify the
> timing in the driver.
>   - change config symbol to DRM_PANEL_LG_LG4573
>   - change filename to panel-lg-lg4573.c
>   - get rid of power_on_delay
>   - use cpu_to_be16()
>   - rework lg4573_spi_write_u16_array()
>   - introduce lg4573_spi_write_dcs()
>   - reworked error reporting
> 
>  .../devicetree/bindings/panel/lg,lg4573.txt|  19 +
>  drivers/gpu/drm/panel/Kconfig  |   8 +
>  drivers/gpu/drm/panel/Makefile |   1 +
>  drivers/gpu/drm/panel/panel-lg-lg4573.c| 382 
> +
>  4 files changed, 410 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/panel/lg,lg4573.txt
>  create mode 100644 drivers/gpu/drm/panel/panel-lg-lg4573.c

There were a couple of review comments that you missed, but I've
addressed them while applying. Might be good to give it[0] a spin just
to make sure I didn't accidentally break anything.

Thierry

[0]: git://anongit.freedesktop.org/tegra/linux#drm/panel/for-next
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/ec50dd46/attachment.sig>

[PATCH 1/5] drm: add interface to get drm devices on the system v2

[Emil Velikov]

On 13 August 2015 at 04:33, Jammy Zhou  wrote:
> From: Emil Velikov 
>
> For mutiple GPU support, the devices on the system should be enumerated
> to get necessary information about each device, and the drmGetDevices
> interface is added for this. Currently only PCI devices are supported for
> the enumeration.
>
If there are any other devices they will still be counted when
drmGetDevices(NULL, 0)... Is that intentional ?


> +static int drmParsePciDeviceInfo(const char *config,
> + drmPciDeviceInfoPtr device)
> +{
> +if (config == NULL)
> +return -EINVAL;
> +
> +device->vendor_id = config[0] | (config[1] << 8);
> +device->device_id = config[2] | (config[3] << 8);
> +device->revision_id = config[8];
> +device->subvendor_id = config[44] | (config[45] << 8);
> +device->subdevice_id = config[46] | (config[47] << 8);
> +
Something funny is happening here - on my intel system vendor_id is
reported as 0xff86, instead of 0x8086. Subvendor/device are also
messed up - ffaa and ffda instead of 17aa + 21da.

One could bikeshed on the de-duplication error path(s), but
considering that things work and there are no leaks we can leave that
for some other day.

-Emil

[PATCH v3 2/2] drm/panel: Add display timing for Okaya RS800480T-7X0GP

[Gary Bisson]

Hi Thierry,

On Thu, Aug 13, 2015 at 2:32 PM, Thierry Reding
 wrote:
> On Wed, Jun 10, 2015 at 06:44:23PM +0200, Gary Bisson wrote:
>> Add support for the Okaya RS800480T-7X0GP to the DRM simple panel
>> driver.
>>
>> The RS800480T-7X0GP is a WVGA (800x480) panel with an 18-bit parallel
>> LCD interface. It supports pixel clocks in the range of 30-40 MHz.
>>
>> This panel details can be found at:
>> http://boundarydevices.com/product/7-800x480-display/
>>
>> Signed-off-by: Gary Bisson 
>> ---
>>  .../bindings/panel/okaya,rs800480t_7x0gp.txt   |  7 +
>>  drivers/gpu/drm/panel/panel-simple.c   | 33 
>> ++
>>  2 files changed, 40 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt 
>> b/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
>> new file mode 100644
>> index 000..f7c729d
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
>> @@ -0,0 +1,7 @@
>> +OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
>> +
>> +Required properties:
>> +- compatible: should be "okaya,rs800480t_7x0gp"
>
> Underscores are not typically used in compatible strings, so I've
> changed this to "okaya,rs800480t-7x0gp".

Thanks! I'll make sure not to use underscores for such names in the future.

Regards,
Gary

[PATCH v3 2/2] drm/panel: Add display timing for Okaya RS800480T-7X0GP

[Thierry Reding]

On Wed, Jun 10, 2015 at 06:44:23PM +0200, Gary Bisson wrote:
> Add support for the Okaya RS800480T-7X0GP to the DRM simple panel
> driver.
> 
> The RS800480T-7X0GP is a WVGA (800x480) panel with an 18-bit parallel
> LCD interface. It supports pixel clocks in the range of 30-40 MHz.
> 
> This panel details can be found at:
> http://boundarydevices.com/product/7-800x480-display/
> 
> Signed-off-by: Gary Bisson 
> ---
>  .../bindings/panel/okaya,rs800480t_7x0gp.txt   |  7 +
>  drivers/gpu/drm/panel/panel-simple.c   | 33 
> ++
>  2 files changed, 40 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt 
> b/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
> new file mode 100644
> index 000..f7c729d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/okaya,rs800480t_7x0gp.txt
> @@ -0,0 +1,7 @@
> +OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel
> +
> +Required properties:
> +- compatible: should be "okaya,rs800480t_7x0gp"

Underscores are not typically used in compatible strings, so I've
changed this to "okaya,rs800480t-7x0gp".

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/2bac5b97/attachment.sig>

[PATCH] Update maintainers for DRM STI driver

[Benjamin Gaignard]

Add Vincent Abriou and myself has maintainers.

Signed-off-by: Benjamin Gaignard 
---
 MAINTAINERS | 9 +
 1 file changed, 9 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9c9dd5f..a6fbdf1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3592,6 +3592,15 @@ S:   Maintained
 F: drivers/gpu/drm/rockchip/
 F: Documentation/devicetree/bindings/video/rockchip*

+DRM DRIVERS FOR STI
+M: Benjamin Gaignard 
+M: Vincent Abriou 
+L: dri-devel at lists.freedesktop.org
+T: git http://git.linaro.org/people/benjamin.gaignard/kernel.git
+S: Maintained
+F: drivers/gpu/drm/sti
+F: Documentation/devicetree/bindings/gpu/st,stih4xx.txt
+
 DSBR100 USB FM RADIO DRIVER
 M: Alexey Klimov 
 L: linux-media at vger.kernel.org
-- 
1.9.1

[PATCH v3 1/2] of: add Okaya Electric America vendor prefix

[Thierry Reding]

On Wed, Jun 10, 2015 at 06:44:22PM +0200, Gary Bisson wrote:
> This patch adds vendor prefix for Okaya Electronic America, a provider
> of LCD modules and display technologies.
> 
> Signed-off-by: Gary Bisson 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/df4e57d5/attachment.sig>

[PATCH v14 3/6] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel

[Thierry Reding]

On Wed, Jul 29, 2015 at 04:30:02PM +0800, Jianwei Wang wrote:
> This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
> simple panel driver.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> Acked-by: Daniel Vetter 
> ---
>  .../bindings/panel/nec,nl4827hc19_05b.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt 
> b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> new file mode 100644
> index 000..20e9473
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> @@ -0,0 +1,7 @@
> +NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
> +
> +Required properties:
> +- compatible: should be "nec,nl4827hc19_05b"

Underscores are deprecated in compatible strings, so I've applied this
with "nec,nl4827hc19-05b".

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/db690ec4/attachment-0001.sig>

[PATCH v14 3/6] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel

[Thierry Reding]

On Wed, Jul 29, 2015 at 04:30:02PM +0800, Jianwei Wang wrote:
> This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
> simple panel driver.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 
> Acked-by: Daniel Vetter 
> ---
>  .../bindings/panel/nec,nl4827hc19_05b.txt  |  7 ++
>  drivers/gpu/drm/panel/panel-simple.c   | 26 
> ++
>  2 files changed, 33 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt

Applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/533f3a7b/attachment.sig>

[PATCH v2 1/2] drm/panel: simple: Add bus format for HannStar HSD070PWW1 LVDS panel

[Thierry Reding]

On Wed, Aug 12, 2015 at 12:32:12PM +0200, Lucas Stach wrote:
> From: Philipp Zabel 
> 
> The bus format both specifies the bpc and the way the individual bits get
> serialized into the 7 LVDS timeslots.
> 
> While the is only one standard mapping for 6 bpc and so the driver could
> infer the bit mapping from the bpc alone, there are more options for the
> 8 bpc case which makes specifiying the bus format mandatory.
> To keep things consistent across panels and to set a precedent for new
> panel additions add the proper bus format.
> 
> Signed-off-by: Philipp Zabel 
> Signed-off-by: Lucas Stach 
> ---
> v2: lst: added more elaborate commit message
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 1 +
>  1 file changed, 1 insertion(+)

Both patches applied, thanks.

Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/5963ab19/attachment.sig>

vmwgfx GL3 and other -next (4.3) pathches

[Thomas Hellstrom]

On 08/13/2015 01:47 PM, Emil Velikov wrote:
> Hi Thomas,
>
> On 12 August 2015 at 19:31, Thomas Hellstrom  wrote:
> ...
>> - GL3 - support for a new device functionality called "DX"
> Out of curiosity - what what does DX stand for ?

Hmm. I'm not 100% sure. Given the history of the device interface I
guess it started out as "DX10" but to avoid legal issues it was renamed
to DX.

/Thomas

>
> Thanks
> Emil
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Eric Anholt]

u/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
>> new file mode 100644
>> index 000..4aa07ca
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vc4/Makefile
>> @@ -0,0 +1,18 @@
>> +ccflags-y := -Iinclude/drm
>> +
>> +# Please keep these build lists sorted!
>> +
>> +# core driver code
>> +vc4-y := \
>> +vc4_bo.o \
>> +vc4_crtc.o \
>> +vc4_drv.o \
>> +vc4_kms.o \
>> +vc4_hdmi.o \
>> +vc4_hvs.o \
>> +vc4_plane.o \
>> +$()
>> +
>> +vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
>> +
>> +obj-$(CONFIG_DRM_VC4)  += vc4.o
>> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
>> new file mode 100644
>> index 000..fee8cac
>> --- /dev/null
>> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
>> @@ -0,0 +1,54 @@
>> +/*
>> + *  Copyright © 2015 Broadcom
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +/* DOC: VC4 GEM BO management support.
>> + *
>> + * The VC4 GPU architecture (both scanout and rendering) has direct
>> + * access to system memory with no MMU in between.  To support it, we
>> + * use the GEM CMA helper functions to allocate contiguous ranges of
>> + * physical memory for our BOs.
>> + */
>
> Since you're doing kerneldoc considered pulling it all into a new vc4
> section in the drm docbook template?

I hadn't found the docbook template.  Interesting.  I'll try to cook up
some general vc4 docs for that.  I think that could be a separate
commit, though?

>> +
>> +#include "vc4_drv.h"
>> +
>> +struct vc4_bo *vc4_bo_create(struct drm_device *dev, size_t size)
>> +{
>> +struct drm_gem_cma_object *cma_obj;
>> +
>> +cma_obj = drm_gem_cma_create(dev, size);
>> +if (IS_ERR(cma_obj))
>> +return NULL;
>> +else
>> +return to_vc4_bo(_obj->base);
>> +}
>> +
>> +int vc4_dumb_create(struct drm_file *file_priv,
>> +struct drm_device *dev,
>> +struct drm_mode_create_dumb *args)
>> +{
>> +int min_pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>> +struct vc4_bo *bo = NULL;
>> +int ret;
>> +
>> +if (args->pitch < min_pitch)
>> +args->pitch = min_pitch;
>> +
>> +if (args->size < args->pitch * args->height)
>> +args->size = args->pitch * args->height;
>> +
>> +mutex_lock(>struct_mutex);
>> +bo = vc4_bo_create(dev, roundup(args->size, PAGE_SIZE));
>> +mutex_unlock(>struct_mutex);
>
> I'm on a struct_mutex crusade (trying to get rid of it in core and allow
> drivers to live without it). On a quick look there doesn't seem to be
> anything that needs struct_mutex here, so please just remove it. If there
> is indeed something vc4-internal you want to protect, please use your own
> driver-internal mutex (e.g. for drm_mm or command submission or whatever).
>
> btw the last bit in the drm core for modern drivers that needs
> struct_mutex is mmap_offset gem object lookup. I plan to replace that with
> kref_get_unless_zero trickery, which would make the core and a lot of
> drivers struct_mutex free and so relegate it mostly to a legacy role (and
> can be forgotten).

Struct mutex is here because this code is from the V3D series, with the
in-kernel BO cache ripped out (it turns out that the CMA allocator is
slow, and you can't just userspace cache since we have to do allocations
within the kernel to the tune of a couple per draw and that's too much).

I'll pull the mutex calls out for now until the cache stuff is
submitted.

>> +static bool vc4_crtc_mode_fixup(struct drm_crtc *crtc,
>> +const struct drm_display_mode *mode,
>> +struct drm_display_mode *adjusted_mode)
>> +{
>> +return true;
>> +}
>
> mode_fixup on crtcs is optional since 840bfe953384a and I just merged a
> patch to make it optional for encoders too (when using atomic helpers
> which you do). You can remove them both.

Great!  It felt like there was a *lot* of boilerplate when I was first
writing this stuff, and things are way better than they used to be.

>> +static int vc4_drm_load(struct drm_device *dev, unsigned long flags)
>> +{
>> +struct vc4_dev *vc4;
>> +int ret;
>> +
>> +vc4 = devm_kzalloc(dev->dev, sizeof(*vc4), GFP_KERNEL);
>> +if (!vc4)
>> +return -ENOMEM;
>> +
>> +dev_set_drvdata(dev->dev, dev);
>> +vc4->dev = dev;
>> +dev->dev_private = vc4;
>> +
>> +drm_mode_config_init(dev);
>> +
>> +ret = component_bind_all(dev->dev, dev);
>> +if (ret)
>> +return ret;
>> +
>> +vc4_kms_load(dev);
>> +
>> +return 0;
>> +}
>
> ->load has backwards init ordering (we register public interfaces before
> calling it, yay) because backwards compat. Hence deprecated, please use
> drm_dev_alloc(); ... driver init including drm_dev_set_unique();
> drm_dev_register(); instead and drop ->load.

Will do.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/dca1b430/attachment.sig>

[PATCH v4] mmap on the dma-buf directly

[Thomas Hellstrom]

On 08/13/2015 01:29 AM, Tiago Vignatti wrote:
> Hi,
>
> The idea is to create a GEM bo in one process and pass the prime handle of the
> it to another process, which in turn uses the handle only to map and write.
> This could be useful for Chrome OS architecture, where the Web content
> ("unpriviledged process") maps and CPU-draws a buffer, which was previously
> allocated in the GPU process ("priviledged process").
>
> In v2, I've added a patch that Daniel kindly drafted to allow the
> unpriviledged process flush through a prime fd. In v3, I've fixed a few
> concerns and then added end_cpu_access to i915. In v4, I fixed Sumit Semwal's
> concerns about dma-duf documentation and the FIXME missing in that same patch,
> and also removed WARN in i915 dma-buf mmap (pointed by Chris). PTAL.
>
> Best Regards,
>
> Tiago
Tiago,

I take it, this is intended to be a generic interface used mostly for 2D
rendering.

In that case, using SYNC is crucial for performance of incoherent
architectures and I'd rather see it mandatory than an option. It could
perhaps be made mandatory preferrably using an error or a one-time
kernel warning. If nobody uses the SYNC interface, it is of little use.

Also I think the syncing needs to be extended to two dimensions. A long
time ago when this was brought up people argued why we should limit it
to two dimensions, but I believe two dimensions addresses most
performance-problematic use-cases. A default implementation of
twodimensional sync can easily be made using the one-dimensional API.

Thanks,
Thomas






>
>
> Daniel Thompson (1):
>   drm: prime: Honour O_RDWR during prime-handle-to-fd
>
> Daniel Vetter (1):
>   dma-buf: Add ioctls to allow userspace to flush
>
> Tiago Vignatti (2):
>   drm/i915: Implement end_cpu_access
>   drm/i915: Use CPU mapping for userspace dma-buf mmap()
>
>  Documentation/dma-buf-sharing.txt  | 12 
>  drivers/dma-buf/dma-buf.c  | 50 
> ++
>  drivers/gpu/drm/drm_prime.c| 10 ++-
>  drivers/gpu/drm/i915/i915_gem_dmabuf.c | 28 ++-
>  include/uapi/drm/drm.h |  1 +
>  include/uapi/linux/dma-buf.h   | 43 +
>  6 files changed, 136 insertions(+), 8 deletions(-)
>  create mode 100644 include/uapi/linux/dma-buf.h
>

[PATCH 01/13] drm/gma500: Sanity-check pipe index

[Patrik Jakobsson]

On Wed, Aug 12, 2015 at 5:00 PM, Thierry Reding
 wrote:
> From: Thierry Reding 
>
> If the DSI output isn't connected, then mdfld_dsi_encoder_get_pipe()
> will return -1. The mdfld_dsi_dp_mode_set() function doesn't properly
> check for this condition and causes the following compiler warnings:
>
>   CC  drivers/gpu/drm/gma500/mdfld_dsi_dpi.o
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c: In function 
> ‘mdfld_dsi_dpi_mode_set’:
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:828:35: warning: array 
> subscript is below array bounds [-Warray-bounds]
>   u32 pipeconf = dev_priv->pipeconf[pipe];
>^
> drivers/gpu/drm/gma500/mdfld_dsi_dpi.c:829:33: warning: array 
> subscript is below array bounds [-Warray-bounds]
>   u32 dspcntr = dev_priv->dspcntr[pipe];
>  ^
>
> Fix this by checking for a valid pipe before indexing the pipeconf and
> dspcntr arrays.
>
> Cc: Patrik Jakobsson 
> Signed-off-by: Thierry Reding 

Reviewed-by: Patrik Jakobsson 

vmwgfx GL3 and other -next (4.3) pathches

[Emil Velikov]

Hi Thomas,

On 12 August 2015 at 19:31, Thomas Hellstrom  wrote:
...
> - GL3 - support for a new device functionality called "DX"
Out of curiosity - what what does DX stand for ?

Thanks
Emil

[PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Emil Velikov]

On 13 August 2015 at 01:56, Eric Anholt  wrote:
> This is the start of a full VC4 driver.  Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is).  However, this is enough for fbcon and bringing up X using
> xf86-video-modesetting.
>
> Signed-off-by: Eric Anholt 
...
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/Makefile
> @@ -0,0 +1,18 @@
> +ccflags-y := -Iinclude/drm
> +
> +# Please keep these build lists sorted!
> +
> +# core driver code
> +vc4-y := \
> +   vc4_bo.o \
> +   vc4_crtc.o \
> +   vc4_drv.o \
> +   vc4_kms.o \
> +   vc4_hdmi.o \
> +   vc4_hvs.o \
> +   vc4_plane.o \
> +   $()
> +
In case anyone is curious - this is the first sentinel in the whole
kernel (some 2000+ Makefiles) :-)

-Emil

[PATCH] drm/i915: Only dither on 6bpc panels

[Jani Nikula]

On Thu, 13 Aug 2015, Mario Kleiner  wrote:
> Thanks for the quick fix! Comments below...
>
> On 08/12/2015 11:43 AM, Daniel Vetter wrote:
>> In
>>
>> commit d328c9d78d64ca11e744fe227096990430a88477
>> Author: Daniel Vetter 
>> Date:   Fri Apr 10 16:22:37 2015 +0200
>>
>>  drm/i915: Select starting pipe bpp irrespective or the primary plane
>>
>> we started to select the pipe bpp from sink capabilities and not from
>> the primary framebuffer - that one might change (and we don't want to
>> incur a modeset) and sprites might contain higher bpp content too.
>>
>> Problem is that now if you have a 10bpc screen and display 24bpp rgb
>> primary then we select dithering, and apparently that mangles the high
>> 8 bits even (even thought you'd expect dithering only to affect how
>> 12bpc gets mapped into 10bpc). And that mangling upsets certain users.
>>
>
> Probably doesn't matter, but your explanation of the former problem here 
> is slightly off. We also selected dithering on a 8 bpc screen displaying 
> a 24bpp rgb primary, because pipe_bpp is 24 for such a typical 8 bpc 
> sink, but since the commit mentioned above, base_bpp is always the 
> absolute maximum supported by the hardware, e.g., 36 bpp on my Ironlake 
> chip. Iow. the only way to not get dithering would have been to connect 
> a deep color 12 bpc display, so pipe_bpp == 36 == base_bpp.
>
>> Hence only enable dithering on 6bpc screens where we difinitely and
>> always want it.
>>
>
> Other than that, i tested the patch on both 8 bpc output with my 
> measurement equipment and on the internal laptop 6 bpc panel, and 
> everything is fine now - No banding on the 6 bpc panel, no banding or 
> equipment failure on the external 8 bpc output. Life is good again :)
>
> Reviewed-and-tested-by: Mario Kleiner 

Pushed to drm-intel-fixes, thanks for the patch and review and testing.

BR,
Jani.

>
> thanks,
> -mario
>
>> Cc: Mario Kleiner 
>> Reported-by: Mario Kleiner 
>> Signed-off-by: Daniel Vetter 
>> ---
>>   drivers/gpu/drm/i915/intel_display.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 9a2f229a1c3a..128462e0a0b5 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -12186,7 +12186,9 @@ encoder_retry:
>>  goto encoder_retry;
>>  }
>>
>> -pipe_config->dither = pipe_config->pipe_bpp != base_bpp;
>> +/* Dithering seems to not pass-through bits correctly when it should, so
>> + * only enable it on 6bpc panels. */
>> +pipe_config->dither = pipe_config->pipe_bpp == 6*3;
>>  DRM_DEBUG_KMS("plane bpp: %i, pipe bpp: %i, dithering: %i\n",
>>base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
>>
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/irq: More pipe/crtc consistency cleanups

[Thierry Reding]

From: Thierry Reding 

Commit cc1ef118fc09 ("drm/irq: Make pipe unsigned and name consistent")
missed a few occurrences of int pipe/crtc across various rebases. Clean
the remaining ones up now.

Signed-off-by: Thierry Reding 
---
 drivers/gpu/drm/drm_irq.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 20cf5776ce70..3960168503f1 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -74,11 +74,11 @@ module_param_named(vblankoffdelay, drm_vblank_offdelay, 
int, 0600);
 module_param_named(timestamp_precision_usec, drm_timestamp_precision, int, 
0600);
 module_param_named(timestamp_monotonic, drm_timestamp_monotonic, int, 0600);

-static void store_vblank(struct drm_device *dev, int crtc,
+static void store_vblank(struct drm_device *dev, unsigned int pipe,
 u32 vblank_count_inc,
 struct timeval *t_vblank)
 {
-   struct drm_vblank_crtc *vblank = >vblank[crtc];
+   struct drm_vblank_crtc *vblank = >vblank[pipe];
u32 tslot;

assert_spin_locked(>vblank_time_lock);
@@ -88,7 +88,7 @@ static void store_vblank(struct drm_device *dev, int crtc,
 * the latching of vblank->count below.
 */
tslot = vblank->count + vblank_count_inc;
-   vblanktimestamp(dev, crtc, tslot) = *t_vblank;
+   vblanktimestamp(dev, pipe, tslot) = *t_vblank;
}

/*
@@ -867,7 +867,7 @@ drm_get_last_vbltimestamp(struct drm_device *dev, unsigned 
int pipe,
  * Returns:
  * The software vblank counter.
  */
-u32 drm_vblank_count(struct drm_device *dev, int pipe)
+u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];

@@ -1292,7 +1292,7 @@ EXPORT_SYMBOL(drm_crtc_vblank_off);

 /**
  * drm_crtc_vblank_reset - reset vblank state to off on a CRTC
- * @drm_crtc: CRTC in question
+ * @crtc: CRTC in question
  *
  * Drivers can use this function to reset the vblank state to off at load time.
  * Drivers should use this together with the drm_crtc_vblank_off() and
@@ -1300,12 +1300,12 @@ EXPORT_SYMBOL(drm_crtc_vblank_off);
  * drm_crtc_vblank_off() is that this function doesn't save the vblank counter
  * and hence doesn't need to call any driver hooks.
  */
-void drm_crtc_vblank_reset(struct drm_crtc *drm_crtc)
+void drm_crtc_vblank_reset(struct drm_crtc *crtc)
 {
struct drm_device *dev = drm_crtc->dev;
unsigned long irqflags;
-   int crtc = drm_crtc_index(drm_crtc);
-   struct drm_vblank_crtc *vblank = >vblank[crtc];
+   unsigned int pipe = drm_crtc_index(crtc);
+   struct drm_vblank_crtc *vblank = >vblank[pipe];

spin_lock_irqsave(>vbl_lock, irqflags);
/*
-- 
2.4.5

[PATCH 5/5] amdgpu: make vamgr per device v2

[Jammy Zhou]

Each device can have its own vamgr, so make it per device now.
This can fix the failure with multiple GPUs used in one single
process.

v2: rebase

Signed-off-by: Jammy Zhou 
Reviewed-by: Christian König 
---
 amdgpu/amdgpu_device.c   | 13 +++--
 amdgpu/amdgpu_internal.h |  5 -
 amdgpu/amdgpu_vamgr.c| 24 +---
 3 files changed, 12 insertions(+), 30 deletions(-)

diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index 0ef1d31..d5f65e5 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -131,7 +131,8 @@ static int amdgpu_get_auth(int fd, int *auth)

 static void amdgpu_device_free_internal(amdgpu_device_handle dev)
 {
-   amdgpu_vamgr_reference(>vamgr, NULL);
+   amdgpu_vamgr_deinit(dev->vamgr);
+   free(dev->vamgr);
util_hash_table_destroy(dev->bo_flink_names);
util_hash_table_destroy(dev->bo_handles);
pthread_mutex_destroy(>bo_table_mutex);
@@ -252,7 +253,13 @@ int amdgpu_device_initialize(int fd,
if (r)
goto cleanup;

-   dev->vamgr = amdgpu_vamgr_get_global(dev);
+   dev->vamgr = calloc(1, sizeof(struct amdgpu_bo_va_mgr));
+   if (dev->vamgr == NULL)
+   goto cleanup;
+
+   amdgpu_vamgr_init(dev->vamgr, dev->dev_info.virtual_address_offset,
+ dev->dev_info.virtual_address_max,
+ dev->dev_info.virtual_address_alignment);

max = MIN2(dev->dev_info.virtual_address_max, 0x);
start = amdgpu_vamgr_find_va(dev->vamgr,
@@ -279,6 +286,8 @@ free_va:
r = -ENOMEM;
amdgpu_vamgr_free_va(dev->vamgr, start,
 max - dev->dev_info.virtual_address_offset);
+   amdgpu_vamgr_deinit(dev->vamgr);
+   free(dev->vamgr);

 cleanup:
if (dev->fd >= 0)
diff --git a/amdgpu/amdgpu_internal.h b/amdgpu/amdgpu_internal.h
index ca155be..cb06dbf 100644
--- a/amdgpu/amdgpu_internal.h
+++ b/amdgpu/amdgpu_internal.h
@@ -51,7 +51,6 @@ struct amdgpu_bo_va_hole {
 };

 struct amdgpu_bo_va_mgr {
-   atomic_t refcount;
/* the start virtual address */
uint64_t va_offset;
uint64_t va_max;
@@ -124,10 +123,6 @@ struct amdgpu_context {

 drm_private void amdgpu_bo_free_internal(amdgpu_bo_handle bo);

-drm_private struct amdgpu_bo_va_mgr* amdgpu_vamgr_get_global(struct 
amdgpu_device *dev);
-
-drm_private void amdgpu_vamgr_reference(struct amdgpu_bo_va_mgr **dst, struct 
amdgpu_bo_va_mgr *src);
-
 drm_private void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t 
start,
   uint64_t max, uint64_t alignment);

diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index 698826d..659e6c8 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -33,8 +33,6 @@
 #include "amdgpu_internal.h"
 #include "util_math.h"

-static struct amdgpu_bo_va_mgr vamgr = {{0}};
-
 int amdgpu_va_range_query(amdgpu_device_handle dev,
  enum amdgpu_gpu_va_range type, uint64_t *start, 
uint64_t *end)
 {
@@ -67,26 +65,6 @@ drm_private void amdgpu_vamgr_deinit(struct amdgpu_bo_va_mgr 
*mgr)
pthread_mutex_destroy(>bo_va_mutex);
 }

-drm_private struct amdgpu_bo_va_mgr * amdgpu_vamgr_get_global(struct 
amdgpu_device *dev)
-{
-   int ref;
-   ref = atomic_inc_return();
-
-   if (ref == 1)
-   amdgpu_vamgr_init(, dev->dev_info.virtual_address_offset,
- dev->dev_info.virtual_address_max,
- dev->dev_info.virtual_address_alignment);
-   return 
-}
-
-drm_private void amdgpu_vamgr_reference(struct amdgpu_bo_va_mgr **dst,
-   struct amdgpu_bo_va_mgr *src)
-{
-   if (update_references(&(*dst)->refcount, NULL))
-   amdgpu_vamgr_deinit(*dst);
-   *dst = src;
-}
-
 drm_private uint64_t amdgpu_vamgr_find_va(struct amdgpu_bo_va_mgr *mgr, 
uint64_t size,
uint64_t alignment, uint64_t base_required)
 {
@@ -102,7 +80,7 @@ drm_private uint64_t amdgpu_vamgr_find_va(struct 
amdgpu_bo_va_mgr *mgr, uint64_t
pthread_mutex_lock(>bo_va_mutex);
/* TODO: using more appropriate way to track the holes */
/* first look for a hole */
-   LIST_FOR_EACH_ENTRY_SAFE(hole, n, _holes, list) {
+   LIST_FOR_EACH_ENTRY_SAFE(hole, n, >va_holes, list) {
if (base_required) {
if(hole->offset > base_required ||
(hole->offset + hole->size) < (base_required + 
size))
-- 
1.9.1

[PATCH 4/5] amdgpu: fix one warning from previous commit

[Jammy Zhou]

The local variable 'vamgr' is unused in amdgpu_va_range_free.

Signed-off-by: Jammy Zhou 
Reviewed-by: Alex Deucher 
---
 amdgpu/amdgpu_vamgr.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index 91aad4e..698826d 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -295,8 +295,6 @@ int amdgpu_va_range_alloc(amdgpu_device_handle dev,

 int amdgpu_va_range_free(amdgpu_va_handle va_range_handle)
 {
-   struct amdgpu_bo_va_mgr *vamgr;
-
if(!va_range_handle || !va_range_handle->address)
return 0;

-- 
1.9.1

[PATCH 3/5] amdgpu: add flag to support 32bit VA address v3

[Jammy Zhou]

The AMDGPU_VA_RANGE_32_BIT flag is added to request VA range in the
32bit address space for amdgpu_va_range_alloc.

The 32bit address space is reserved at initialization time, and managed
with a separate VAMGR as part of the global VAMGR. And if no enough VA
space available in range above 4GB, this reserved range can be used as
fallback.

v2: add comment for AMDGPU_VA_RANGE_32_BIT, and add vamgr to va_range
v3: rebase to Emil's drm_private series

Signed-off-by: Jammy Zhou 
Reviewed-by: Christian König 
---
 amdgpu/amdgpu.h  |  5 +
 amdgpu/amdgpu_device.c   | 20 
 amdgpu/amdgpu_internal.h |  9 +
 amdgpu/amdgpu_vamgr.c| 34 +++---
 4 files changed, 61 insertions(+), 7 deletions(-)

diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index a90c1ac..1e633e3 100644
--- a/amdgpu/amdgpu.h
+++ b/amdgpu/amdgpu.h
@@ -1075,6 +1075,11 @@ int amdgpu_read_mm_registers(amdgpu_device_handle dev, 
unsigned dword_offset,
 uint32_t *values);

 /**
+ * Flag to request VA address range in the 32bit address space
+*/
+#define AMDGPU_VA_RANGE_32_BIT 0x1
+
+/**
  * Allocate virtual address range
  *
  * \param dev - [in] Device handle. See #amdgpu_device_initialize()
diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
index b977847..0ef1d31 100644
--- a/amdgpu/amdgpu_device.c
+++ b/amdgpu/amdgpu_device.c
@@ -44,6 +44,7 @@
 #include "amdgpu_drm.h"
 #include "amdgpu_internal.h"
 #include "util_hash_table.h"
+#include "util_math.h"

 #define PTR_TO_UINT(x) ((unsigned)((intptr_t)(x)))
 #define UINT_TO_PTR(x) ((void *)((intptr_t)(x)))
@@ -174,6 +175,7 @@ int amdgpu_device_initialize(int fd,
int flag_auth = 0;
int flag_authexist=0;
uint32_t accel_working = 0;
+   uint64_t start, max;

*device_handle = NULL;

@@ -252,6 +254,19 @@ int amdgpu_device_initialize(int fd,

dev->vamgr = amdgpu_vamgr_get_global(dev);

+   max = MIN2(dev->dev_info.virtual_address_max, 0x);
+   start = amdgpu_vamgr_find_va(dev->vamgr,
+max - dev->dev_info.virtual_address_offset,
+dev->dev_info.virtual_address_alignment, 
0);
+   if (start > 0x)
+   goto free_va; /* shouldn't get here */
+
+   dev->vamgr_32 =  calloc(1, sizeof(struct amdgpu_bo_va_mgr));
+   if (dev->vamgr_32 == NULL)
+   goto free_va;
+   amdgpu_vamgr_init(dev->vamgr_32, start, max,
+ dev->dev_info.virtual_address_alignment);
+
*major_version = dev->major_version;
*minor_version = dev->minor_version;
*device_handle = dev;
@@ -260,6 +275,11 @@ int amdgpu_device_initialize(int fd,

return 0;

+free_va:
+   r = -ENOMEM;
+   amdgpu_vamgr_free_va(dev->vamgr, start,
+max - dev->dev_info.virtual_address_offset);
+
 cleanup:
if (dev->fd >= 0)
close(dev->fd);
diff --git a/amdgpu/amdgpu_internal.h b/amdgpu/amdgpu_internal.h
index 92eb5ec..ca155be 100644
--- a/amdgpu/amdgpu_internal.h
+++ b/amdgpu/amdgpu_internal.h
@@ -65,6 +65,7 @@ struct amdgpu_va {
uint64_t address;
uint64_t size;
enum amdgpu_gpu_va_range range;
+   struct amdgpu_bo_va_mgr *vamgr;
 };

 struct amdgpu_device {
@@ -82,7 +83,10 @@ struct amdgpu_device {
pthread_mutex_t bo_table_mutex;
struct drm_amdgpu_info_device dev_info;
struct amdgpu_gpu_info info;
+   /** The global VA manager for the whole virtual address space */
struct amdgpu_bo_va_mgr *vamgr;
+   /** The VA manager for the 32bit address space */
+   struct amdgpu_bo_va_mgr *vamgr_32;
 };

 struct amdgpu_bo {
@@ -124,6 +128,11 @@ drm_private struct amdgpu_bo_va_mgr* 
amdgpu_vamgr_get_global(struct amdgpu_devic

 drm_private void amdgpu_vamgr_reference(struct amdgpu_bo_va_mgr **dst, struct 
amdgpu_bo_va_mgr *src);

+drm_private void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t 
start,
+  uint64_t max, uint64_t alignment);
+
+drm_private void amdgpu_vamgr_deinit(struct amdgpu_bo_va_mgr *mgr);
+
 drm_private uint64_t amdgpu_vamgr_find_va(struct amdgpu_bo_va_mgr *mgr, 
uint64_t size,
uint64_t alignment, uint64_t base_required);

diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index 71fd2b1..91aad4e 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -46,7 +46,7 @@ int amdgpu_va_range_query(amdgpu_device_handle dev,
return -EINVAL;
 }

-static void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t start,
+drm_private void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t 
start,
  uint64_t max, uint64_t alignment)
 {
mgr->va_offset = start;
@@ -57,7 +57,7 @@ static void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, 
uint64_t start,

[PATCH 2/5] amdgpu: improve amdgpu_vamgr_init

[Jammy Zhou]

Make it a generic function independent of the device info.

Signed-off-by: Jammy Zhou 
Reviewed-by: Christian König 
---
 amdgpu/amdgpu_vamgr.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/amdgpu/amdgpu_vamgr.c b/amdgpu/amdgpu_vamgr.c
index cc4a1c4..71fd2b1 100644
--- a/amdgpu/amdgpu_vamgr.c
+++ b/amdgpu/amdgpu_vamgr.c
@@ -46,11 +46,12 @@ int amdgpu_va_range_query(amdgpu_device_handle dev,
return -EINVAL;
 }

-static void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, struct 
amdgpu_device *dev)
+static void amdgpu_vamgr_init(struct amdgpu_bo_va_mgr *mgr, uint64_t start,
+ uint64_t max, uint64_t alignment)
 {
-   mgr->va_offset = dev->dev_info.virtual_address_offset;
-   mgr->va_max = dev->dev_info.virtual_address_max;
-   mgr->va_alignment = dev->dev_info.virtual_address_alignment;
+   mgr->va_offset = start;
+   mgr->va_max = max;
+   mgr->va_alignment = alignment;

list_inithead(>va_holes);
pthread_mutex_init(>bo_va_mutex, NULL);
@@ -72,7 +73,9 @@ drm_private struct amdgpu_bo_va_mgr * 
amdgpu_vamgr_get_global(struct amdgpu_devi
ref = atomic_inc_return();

if (ref == 1)
-   amdgpu_vamgr_init(, dev);
+   amdgpu_vamgr_init(, dev->dev_info.virtual_address_offset,
+ dev->dev_info.virtual_address_max,
+ dev->dev_info.virtual_address_alignment);
return 
 }

-- 
1.9.1

[PATCH 1/5] drm: add interface to get drm devices on the system v2

[Jammy Zhou]

From: Emil Velikov 

For mutiple GPU support, the devices on the system should be enumerated
to get necessary information about each device, and the drmGetDevices
interface is added for this. Currently only PCI devices are supported for
the enumeration.

Typical usage:
int count;
drmDevicePtr *foo;
count = drmGetDevices(NULL, 0);
foo = calloc(count, sizeof(drmDevicePtr));
count = drmGetDevices(foo, count);
/* find proper device, open correct device node, etc */
drmFreeDevices(foo, count);
free(foo);

v2: change according to feedback from Emil

Signed-off-by: Jammy Zhou 
---
 xf86drm.c | 351 ++
 xf86drm.h |  34 ++
 2 files changed, 385 insertions(+)

diff --git a/xf86drm.c b/xf86drm.c
index 5e02969..237663b 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -55,6 +55,7 @@
 #ifdef HAVE_SYS_MKDEV_H
 # include  /* defines major(), minor(), and makedev() on Solaris 
*/
 #endif
+#include 

 /* Not all systems have MAP_FAILED defined */
 #ifndef MAP_FAILED
@@ -2829,3 +2830,353 @@ char *drmGetRenderDeviceNameFromFd(int fd)
 {
return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
 }
+
+#ifdef __linux__
+static int drmParseSubsystemType(const char *str)
+{
+char link[PATH_MAX + 1] = "";
+char *name;
+
+if (readlink(str, link, PATH_MAX) < 0)
+return -EINVAL;
+
+name = strrchr(link, '/');
+if (!name)
+return -EINVAL;
+
+name++;
+
+if (strncmp(name, "pci", 3) == 0)
+return DRM_BUS_PCI;
+
+return -EINVAL;
+}
+
+static int drmParsePciBusInfo(const char *str, drmPciBusInfoPtr info)
+{
+int domain, bus, dev, func;
+char *value;
+
+if (str == NULL)
+return -EINVAL;
+
+value = strstr(str, "PCI_SLOT_NAME=");
+if (value == NULL)
+return -EINVAL;
+
+value += strlen("PCI_SLOT_NAME=");
+
+if (sscanf(value, "%04x:%02x:%02x.%1u",
+   , , , ) != 4)
+return -EINVAL;
+
+info->domain = domain;
+info->bus = bus;
+info->dev = dev;
+info->func = func;
+
+return 0;
+}
+
+static int drmSameDevice(drmDevicePtr a, drmDevicePtr b)
+{
+if (a->bustype != b->bustype)
+return 0;
+
+switch (a->bustype) {
+case DRM_BUS_PCI:
+if (memcmp(a->businfo.pci, b->businfo.pci, sizeof(drmPciBusInfo)) == 0)
+return 1;
+default:
+break;
+}
+
+return 0;
+}
+
+static int drmGetNodeType(const char *name)
+{
+if (strncmp(name, DRM_PRIMARY_MINOR_NAME,
+sizeof(DRM_PRIMARY_MINOR_NAME) - 1) == 0)
+return DRM_NODE_PRIMARY;
+
+if (strncmp(name, DRM_CONTROL_MINOR_NAME,
+sizeof(DRM_CONTROL_MINOR_NAME ) - 1) == 0)
+return DRM_NODE_CONTROL;
+
+if (strncmp(name, DRM_RENDER_MINOR_NAME,
+sizeof(DRM_RENDER_MINOR_NAME) - 1) == 0)
+return DRM_NODE_RENDER;
+
+return -EINVAL;
+}
+
+static int drmParsePciDeviceInfo(const char *config,
+ drmPciDeviceInfoPtr device)
+{
+if (config == NULL)
+return -EINVAL;
+
+device->vendor_id = config[0] | (config[1] << 8);
+device->device_id = config[2] | (config[3] << 8);
+device->revision_id = config[8];
+device->subvendor_id = config[44] | (config[45] << 8);
+device->subdevice_id = config[46] | (config[47] << 8);
+
+return 0;
+}
+
+static void drmFreeDevice(drmDevicePtr device)
+{
+int i;
+
+if (device == NULL)
+return;
+
+if (device->nodes != NULL)
+for (i = 0; i < DRM_NODE_MAX; i++)
+free(device->nodes[i]);
+
+free(device->nodes);
+free(device->businfo.pci);
+free(device->deviceinfo.pci);
+}
+
+void drmFreeDevices(drmDevicePtr devices[], int count)
+{
+int i;
+
+if (devices == NULL)
+return;
+
+for (i = 0; i < count; i++) {
+drmFreeDevice(devices[i]);
+free(devices[i]);
+devices[i] = NULL;
+}
+}
+
+/**
+ * Get drm devices on the system
+ *
+ * \param devices the array of devices with drmDevicePtr elements
+ *can be NULL to get the device number first
+ * \param max_devices the maximum number of devices for the array
+ *
+ * \return on error - negative error code,
+ * if devices is NULL - total number of devices available on the 
system,
+ * alternatively the number of devices stored in devices[], which is
+ * capped by the max_devices.
+ */
+int drmGetDevices(drmDevicePtr devices[], int max_devices)
+{
+drmDevicePtr devs = NULL;
+drmPciBusInfoPtr pcibus = NULL;
+drmPciDeviceInfoPtr pcidevice = NULL;
+DIR *sysdir = NULL;
+struct dirent *dent = NULL;
+struct stat sbuf = {0};
+char node[PATH_MAX + 1] = "";
+char path[PATH_MAX + 1] = "";
+char data[128] = "";
+char config[64] = "";
+int node_type, subsystem_type;
+int maj, min;
+int fd;
+int ret, i = 0, j, node_count, device_count = 0;
+int max_count = 16;
+int *duplicated = NULL;
+
+

[PATCH 0/5] some drm and amdgpu patches

[Jammy Zhou]

This series is a set of patches in my side pending for merge. And I rebased it
with the drm_private series from Emil.

Emil Velikov (1):
  drm: add interface to get drm devices on the system v2

Jammy Zhou (4):
  amdgpu: improve amdgpu_vamgr_init
  amdgpu: add flag to support 32bit VA address v3
  amdgpu: fix one warning from previous commit
  amdgpu: make vamgr per device v2

 amdgpu/amdgpu.h  |   5 +
 amdgpu/amdgpu_device.c   |  33 -
 amdgpu/amdgpu_internal.h |  10 +-
 amdgpu/amdgpu_vamgr.c|  61 
 xf86drm.c| 351 +++
 xf86drm.h|  34 +
 6 files changed, 458 insertions(+), 36 deletions(-)

-- 
1.9.1

[PATCH 3/7] prime_mmap: Add basic tests to write in a bo using CPU

[Tiago Vignatti]

On 08/13/2015 04:01 AM, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 08:29:16PM -0300, Tiago Vignatti wrote:
>> This patch adds test_correct_cpu_write, which maps the texture buffer 
>> through a
>> prime fd and then writes directly to it using the CPU. It stresses the driver
>> to guarantee cache synchronization among the different domains.
>>
>> This test also adds test_forked_cpu_write, which creates the GEM bo in one
>> process and pass the prime handle of the it to another process, which in turn
>> uses the handle only to map and write. Grossly speaking this test simulates
>> Chrome OS  architecture, where the Web content ("unpriviledged process") maps
>> and CPU-draws a buffer, which was previously allocated in the GPU process
>> ("priviledged process").
>>
>> This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
>> O_RDWR during prime-handle-to-fd").
>>
>> Signed-off-by: Tiago Vignatti 
>
> Squash with previous patch?

why? if the whole point is to decrease the amount of patches, then I 
prefer to squash 2/7 with the 1/7 (although they're from different 
authors and would be nice to keep separately the changes from each). 
This patch here introduces this writing to mmap'ed dma-buf fd, a concept 
that is still in debate, requiring a kernel counter-part so that's why I 
preferred to keep it away.


>> ---
>>   lib/ioctl_wrappers.c |  5 +++-
>>   tests/prime_mmap.c   | 65 
>> 
>>   2 files changed, 69 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
>> index 53bd635..941fa66 100644
>> --- a/lib/ioctl_wrappers.c
>> +++ b/lib/ioctl_wrappers.c
>> @@ -1125,6 +1125,9 @@ void gem_require_ring(int fd, int ring_id)
>>
>>   /* prime */
>>
>> +#ifndef DRM_RDWR
>> +#define DRM_RDWR O_RDWR
>> +#endif
>>   /**
>>* prime_handle_to_fd:
>>* @fd: open i915 drm file descriptor
>> @@ -1142,7 +1145,7 @@ int prime_handle_to_fd(int fd, uint32_t handle)
>>
>>  memset(, 0, sizeof(args));
>>  args.handle = handle;
>> -args.flags = DRM_CLOEXEC;
>> +args.flags = DRM_CLOEXEC | DRM_RDWR;
>
> This needs to be optional otherwise all the existing prime tests start
> falling over on older kernels. Probably need a
> prime_handle_to_fd_with_mmap, which doesn an igt_skip if it fails.

true. Thank you.


> -Daniel
>
>>  args.fd = -1;
>>
>>  do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, );
>> diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
>> index dc59e8f..ad91371 100644
>> --- a/tests/prime_mmap.c
>> +++ b/tests/prime_mmap.c
>> @@ -22,6 +22,7 @@
>>*
>>* Authors:
>>*Rob Bradford 
>> + *Tiago Vignatti 
>>*
>>*/
>>
>> @@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
>>   }
>>
>>   static void
>> +fill_bo_cpu(char *ptr)
>> +{
>> +memcpy(ptr, pattern, sizeof(pattern));
>> +}
>> +
>> +static void
>>   test_correct(void)
>>   {
>>  int dma_buf_fd;
>> @@ -180,6 +187,62 @@ test_forked(void)
>>  gem_close(fd, handle);
>>   }
>>
>> +/* test CPU write. This has a rather big implication for the driver which 
>> must
>> + * guarantee cache synchronization when writing the bo using CPU. */
>> +static void
>> +test_correct_cpu_write(void)
>> +{
>> +int dma_buf_fd;
>> +char *ptr;
>> +uint32_t handle;
>> +
>> +handle = gem_create(fd, BO_SIZE);
>> +
>> +dma_buf_fd = prime_handle_to_fd(fd, handle);
>> +igt_assert(errno == 0);
>> +
>> +/* Check correctness of map using write protection (PROT_WRITE) */
>> +ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, 
>> dma_buf_fd, 0);
>> +igt_assert(ptr != MAP_FAILED);
>> +
>> +/* Fill bo using CPU */
>> +fill_bo_cpu(ptr);
>> +
>> +/* Check pattern correctness */
>> +igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
>> +
>> +munmap(ptr, BO_SIZE);
>> +close(dma_buf_fd);
>> +gem_close(fd, handle);
>> +}
>> +
>> +/* map from another process and then write using CPU */
>> +static void
>> +test_forked_cpu_write(void)
>> +{
>> +int dma_buf_fd;
>> +char *ptr;
>> +uint32_t handle;
>> +
>> +handle = gem_create(fd, BO_SIZE);
>> +
>> +dma_buf_fd = prime_handle_to_fd(fd, handle);
>> +igt_assert(errno == 0);
>> +
>> +igt_fork(childno, 1) {
>> +ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED, 
>> dma_buf_fd, 0);
>> +igt_assert(ptr != MAP_FAILED);
>> +fill_bo_cpu(ptr);
>> +
>> +igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
>> +munmap(ptr, BO_SIZE);
>> +close(dma_buf_fd);
>> +}
>> +close(dma_buf_fd);
>> +igt_waitchildren();
>> +gem_close(fd, handle);
>> +}
>> +
>>   static void
>>   test_refcounting(void)
>>   {
>> @@ -346,6 +409,8 @@ igt_main
>>  { "test_map_unmap", test_map_unmap },
>>  { "test_reprime", test_reprime },
>>  { "test_forked", test_forked },
>> +{ 

[PATCH 08/13] drm/irq: Check for valid VBLANK before dereference

[Thierry Reding]

On Wed, Aug 12, 2015 at 05:40:11PM +0200, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 05:00:30PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > When accessing the array of per-CRTC VBLANK structures we must always
> > check that the index into the array is valid before dereferencing to
> > avoid crashing.
> > 
> > Signed-off-by: Thierry Reding 
> 
> This misses vblank_reset (I guess that function is newer than your
> patches). Can you please do a follow-up? I merged this one meanwhile.

We only have drm_crtc_vblank_reset(), in which case there's no need to
check the index because it's obtained directly from a struct drm_crtc *
and hence will be valid.

Thierry

> > ---
> >  drivers/gpu/drm/drm_irq.c | 10 --
> >  1 file changed, 8 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index 5c666c780fe9..a957b9618e85 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -1110,10 +1110,10 @@ void drm_vblank_put(struct drm_device *dev, int 
> > crtc)
> >  {
> > struct drm_vblank_crtc *vblank = >vblank[crtc];
> >  
> > -   if (WARN_ON(atomic_read(>refcount) == 0))
> > +   if (WARN_ON(crtc >= dev->num_crtcs))
> > return;
> >  
> > -   if (WARN_ON(crtc >= dev->num_crtcs))
> > +   if (WARN_ON(atomic_read(>refcount) == 0))
> > return;
> >  
> > /* Last user schedules interrupt disable */
> > @@ -1158,6 +1158,9 @@ void drm_wait_one_vblank(struct drm_device *dev, int 
> > crtc)
> > int ret;
> > u32 last;
> >  
> > +   if (WARN_ON(crtc >= dev->num_crtcs))
> > +   return;
> > +
> > ret = drm_vblank_get(dev, crtc);
> > if (WARN(ret, "vblank not available on crtc %i, ret=%i\n", crtc, ret))
> > return;
> > @@ -1428,6 +1431,9 @@ void drm_vblank_post_modeset(struct drm_device *dev, 
> > int crtc)
> > if (!dev->num_crtcs)
> > return;
> >  
> > +   if (WARN_ON(crtc >= dev->num_crtcs))
> > +   return;
> > +
> > if (vblank->inmodeset) {
> > spin_lock_irqsave(>vbl_lock, irqflags);
> > dev->vblank_disable_allowed = true;
> > -- 
> > 2.4.5
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/3bdec4f5/attachment.sig>

[PATCH 10/13] drm/irq: Add drm_crtc_vblank_count_and_time()

[Thierry Reding]

On Wed, Aug 12, 2015 at 05:35:08PM +0200, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 05:00:32PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > This function is the KMS native variant of drm_vblank_count_and_time().
> > It takes a struct drm_crtc * instead of a struct drm_device * and an
> > index of the CRTC.
> > 
> > Eventually the goal is to access vblank data through the CRTC only so
> > that the per-CRTC data can be moved to struct drm_crtc.
> > 
> > Signed-off-by: Thierry Reding 
> 
> We seem to not use this anywhere outside for drm_irq.c, so maybe just drop
> the kerneldoc and EXPORT_SYMBOL? The actual comment starting with "Fecthes
> the "cooked" vblank ..." should imo be kept.

There don't seem to be any users of this, so I guess we can ignore this
for now.

Thierry

> > ---
> >  drivers/gpu/drm/drm_irq.c | 23 +++
> >  include/drm/drmP.h|  2 ++
> >  2 files changed, 25 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> > index f42459b2862d..904914d8f1f1 100644
> > --- a/drivers/gpu/drm/drm_irq.c
> > +++ b/drivers/gpu/drm/drm_irq.c
> > @@ -913,6 +913,8 @@ EXPORT_SYMBOL(drm_crtc_vblank_count);
> >   * vblank events since the system was booted, including lost events due to
> >   * modesetting activity. Returns corresponding system timestamp of the time
> >   * of the vblank interval that corresponds to the current vblank counter 
> > value.
> > + *
> > + * This is the legacy version of drm_crtc_vblank_count_and_time().
> >   */
> >  u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned int pipe,
> >   struct timeval *vblanktime)
> > @@ -939,6 +941,27 @@ u32 drm_vblank_count_and_time(struct drm_device *dev, 
> > unsigned int pipe,
> >  }
> >  EXPORT_SYMBOL(drm_vblank_count_and_time);
> >  
> > +/**
> > + * drm_crtc_vblank_count_and_time - retrieve "cooked" vblank counter value
> > + * and the system timestamp corresponding to that vblank counter value
> > + * @crtc: which counter to retrieve
> > + * @vblanktime: Pointer to struct timeval to receive the vblank timestamp.
> > + *
> > + * Fetches the "cooked" vblank count value that represents the number of
> > + * vblank events since the system was booted, including lost events due to
> > + * modesetting activity. Returns corresponding system timestamp of the time
> > + * of the vblank interval that corresponds to the current vblank counter 
> > value.
> > + *
> > + * This is the native KMS version of drm_vblank_count_and_time().
> > + */
> > +u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> > +  struct timeval *vblanktime)
> > +{
> > +   return drm_vblank_count_and_time(crtc->dev, drm_crtc_index(crtc),
> > +vblanktime);
> > +}
> > +EXPORT_SYMBOL(drm_crtc_vblank_count_and_time);
> > +
> >  static void send_vblank_event(struct drm_device *dev,
> > struct drm_pending_vblank_event *e,
> > unsigned long seq, struct timeval *now)
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index 020afa343dff..7cd480614035 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -927,6 +927,8 @@ extern u32 drm_vblank_count(struct drm_device *dev, int 
> > pipe);
> >  extern u32 drm_crtc_vblank_count(struct drm_crtc *crtc);
> >  extern u32 drm_vblank_count_and_time(struct drm_device *dev, unsigned int 
> > pipe,
> >  struct timeval *vblanktime);
> > +extern u32 drm_crtc_vblank_count_and_time(struct drm_crtc *crtc,
> > + struct timeval *vblanktime);
> >  extern void drm_send_vblank_event(struct drm_device *dev, unsigned int 
> > pipe,
> >   struct drm_pending_vblank_event *e);
> >  extern void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
> > -- 
> > 2.4.5
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/70d7af20/attachment-0001.sig>

[PATCH v4] mmap on the dma-buf directly

[Tiago Vignatti]

On 08/13/2015 08:09 AM, Thomas Hellstrom wrote:
> Tiago,
>
> I take it, this is intended to be a generic interface used mostly for 2D
> rendering.

yup. "generic" is an important point that I've actually forgot to 
mention in the description, which is probably the whole motivation for 
bringing this up.

We want avoid link any vendor-specific library to the unpriviledged 
process for security reasons, so it's a requirement to it not have 
access to driver-specific ioctls when mapping the buffers. The use-case 
for it is texturing from CPU rendered buffer, like you said, with the 
intention of passing these buffers among processes without performing 
any copy in the user-space ("zero-copy").

> In that case, using SYNC is crucial for performance of incoherent
> architectures and I'd rather see it mandatory than an option. It could
> perhaps be made mandatory preferrably using an error or a one-time
> kernel warning. If nobody uses the SYNC interface, it is of little use.

hmm I'm not sure it is little use. Our hardware (the "LLC" capable) has 
this very specific case where the cache gets dirty wrt the GPU, which is 
when the same buffer is shared with the scanout device. This is not 
something will happen in Chrome OS for example, so we wouldn't need the 
SYNC markers there.

In any case I think that making it mandatory works for us, but I'll have 
to check with Daniel/Chris whether there are performance penalties when 
accessing it and so on.

> Also I think the syncing needs to be extended to two dimensions. A long
> time ago when this was brought up people argued why we should limit it
> to two dimensions, but I believe two dimensions addresses most
> performance-problematic use-cases. A default implementation of
> twodimensional sync can easily be made using the one-dimensional API.

two dimension sync? You're saying that there could be a GPU access API 
in dma-buf as well? I don't get it, what's the use-case? I'm sure I 
missed the discussions because I wasn't particularly interested in this 
whole thingy before :)

Thanks for reviewing, Thomas.

Tiago

[PATCH 07/13] drm/sti: Store correct CRTC index in events

[Thierry Reding]

On Wed, Aug 12, 2015 at 05:26:01PM +0200, Benjamin Gaignard wrote:
> The fix look good however it enter in conflict with the large rework
> we have done to support atomic.
> The pull request for this has been send.
> Would it be ok for you if we include your patch in the your next
> series of patches ?

Sure, I can keep carrying this and rebase on your changes when they've
landed.

Thierry

> 2015-08-12 17:00 GMT+02:00 Thierry Reding :
> > From: Thierry Reding 
> >
> > A negative pipe causes a special case to be triggered for drivers that
> > don't have proper VBLANK support. STi does support VBLANKs, so there is
> > no need for the fallback code.
> >
> > Cc: Benjamin Gaignard 
> > Signed-off-by: Thierry Reding 
> > ---
> >  drivers/gpu/drm/sti/sti_drm_crtc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.c 
> > b/drivers/gpu/drm/sti/sti_drm_crtc.c
> > index 26e63bf14efe..67279cc74348 100644
> > --- a/drivers/gpu/drm/sti/sti_drm_crtc.c
> > +++ b/drivers/gpu/drm/sti/sti_drm_crtc.c
> > @@ -234,7 +234,7 @@ int sti_drm_crtc_vblank_cb(struct notifier_block *nb,
> >
> > spin_lock_irqsave(_dev->event_lock, flags);
> > if (compo->mixer[*crtc]->pending_event) {
> > -   drm_send_vblank_event(drm_dev, -1,
> > +   drm_send_vblank_event(drm_dev, *crtc,
> > compo->mixer[*crtc]->pending_event);
> > drm_vblank_put(drm_dev, *crtc);
> > compo->mixer[*crtc]->pending_event = NULL;
> > --
> > 2.4.5
> >
> 
> 
> 
> -- 
> Benjamin Gaignard
> 
> Graphic Working Group
> 
> Linaro.org │ Open source software for ARM SoCs
> 
> Follow Linaro: Facebook | Twitter | Blog
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/d8ee7324/attachment.sig>

[PATCH 04/13] drm/imx: Make pipe number unsigned

[Thierry Reding]

On Wed, Aug 12, 2015 at 05:24:34PM +0200, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 05:00:26PM +0200, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > There's no reason whatsoever why this should ever be negative.
> > 
> > Cc: Philipp Zabel 
> > Acked-by: Philipp Zabel 
> > Signed-off-by: Thierry Reding 
> 
> Just kill it and replace with drm_crtc_index. Using that for vblank events
> instead of some driver-specific thing is kinda abi.

Would you mind if I did that as a follow-up? That way the changes per
patch stay more concise.

Thierry

> > ---
> >  drivers/gpu/drm/imx/imx-drm-core.c | 4 ++--
> >  drivers/gpu/drm/imx/imx-drm.h  | 2 +-
> >  2 files changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> > b/drivers/gpu/drm/imx/imx-drm-core.c
> > index 74f505b0dd02..c50cd97b1c4e 100644
> > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > @@ -45,14 +45,14 @@ struct imx_drm_device {
> >  
> >  struct imx_drm_crtc {
> > struct drm_crtc *crtc;
> > -   int pipe;
> > +   unsigned intpipe;
> > struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
> >  };
> >  
> >  static int legacyfb_depth = 16;
> >  module_param(legacyfb_depth, int, 0444);
> >  
> > -int imx_drm_crtc_id(struct imx_drm_crtc *crtc)
> > +unsigned int imx_drm_crtc_id(struct imx_drm_crtc *crtc)
> >  {
> > return crtc->pipe;
> >  }
> > diff --git a/drivers/gpu/drm/imx/imx-drm.h b/drivers/gpu/drm/imx/imx-drm.h
> > index 28e776d8d9d2..eebf0e2fefd0 100644
> > --- a/drivers/gpu/drm/imx/imx-drm.h
> > +++ b/drivers/gpu/drm/imx/imx-drm.h
> > @@ -12,7 +12,7 @@ struct drm_framebuffer;
> >  struct imx_drm_crtc;
> >  struct platform_device;
> >  
> > -int imx_drm_crtc_id(struct imx_drm_crtc *crtc);
> > +unsigned int imx_drm_crtc_id(struct imx_drm_crtc *crtc);
> >  
> >  struct imx_drm_crtc_helper_funcs {
> > int (*enable_vblank)(struct drm_crtc *crtc);
> > -- 
> > 2.4.5
> > 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/3b84010d/attachment.sig>

[PATCH] drm/exynos: Staticize local function in exynos_drm_gem.c

[Krzysztof Kozlowski]

The exynos_drm_gem_mmap_buffer() is not used outside so make it static.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 0d5b9698d384..d9f6de012235 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -318,7 +318,7 @@ void exynos_drm_gem_put_dma_addr(struct drm_device *dev,
drm_gem_object_unreference_unlocked(obj);
 }

-int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj *exynos_gem_obj,
+static int exynos_drm_gem_mmap_buffer(struct exynos_drm_gem_obj 
*exynos_gem_obj,
  struct vm_area_struct *vma)
 {
struct drm_device *drm_dev = exynos_gem_obj->base.dev;
-- 
1.9.1

[Bug 102811] New: [BISECTED] [radeon] Monitor loses HDMI video signal - blank screen after boot

[bugzilla-dae...@bugzilla.kernel.org]

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

Bug ID: 102811
   Summary: [BISECTED] [radeon] Monitor loses HDMI video signal -
blank screen after boot
   Product: Drivers
   Version: 2.5
Kernel Version: 4.1
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: sweeneygj at gmx.com
Regression: No

Created attachment 184821
  --> https://bugzilla.kernel.org/attachment.cgi?id=184821=edit
bisect log to locate problem patch

M/B: MA488TD-M EVO
Monitor: Hanns-G HS241HPBEEW01

Monitor connected via HDMI only.

In 4.1 boot up progresses until display manager login at which point the
monitor loses signal - 'No Signal Input. Check Video cable'. 

4.0.9  works fine.

Bisect log attached.

Good boot finds HDMI connector:

Aug 13 09:20:10 gaia kernel: [4.959062] [drm] Radeon Display Connectors
Aug 13 09:20:10 gaia kernel: [4.959066] [drm] Connector 0:
Aug 13 09:20:10 gaia kernel: [4.959067] [drm]   VGA-1
Aug 13 09:20:10 gaia kernel: [4.959069] [drm]   DDC: 0x7e40 0x7e40 0x7e44
0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
Aug 13 09:20:10 gaia kernel: [4.959070] [drm]   Encoders:
Aug 13 09:20:10 gaia kernel: [4.959071] [drm] CRT1:
INTERNAL_KLDSCP_DAC1
Aug 13 09:20:10 gaia kernel: [4.959072] [drm] Connector 1:
Aug 13 09:20:10 gaia kernel: [4.959073] [drm]   HDMI-A-1
Aug 13 09:20:10 gaia kernel: [4.959074] [drm]   HPD3
Aug 13 09:20:10 gaia kernel: [4.959076] [drm]   DDC: 0x7e50 0x7e50 0x7e54
0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
Aug 13 09:20:10 gaia kernel: [4.959077] [drm]   Encoders:
Aug 13 09:20:10 gaia kernel: [4.959078] [drm] DFP3:
INTERNAL_KLDSCP_LVTMA
Aug 13 09:20:10 gaia kernel: [5.038659] [drm] fb mappable at 0xD0359000
Aug 13 09:20:10 gaia kernel: [5.038661] [drm] vram apper at 0xD000
Aug 13 09:20:10 gaia kernel: [5.038662] [drm] size 8294400
Aug 13 09:20:10 gaia kernel: [5.038663] [drm] fb depth is 24
Aug 13 09:20:10 gaia kernel: [5.038664] [drm]pitch is 7680


Bad boot finds DVI-D connector:

Aug 12 22:10:53 gaia kernel: [5.107030] [drm] Radeon Display Connectors
Aug 12 22:10:53 gaia kernel: [5.107034] [drm] Connector 0:
Aug 12 22:10:53 gaia kernel: [5.107035] [drm]   VGA-1
Aug 12 22:10:53 gaia kernel: [5.107037] [drm]   DDC: 0x7e40 0x7e40 0x7e44
0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
Aug 12 22:10:53 gaia kernel: [5.107038] [drm]   Encoders:
Aug 12 22:10:53 gaia kernel: [5.107040] [drm] CRT1:
INTERNAL_KLDSCP_DAC1
Aug 12 22:10:53 gaia kernel: [5.107041] [drm] Connector 1:
Aug 12 22:10:53 gaia kernel: [5.107042] [drm]   DVI-D-1
Aug 12 22:10:53 gaia kernel: [5.107043] [drm]   HPD1
Aug 12 22:10:53 gaia kernel: [5.107045] [drm]   DDC: 0x7e50 0x7e50 0x7e54
0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
Aug 12 22:10:53 gaia kernel: [5.107046] [drm]   Encoders:
Aug 12 22:10:53 gaia kernel: [5.107047] [drm] DFP3:
INTERNAL_KLDSCP_LVTMA
Aug 12 22:10:53 gaia kernel: [5.186593] [drm] fb mappable at 0xD0359000
Aug 12 22:10:53 gaia kernel: [5.186595] [drm] vram apper at 0xD000
Aug 12 22:10:53 gaia kernel: [5.186596] [drm] size 8294400
Aug 12 22:10:53 gaia kernel: [5.186597] [drm] fb depth is 24
Aug 12 22:10:53 gaia kernel: [5.186598] [drm]pitch is 7680

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 91621] Tonga Xonotic artifacts with DRI3

[bugzilla-dae...@freedesktop.org]

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

Andy Furniss  changed:

   What|Removed |Added

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

--- Comment #2 from Andy Furniss  ---
Yes, that fixes it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/80e2e790/attachment.html>

[PULL] topic/drm-misc

[Daniel Vetter]

Hi Dave,

Final drm-misc pull for 4.3:
- fbdev emulation Kconfig option for everyone thanks to Archit. It's not
  everything yet bit this is fairly tricky since it spawns all drivers.
- vgaarb & vgaswitcheroo polish from Thierry
- some drm_irq.c cleanups (Thierry)
- struct_mutex crusade from me
- more fbdev panic handling removal
- various things all over in drm core

Note that this pull is relative to my earlier drm-misc pull that's still
outstanding, so please take them both.

Eric, this contains the patch to make encoder->mode_fixup optional I
talked about in my vc4 review. You can base vc4 on this tag here, it'll
stay stable.

Cheers, Daniel


The following changes since commit 8c10342cb48f3140d9abeadcfd2fa6625d447282:

  drm/atomic: Update legacy DPMS state during modesets, v3. (2015-07-27 
16:23:29 +0200)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2015-08-13

for you to fetch changes up to d4853630b334017cab9a4602f5e9677e3b792c8a:

  drm/atomic: Use KMS VBLANK API (2015-08-12 17:41:30 +0200)


Archit Taneja (25):
  drm/fb_helper: Add drm_fb_helper functions to manage fb_info creation
  drm/fb_helper: Create a wrapper for unlink_framebuffer
  drm/fb_helper: Create wrappers for fb_sys_read/write funcs
  drm/fb_helper: Create wrappers for blit, copyarea and fillrect funcs
  drm/fb_helper: Create a wrapper for fb_set_suspend
  drm/rockchip: Use new drm_fb_helper functions
  drm/armada: Use new drm_fb_helper functions
  drm/ast: Use new drm_fb_helper functions
  drm/tegra: Use new drm_fb_helper functions
  drm/msm: Use new drm_fb_helper functions
  drm/exynos: Use new drm_fb_helper functions
  drm/gma500: Use new drm_fb_helper functions
  drm/qxl: Use new drm_fb_helper functions
  drm/udl: Use new drm_fb_helper functions
  drm/fb_cma_helper: Use new drm_fb_helper functions
  drm/cirrus: Use new drm_fb_helper functions
  drm/omap: Use new drm_fb_helper functions
  drm/mgag200: Use new drm_fb_helper functions
  drm/radeon: Use new drm_fb_helper functions
  drm/i915: Use new drm_fb_helper functions
  drm/nouveau: Use new drm_fb_helper functions
  drm/bochs: Use new drm_fb_helper functions
  drm/amdgpu: Use new drm_fb_helper functions
  drm/virtio: Use new drm_fb_helper functions
  drm: Add top level Kconfig option for DRM fbdev emulation

Daniel Vetter (19):
  drm/omap: Fixup compile fail
  drm/fbdev: Return -EBUSY when oopsing
  drm/fb-helper: Stop using trylocks in force_restore
  drm: Remove __drm_modeset_lock_all
  drm: Fixup locking WARNINGs in drm_mode_config_reset
  drm/gem: Be more friendly with locking checks
  drm/ast: Don't grab dev->struct_mutex for in mmap offset ioctl
  drm/bochs: Don't grab dev->struct_mutex for in mmap offset ioctl
  drm/mga200g: Don't grab dev->struct_mutex for in mmap offset ioctl
  drm/mga200g: Hold a proper reference for cursor_set
  drm/cirrus: Don't grab dev->struct_mutex for in mmap offset ioctl
  drm/cma-helper: Don't grab dev->struct_mutex for in mmap offset ioctl
  drm/rockchip: Don't grab dev->struct_mutex for in mmap offset ioctl
  drm/nouveau: Don't take dev->struct_mutex in ttm_fini
  drm/qxl: Don't take dev->struct_mutex in bo_force_delete
  drm/edid: Use ARRAY_SIZE in drm_add_modes_noedid
  drm/atomic: Paper over locking WARN in default_state_clear
  drm/atomic: Call ww_acquire_done after check phase is complete
  drm/i915: Use CONFIG_DRM_FBDEV_EMULATION

Geert Uytterhoeven (2):
  drm/fb-helper: Clarify drm_fb_helper_restore_fbdev_mode*()
  drm/fb-helper: Move drm_fb_helper_force_kernel_mode() inside #ifdef

Inki Dae (1):
  drm/atomic: fix null pointer access to mode_fixup callback

Maarten Lankhorst (1):
  drm/core: Set mode to NULL when connectors in a set drops to 0.

Thierry Reding (16):
  drm: Remove two-level menu in Kconfig
  vgaarb: Stop complaining about absent devices
  vgaarb: Use vgaarb: prefix consistently in messages
  vgaarb: Fix a few checkpatch errors and warnings
  vga_switcheroo: Use pr_*() instead of printk()
  vga_switcheroo: Cleanup header comment
  vga_switcheroo: Use pr_fmt()
  vga_switcheroo: Wrap overly long lines
  vga_switcheroo: Remove unnecessary checks
  drm/plane: Use consistent data types for format count
  drm/plane: Remove redundant extern
  drm/irq: Remove negative CRTC index special-case
  drm/irq: Check for valid VBLANK before dereference
  drm/irq: Make pipe unsigned and name consistent
  drm/irq: Document return values more consistently
  drm/atomic: Use KMS VBLANK API

Viresh Kumar (1):
  drivers: gpu: Drop unlikely before IS_ERR(_OR_NULL)

 drivers/gpu/drm/Kconfig   |  20 ++
 drivers/gpu/drm/Makefile  

[PATCH 3/7] drm/vc4: Add KMS support for Raspberry Pi.

[Daniel Vetter]

On Wed, Aug 12, 2015 at 05:56:16PM -0700, Eric Anholt wrote:
> This is the start of a full VC4 driver.  Right now this just supports
> configuring the display using a pre-existing video mode (because
> changing the pixel clock isn't available yet, and doesn't work when it
> is).  However, this is enough for fbcon and bringing up X using
> xf86-video-modesetting.
> 
> Signed-off-by: Eric Anholt 
> ---
>  drivers/gpu/drm/Kconfig   |   2 +
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/vc4/Kconfig   |  14 +
>  drivers/gpu/drm/vc4/Makefile  |  18 ++
>  drivers/gpu/drm/vc4/vc4_bo.c  |  54 
>  drivers/gpu/drm/vc4/vc4_crtc.c| 583 ++
>  drivers/gpu/drm/vc4/vc4_debugfs.c |  38 +++
>  drivers/gpu/drm/vc4/vc4_drv.c | 249 +++
>  drivers/gpu/drm/vc4/vc4_drv.h | 123 +++
>  drivers/gpu/drm/vc4/vc4_hdmi.c| 651 
> ++
>  drivers/gpu/drm/vc4/vc4_hvs.c | 172 ++
>  drivers/gpu/drm/vc4/vc4_kms.c |  84 +
>  drivers/gpu/drm/vc4/vc4_plane.c   | 320 +++
>  drivers/gpu/drm/vc4/vc4_regs.h| 562 
>  14 files changed, 2871 insertions(+)
>  create mode 100644 drivers/gpu/drm/vc4/Kconfig
>  create mode 100644 drivers/gpu/drm/vc4/Makefile
>  create mode 100644 drivers/gpu/drm/vc4/vc4_bo.c
>  create mode 100644 drivers/gpu/drm/vc4/vc4_crtc.c
>  create mode 100644 drivers/gpu/drm/vc4/vc4_debugfs.c
>  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.c
>  create mode 100644 drivers/gpu/drm/vc4/vc4_drv.h
>  create mode 100644 drivers/gpu/drm/vc4/vc4_hdmi.c
>  create mode 100644 drivers/gpu/drm/vc4/vc4_hvs.c
>  create mode 100644 drivers/gpu/drm/vc4/vc4_kms.c
>  create mode 100644 drivers/gpu/drm/vc4/vc4_plane.c
>  create mode 100644 drivers/gpu/drm/vc4/vc4_regs.h

Made a quick pass and found a few things to update to latest drm
developments. Of course didn't look at the hardware details since no clue,
but looks really nice overall.
-Daniel

> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index c46ca31..1730a76 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -240,3 +240,5 @@ source "drivers/gpu/drm/sti/Kconfig"
>  source "drivers/gpu/drm/amd/amdkfd/Kconfig"
>  
>  source "drivers/gpu/drm/imx/Kconfig"
> +
> +source "drivers/gpu/drm/vc4/Kconfig"
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 5713d05..b991ac5 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -42,6 +42,7 @@ obj-$(CONFIG_DRM_MGA)   += mga/
>  obj-$(CONFIG_DRM_I810)   += i810/
>  obj-$(CONFIG_DRM_I915)  += i915/
>  obj-$(CONFIG_DRM_MGAG200) += mgag200/
> +obj-$(CONFIG_DRM_VC4)  += vc4/
>  obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/
>  obj-$(CONFIG_DRM_SIS)   += sis/
>  obj-$(CONFIG_DRM_SAVAGE)+= savage/
> diff --git a/drivers/gpu/drm/vc4/Kconfig b/drivers/gpu/drm/vc4/Kconfig
> new file mode 100644
> index 000..130cc94
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/Kconfig
> @@ -0,0 +1,14 @@
> +config DRM_VC4
> + tristate "Broadcom VC4 Graphics"
> + depends on ARCH_BCM2835
> + depends on DRM
> + select DRM_KMS_HELPER
> + select DRM_KMS_FB_HELPER
> + select DRM_KMS_CMA_HELPER

drm-misc/linux-next already has Archit's patches to enable/disable fbdev
in the core code, so you don't need to bother about these selects here any
more, it'll no-op out if drm fbdev emulation isn't enabled. Since you're
reusing cma fbdev helpers I don't think there's any need for other changes
because of this.

> + help
> +   Choose this option if you have a system that has a Broadcom
> +   VC4 GPU, such as the Raspberry Pi or other BCM2708/BCM2835.
> +
> +   This driver requires that "avoid_warnings=2" be present in
> +   the config.txt for the firmware, to keep it from smashing
> +   our display setup.
> diff --git a/drivers/gpu/drm/vc4/Makefile b/drivers/gpu/drm/vc4/Makefile
> new file mode 100644
> index 000..4aa07ca
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/Makefile
> @@ -0,0 +1,18 @@
> +ccflags-y := -Iinclude/drm
> +
> +# Please keep these build lists sorted!
> +
> +# core driver code
> +vc4-y := \
> + vc4_bo.o \
> + vc4_crtc.o \
> + vc4_drv.o \
> + vc4_kms.o \
> + vc4_hdmi.o \
> + vc4_hvs.o \
> + vc4_plane.o \
> + $()
> +
> +vc4-$(CONFIG_DEBUG_FS) += vc4_debugfs.o
> +
> +obj-$(CONFIG_DRM_VC4)  += vc4.o
> diff --git a/drivers/gpu/drm/vc4/vc4_bo.c b/drivers/gpu/drm/vc4/vc4_bo.c
> new file mode 100644
> index 000..fee8cac
> --- /dev/null
> +++ b/drivers/gpu/drm/vc4/vc4_bo.c
> @@ -0,0 +1,54 @@
> +/*
> + *  Copyright © 2015 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +/* DOC: VC4 GEM BO management support.
> + *
> + * The VC4 

[Bug 102401] Radeon Displayport Audio Warping

[bugzilla-dae...@bugzilla.kernel.org]

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

Maxqia  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

vmwgfx GL3 and other -next (4.3) pathches

[Thomas Hellstrom]

On 08/13/2015 08:38 AM, Daniel Vetter wrote:
> On Thu, Aug 13, 2015 at 7:04 AM, Thomas Hellstrom  
> wrote:
>>> Out of curiosity I did take a (very) quick look and also tried to find the
>>> corresponding userspace parts. On a quick search I didn't find anything
>>> for libdrm or mesa, neither on mailing lists or already committed. Where
>>> are those pieces?
>>> -Daniel
>> The mesa code is ready and working but undergoing final tidying before
>> upstreaming. The aim is of course to release it well before linux 4.3 is
>> out. However our kernel interface has just undergone very minor change
> In my opinion userspace must be ready for merging (and public) before
> the kernel code can go in. That's at least what I enforce for i915 and
> how all other drivers are handled.
> -Daniel

OK. I was under the impression that this was only enforced on big
user-space interface changes, new drivers or if there was a suspicion
that the user-space part would never be open-sourced. Let's see what we
can do to speed this up.

Thanks,
Thomas

[PATCH 1/7] prime_mmap: Add new test for calling mmap() on dma-buf fds

[Daniel Vetter]

On Wed, Aug 12, 2015 at 08:29:14PM -0300, Tiago Vignatti wrote:
> From: Rob Bradford 
> 
> This test has the following subtests:
>  - test_correct for correctness of the data
>  - test_map_unmap checks for mapping idempotency
>  - test_reprime checks for dma-buf creation idempotency
>  - test_forked checks for multiprocess access
>  - test_refcounting checks for buffer reference counting
>  - test_dup chats that dup()ing the fd works
>  - test_errors checks the error return values for failures
>  - test_aperture_limit tests multiple buffer creation at the gtt aperture
>limit
> 
> Signed-off-by: Rob Bradford 
> Signed-off-by: Tiago Vignatti 
> ---
>  tests/Makefile.sources |   1 +
>  tests/prime_mmap.c | 383 
> +
>  2 files changed, 384 insertions(+)
>  create mode 100644 tests/prime_mmap.c
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index c94714b..5b2072e 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -90,6 +90,7 @@ TESTS_progs_M = \
>   pm_rps \
>   pm_rc6_residency \
>   pm_sseu \
> + prime_mmap \
>   prime_self_import \
>   template \
>   $(NULL)
> diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
> new file mode 100644
> index 000..4dc2055
> --- /dev/null
> +++ b/tests/prime_mmap.c
> @@ -0,0 +1,383 @@
> +/*
> + * Copyright © 2014 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + *Rob Bradford 
> + *
> + */
> +
> +/*
> + * Testcase: Check whether mmap()ing dma-buf works
> + */
> +#define _GNU_SOURCE
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "drm.h"
> +#include "i915_drm.h"
> +#include "drmtest.h"
> +#include "igt_debugfs.h"
> +#include "ioctl_wrappers.h"
> +
> +#define BO_SIZE (16*1024)
> +
> +static int fd;
> +
> +char pattern[] = {0xff, 0x00, 0x00, 0x00,
> + 0x00, 0xff, 0x00, 0x00,
> + 0x00, 0x00, 0xff, 0x00,
> + 0x00, 0x00, 0x00, 0xff};
> +
> +static void
> +fill_bo(uint32_t handle, size_t size)
> +{
> + off_t i;
> + for (i = 0; i < size; i+=sizeof(pattern))
> + {
> + gem_write(fd, handle, i, pattern, sizeof(pattern));
> + }
> +}
> +
> +static int
> +pattern_check(char *ptr, size_t size)
> +{
> + off_t i;
> + for (i = 0; i < size; i+=sizeof(pattern))
> + {
> + if (memcmp(ptr, pattern, sizeof(pattern)) != 0)
> + return 1;
> + }
> +
> + return 0;
> +}
> +
> +static void
> +test_correct(void)
> +{
> + int dma_buf_fd;
> + char *ptr1, *ptr2;
> + uint32_t handle;
> +
> + handle = gem_create(fd, BO_SIZE);
> + fill_bo(handle, BO_SIZE);
> +
> + dma_buf_fd = prime_handle_to_fd(fd, handle);
> + igt_assert(errno == 0);
> +
> + /* Check correctness vs GEM_MMAP_GTT */
> + ptr1 = gem_mmap(fd, handle, BO_SIZE, PROT_READ | PROT_WRITE);
> + ptr2 = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
> + igt_assert(ptr1 != MAP_FAILED);
> + igt_assert(ptr2 != MAP_FAILED);
> + igt_assert(memcmp(ptr1, ptr2, BO_SIZE) == 0);
> +
> + /* Check pattern correctness */
> + igt_assert(pattern_check(ptr2, BO_SIZE) == 0);
> +
> + munmap(ptr1, BO_SIZE);
> + munmap(ptr2, BO_SIZE);
> + close(dma_buf_fd);
> + gem_close(fd, handle);
> +}
> +
> +static void
> +test_map_unmap(void)
> +{
> + int dma_buf_fd;
> + char *ptr;
> + uint32_t handle;
> +
> + handle = gem_create(fd, BO_SIZE);
> + fill_bo(handle, BO_SIZE);
> +
> + dma_buf_fd = prime_handle_to_fd(fd, handle);
> + igt_assert(errno == 0);
> +
> + ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
> + igt_assert(ptr != MAP_FAILED);
> + igt_assert(pattern_check(ptr, BO_SIZE) 

[PATCH 3/7] prime_mmap: Add basic tests to write in a bo using CPU

[Daniel Vetter]

On Wed, Aug 12, 2015 at 08:29:16PM -0300, Tiago Vignatti wrote:
> This patch adds test_correct_cpu_write, which maps the texture buffer through 
> a
> prime fd and then writes directly to it using the CPU. It stresses the driver
> to guarantee cache synchronization among the different domains.
> 
> This test also adds test_forked_cpu_write, which creates the GEM bo in one
> process and pass the prime handle of the it to another process, which in turn
> uses the handle only to map and write. Grossly speaking this test simulates
> Chrome OS  architecture, where the Web content ("unpriviledged process") maps
> and CPU-draws a buffer, which was previously allocated in the GPU process
> ("priviledged process").
> 
> This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
> O_RDWR during prime-handle-to-fd").
> 
> Signed-off-by: Tiago Vignatti 

Squash with previous patch?
> ---
>  lib/ioctl_wrappers.c |  5 +++-
>  tests/prime_mmap.c   | 65 
> 
>  2 files changed, 69 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
> index 53bd635..941fa66 100644
> --- a/lib/ioctl_wrappers.c
> +++ b/lib/ioctl_wrappers.c
> @@ -1125,6 +1125,9 @@ void gem_require_ring(int fd, int ring_id)
>  
>  /* prime */
>  
> +#ifndef DRM_RDWR
> +#define DRM_RDWR O_RDWR
> +#endif
>  /**
>   * prime_handle_to_fd:
>   * @fd: open i915 drm file descriptor
> @@ -1142,7 +1145,7 @@ int prime_handle_to_fd(int fd, uint32_t handle)
>  
>   memset(, 0, sizeof(args));
>   args.handle = handle;
> - args.flags = DRM_CLOEXEC;
> + args.flags = DRM_CLOEXEC | DRM_RDWR;

This needs to be optional otherwise all the existing prime tests start
falling over on older kernels. Probably need a
prime_handle_to_fd_with_mmap, which doesn an igt_skip if it fails.
-Daniel

>   args.fd = -1;
>  
>   do_ioctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, );
> diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
> index dc59e8f..ad91371 100644
> --- a/tests/prime_mmap.c
> +++ b/tests/prime_mmap.c
> @@ -22,6 +22,7 @@
>   *
>   * Authors:
>   *Rob Bradford 
> + *Tiago Vignatti 
>   *
>   */
>  
> @@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
>  }
>  
>  static void
> +fill_bo_cpu(char *ptr)
> +{
> + memcpy(ptr, pattern, sizeof(pattern));
> +}
> +
> +static void
>  test_correct(void)
>  {
>   int dma_buf_fd;
> @@ -180,6 +187,62 @@ test_forked(void)
>   gem_close(fd, handle);
>  }
>  
> +/* test CPU write. This has a rather big implication for the driver which 
> must
> + * guarantee cache synchronization when writing the bo using CPU. */
> +static void
> +test_correct_cpu_write(void)
> +{
> + int dma_buf_fd;
> + char *ptr;
> + uint32_t handle;
> +
> + handle = gem_create(fd, BO_SIZE);
> +
> + dma_buf_fd = prime_handle_to_fd(fd, handle);
> + igt_assert(errno == 0);
> +
> + /* Check correctness of map using write protection (PROT_WRITE) */
> + ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, 
> dma_buf_fd, 0);
> + igt_assert(ptr != MAP_FAILED);
> +
> + /* Fill bo using CPU */
> + fill_bo_cpu(ptr);
> +
> + /* Check pattern correctness */
> + igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
> +
> + munmap(ptr, BO_SIZE);
> + close(dma_buf_fd);
> + gem_close(fd, handle);
> +}
> +
> +/* map from another process and then write using CPU */
> +static void
> +test_forked_cpu_write(void)
> +{
> + int dma_buf_fd;
> + char *ptr;
> + uint32_t handle;
> +
> + handle = gem_create(fd, BO_SIZE);
> +
> + dma_buf_fd = prime_handle_to_fd(fd, handle);
> + igt_assert(errno == 0);
> +
> + igt_fork(childno, 1) {
> + ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED, 
> dma_buf_fd, 0);
> + igt_assert(ptr != MAP_FAILED);
> + fill_bo_cpu(ptr);
> +
> + igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
> + munmap(ptr, BO_SIZE);
> + close(dma_buf_fd);
> + }
> + close(dma_buf_fd);
> + igt_waitchildren();
> + gem_close(fd, handle);
> +}
> +
>  static void
>  test_refcounting(void)
>  {
> @@ -346,6 +409,8 @@ igt_main
>   { "test_map_unmap", test_map_unmap },
>   { "test_reprime", test_reprime },
>   { "test_forked", test_forked },
> + { "test_correct_cpu_write", test_correct_cpu_write },
> + { "test_forked_cpu_write", test_forked_cpu_write },
>   { "test_refcounting", test_refcounting },
>   { "test_dup", test_dup },
>   { "test_errors", test_errors },
> -- 
> 2.1.0
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 0/2] drm: CMA fbdev stride adjustment

[Daniel Vetter]

On Wed, Aug 12, 2015 at 03:52:12PM -0500, Rob Herring wrote:
> I'm working on a DRM driver for PXA1928. Other than a stride alignment 
> requirement of 16 bytes, I have no other reason not to use fbdev_cma. 
> While I can adjust the stride for drm_gem_cma_dumb_create, I cannot do 
> the same for drm_fbdev_cma_create without duplicating a bunch of code. 
> This series allows fbdev_cma users to override the fb_probe function, so 
> the stride can be adjusted.
> 
> It appears to me that rcar-du has a bug that it doesn't handle alignment 
> requirements for this case as well. Probably just getting lucky with 
> tested resolutions/bpp.
> 
> Also, AFAICT the Rockchip driver has no real reason to use a custom GEM 
> allocator instead of the CMA one. It sets the DMA_ATTR_NO_KERNEL_MAPPING 
> DMA attr, but that could easily be supported by the CMA allocator.

I think it'd be easier to review this with the driver at hand. That's also
generally the requirement for merging new code - it needs an in-kernel
user.
-Daniel

> 
> Rob
> 
> Rob Herring (2):
>   drm/cma: allow custom fb helper functions
>   drm/cma: allow adjusting the pitch for CMA fbdev
> 
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  2 +-
>  drivers/gpu/drm/drm_fb_cma_helper.c  | 13 ++---
>  drivers/gpu/drm/imx/imx-drm-core.c   |  2 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 ++-
>  drivers/gpu/drm/sti/sti_drm_drv.c|  2 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 +-
>  include/drm/drm_fb_cma_helper.h  |  7 +++
>  include/drm/drm_fb_helper.h  |  1 +
>  8 files changed, 24 insertions(+), 8 deletions(-)
> 
> -- 
> 2.1.4
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro

[Daniel Vetter]

On Thu, Aug 13, 2015 at 1:37 AM, Lukas Wunner  wrote:
> Hi Daniel,
>
> On Wed, Aug 12, 2015 at 04:16:25PM +0200, Daniel Vetter wrote:
>> > * Reprobing if the inactive GPU initializes before the apple-gmux module:
>> >   v1 used Matthew Garrett's approach of adding a driver callback.
>> >   v2 simply generates a hotplug event instead. nouveau polls its outputs
>> >   every 10 seconds so we want it to poll immediately once apple-gmux
>> >   registers. That is achieved by the hotplug event. The i915 driver is
>> >   changed to behave identically to nouveau. (Right now it deletes LVDS
>> >   and eDP connectors from the mode configuration if they can't be probed,
>> >   deeming them to be ghosts.)
>>
>> I thought -EDEFERREDPROBE is what we should be using if drivers don't get
>> loaded in the right order? Hand-rolling depency avoidance stuff is imo a
>> horrible idea.
> [...]
>> I think just reading edid and the relevant dp aux data in apple-gmux or
>> somewhere like that and stalling driver load until that's ready is the
>> only clean option.
>
> I'm afraid we can't stall initialization of a driver like that because
> even though the GPU may not be switched to the panel, it may still have
> an external monitor attached.
>
> All MacBook Pros have external DP and/or HDMI ports and these are
> either soldered to the discrete GPU (model year 2011 and onwards)
> or switchable between the discrete and integrated GPU (until 2010;
> I think they are even switchable separately from the panel).
>
> So basically we'd have to initialize the driver normally, and if
> intel_lvds_init() or intel_edp_init_connector() fail we'd have to
> somehow pass that up the call chain so that i915_pci_probe() can
> return -EPROBE_DEFER. And whenever we're asked to reprobe we'd
> repeat initialization of the LVDS or eDP connector.
>
> I'm wondering what the benefit is compared to just keeping the
> connector in the mode configuration, but with status disconnected,
> and reprobing it when the ->output_poll_changed callback gets invoked?
> Because that's what nouveau already does, and what I've changed i915
> to do with patch 13.
>
> vga_switcheroo calls drm_kms_helper_hotplug_event() when the handler
> registers (patch 11), which will invoke ->output_poll_changed.
> So we're talking about the Official DRM Callback [tm] to probe
> outputs, not "hand-rolling depency avoidance". :-)

Oh I didn't spot that one. This kind of layering inversions generally
leads to deadlocks and fun stuff. Also reprobing lvds/edp is just a
side-effect when you have fbdev emulation enabled. If we go with this
re-probing approach then we definitely need a new hook in
vga-switcheroo, and even then there's still the locking problem.

>> > * Framebuffer recreation if the inactive GPU initializes before the
>> >   apple-gmux module (i.e. discarding the default 1024x768 fb and replacing
>> >   with a new one with the actual panel resolution): v1 only supported this
>> >   for i915, v2 has a generic solution which works with nouveau and radeon
>> >   as well. (Necessary if the discrete GPU is forced to be the inactive one
>> >   on boot via the EFI variable.)
>>
>> Would completely remove the need for this ;-)
>
> Unfortunately not: We'd still have to initialize the driver to be able
> to drive external displays. If there are initially no connectors with
> modes, we'll once again end up with the 1024x768 fb.

EDEFERREDPROBE isn't something that gets returned to userspace, it's
just internal handling so that the kernel knows there's a depency
issue and it needs to retry probing once other drivers have finished
loading. It is the generic means linux has to handle cross-driver
depencies which aren't reflected in the bus hierarchy.

I.e. it's just something to make sure that apple-gmux is fully loaded
before i915/nouveau. The driver _will_ be initialized eventually.

>> You can't share the dp aux like that. It's true that we need a bit more
>> data (there's a few eDP related feature blocsk we need), but sharing the
>> aux channel entirely is no-go. If you do you get drivers trying to link
>> train and at best this fails and at worst you'll upset the configuration
>> of the other driver and piss of the panel enough to need a hard reset
>> until it works again.
>
> Yes, so far proxying of the AUX channel is read-only. In those cases
> when writing is necessary for setting up the output, I'm adding code
> to check if the current content of the DPCD is identical to what's
> being written and if so, skip the write. We'll see if this stategy is
> sufficient for the drivers to set up their outputs.

You need to block anything that would write _much_ earlier. By the
time we're doing link-training it's way too late.

>> I think the real tricky bit here with vgaswitcheroo is locking, I need to
>> take a separate lock at the patches for that.
>
> Locking when switching only the DDC lines is facilitated by the ddc_lock
> attribute of struct vgasr_priv. This is all local to 

vmwgfx GL3 and other -next (4.3) pathches

[Daniel Vetter]

On Thu, Aug 13, 2015 at 7:04 AM, Thomas Hellstrom  
wrote:
>> Out of curiosity I did take a (very) quick look and also tried to find the
>> corresponding userspace parts. On a quick search I didn't find anything
>> for libdrm or mesa, neither on mailing lists or already committed. Where
>> are those pieces?
>> -Daniel
>
> The mesa code is ready and working but undergoing final tidying before
> upstreaming. The aim is of course to release it well before linux 4.3 is
> out. However our kernel interface has just undergone very minor change

In my opinion userspace must be ready for merging (and public) before
the kernel code can go in. That's at least what I enforce for i915 and
how all other drivers are handled.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Regression v4.2] Re: [PATCH 7/9] drm/radeon: add VCE 1.0 support v4

[Lucas Stach]

Am Donnerstag, den 13.08.2015, 15:18 +0900 schrieb Michel Dänzer:
> On 13.08.2015 15:03, Lucas Stach wrote:
> > Hi Christian,
> > 
> > this commit is causing a boot regression with v4.2-rcX on my Richland
> > APU (CHIP_ARUBA) based laptop. I didn't have time yet to track down
> > where exactly it is going wrong, but I bisected it down to this single
> > commit.
> > 
> > I don't have the VCE firmware installed on this system, so from a quick
> > look at the code I would expect it to drop out pretty early and just
> > leave the VCE unconfigured, but otherwise keep things working as before.
> > This is unfortunately not the case.
> 
> If the radeon driver is built into the kernel (or loaded from the
> initrd?), the attempt to load the firmware might take a long time to
> time out.
> 
Gah. Thanks, I was too impatient to wait for the firmware loading to
time out. In fact this is a standard Fedora kernel config, so radeon is
a module, but it is built into the initrd.

So it's not really readeons fault, but one more iteration of the fact
that anything involving firmware loading is just horribly inconvenient.
Especially if it's firmware for an optional component.

Regards,
Lucas

[Regression v4.2] Re: [PATCH 7/9] drm/radeon: add VCE 1.0 support v4

[Lucas Stach]

Hi Christian,

this commit is causing a boot regression with v4.2-rcX on my Richland
APU (CHIP_ARUBA) based laptop. I didn't have time yet to track down
where exactly it is going wrong, but I bisected it down to this single
commit.

I don't have the VCE firmware installed on this system, so from a quick
look at the code I would expect it to drop out pretty early and just
leave the VCE unconfigured, but otherwise keep things working as before.
This is unfortunately not the case.

Maybe you can take a look at what's wrong here. We are already pretty
late in the release cycle and I'm unsure if I can find any more time to
look into the issue before the final release.

Thanks,
Lucas

Am Montag, den 11.05.2015, 22:01 +0200 schrieb Christian König:
> From: Christian König 
> 
> Initial support for VCE 1.0 using newest firmware.
> 
> v2: rebased
> v3: fix for TN
> v4: fix FW size calculation
> 
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/radeon/ni.c  |  46 
>  drivers/gpu/drm/radeon/radeon.h  |   1 +
>  drivers/gpu/drm/radeon/radeon_asic.c |  17 +
>  drivers/gpu/drm/radeon/radeon_asic.h |   3 +
>  drivers/gpu/drm/radeon/radeon_vce.c  |  23 +-
>  drivers/gpu/drm/radeon/si.c  |  46 
>  drivers/gpu/drm/radeon/sid.h |   1 +
>  drivers/gpu/drm/radeon/vce_v1_0.c| 140 
> +++
>  8 files changed, 274 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
> index 32f5f03..faffca3 100644
> --- a/drivers/gpu/drm/radeon/ni.c
> +++ b/drivers/gpu/drm/radeon/ni.c
> @@ -2040,6 +2040,25 @@ static int cayman_startup(struct radeon_device *rdev)
>   if (r)
>   rdev->ring[R600_RING_TYPE_UVD_INDEX].ring_size = 0;
>  
> + if (rdev->family == CHIP_ARUBA) {
> + r = radeon_vce_resume(rdev);
> + if (!r)
> + r = vce_v1_0_resume(rdev);
> +
> + if (!r)
> + r = radeon_fence_driver_start_ring(rdev,
> +
> TN_RING_TYPE_VCE1_INDEX);
> + if (!r)
> + r = radeon_fence_driver_start_ring(rdev,
> +
> TN_RING_TYPE_VCE2_INDEX);
> +
> + if (r) {
> + dev_err(rdev->dev, "VCE init error (%d).\n", r);
> + rdev->ring[TN_RING_TYPE_VCE1_INDEX].ring_size = 0;
> + rdev->ring[TN_RING_TYPE_VCE2_INDEX].ring_size = 0;
> + }
> + }
> +
>   r = radeon_fence_driver_start_ring(rdev, CAYMAN_RING_TYPE_CP1_INDEX);
>   if (r) {
>   dev_err(rdev->dev, "failed initializing CP fences (%d).\n", r);
> @@ -2117,6 +2136,19 @@ static int cayman_startup(struct radeon_device *rdev)
>   DRM_ERROR("radeon: failed initializing UVD (%d).\n", r);
>   }
>  
> + ring = >ring[TN_RING_TYPE_VCE1_INDEX];
> + if (ring->ring_size)
> + r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
> +
> + ring = >ring[TN_RING_TYPE_VCE2_INDEX];
> + if (ring->ring_size)
> + r = radeon_ring_init(rdev, ring, ring->ring_size, 0, 0x0);
> +
> + if (!r)
> + r = vce_v1_0_init(rdev);
> + else if (r != -ENOENT)
> + DRM_ERROR("radeon: failed initializing VCE (%d).\n", r);
> +
>   r = radeon_ib_pool_init(rdev);
>   if (r) {
>   dev_err(rdev->dev, "IB initialization failed (%d).\n", r);
> @@ -2272,6 +2304,19 @@ int cayman_init(struct radeon_device *rdev)
>   r600_ring_init(rdev, ring, 4096);
>   }
>  
> + if (rdev->family == CHIP_ARUBA) {
> + r = radeon_vce_init(rdev);
> + if (!r) {
> + ring = >ring[TN_RING_TYPE_VCE1_INDEX];
> + ring->ring_obj = NULL;
> + r600_ring_init(rdev, ring, 4096);
> +
> + ring = >ring[TN_RING_TYPE_VCE2_INDEX];
> + ring->ring_obj = NULL;
> + r600_ring_init(rdev, ring, 4096);
> + }
> + }
> +
>   rdev->ih.ring_obj = NULL;
>   r600_ih_ring_init(rdev, 64 * 1024);
>  
> @@ -2325,6 +2370,7 @@ void cayman_fini(struct radeon_device *rdev)
>   radeon_irq_kms_fini(rdev);
>   uvd_v1_0_fini(rdev);
>   radeon_uvd_fini(rdev);
> + radeon_vce_fini(rdev);
>   cayman_pcie_gart_fini(rdev);
>   r600_vram_scratch_fini(rdev);
>   radeon_gem_fini(rdev);
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index 38603b1..59480fd 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -1719,6 +1719,7 @@ struct radeon_vce {
>   struct drm_file *filp[RADEON_MAX_VCE_HANDLES];
>   unsignedimg_size[RADEON_MAX_VCE_HANDLES];
>   struct delayed_work idle_work;
> + uint32_t

vmwgfx GL3 and other -next (4.3) pathches

[Thomas Hellstrom]

On 08/12/2015 11:02 PM, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 08:31:09PM +0200, Thomas Hellstrom wrote:
>> Hi, all,
>>
>> I've pushed the current upcoming vmwgfx patches for 4.3 into
>>
>> git://people.freedesktop.org/~thomash/linux
>> branch vmwgfx-next for review.
>>
>> There are quite a few patches so I figured that this would be easier
>> than posting all patches on the mailing list.
>> The patches are all internally reviewed, either by me, Sinclair Yeh,
>> Brian Paul or Charmaine Lee.
>>
>> The patchset basically enables the following
>> - Screen targets - Use of a new device API for scanout buffers
>> - Command buffers - A device command buffer queue replacing the old ring
>> fifo.
>> - GL3 - support for a new device functionality called "DX" that enables
>> us to support GL3. Mesa gallium driver support for GL3 is about to be
>> published. The patches for DX support have been heavily squashed.
>>
>> Please let me know if anybody has any objections against this.
> Just submit it to dri-devel, it's really not that much compared to other
> big patch series here ;-)
> -Daniel
OK, I'll do that. I spoke briefly to Dave some time ago and he suggested
using a tree in this way, unless someone on dri-devel objected.

Thanks,
Thomas.

vmwgfx GL3 and other -next (4.3) pathches

[Thomas Hellstrom]

Hi,

On 08/12/2015 11:07 PM, Daniel Vetter wrote:
> On Wed, Aug 12, 2015 at 08:31:09PM +0200, Thomas Hellstrom wrote:
>> Hi, all,
>>
>> I've pushed the current upcoming vmwgfx patches for 4.3 into
>>
>> git://people.freedesktop.org/~thomash/linux
>> branch vmwgfx-next for review.
>>
>> There are quite a few patches so I figured that this would be easier
>> than posting all patches on the mailing list.
>> The patches are all internally reviewed, either by me, Sinclair Yeh,
>> Brian Paul or Charmaine Lee.
>>
>> The patchset basically enables the following
>> - Screen targets - Use of a new device API for scanout buffers
>> - Command buffers - A device command buffer queue replacing the old ring
>> fifo.
>> - GL3 - support for a new device functionality called "DX" that enables
>> us to support GL3. Mesa gallium driver support for GL3 is about to be
>> published. The patches for DX support have been heavily squashed.
>>
>> Please let me know if anybody has any objections against this.
> Out of curiosity I did take a (very) quick look and also tried to find the
> corresponding userspace parts. On a quick search I didn't find anything
> for libdrm or mesa, neither on mailing lists or already committed. Where
> are those pieces?
> -Daniel

The mesa code is ready and working but undergoing final tidying before
upstreaming. The aim is of course to release it well before linux 4.3 is
out. However our kernel interface has just undergone very minor changes.

Typically we don't use libdrm for any vmwgfx-specific code. At least not
yet. The corresponding code sits in the gallium winsys.

Thanks,
Thomas

[Bug 91621] Tonga Xonotic artifacts with DRI3

[bugzilla-dae...@freedesktop.org]

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

--- Comment #1 from Michel Dänzer  ---
Might be fixed in
http://cgit.freedesktop.org/mesa/mesa/commit/?id=6611f65047575054a38ce83ebfe0331e39e1774f
. 

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150813/0650afed/attachment.html>

[PATCH] drm/i915: Only dither on 6bpc panels

[Mario Kleiner]

Thanks for the quick fix! Comments below...

On 08/12/2015 11:43 AM, Daniel Vetter wrote:
> In
>
> commit d328c9d78d64ca11e744fe227096990430a88477
> Author: Daniel Vetter 
> Date:   Fri Apr 10 16:22:37 2015 +0200
>
>  drm/i915: Select starting pipe bpp irrespective or the primary plane
>
> we started to select the pipe bpp from sink capabilities and not from
> the primary framebuffer - that one might change (and we don't want to
> incur a modeset) and sprites might contain higher bpp content too.
>
> Problem is that now if you have a 10bpc screen and display 24bpp rgb
> primary then we select dithering, and apparently that mangles the high
> 8 bits even (even thought you'd expect dithering only to affect how
> 12bpc gets mapped into 10bpc). And that mangling upsets certain users.
>

Probably doesn't matter, but your explanation of the former problem here 
is slightly off. We also selected dithering on a 8 bpc screen displaying 
a 24bpp rgb primary, because pipe_bpp is 24 for such a typical 8 bpc 
sink, but since the commit mentioned above, base_bpp is always the 
absolute maximum supported by the hardware, e.g., 36 bpp on my Ironlake 
chip. Iow. the only way to not get dithering would have been to connect 
a deep color 12 bpc display, so pipe_bpp == 36 == base_bpp.

> Hence only enable dithering on 6bpc screens where we difinitely and
> always want it.
>

Other than that, i tested the patch on both 8 bpc output with my 
measurement equipment and on the internal laptop 6 bpc panel, and 
everything is fine now - No banding on the 6 bpc panel, no banding or 
equipment failure on the external 8 bpc output. Life is good again :)

Reviewed-and-tested-by: Mario Kleiner 

thanks,
-mario

> Cc: Mario Kleiner 
> Reported-by: Mario Kleiner 
> Signed-off-by: Daniel Vetter 
> ---
>   drivers/gpu/drm/i915/intel_display.c | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 9a2f229a1c3a..128462e0a0b5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12186,7 +12186,9 @@ encoder_retry:
>   goto encoder_retry;
>   }
>
> - pipe_config->dither = pipe_config->pipe_bpp != base_bpp;
> + /* Dithering seems to not pass-through bits correctly when it should, so
> +  * only enable it on 6bpc panels. */
> + pipe_config->dither = pipe_config->pipe_bpp == 6*3;
>   DRM_DEBUG_KMS("plane bpp: %i, pipe bpp: %i, dithering: %i\n",
> base_bpp, pipe_config->pipe_bpp, pipe_config->dither);
>
>

[PATCH libdrm 0/9] amdgpu: cleanup the exported symbols

[Zhou, Jammy]

The series are Reviewed-by: Jammy Zhou 

And I will rebase my pending patches on top of this series. Thanks.

Regards,
Jammy

-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of 
Emil Velikov
Sent: Saturday, August 08, 2015 12:45 AM
To: dri-devel at lists.freedesktop.org
Cc: Deucher, Alexander
Subject: [PATCH libdrm 0/9] amdgpu: cleanup the exported symbols

Now that the API is stabilised we can do a bit of a cleanup, and ensure only 
the symbols part of it are exported - 62 -> 34.

This also gives us some ~10% is size reduction of the final binary.

Android support would be nice, but it's not a show stopper :)

Please review,
Emil

___
dri-devel mailing list
dri-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH v2 00/22] Enable gpu switching on the MacBook Pro

[Lukas Wunner]

Hi Daniel,

On Wed, Aug 12, 2015 at 04:16:25PM +0200, Daniel Vetter wrote:
> > * Reprobing if the inactive GPU initializes before the apple-gmux module:
> >   v1 used Matthew Garrett's approach of adding a driver callback.
> >   v2 simply generates a hotplug event instead. nouveau polls its outputs
> >   every 10 seconds so we want it to poll immediately once apple-gmux
> >   registers. That is achieved by the hotplug event. The i915 driver is
> >   changed to behave identically to nouveau. (Right now it deletes LVDS
> >   and eDP connectors from the mode configuration if they can't be probed,
> >   deeming them to be ghosts.)
> 
> I thought -EDEFERREDPROBE is what we should be using if drivers don't get
> loaded in the right order? Hand-rolling depency avoidance stuff is imo a
> horrible idea.
[...]
> I think just reading edid and the relevant dp aux data in apple-gmux or
> somewhere like that and stalling driver load until that's ready is the
> only clean option.

I'm afraid we can't stall initialization of a driver like that because
even though the GPU may not be switched to the panel, it may still have
an external monitor attached.

All MacBook Pros have external DP and/or HDMI ports and these are
either soldered to the discrete GPU (model year 2011 and onwards)
or switchable between the discrete and integrated GPU (until 2010;
I think they are even switchable separately from the panel).

So basically we'd have to initialize the driver normally, and if
intel_lvds_init() or intel_edp_init_connector() fail we'd have to
somehow pass that up the call chain so that i915_pci_probe() can
return -EPROBE_DEFER. And whenever we're asked to reprobe we'd
repeat initialization of the LVDS or eDP connector.

I'm wondering what the benefit is compared to just keeping the
connector in the mode configuration, but with status disconnected,
and reprobing it when the ->output_poll_changed callback gets invoked?
Because that's what nouveau already does, and what I've changed i915
to do with patch 13.

vga_switcheroo calls drm_kms_helper_hotplug_event() when the handler
registers (patch 11), which will invoke ->output_poll_changed.
So we're talking about the Official DRM Callback [tm] to probe
outputs, not "hand-rolling depency avoidance". :-)


> > * Framebuffer recreation if the inactive GPU initializes before the
> >   apple-gmux module (i.e. discarding the default 1024x768 fb and replacing
> >   with a new one with the actual panel resolution): v1 only supported this
> >   for i915, v2 has a generic solution which works with nouveau and radeon
> >   as well. (Necessary if the discrete GPU is forced to be the inactive one
> >   on boot via the EFI variable.)
> 
> Would completely remove the need for this ;-)

Unfortunately not: We'd still have to initialize the driver to be able
to drive external displays. If there are initially no connectors with
modes, we'll once again end up with the 1024x768 fb.


> You can't share the dp aux like that. It's true that we need a bit more
> data (there's a few eDP related feature blocsk we need), but sharing the
> aux channel entirely is no-go. If you do you get drivers trying to link
> train and at best this fails and at worst you'll upset the configuration
> of the other driver and piss of the panel enough to need a hard reset
> until it works again.

Yes, so far proxying of the AUX channel is read-only. In those cases
when writing is necessary for setting up the output, I'm adding code
to check if the current content of the DPCD is identical to what's
being written and if so, skip the write. We'll see if this stategy is
sufficient for the drivers to set up their outputs.


> I think the real tricky bit here with vgaswitcheroo is locking, I need to
> take a separate lock at the patches for that.

Locking when switching only the DDC lines is facilitated by the ddc_lock
attribute of struct vgasr_priv. This is all local to vga_switcheroo.c
and contained in patches 5 and 6.

Locking when proxying the AUX channel is facilitated by the hw_mutex
attribute of struct drm_dp_aux. nouveau has its own locking mechanism
contained in drivers/gpu/drm/nouveau/nvkm/subdev/i2c/pad*.c. Thus,
when proxying via nouveau, there are two locking mechanisms at work
(drm_dp_aux hw_mutex as outer lock + pad as inner lock). This is
nothing introduced by this patch set, all existing code.

Locking of access to the struct vgasr_priv is facilitated by the
vgasr_mutex in vga_switcheroo.c. Also existing code.


Best regards,

Lukas

[Regression v4.2] Re: [PATCH 7/9] drm/radeon: add VCE 1.0 support v4

[Christian König]

On 13.08.2015 08:36, Lucas Stach wrote:
> Am Donnerstag, den 13.08.2015, 15:18 +0900 schrieb Michel Dänzer:
>> On 13.08.2015 15:03, Lucas Stach wrote:
>>> Hi Christian,
>>>
>>> this commit is causing a boot regression with v4.2-rcX on my Richland
>>> APU (CHIP_ARUBA) based laptop. I didn't have time yet to track down
>>> where exactly it is going wrong, but I bisected it down to this single
>>> commit.
>>>
>>> I don't have the VCE firmware installed on this system, so from a quick
>>> look at the code I would expect it to drop out pretty early and just
>>> leave the VCE unconfigured, but otherwise keep things working as before.
>>> This is unfortunately not the case.
>> If the radeon driver is built into the kernel (or loaded from the
>> initrd?), the attempt to load the firmware might take a long time to
>> time out.
>>
> Gah. Thanks, I was too impatient to wait for the firmware loading to
> time out. In fact this is a standard Fedora kernel config, so radeon is
> a module, but it is built into the initrd.
>
> So it's not really readeons fault, but one more iteration of the fact
> that anything involving firmware loading is just horribly inconvenient.
> Especially if it's firmware for an optional component.

Yeah, exactly. The timeout for loading the firmware is really long on 
both the standard Fedora as well as Ubuntu kernels. Not sure if that's 
the default or just their configuration.

While it doesn't have the highest priority for us I usually still do 
tests if working without firmware still works once or twice during the 
upstreaming process. So if you really find that the box doesn't work 
without the firmware leave me a note and I will fix it.

Best regards,
Christian.

>
> Regards,
> Lucas
>

[PATCH v2 07/22] Revert "vga_switcheroo: Add helper function to get the active client"

[Daniel Vetter]

On Wed, Aug 12, 2015 at 07:34:32PM +0200, Lukas Wunner wrote:
> Hi Daniel,
> 
> thanks for taking a look at the patch set.
> 
> On Wed, Aug 12, 2015 at 04:25:52PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 21, 2015 at 10:39:45AM +0200, Lukas Wunner wrote:
> > > This reverts commit 26814ce68904c9faf977c90edac798156311981f.
> > > 
> > > The helper function is no longer needed after Dave Airlie's rewrite
> > > of vga_switcheroo_switch_ddc(), the commit introducing it was only
> > > included because 31f23c3d488e ("drm/edid: Switch DDC when reading
> > > the EDID") does not compile without it.
> [...]
> > > --- a/drivers/gpu/vga/vga_switcheroo.c
> > > +++ b/drivers/gpu/vga/vga_switcheroo.c
> > > @@ -214,20 +214,6 @@ find_active_client(struct list_head *head)
> > >   return NULL;
> > >  }
> > >  
> > > -struct pci_dev *vga_switcheroo_get_active_client(void)
> > > -{
> > > - struct vga_switcheroo_client *client;
> > > - struct pci_dev *pdev = NULL;
> > > -
> > > - mutex_lock(_mutex);
> > > - client = find_active_client(_priv.clients);
> > > - if (client)
> > > - pdev = client->pdev;
> > > - mutex_unlock(_mutex);
> > > - return pdev;
> > > -}
> > > -EXPORT_SYMBOL(vga_switcheroo_get_active_client);
> > 
> > you just added this earlier in this very series. Please reorder/squash
> > patches so that this isn't required.
> 
> I would have to squash patches 2, 4 (by Seth Forshee), 5 (by Dave Airlie),
> 6 and 7 (mine). The work of two of these authors would only be acknowledged
> in the commit message and the history how the code evolved over the course
> of 3 years would not be reflected in the git repo.
> 
> Are you sure? (y/n)

Yes just squash and mention that the patch is based on work from
$list_of_other_authors, plus cc them. There's not much point in
acknowledging when people write broken patches ;-)

> I deliberately didn't squash to preserve authorship and history but if
> you're forcing me at point blank I'll do it. ;-)
> 
> Context: Seth Forshee of Canonical came up with patches in 2012 which Dave
> Airlie didn't like. He rewrote them and left them as a WIP in his git repo
> where I picked them up. Matthew Garrett posted patches of his own last year
> but since they were based on Seth Forshee's code, they didn't get merged
> either.
> 
> The first MacBooks with dual GPUs were introduced 2008, it's 2015 now and
> we're still missing support in the mainline kernel. The issue is not so
> much that GPU switching doesn't work (the screen just turns black) but
> energy consumption because the discrete GPU is used by default and the
> integrated GPU isn't turned off.
> 
> So, machines with huge marketshare + shoddy dual GPU support for years
> = problem.
> 
> We need to fix this, hence the patch set.

Apparently not a lot of people bothered yet to polish this, so it can't be
that bad. I guess everyone just buys the basic model with intel only.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

vmwgfx GL3 and other -next (4.3) pathches

[Daniel Vetter]

On Wed, Aug 12, 2015 at 08:31:09PM +0200, Thomas Hellstrom wrote:
> Hi, all,
> 
> I've pushed the current upcoming vmwgfx patches for 4.3 into
> 
> git://people.freedesktop.org/~thomash/linux
> branch vmwgfx-next for review.
> 
> There are quite a few patches so I figured that this would be easier
> than posting all patches on the mailing list.
> The patches are all internally reviewed, either by me, Sinclair Yeh,
> Brian Paul or Charmaine Lee.
> 
> The patchset basically enables the following
> - Screen targets - Use of a new device API for scanout buffers
> - Command buffers - A device command buffer queue replacing the old ring
> fifo.
> - GL3 - support for a new device functionality called "DX" that enables
> us to support GL3. Mesa gallium driver support for GL3 is about to be
> published. The patches for DX support have been heavily squashed.
> 
> Please let me know if anybody has any objections against this.

Out of curiosity I did take a (very) quick look and also tried to find the
corresponding userspace parts. On a quick search I didn't find anything
for libdrm or mesa, neither on mailing lists or already committed. Where
are those pieces?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

vmwgfx GL3 and other -next (4.3) pathches

[Daniel Vetter]

On Wed, Aug 12, 2015 at 08:31:09PM +0200, Thomas Hellstrom wrote:
> Hi, all,
> 
> I've pushed the current upcoming vmwgfx patches for 4.3 into
> 
> git://people.freedesktop.org/~thomash/linux
> branch vmwgfx-next for review.
> 
> There are quite a few patches so I figured that this would be easier
> than posting all patches on the mailing list.
> The patches are all internally reviewed, either by me, Sinclair Yeh,
> Brian Paul or Charmaine Lee.
> 
> The patchset basically enables the following
> - Screen targets - Use of a new device API for scanout buffers
> - Command buffers - A device command buffer queue replacing the old ring
> fifo.
> - GL3 - support for a new device functionality called "DX" that enables
> us to support GL3. Mesa gallium driver support for GL3 is about to be
> published. The patches for DX support have been heavily squashed.
> 
> Please let me know if anybody has any objections against this.

Just submit it to dri-devel, it's really not that much compared to other
big patch series here ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch