[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing

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

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

--- Comment #100 from John Frei  ---
Unfortunately the new ucode (hawaii_k_smc.bin) file doesn't work for me.

I don't know if it does matter but as I tried to install a Hackintosh system
recently I expericenced EXACTLY the same symptom(black screen, unresponsive
system) after a couple of minutes.

One could argue that it's a complete different setup but it is the fact that if
I disable the GraphicsEnabler then the black screen issue vanishes.
So maybe one can assume that the dpm (via hardware) is corrupt.

Is it possible to try (experimentally) the new amdgpu-pro driver for r9 390 on
Ubuntu 16.04?
Or can we expect to receive the same issue as the all-open stack, either way?

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

[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards

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

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

--- Comment #8 from Chris Bainbridge  ---
> As far as I understand; 3.15.0-rc2-00077-g76e7745 is a later revision (good)
> than 3.15.0-rc2-00069-g1aae31c (bad)

This is not correct. The 77/69 does not imply a linear ordering because of
forks:

$ git merge-base --is-ancestor 3.15.0-rc2-00069-g1aae31c
3.15.0-rc2-00077-g76e7745; echo $?
1

Trust git ;-)

> c2fb3094669a3205f16a32f4119d0afe40b1a1fd is the first bad commit

Not familiar with this code, but from the patch the PLL values are printed out:

 DRM_DEBUG_KMS("%d - %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
  freq, *dot_clock_p * 10, *fb_div_p, *frac_fb_div_p,
  ref_div, post_div);

So suggest enabling debug log and compare those two lines from a working and
non-working kernel.

It should also be trivial to checkout a recent tag and revert the bad commit
(there is a conflict but just delete the avivo_get_fb_ref_div function to
resolve it).

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

[PATCH RESEND v3 2/2] drm/fsl-dcu: use bus_flags for pixel clock polarity

[Stefan Agner]

The drivers current default configuration drives the pixel data
on rising edge of the pixel clock. However, most display sample
data on rising edge... This leads to color shift artefacts visible
especially at edges.

This patch changes the relevant defines to be useful and actually
set the bits, and changes pixel clock polarity to drive the pixel
data on falling edge by default. The patch also adds an explicit
pixel clock polarity flag to the display introduced with the driver
(NEC WQVGA "nec,nl4827hc19-05b") using the new bus_flags field to
retain the initial behavior.

Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 5 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 4 ++--
 drivers/gpu/drm/panel/panel-simple.c   | 3 ++-
 3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
index 365809e..89c0084 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c
@@ -66,6 +66,7 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
 {
struct drm_device *dev = crtc->dev;
struct fsl_dcu_drm_device *fsl_dev = dev->dev_private;
+   struct drm_connector *con = _dev->connector.base;
struct drm_display_mode *mode = >state->mode;
unsigned int hbp, hfp, hsw, vbp, vfp, vsw, index, pol = 0;

@@ -80,6 +81,10 @@ static void fsl_dcu_drm_crtc_mode_set_nofb(struct drm_crtc 
*crtc)
vfp = mode->vsync_start - mode->vdisplay;
vsw = mode->vsync_end - mode->vsync_start;

+   /* INV_PXCK as default (most display sample data on rising edge) */
+   if (!(con->display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_POSEDGE))
+   pol |= DCU_SYN_POL_INV_PXCK;
+
if (mode->flags & DRM_MODE_FLAG_NHSYNC)
pol |= DCU_SYN_POL_INV_HS_LOW;

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index 5bb7c26..c275f90 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -47,8 +47,8 @@
 #define DCU_VSYN_PARA_FP(x)(x)

 #define DCU_SYN_POL0x0024
-#define DCU_SYN_POL_INV_PXCK_FALL  (0 << 6)
-#define DCU_SYN_POL_NEG_REMAIN (0 << 5)
+#define DCU_SYN_POL_INV_PXCK   BIT(6)
+#define DCU_SYN_POL_NEGBIT(5)
 #define DCU_SYN_POL_INV_VS_LOW BIT(1)
 #define DCU_SYN_POL_INV_HS_LOW BIT(0)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 77ae07f..b19c88f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1053,7 +1053,8 @@ static const struct panel_desc nec_nl4827hc19_05b = {
.width = 95,
.height = 54,
},
-   .bus_format = MEDIA_BUS_FMT_RGB888_1X24
+   .bus_format = MEDIA_BUS_FMT_RGB888_1X24,
+   .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
 };

 static const struct display_timing okaya_rs800480t_7x0gp_timing = {
-- 
2.8.2

[PATCH RESEND v3 1/2] drm: introduce bus_flags in drm_display_info

[Stefan Agner]

Introduce bus_flags to specify display bus properties like signal
polarities. This is useful for parallel display buses, e.g. to
specify the pixel clock or data enable polarity.

Suggested-by: Thierry Reding 
Acked-by: Philipp Zabel 
Acked-by: Manfred Schlaegl 
Acked-by: Daniel Vetter 
Signed-off-by: Stefan Agner 
---
 drivers/gpu/drm/panel/panel-simple.c | 2 ++
 include/drm/drm_crtc.h   | 9 +
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index ceb2048..77ae07f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -72,6 +72,7 @@ struct panel_desc {
} delay;

u32 bus_format;
+   u32 bus_flags;
 };

 struct panel_simple {
@@ -144,6 +145,7 @@ static int panel_simple_get_fixed_modes(struct panel_simple 
*panel)
if (panel->desc->bus_format)
drm_display_info_set_bus_formats(>display_info,
 >desc->bus_format, 1);
+   connector->display_info.bus_flags = panel->desc->bus_flags;

return num;
 }
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4acdaf5..d1559cd 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -118,6 +118,14 @@ enum subpixel_order {
 #define DRM_COLOR_FORMAT_RGB444(1<<0)
 #define DRM_COLOR_FORMAT_YCRCB444  (1<<1)
 #define DRM_COLOR_FORMAT_YCRCB422  (1<<2)
+
+#define DRM_BUS_FLAG_DE_LOW(1<<0)
+#define DRM_BUS_FLAG_DE_HIGH   (1<<1)
+/* drive data on pos. edge */
+#define DRM_BUS_FLAG_PIXDATA_POSEDGE   (1<<2)
+/* drive data on neg. edge */
+#define DRM_BUS_FLAG_PIXDATA_NEGEDGE   (1<<3)
+
 /*
  * Describes a given display (e.g. CRT or flat panel) and its limitations.
  */
@@ -139,6 +147,7 @@ struct drm_display_info {

const u32 *bus_formats;
unsigned int num_bus_formats;
+   u32 bus_flags;

/* Mask of supported hdmi deep color modes */
u8 edid_hdmi_dc_modes;
-- 
2.8.2

[PATCH RESEND v3 0/2] drm: introduce bus_flags for pixel clock polarity

[Stefan Agner]

This resend is just rebased on drm-next as of today (+Daniels Ack).

Dropped the first patch in version 3 since that is already applied
in v4.6. Also moved all generic changes (including the changes in
panel-simple) to the first, generic patch.

Instead of using struct drm_display_mode to convey the pixel clock
polarity information, this patchset introduces a new field called
bus_flags stored in struct drm_display_info.

--
Stefan

Changes since v2:
- Rebased to v4.6 and dropped ("drm/fsl-dcu: use mode flags for hsync/vsync
  polarity"), already part of v4.6-rc1
- Moved all generic changes to the first commit

Changes since v1:
- Introduce bus_flags to convey the pixel clock polarity from
  panel-simple.c to the driver.

Stefan Agner (2):
  drm: introduce bus_flags in drm_display_info
  drm/fsl-dcu: use bus_flags for pixel clock polarity

 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_crtc.c | 5 +
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h  | 4 ++--
 drivers/gpu/drm/panel/panel-simple.c   | 5 -
 include/drm/drm_crtc.h | 9 +
 4 files changed, 20 insertions(+), 3 deletions(-)

-- 
2.8.2

[Bug 94900] HD6950 GPU lockup with various steam games (octodad, saints row 4)

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

 puchatek.local kernel: CPU: 1 PID: 1301 Comm: Xorg Not tainted
4.6.0-0.rc6.git0.1.fc25.x86_64 #1
maj 04 22:54:39 puchatek.local kernel: Hardware name: Gigabyte Technology Co.,
Ltd. To be filled by O.E.M./P67X-UD3-B3, BIOS U1b 03/13/2013
maj 04 22:54:39 puchatek.local kernel: task: 880600c19e80 ti:
8805f1264000 task.ti: 8805f1264000
maj 04 22:54:39 puchatek.local kernel: RIP: 0010:[] 
[] radeon_ring_backup+0xd1/0x160 [radeon]
maj 04 22:54:39 puchatek.local kernel: RSP: 0018:8805f1267c30  EFLAGS:
00010202
maj 04 22:54:39 puchatek.local kernel: RAX: c90003ab9000 RBX:
 RCX: 
maj 04 22:54:39 puchatek.local kernel: RDX:  RSI:
c90403688ffc RDI: 000bec80
maj 04 22:54:39 puchatek.local kernel: RBP: 8805f1267c58 R08:
8805ce164f00 R09: 8163
maj 04 22:54:39 puchatek.local kernel: R10: 81a3ab0b R11:
ea0017622d80 R12: 8805fefc14e0
maj 04 22:54:39 puchatek.local kernel: R13: 0002fb21 R14:
8805fefc14b8 R15: 8805f1267ca0
maj 04 22:54:39 puchatek.local kernel: FS:  7f64ad245a40()
GS:88061ec4() knlGS:
maj 04 22:54:39 puchatek.local kernel: CS:  0010 DS:  ES:  CR0:
80050033
maj 04 22:54:39 puchatek.local kernel: CR2: c90403688ffc CR3:
dd6a3000 CR4: 000406e0
maj 04 22:54:39 puchatek.local kernel: Stack:
maj 04 22:54:39 puchatek.local kernel:  8805fefc 8805fefc14e0
8805f1267ca0 8805fefc14e0
maj 04 22:54:39 puchatek.local kernel:   8805f1267d10
c013cd1d 8805fefc0740
maj 04 22:54:39 puchatek.local kernel:  00ff88060001 8805fefc0018
8806000493c0 8805589e6df0
maj 04 22:54:39 puchatek.local kernel: Call Trace:
maj 04 22:54:39 puchatek.local kernel:  []
radeon_gpu_reset+0xcd/0x330 [radeon]
maj 04 22:54:39 puchatek.local kernel:  [] ?
fence_wait_timeout+0x7d/0x150
maj 04 22:54:39 puchatek.local kernel:  []
radeon_gem_handle_lockup.part.3+0xe/0x20 [radeon]
maj 04 22:54:39 puchatek.local kernel:  []
radeon_gem_wait_idle_ioctl+0xf1/0x150 [radeon]
maj 04 22:54:39 puchatek.local kernel:  []
drm_ioctl+0x152/0x540 [drm]
maj 04 22:54:39 puchatek.local kernel:  [] ?
radeon_gem_busy_ioctl+0x100/0x100 [radeon]
maj 04 22:54:39 puchatek.local kernel:  [] ?
do_futex+0x2c4/0xb10
maj 04 22:54:39 puchatek.local kernel:  []
radeon_drm_ioctl+0x4f/0x90 [radeon]
maj 04 22:54:39 puchatek.local kernel:  []
do_vfs_ioctl+0xa3/0x5d0
maj 04 22:54:39 puchatek.local kernel:  []
SyS_ioctl+0x79/0x90
maj 04 22:54:39 puchatek.local kernel:  []
entry_SYSCALL_64_fastpath+0x1a/0xa4
maj 04 22:54:39 puchatek.local kernel: Code: 0b c1 48 85 c0 49 89 07 74 7d 41
8d 7d ff 31 d2 48 c1 e7 02 eb 07 49 8b 07 48 83 c2 04 49 8b 74 24 08 8d 4b 01
89 db 48 8d 34 9e <8b> 36 89 34 10 41 23 4c 24 54 48 39 d7 89 cb 75 da 4c 89 f7
e8 
maj 04 22:54:39 puchatek.local kernel: RIP  []
radeon_ring_backup+0xd1/0x160 [radeon]
maj 04 22:54:39 puchatek.local kernel:  RSP 
maj 04 22:54:39 puchatek.local kernel: CR2: c90403688ffc
maj 04 22:54:39 puchatek.local kernel: ---[ end trace 73d74f5579095394 ]---
maj 04 22:54:44 puchatek.local kernel: sysrq: SysRq : Emergency Sync

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

[PATCH] drm: sun4i: print DMA address correctly

[Maxime Ripard]

On Tue, May 03, 2016 at 05:23:28PM +0200, Arnd Bergmann wrote:
> The newly added sun4i drm driver prints a dma address using the %x
> format string, which cannot work when dma_addr_t is 64 bit,
> and gcc warns about this configuration:
> 
> drm/sun4i/sun4i_backend.c: In function 'sun4i_backend_update_layer_buffer':
> drm/sun4i/sun4i_backend.c:193:84: error: format '%x' expects argument of type 
> 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned 
> int}' [-Werror=format=]
>   DRM_DEBUG_DRIVER("Using GEM @ 0x%x\n", gem->paddr);
> drm/sun4i/sun4i_backend.c:201:84: error: format '%x' expects argument of type 
> 'unsigned int', but argument 3 has type 'dma_addr_t {aka long long unsigned 
> int}' [-Werror=format=]
>   DRM_DEBUG_DRIVER("Setting buffer address to 0x%x\n", paddr);
> 
> This changes the code to use the explicit %pad format string, which
> always prints the right length.
> 
> Signed-off-by: Arnd Bergmann 

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/459377c2/attachment-0001.sig>

[PATCH] drm/sun4i: add COMMON_CLK dependency

[Maxime Ripard]

Hi,

On Mon, May 02, 2016 at 12:59:48PM +0200, Arnd Bergmann wrote:
> The sun4i drm driver uses the clk-provider interfaces, which are not available
> when CONFIG_COMMON_CLK is disabled:
> 
> drivers/gpu/drm/sun4i/sun4i_dotclock.c:19:16: error: field 'hw' has 
> incomplete type
>   struct clk_hw hw;
> In file included from ../include/asm-generic/bug.h:13:0,
>  from ../arch/arm/include/asm/bug.h:59,
>  from ../include/linux/bug.h:4,
>  from ../include/linux/io.h:23,
>  from ../include/linux/clk-provider.h:14,
>  from ../drivers/gpu/drm/sun4i/sun4i_dotclock.c:13:
> drivers/gpu/drm/sun4i/sun4i_dotclock.c: In function 'hw_to_dclk':
> include/linux/kernel.h:831:48: error: initialization from incompatible 
> pointer type [-Werror=incompatible-pointer-types]
> ...
> 
> This adds a Kconfig dependency to prevent the driver from being enabled
> in this case.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")

Applied, thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/4e0a095f/attachment.sig>

[PATCH v4 00/11] drm: Add Allwinner A10 display engine support

[Maxime Ripard]

he reset_ops const
> 
>   - Reworked the DRM cmdline mode parsing code to allow named mode
>   - Fixed the TV mode lookup when the mode name is not present (for
> example because it was given by the userspace)
> 
>   - Made the driver outputs optional (to avoid crashing when a board
> doesn't have either a panel or a composite output enabled)
>   - Added multiple plane support with transparency
>   - Moved the backend registers writes commit in the CRTC atomic_flush
> callback
>   - Removed the load / unload functions
>   - Removed the enabled booleans in my private structure and removed
> the implicit call to disable_unused_functions in the DRM core to
> push it in the drivers.
>   - Fixed a few bitmasks on some bitfields definition
>   - Fixed the RGB connector mode validation that was not testing the
> right values    

Applied the DT patches.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/797aca40/attachment.sig>

[PATCH v3 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[Sharma, Shashank]

Reviewed-by: Shashank Sharma 

Regards
Shashank
On 5/4/2016 5:15 PM, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> DP dual mode type 1 DVI adaptors aren't required to implement any
> registers, so it's a bit hard to detect them. The best way would
> be to check the state of the CONFIG1 pin, but we have no way to
> do that. So as a last resort, check the VBT to see if the HDMI
> port is in fact a dual mode capable DP port.
>
> v2: Deal with VBT code reorganization
>  Deal with DRM_DP_DUAL_MODE_UNKNOWN
>  Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit
>  Accept both DP and HDMI dvo_port in VBT as my BSW
>  at least declare its DP port as HDMI :(
> v3: Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT (Shashanl)
>
> Cc: stable at vger.kernel.org
> Cc: Tore Anderson 
> Reported-by: Tore Anderson 
> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> Cc: Paulo Zanoni 
> Cc: Shashank Sharma 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>   drivers/gpu/drm/i915/i915_drv.h   |  1 +
>   drivers/gpu/drm/i915/intel_bios.c | 36 
> +++
>   drivers/gpu/drm/i915/intel_hdmi.c | 30 +
>   drivers/gpu/drm/i915/intel_vbt_defs.h | 12 
>   4 files changed, 75 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ff6aaf0c4e1e..abe43922a08f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3489,6 +3489,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t 
> size);
>   bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
>   bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
> *i2c_pin);
>   bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port 
> port);
> +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum 
> port port);
>   bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
> *port);
>   bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
>enum port port);
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 81518116e00d..8b68c4882fba 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1597,6 +1597,42 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
> *dev_priv, enum port port)
>   return false;
>   }
>
> +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum 
> port port)
> +{
> + static const struct {
> + u16 dp, hdmi;
> + } port_mapping[] = {
> + /*
> +  * Buggy VBTs may declare DP ports as having
> +  * HDMI type dvo_port :( So let's check both.
> +  */
> + [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
> + [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
> + [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
> + [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> + };
> + int i;
> +
> + if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> + return false;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + const union child_device_config *p_child =
> + _priv->vbt.child_dev[i];
> +
> + if ((p_child->common.dvo_port == port_mapping[port].dp ||
> +  p_child->common.dvo_port == port_mapping[port].hdmi) &&
> + (p_child->common.device_type & 
> DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> + (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
> + return true;
> + }
> +
> + return false;
> +}
> +
>   /**
>* intel_bios_is_dsi_present - is DSI present in VBT
>* @dev_priv:   i915 device instance
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index c4d93e6b4bed..6b52c6accf6a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1396,16 +1396,38 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
>   }
>
>   static void
> -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
> +intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool 
> has_edid)
>   {
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
>   struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
> + enum port port = hdmi_to_dig_port(hdmi)->port;
>   struct i2c_adapter *adapter =
>   intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
>   enum drm_dp_dual_mode_type type = drm_dp_dual_mode_detect(adapter);
>
> - if (type == DRM_DP_DUAL_MODE_NONE ||
> - type == DRM_DP_DUAL_MODE_UNKNOWN)
> + /*
> +  * Type 1 DVI adaptors 

[PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[Sharma, Shashank]

On 5/4/2016 5:19 PM, Ville Syrjälä wrote:
> On Wed, May 04, 2016 at 03:43:30PM +0530, Sharma, Shashank wrote:
>>
>> On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote:
>>> From: Ville Syrjälä 
>>>
>>> To save a bit of power, let's try to turn off the TMDS output buffers
>>> in DP++ adaptors when we're not driving the port.
>>>
>>> v2: Let's not forget DDI, toss in a debug message while at it
>>> v3: Just do the TMDS output control based on adaptor type. With the
>>>   helper getting passed the type, we wouldn't actually have to
>>>   check at all in the driver, but the check eliminates the debug
>>>   output more honest
>>>
>>> Cc: stable at vger.kernel.org
>>> Cc: Tore Anderson 
>>> Cc: Paulo Zanoni 
>>> Cc: Shashank Sharma 
>>> Cc: Daniel Vetter 
>>> Signed-off-by: Ville Syrjälä 
>>> ---
>>>drivers/gpu/drm/i915/intel_ddi.c  | 12 
>>>drivers/gpu/drm/i915/intel_drv.h  |  1 +
>>>drivers/gpu/drm/i915/intel_hdmi.c | 20 
>>>3 files changed, 33 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
>>> b/drivers/gpu/drm/i915/intel_ddi.c
>>> index 422ec81ef59b..a3600704e6d4 100644
>>> --- a/drivers/gpu/drm/i915/intel_ddi.c
>>> +++ b/drivers/gpu/drm/i915/intel_ddi.c
>>> @@ -1601,6 +1601,12 @@ static void intel_ddi_pre_enable(struct 
>>> intel_encoder *intel_encoder)
>>> enum port port = intel_ddi_get_encoder_port(intel_encoder);
>>> int type = intel_encoder->type;
>>>
>>> +   if (type == INTEL_OUTPUT_HDMI) {
>> how to handle type2 active adapters here, which can show type = DP ?
>
> The dual mode concept shouldn't apply to active adapters. Those, as you
> say, appear as DP and so will be handled as if they were native DP sinks
> more or less.
>
> Or are you aware of active DP dongles that also implement the dual mode
> standatd? Apart from LSPCON of course. Actually I'm not sure how LSPCON
> will handle this. If we drive it in PCON mode, would it still respect
> the dual mode register settings, including the TMDS OE# state?
>
I cross checked LSPCON specs, it respects TMDS_OE (0x80, 0x20) register 
only in LS mode (like stype 2 adapter), by putting it in low power 
state. So I guess you are right, we have to handle LSPCON separately, 
based on if it's in LS mode or PCON mode.  May be while re-basing LSPCON 
layer on top of this new series, I can think of this.

Reviewed-by: Shashank Sharma 

Regards
Shashank
>>> +   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
>>> +
>>> +   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
>>> +   }
>>> +
>>> intel_prepare_ddi_buffer(intel_encoder);
>>>
>>> if (type == INTEL_OUTPUT_EDP) {
>>> @@ -1667,6 +1673,12 @@ static void intel_ddi_post_disable(struct 
>>> intel_encoder *intel_encoder)
>>> DPLL_CTRL2_DDI_CLK_OFF(port)));
>>> else if (INTEL_INFO(dev)->gen < 9)
>>> I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
>>> +
>>> +   if (type == INTEL_OUTPUT_HDMI) {
>> Same as above.
>>
>> Regards
>> Shashank
>>> +   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
>>> +
>>> +   intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
>>> +   }
>>>}
>>>
>>>static void intel_enable_ddi(struct intel_encoder *intel_encoder)
>>> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
>>> b/drivers/gpu/drm/i915/intel_drv.h
>>> index e94d18fb2ff1..dbcb80c70e2e 100644
>>> --- a/drivers/gpu/drm/i915/intel_drv.h
>>> +++ b/drivers/gpu/drm/i915/intel_drv.h
>>> @@ -1419,6 +1419,7 @@ void intel_hdmi_init_connector(struct 
>>> intel_digital_port *intel_dig_port,
>>>struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
>>>bool intel_hdmi_compute_config(struct intel_encoder *encoder,
>>>struct intel_crtc_state *pipe_config);
>>> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool 
>>> enable);
>>>
>>>
>>>/* intel_lvds.c */
>>> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
>>> b/drivers/gpu/drm/i915/intel_hdmi.c
>>> index 31ca11134294..c4d93e6b4bed 100644
>>> --- a/drivers/gpu/drm/i915/intel_hdmi.c
>>> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
>>> @@ -836,6 +836,22 @@ static void hsw_set_infoframes(struct drm_encoder 
>>> *encoder,
>>> intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
>>>}
>>>
>>> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool 
>>> enable)
>>> +{
>>> +   struct drm_i915_private *dev_priv = to_i915(intel_hdmi_to_dev(hdmi));
>>> +   struct i2c_adapter *adapter =
>>> +   intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
>>> +
>>> +   if (hdmi->dp_dual_mode.type < DRM_DP_DUAL_MODE_TYPE2_DVI)
>>> +   return;
>>> +
>>> +   DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS output\n",
>>> + enable ? "Enabling" : "Disabling");
>>> +
>>> +   drm_dp_dual_mode_set_tmds_output(hdmi->dp_dual_mode.type,
>>> +

[PATCH 2/3] drm/fb_helper: Fix references to dev->mode_config.num_connector

[Daniel Vetter]

On Wed, May 04, 2016 at 11:28:52AM -0400, Lyude wrote:
> During boot, MST hotplugs are generally expected (even if no physical
> hotplugging occurs) and result in DRM's connector topology changing.
> This means that using num_connector from the current mode configuration
> can lead to the number of connectors changing under us. This can lead to
> some nasty scenarios in fbcon:
> 
> - We allocate an array to the size of dev->mode_config.num_connectors.
> - MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
> - We try to loop through each element in the array using the new value
>   of dev->mode_config.num_connectors, and end up going out of bounds
>   since dev->mode_config.num_connectors is now larger then the array we
>   allocated.
> 
> fb_helper->connector_count however, will always remain consistent while
> we do a modeset in fb_helper.
> 
> Cc: stable at vger.kernel.org
> Signed-off-by: Lyude 

Ok, this one looks like it's indeed in the same critical section (within
drm_setup_outputs) as where we allocate the fb helper connector array. So
I think this one here is not needed to fix a bug?

Still makes sense as a patch, but not with cc: stable I think.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 855108e..15204c0 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1914,7 +1914,7 @@ static int drm_pick_crtcs(struct drm_fb_helper 
> *fb_helper,
>   if (modes[n] == NULL)
>   return best_score;
>  
> - crtcs = kzalloc(dev->mode_config.num_connector *
> + crtcs = kzalloc(fb_helper->connector_count *
>   sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
>   if (!crtcs)
>   return best_score;
> @@ -1960,7 +1960,7 @@ static int drm_pick_crtcs(struct drm_fb_helper 
> *fb_helper,
>   if (score > best_score) {
>   best_score = score;
>   memcpy(best_crtcs, crtcs,
> -dev->mode_config.num_connector *
> +fb_helper->connector_count *
>  sizeof(struct drm_fb_helper_crtc *));
>   }
>   }
> -- 
> 2.5.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo

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

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

--- Comment #9 from Jani Väinölä  ---
I guess I should leave the bug open so you can investigate why this discrete
card is not running properly in normal mode? (BTW: I noticed now that my card
is an R7 M260X according to the laptop-box).

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

[Bug 117591] amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo

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

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

--- Comment #8 from Jani Väinölä  ---
Yes it did! :) Perfect! Thanks! I have been running the laptop now for an hour
and it is still working great.

Now if I run lspci -vv I get:
04:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT
[Radeon R7 M260/M265] (rev 81)
DeviceName: AMD Radeon (TM) R7 M260
Subsystem: Hewlett-Packard Company Topaz XT [Radeon R7 M260/M265]
Physical Slot: 0-1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: amdgpu
Kernel modules: amdgpu

Which basically means that the system can find it...so if I understand this
correctly (after googling) this command disables the driver power control and
this means that my discrete card is not automatically turned on? That suits me
fine since I don't use it anyway.

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

[PATCH 1/3] drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()

[Daniel Vetter]

On Wed, May 04, 2016 at 11:28:51AM -0400, Lyude wrote:
> During boot time, MST devices usually send a ton of hotplug events
> irregardless of whether or not any physical hotplugs actually occurred.
> Hotplugs mean connectors being created/destroyed, and the number of DRM
> connectors changing under us. This isn't a problem if we use
> fb_helper->connector_count since we only set it once in the code,
> however if we use num_connector from struct drm_mode_config we risk it's
> value changing under us. On top of that, there's even a chance that
> dev->mode_config.num_connector != fb_helper->connector_count. If the
> number of connectors happens to increase under us, we'll end up using
> the wrong array size for memcpy and start writing beyond the actual
> length of the array, occasionally resulting in kernel panics.
> 
> Cc: stable at vger.kernel.org
> Signed-off-by: Lyude 

So at first I thought this is impossible, because we hold the
dev->mode_config.mutex in all relevant places. But we drop it in-between,
so this can indeed race.

> ---
>  drivers/gpu/drm/i915/intel_fbdev.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 97a91e6..c607217 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -366,12 +366,12 @@ static bool intel_fb_initial_config(struct 
> drm_fb_helper *fb_helper,
>   uint64_t conn_configured = 0, mask;
>   int pass = 0;
>  
> - save_enabled = kcalloc(dev->mode_config.num_connector, sizeof(bool),
> + save_enabled = kcalloc(fb_helper->connector_count, sizeof(bool),
>  GFP_KERNEL);
>   if (!save_enabled)
>   return false;
>  
> - memcpy(save_enabled, enabled, dev->mode_config.num_connector);
> + memcpy(save_enabled, enabled, fb_helper->connector_count);

If num_connector < connector_count  this can still go boom. I think we
need to create a local variable

int num_conn = min(..., ...);

and then use that all throughout. Plus a big comment that fbdev setup
drops locks and hence might become inconsistent.
-Daniel

>   mask = (1 << fb_helper->connector_count) - 1;
>  retry:
>   for (i = 0; i < fb_helper->connector_count; i++) {
> @@ -510,7 +510,7 @@ retry:
>   if (fallback) {
>  bail:
>   DRM_DEBUG_KMS("Not using firmware configuration\n");
> - memcpy(enabled, save_enabled, dev->mode_config.num_connector);
> + memcpy(enabled, save_enabled, fb_helper->connector_count);
>   kfree(save_enabled);
>   return false;
>   }
> -- 
> 2.5.5
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Intel-gfx] [PATCH 3/3] drm/fb_helper: Fix a few typos

[Daniel Vetter]

On Wed, May 04, 2016 at 11:28:53AM -0400, Lyude wrote:
> s/modest/modeset/
> s/aftert/after/
> 
> Signed-off-by: Lyude 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/drm_fb_helper.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 15204c0..7778a0e 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -2104,8 +2104,8 @@ out:
>   * cmdline option.
>   *
>   * The other option is to just disable fbdev emulation since very likely the
> - * first modest from userspace will crash in the same way, and is even 
> easier to
> - * debug. This can be done by setting the drm_kms_helper.fbdev_emulation=0
> + * first modeset from userspace will crash in the same way, and is even 
> easier
> + * to debug. This can be done by setting the drm_kms_helper.fbdev_emulation=0
>   * kernel cmdline option.
>   *
>   * RETURNS:
> @@ -2150,7 +2150,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
>   * hotplug interrupt).
>   *
>   * Note that drivers may call this even before calling
> - * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This 
> allows
> + * drm_fb_helper_initial_config but only after drm_fb_helper_init. This 
> allows
>   * for a race-free fbcon setup and will make sure that the fbdev emulation 
> will
>   * not miss any hotplug events.
>   *
> -- 
> 2.5.5
> 
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[PATCH] drm/edid : calculate vsync and hsync from range limits block according to the EDID 1.4

[Jani Nikula]

On Tue, 03 May 2016, Vitaly Prosyak  wrote:
> Do calculation of vsync and hsync from range limits
> EDID block according to the spec. EDID 1.4.
>
> Signed-off-by: Vitaly Prosyak 
> ---
>  drivers/gpu/drm/drm_edid.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 7e49962..601152b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1977,11 +1977,11 @@ mode_in_hsync_range(const struct drm_display_mode 
> *mode,
>   int hsync, hmin, hmax;
>  
>   hmin = t[7];
> - if (edid->revision >= 4)
> - hmin += ((t[4] & 0x04) ? 255 : 0);
> + if (edid->revision >= 4 && ((t[4] & 0x0c) == 0x0c))
> + hmin += 255 ;
>   hmax = t[8];
> - if (edid->revision >= 4)
> - hmax += ((t[4] & 0x08) ? 255 : 0);
> + if (edid->revision >= 4 && (t[4] & 0x08))
> + hmax += 255;
>   hsync = drm_mode_hsync(mode);
>  
>   return (hsync <= hmax && hsync >= hmin);
> @@ -1994,11 +1994,11 @@ mode_in_vsync_range(const struct drm_display_mode 
> *mode,
>   int vsync, vmin, vmax;
>  
>   vmin = t[5];
> - if (edid->revision >= 4)
> - vmin += ((t[4] & 0x01) ? 255 : 0);
> + if (edid->revision >= 4 && ((t[4] & 0x03) == 0x03))
> + vmin += 255;
>   vmax = t[6];
> - if (edid->revision >= 4)
> - vmax += ((t[4] & 0x02) ? 255 : 0);
> + if (edid->revision >= 4 && (t[4] & 0x02))
> + vmax += 255;

Please fix the indentation to use tabs on the lines you change while
you're at it.

BR,
Jani.


>   vsync = drm_mode_vrefresh(mode);
>  
>   return (vsync <= vmax && vsync >= vmin);

-- 
Jani Nikula, Intel Open Source Technology Center

[GIT PULL v3] drm-hisilicon-next for 4.7

[Dave Airlie]

On 29 April 2016 at 18:40, Xinliang Liu  wrote:
> Hi Dave,
>
> v3:
> This driver should only work on arm64 system.
> So add ARM64 depends on to the Kconfig in this commit:
> 23e7b2ab9a8f drm/hisilicon: Add hisilicon kirin drm master driver
>
> The 32-bit system compilation warnings and errors should not be existed.
> Please help to try and let me know if there is any problem.
>
> Thanks,
> -xinliang
>
> The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:
>
>   Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu
> into drm-next (2016-04-29 14:57:51 +1000)
>
> are available in the git repository at:

git pull request seems to have lost the repo?

Dave.

[PATCH] drm: Fix up markup fumble

[Jani Nikula]

On Wed, 04 May 2016, Daniel Vetter  wrote:
> It's & for struct references, not #.
>
> Signed-off-by: Daniel Vetter 
> ---
>  include/drm/drm_modeset_helper_vtables.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h 
> b/include/drm/drm_modeset_helper_vtables.h
> index b61c2d45192e..d4619dc2eecb 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -672,7 +672,7 @@ struct drm_connector_helper_funcs {
>* fixed panel can also manually add specific modes using
>* drm_mode_probed_add(). Drivers which manually add modes should also
>* make sure that the @display_info, @width_mm and @height_mm fields of 
> the
> -  * struct #drm_connector are filled in.
> +  * struct _connector are filled in.

This is all right, but in the future I think we should promote "
foo" over "struct ". Both work now, but the former makes support for
 foo and  foo nicer in kernel-doc.

BR,
Jani.

>*
>* Virtual drivers that just want some standard VESA mode with a given
>* resolution can call drm_add_modes_noedid(), and mark the preferred

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH V3 4/4] soc/tegra: pmc: Register PMC child devices as platform device

[Laxman Dewangan]

Power Management Controller(PMC) of Tegra does the multiple chip
power related functionality for internal and IO interfacing.
Some of the functionalities are power gating of IP blocks, IO pads
voltage and power state configuration, system power state configurations,
wakeup controls etc.

Different functionalities of the PMC are provided through different
framework like IO pads control can be provided through pinctrl framework,
IO power control is via misc driver etc. All sub functionalities are
represented as PMC child devices.

Register the PMC child devices as platform device and fill the child
devices table for Tegra124 and Tegra210.

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
Reworked on DT for having flat entry and register all child devices
as simple platform device instead of of_populate_device().

Changes from V2:
- Handling of the release of child devices on error.
- Register sub devices for T124 and T210 as T124 supports the DPD of IO
  pads.
---
 drivers/soc/tegra/pmc.c | 82 +++--
 1 file changed, 80 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 0611cea..0eb652f 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -132,6 +132,8 @@ struct tegra_pmc_soc {
const u8 *cpu_powergates;
const struct tegra_io_pads_control *io_pads_control;
unsigned int num_io_pads;
+   const char **sub_devs_name;
+   unsigned int num_sub_devs;
bool has_tsense_reset;
bool has_gpu_clamps;
 };
@@ -158,6 +160,7 @@ struct tegra_pmc_soc {
  * @lp0_vec_size: size of the LP0 warm boot code
  * @powergates_available: Bitmap of available power gates
  * @powergates_lock: mutex for power gate register access
+ * @pdevs: Platform device for PMC child devices.
  */
 struct tegra_pmc {
struct device *dev;
@@ -184,6 +187,8 @@ struct tegra_pmc {
DECLARE_BITMAP(powergates_available, TEGRA_POWERGATE_MAX);

struct mutex powergates_lock;
+
+   struct platform_device **pdevs;
 };

 static struct tegra_pmc *pmc = &(struct tegra_pmc) {
@@ -1310,6 +1315,57 @@ out:
of_node_put(np);
 }

+static int  tegra_pmc_init_sub_devs(struct tegra_pmc *pmc)
+{
+   int ret, i;
+
+   if (!pmc->soc->num_sub_devs)
+   return 0;
+
+   pmc->pdevs = devm_kzalloc(pmc->dev, pmc->soc->num_sub_devs *
+ sizeof(**pmc->pdevs), GFP_KERNEL);
+   if (!pmc->pdevs)
+   return -ENOMEM;
+
+   for (i = 0; i < pmc->soc->num_sub_devs; ++i) {
+   pmc->pdevs[i] = platform_device_register_data(pmc->dev,
+   pmc->soc->sub_devs_name[i],
+   0, NULL, 0);
+   if (IS_ERR(pmc->pdevs[i])) {
+   ret = PTR_ERR(pmc->pdevs[i]);
+   dev_err(pmc->dev,
+   "Failed to register platform device for %s: 
%d\n",
+   pmc->soc->sub_devs_name[i], ret);
+   goto pdev_cleanups;
+   }
+   }
+
+   return 0;
+
+pdev_cleanups:
+   while (--i >= 0) {
+   platform_device_unregister(pmc->pdevs[i]);
+   pmc->pdevs[i] = NULL;
+   }
+
+   return ret;
+}
+
+static void tegra_pmc_deinit_sub_devs(struct tegra_pmc *pmc)
+{
+   int i;
+
+   if (!pmc->soc->num_sub_devs || !pmc->pdevs)
+   return;
+
+   for (i = 0; i < pmc->soc->num_sub_devs; ++i) {
+   if (pmc->pdevs[i]) {
+   platform_device_unregister(pmc->pdevs[i]);
+   pmc->pdevs[i] = NULL;
+   }
+   }
+}
+
 static int tegra_pmc_probe(struct platform_device *pdev)
 {
void __iomem *base;
@@ -1339,10 +1395,14 @@ static int tegra_pmc_probe(struct platform_device *pdev)

tegra_pmc_init_tsense_reset(pmc);

+   err = tegra_pmc_init_sub_devs(pmc);
+   if (err < 0)
+   dev_warn(pmc->dev, "Failed to register sub devices: %d\n", err);
+
if (IS_ENABLED(CONFIG_DEBUG_FS)) {
err = tegra_powergate_debugfs_init();
if (err < 0)
-   return err;
+   goto cleanups;
}

err = register_restart_handler(_pmc_restart_handler);
@@ -1350,7 +1410,7 @@ static int tegra_pmc_probe(struct platform_device *pdev)
debugfs_remove(pmc->debugfs);
dev_err(>dev, "unable to register restart handler, %d\n",
err);
-   return err;
+   goto cleanups;
}

tegra_powergate_init(pmc);
@@ -1361,6 +1421,11 @@ static int tegra_pmc_probe(struct platform_device *pdev)
mutex_unlock(>powergates_lock);

return 0;
+
+cleanups:
+   tegra_pmc_deinit_sub_devs(pmc);
+
+   return err;
 }

 #if defined(CONFIG_PM_SLEEP) && 

[PATCH V3 3/4] soc/tegra: pmc: Add support for IO pads power state and voltage

[Laxman Dewangan]

The IO pins of Tegra SoCs are grouped for common control of IO
interface like setting voltage signal levels and power state of
the interface. The group is generally referred as IO pads. The
power state and voltage control of IO pins can be done at IO pads
level.

Tegra generation SoC supports the power down of IO pads when it
is not used even in the active state of system. This saves power
from that IO interface. Also it supports multiple voltage level
in IO pins for interfacing on some of pads. The IO pad voltage is
automatically detected till T124, hence SW need not to configure
this. But from T210, the automatically detection logic has been
removed, hence SW need to explicitly set the IO pad voltage into
IO pad configuration registers.

Add support to set the power states and voltage level of the IO pads
from client driver. The implementation for the APIs are in generic
which is applicable for all generation os Tegra SoC.

IO pads ID and information of bit field for power state and voltage
level controls are added for Tegra124, Tegra132 and Tegra210. The sor
driver is modified to use the new APIs.

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
This is reworked on earlier path to have separation between IO rails and
io pads and add power state and voltage control APIs in single call.

Changes from V2:
- Remove the tegra_io_rail_power_off/on() apis and change client (sor) driver
to use the new APIs for IO pad power.
- Remove the TEGRA_IO_RAIL_ macros.
---
 drivers/gpu/drm/tegra/sor.c |   8 +-
 drivers/soc/tegra/pmc.c | 242 +++-
 include/soc/tegra/pmc.h | 116 ++---
 3 files changed, 299 insertions(+), 67 deletions(-)

diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 757c6e8..1d90171 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -1134,7 +1134,7 @@ static void tegra_sor_edp_disable(struct drm_encoder 
*encoder)
dev_err(sor->dev, "failed to disable DP: %d\n", err);
}

-   err = tegra_io_rail_power_off(TEGRA_IO_RAIL_LVDS);
+   err = tegra_io_pads_power_disable(TEGRA_IO_PAD_LVDS);
if (err < 0)
dev_err(sor->dev, "failed to power off I/O rail: %d\n", err);

@@ -1296,7 +1296,7 @@ static void tegra_sor_edp_enable(struct drm_encoder 
*encoder)
tegra_sor_writel(sor, value, SOR_DP_PADCTL0);

/* step 2 */
-   err = tegra_io_rail_power_on(TEGRA_IO_RAIL_LVDS);
+   err = tegra_io_pads_power_enable(TEGRA_IO_PAD_LVDS);
if (err < 0)
dev_err(sor->dev, "failed to power on I/O rail: %d\n", err);

@@ -1748,7 +1748,7 @@ static void tegra_sor_hdmi_disable(struct drm_encoder 
*encoder)
if (err < 0)
dev_err(sor->dev, "failed to power down SOR: %d\n", err);

-   err = tegra_io_rail_power_off(TEGRA_IO_RAIL_HDMI);
+   err = tegra_io_pads_power_disable(TEGRA_IO_PAD_HDMI);
if (err < 0)
dev_err(sor->dev, "failed to power off HDMI rail: %d\n", err);

@@ -1787,7 +1787,7 @@ static void tegra_sor_hdmi_enable(struct drm_encoder 
*encoder)

div = clk_get_rate(sor->clk) / 100 * 4;

-   err = tegra_io_rail_power_on(TEGRA_IO_RAIL_HDMI);
+   err = tegra_io_pads_power_enable(TEGRA_IO_PAD_HDMI);
if (err < 0)
dev_err(sor->dev, "failed to power on HDMI rail: %d\n", err);

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index eff9425..0611cea 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -76,6 +76,10 @@

 #define PMC_SCRATCH41  0x140

+/* Power detect for pad voltage */
+#define PMC_PWR_DET0x48
+#define PMC_PWR_DET_VAL0xe4
+
 #define PMC_SENSOR_CTRL0x1b0
 #define PMC_SENSOR_CTRL_SCRATCH_WRITE  BIT(2)
 #define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)
@@ -115,12 +119,19 @@ struct tegra_powergate {
unsigned int num_resets;
 };

+struct tegra_io_pads_control {
+   int pad_id;
+   int dpd_bit_pos;
+   int pwr_bit_pos;
+};
+
 struct tegra_pmc_soc {
unsigned int num_powergates;
const char *const *powergates;
unsigned int num_cpu_powergates;
const u8 *cpu_powergates;
-
+   const struct tegra_io_pads_control *io_pads_control;
+   unsigned int num_io_pads;
bool has_tsense_reset;
bool has_gpu_clamps;
 };
@@ -196,6 +207,14 @@ static void tegra_pmc_writel(u32 value, unsigned long 
offset)
writel(value, pmc->base + offset);
 }

+static void tegra_pmc_read_modify_write(unsigned long offset, u32 mask, u32 
val)
+{
+   u32 pmc_reg = tegra_pmc_readl(offset);
+
+   pmc_reg = (pmc_reg & ~mask) | (val & mask);
+   tegra_pmc_writel(pmc_reg, offset);
+}
+
 static inline bool tegra_powergate_state(int id)
 {
if (id == TEGRA_POWERGATE_3D && pmc->soc->has_gpu_clamps)
@@ -841,22 +860,51 @@ static void 

[PATCH V3 2/4] soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()

[Laxman Dewangan]

The function tegra_pmc_readl() returns the u32 type data and hence
change the data type of variable where this data is stored to u32
type.

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
-This is new in series as per discussion on V1 series to use u32 for
tegra_pmc_readl.

Changes from V2:
- Make unsigned long to u32 for some missed variable from V1.
---
 drivers/soc/tegra/pmc.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index 2c3f1f9..eff9425 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -844,7 +844,8 @@ static void tegra_powergate_init(struct tegra_pmc *pmc)
 static int tegra_io_rail_prepare(unsigned int id, unsigned long *request,
 unsigned long *status, unsigned int *bit)
 {
-   unsigned long rate, value;
+   unsigned long rate;
+   u32 value;

*bit = id % 32;

@@ -868,17 +869,18 @@ static int tegra_io_rail_prepare(unsigned int id, 
unsigned long *request,
tegra_pmc_writel(DPD_SAMPLE_ENABLE, DPD_SAMPLE);

/* must be at least 200 ns, in APB (PCLK) clock cycles */
-   value = DIV_ROUND_UP(10, rate);
-   value = DIV_ROUND_UP(200, value);
+   rate = DIV_ROUND_UP(10, rate);
+   rate = DIV_ROUND_UP(200, rate);
+   value = (u32)rate;
tegra_pmc_writel(value, SEL_DPD_TIM);

return 0;
 }

-static int tegra_io_rail_poll(unsigned long offset, unsigned long mask,
- unsigned long val, unsigned long timeout)
+static int tegra_io_rail_poll(unsigned long offset, u32 mask,
+ u32 val, unsigned long timeout)
 {
-   unsigned long value;
+   u32 value;

timeout = jiffies + msecs_to_jiffies(timeout);

@@ -900,8 +902,9 @@ static void tegra_io_rail_unprepare(void)

 int tegra_io_rail_power_on(unsigned int id)
 {
-   unsigned long request, status, value;
-   unsigned int bit, mask;
+   unsigned long request, status;
+   unsigned int bit;
+   u32 value, mask;
int err;

mutex_lock(>powergates_lock);
@@ -935,8 +938,9 @@ EXPORT_SYMBOL(tegra_io_rail_power_on);

 int tegra_io_rail_power_off(unsigned int id)
 {
-   unsigned long request, status, value;
-   unsigned int bit, mask;
+   unsigned long request, status;
+   unsigned int bit;
+   u32 value, mask;
int err;

mutex_lock(>powergates_lock);
-- 
2.1.4

[PATCH V3 1/4] soc/tegra: pmc: Use BIT macro for register field definition

[Laxman Dewangan]

Use BIT macro for register field definition and make constant as U
when using in shift operator like (3 << 30) to (3U << 30)

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
- Remove the indenting of line which is not for BIT macro usage.
Changes from V2:
- None
---
 drivers/soc/tegra/pmc.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/soc/tegra/pmc.c b/drivers/soc/tegra/pmc.c
index bb17345..2c3f1f9 100644
--- a/drivers/soc/tegra/pmc.c
+++ b/drivers/soc/tegra/pmc.c
@@ -45,28 +45,28 @@
 #include 

 #define PMC_CNTRL  0x0
-#define  PMC_CNTRL_SYSCLK_POLARITY (1 << 10)  /* sys clk polarity */
-#define  PMC_CNTRL_SYSCLK_OE   (1 << 11)  /* system clock enable */
-#define  PMC_CNTRL_SIDE_EFFECT_LP0 (1 << 14)  /* LP0 when CPU pwr gated */
-#define  PMC_CNTRL_CPU_PWRREQ_POLARITY (1 << 15)  /* CPU pwr req polarity */
-#define  PMC_CNTRL_CPU_PWRREQ_OE   (1 << 16)  /* CPU pwr req enable */
-#define  PMC_CNTRL_INTR_POLARITY   (1 << 17)  /* inverts INTR polarity */
+#define PMC_CNTRL_SYSCLK_POLARITY  BIT(10) /* sys clk polarity */
+#define PMC_CNTRL_SYSCLK_OEBIT(11) /* system clock enable */
+#define PMC_CNTRL_SIDE_EFFECT_LP0  BIT(14) /* LP0 when CPU pwr gated */
+#define PMC_CNTRL_CPU_PWRREQ_POLARITY  BIT(15) /* CPU pwr req polarity */
+#define PMC_CNTRL_CPU_PWRREQ_OEBIT(16) /* CPU pwr req enable */
+#define PMC_CNTRL_INTR_POLARITYBIT(17)/* inverts INTR polarity 
*/

 #define DPD_SAMPLE 0x020
-#define  DPD_SAMPLE_ENABLE (1 << 0)
-#define  DPD_SAMPLE_DISABLE(0 << 0)
+#define DPD_SAMPLE_ENABLE  BIT(0)
+#define DPD_SAMPLE_DISABLE (0 << 0)

 #define PWRGATE_TOGGLE 0x30
-#define  PWRGATE_TOGGLE_START  (1 << 8)
+#define PWRGATE_TOGGLE_START   BIT(8)

 #define REMOVE_CLAMPING0x34

 #define PWRGATE_STATUS 0x38

 #define PMC_SCRATCH0   0x50
-#define  PMC_SCRATCH0_MODE_RECOVERY(1 << 31)
-#define  PMC_SCRATCH0_MODE_BOOTLOADER  (1 << 30)
-#define  PMC_SCRATCH0_MODE_RCM (1 << 1)
+#define PMC_SCRATCH0_MODE_RECOVERY BIT(31)
+#define PMC_SCRATCH0_MODE_BOOTLOADER   BIT(30)
+#define PMC_SCRATCH0_MODE_RCM  BIT(1)
 #define  PMC_SCRATCH0_MODE_MASK(PMC_SCRATCH0_MODE_RECOVERY | \
 PMC_SCRATCH0_MODE_BOOTLOADER | \
 PMC_SCRATCH0_MODE_RCM)
@@ -77,14 +77,14 @@
 #define PMC_SCRATCH41  0x140

 #define PMC_SENSOR_CTRL0x1b0
-#define PMC_SENSOR_CTRL_SCRATCH_WRITE  (1 << 2)
-#define PMC_SENSOR_CTRL_ENABLE_RST (1 << 1)
+#define PMC_SENSOR_CTRL_SCRATCH_WRITE  BIT(2)
+#define PMC_SENSOR_CTRL_ENABLE_RST BIT(1)

 #define IO_DPD_REQ 0x1b8
-#define  IO_DPD_REQ_CODE_IDLE  (0 << 30)
-#define  IO_DPD_REQ_CODE_OFF   (1 << 30)
-#define  IO_DPD_REQ_CODE_ON(2 << 30)
-#define  IO_DPD_REQ_CODE_MASK  (3 << 30)
+#define IO_DPD_REQ_CODE_IDLE   (0 << 30)
+#define IO_DPD_REQ_CODE_OFF(1U << 30)
+#define IO_DPD_REQ_CODE_ON (2U << 30)
+#define IO_DPD_REQ_CODE_MASK   (3U << 30)

 #define IO_DPD_STATUS  0x1bc
 #define IO_DPD2_REQ0x1c0
@@ -96,10 +96,10 @@
 #define PMC_SCRATCH54_ADDR_SHIFT   0

 #define PMC_SCRATCH55  0x25c
-#define PMC_SCRATCH55_RESET_TEGRA  (1 << 31)
+#define PMC_SCRATCH55_RESET_TEGRA  BIT(31)
 #define PMC_SCRATCH55_CNTRL_ID_SHIFT   27
 #define PMC_SCRATCH55_PINMUX_SHIFT 24
-#define PMC_SCRATCH55_16BITOP  (1 << 15)
+#define PMC_SCRATCH55_16BITOP  BIT(15)
 #define PMC_SCRATCH55_CHECKSUM_SHIFT   16
 #define PMC_SCRATCH55_I2CSLV1_SHIFT0

-- 
2.1.4

[PATCH V3 0/4] soc/tegra: Add support for IO pads power and voltage control

[Laxman Dewangan]

The IO pins of Tegra SoCs are grouped for common control of IO interface
like setting voltage signal levels and power state of the interface. The
group is generally referred as IO pads. The power state and voltage control
of IO pins can be done at IO pads level.

Tegra124 onwards IO pads support the power down state when system is
active. The voltage levels on IO pads are auto detected on Tegra124/
Tegra132 but it is not in Tegra210. For Tegra210, the SW need to
explicitly configure the voltage levels of IO pads

This series add the interface for the IO pad power state and voltage
configurations. Modifies the client to use new APIs.
Register the child devices to provide the client interface to configure
IO pads power state and voltage from Device tree.

---
Changes from V2:
- Drop the pinctrl driver from series till pmc interfce is finalise.
- Move client to use the new APIs.
- Remove older APIs to configure IO rail and related macros.

Laxman Dewangan (4):
  soc/tegra: pmc: Use BIT macro for register field definition
  soc/tegra: pmc: Correct type of variable for tegra_pmc_readl()
  soc/tegra: pmc: Add support for IO pads power state and voltage
  soc/tegra: pmc: Register PMC child devices as platform device

 drivers/gpu/drm/tegra/sor.c |   8 +-
 drivers/soc/tegra/pmc.c | 382 +---
 include/soc/tegra/pmc.h | 116 +-
 3 files changed, 410 insertions(+), 96 deletions(-)

-- 
2.1.4

[GIT PULL v3] drm-hisilicon-next for 4.7

[Xinliang Liu]

On 4 May 2016 at 15:24, Dave Airlie  wrote:
> On 29 April 2016 at 18:40, Xinliang Liu  wrote:
>> Hi Dave,
>>
>> v3:
>> This driver should only work on arm64 system.
>> So add ARM64 depends on to the Kconfig in this commit:
>> 23e7b2ab9a8f drm/hisilicon: Add hisilicon kirin drm master driver
>>
>> The 32-bit system compilation warnings and errors should not be existed.
>> Please help to try and let me know if there is any problem.
>>
>> Thanks,
>> -xinliang
>>
>> The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:
>>
>>   Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu
>> into drm-next (2016-04-29 14:57:51 +1000)
>>
>> are available in the git repository at:
>
> git pull request seems to have lost the repo?

Sorry for that. Here it is:

The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:

  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu
into drm-next (2016-04-29 14:57:51 +1000)

are available in the git repository at:

  git at github.com:xin3liang/linux.git tags/drm-hisilicon-next-2016-04-29

for you to fetch changes up to c84ffde963e227bf68efb12315bd39c75e00ff05:

  MAINTAINERS: Add maintainer for hisilicon DRM driver (2016-04-29
16:39:15 +0800)


drm-hisilicon-next for 4.7

Add new hisilicon kirin drm driver:
- Add maintainer for hisilicon DRM driver
- Add support for external bridge
- Add designware dsi host driver
- Add designware dsi encoder driver
- Add cma fbdev and hotplug
- Add vblank driver for ADE
- Add plane driver for ADE
- Add crtc driver for ADE
- Add hisilicon kirin drm master driver
- Add device tree binding for hi6220 display subsystem


Xinliang Liu (10):
  drm/hisilicon: Add device tree binding for hi6220 display subsystem
  drm/hisilicon: Add hisilicon kirin drm master driver
  drm/hisilicon: Add crtc driver for ADE
  drm/hisilicon: Add plane driver for ADE
  drm/hisilicon: Add vblank driver for ADE
  drm/hisilicon: Add cma fbdev and hotplug
  drm/hisilicon: Add designware dsi encoder driver
  drm/hisilicon: Add designware dsi host driver
  drm/hisilicon: Add support for external bridge
  MAINTAINERS: Add maintainer for hisilicon DRM driver

 Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt   |   72 +++
 Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt |   64 +++
 MAINTAINERS  |   10 +
 drivers/gpu/drm/Kconfig  |2 +
 drivers/gpu/drm/Makefile |1 +
 drivers/gpu/drm/hisilicon/Kconfig|5 +
 drivers/gpu/drm/hisilicon/Makefile   |5 +
 drivers/gpu/drm/hisilicon/kirin/Kconfig  |   18 +
 drivers/gpu/drm/hisilicon/kirin/Makefile |6 +
 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c |
857 ++
 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h |  103 
 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h  |
230 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c  |
1057 ++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c  |
367 +++
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h  |   31 ++
 15 files changed, 2828 insertions(+)
 create mode 100644
Documentation/devicetree/bindings/display/hisilicon/dw-dsi.txt
 create mode 100644
Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt
 create mode 100644 drivers/gpu/drm/hisilicon/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Kconfig
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/Makefile
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
 create mode 100644 drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h

>
> Dave.

[PATCH v2 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[Sharma, Shashank]

On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> DP dual mode type 1 DVI adaptors aren't required to implement any
> registers, so it's a bit hard to detect them. The best way would
> be to check the state of the CONFIG1 pin, but we have no way to
> do that. So as a last resort, check the VBT to see if the HDMI
> port is in fact a dual mode capable DP port.
>
> v2: Deal with VBT code reorganization
>  Deal with DRM_DP_DUAL_MODE_UNKNOWN
>  Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit
>  Accept both DP and HDMI dvo_port in VBT as my BSW
>  at least declare its DP port as HDMI :(
>
> Cc: stable at vger.kernel.org
> Cc: Tore Anderson 
> Reported-by: Tore Anderson 
> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> Cc: Paulo Zanoni 
> Cc: Shashank Sharma 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>   drivers/gpu/drm/i915/i915_drv.h   |  1 +
>   drivers/gpu/drm/i915/intel_bios.c | 36 
> +++
>   drivers/gpu/drm/i915/intel_hdmi.c | 30 +
>   drivers/gpu/drm/i915/intel_vbt_defs.h | 13 +
>   4 files changed, 76 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ff6aaf0c4e1e..abe43922a08f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -3489,6 +3489,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t 
> size);
>   bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
>   bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
> *i2c_pin);
>   bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port 
> port);
> +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum 
> port port);
>   bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
> *port);
>   bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
>enum port port);
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 81518116e00d..8b68c4882fba 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1597,6 +1597,42 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
> *dev_priv, enum port port)
>   return false;
>   }
>
> +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum 
> port port)
> +{
> + static const struct {
> + u16 dp, hdmi;
> + } port_mapping[] = {
> + /*
> +  * Buggy VBTs may declare DP ports as having
> +  * HDMI type dvo_port :( So let's check both.
> +  */
> + [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
> + [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
> + [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
> + [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> + };
> + int i;
> +
> + if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> + return false;
> +
> + if (!dev_priv->vbt.child_dev_num)
> + return false;
> +
> + for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> + const union child_device_config *p_child =
> + _priv->vbt.child_dev[i];
> +
> + if ((p_child->common.dvo_port == port_mapping[port].dp ||
> +  p_child->common.dvo_port == port_mapping[port].hdmi) &&
> + (p_child->common.device_type & 
> DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> + (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
> + return true;
> + }
> +
> + return false;
> +}
> +
>   /**
>* intel_bios_is_dsi_present - is DSI present in VBT
>* @dev_priv:   i915 device instance
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index c4d93e6b4bed..6b52c6accf6a 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1396,16 +1396,38 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
>   }
>
>   static void
> -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
> +intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool 
> has_edid)
>   {
>   struct drm_i915_private *dev_priv = to_i915(connector->dev);
>   struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
> + enum port port = hdmi_to_dig_port(hdmi)->port;
>   struct i2c_adapter *adapter =
>   intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
>   enum drm_dp_dual_mode_type type = drm_dp_dual_mode_detect(adapter);
>
> - if (type == DRM_DP_DUAL_MODE_NONE ||
> - type == DRM_DP_DUAL_MODE_UNKNOWN)
> + /*
> +  * Type 1 DVI adaptors are not required to implement any
> +  * registers, so we can't always detect their presence.

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

[Daniel Vetter]

On Wed, May 04, 2016 at 02:24:14PM +0100, Robert Bragg wrote:
> On Wed, May 4, 2016 at 1:24 PM, Daniel Vetter  wrote:
> 
> > On Wed, May 04, 2016 at 10:49:53AM +0100, Robert Bragg wrote:
> > > On Wed, May 4, 2016 at 10:09 AM, Martin Peres <
> > martin.peres at linux.intel.com>
> > > wrote:
> > >
> > > > On 03/05/16 23:03, Robert Bragg wrote:
> > > >
> > > >>
> > > >>
> > > >> On Tue, May 3, 2016 at 8:34 PM, Robert Bragg  > > >> > wrote:
> > > >>
> > > >> Sorry for the delay replying to this, I missed it.
> > > >>
> > > >> On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres <
> > martin.peres at free.fr
> > > >> > wrote:
> > > >>
> > > >> On 20/04/16 17:23, Robert Bragg wrote:
> > > >>
> > > >> Gen graphics hardware can be set up to periodically write
> > > >> snapshots of
> > > >> performance counters into a circular buffer via its
> > > >> Observation
> > > >> Architecture and this patch exposes that capability to
> > > >> userspace via the
> > > >> i915 perf interface.
> > > >>
> > > >> Cc: Chris Wilson  > > >> >
> > > >> Signed-off-by: Robert Bragg  > > >> >
> > > >> Signed-off-by: Zhenyu Wang  > > >> >
> > > >>
> > > >> ---
> > > >>   drivers/gpu/drm/i915/i915_drv.h |  56 +-
> > > >>   drivers/gpu/drm/i915/i915_gem_context.c |  24 +-
> > > >>   drivers/gpu/drm/i915/i915_perf.c| 940
> > > >> +++-
> > > >>   drivers/gpu/drm/i915/i915_reg.h | 338
> > 
> > > >>   include/uapi/drm/i915_drm.h |  70 ++-
> > > >>   5 files changed, 1408 insertions(+), 20 deletions(-)
> > > >>
> > > >> +
> > > >> +
> > > >> +   /* It takes a fairly long time for a new MUX
> > > >> configuration to
> > > >> +* be be applied after these register writes. This
> > > >> delay
> > > >> +* duration was derived empirically based on the
> > > >> render_basic
> > > >> +* config but hopefully it covers the maximum
> > > >> configuration
> > > >> +* latency...
> > > >> +*/
> > > >> +   mdelay(100);
> > > >>
> > > >>
> > > >> With such a HW and SW design, how can we ever expose hope to
> > get
> > > >> any
> > > >> kind of performance when we are trying to monitor different
> > > >> metrics on each
> > > >> draw call? This may be acceptable for system monitoring, but
> > it
> > > >> is problematic
> > > >> for the GL extensions :s
> > > >>
> > > >>
> > > >> Since it seems like we are going for a perf API, it means that
> > > >> for every change
> > > >> of metrics, we need to flush the commands, wait for the GPU to
> > > >> be done, then
> > > >> program the new set of metrics via an IOCTL, wait 100 ms, and
> > > >> then we may
> > > >> resume rendering ... until the next change. We are talking
> > about
> > > >> a latency of
> > > >> 6-7 frames at 60 Hz here... this is non-negligeable...
> > > >>
> > > >>
> > > >> I understand that we have a ton of counters and we may hide
> > > >> latency by not
> > > >> allowing using more than half of the counters for every draw
> > > >> call or frame, but
> > > >> even then, this 100ms delay is killing this approach
> > altogether.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> So revisiting this to double check how things fail with my latest
> > > >> driver/tests without the delay, I apparently can't reproduce test
> > > >> failures without the delay any more...
> > > >>
> > > >> I think the explanation is that since first adding the delay to the
> > > >> driver I also made the the driver a bit more careful to not forward
> > > >> spurious reports that look invalid due to a zeroed report id field,
> > and
> > > >> that mechanism keeps the unit tests happy, even though there are still
> > > >> some number of invalid reports generated if we don't wait.
> > > >>
> > > >> One problem with simply having no delay is that the driver prints an
> > > >> error if it sees an invalid reports so I get a lot of 'Skipping
> > > >> spurious, invalid OA report' dmesg spam. Also this was intended more
> > as
> > > >> a last resort mechanism, and I wouldn't feel too happy about squashing
> > > >> the error message and potentially sweeping other error cases under the
> > > >> carpet.
> > > >>
> > > >> Experimenting to see if the delay can at least be reduced, I brought
> > the
> > > >> 

[PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[Sharma, Shashank]

On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> To save a bit of power, let's try to turn off the TMDS output buffers
> in DP++ adaptors when we're not driving the port.
>
> v2: Let's not forget DDI, toss in a debug message while at it
> v3: Just do the TMDS output control based on adaptor type. With the
>  helper getting passed the type, we wouldn't actually have to
>  check at all in the driver, but the check eliminates the debug
>  output more honest
>
> Cc: stable at vger.kernel.org
> Cc: Tore Anderson 
> Cc: Paulo Zanoni 
> Cc: Shashank Sharma 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>   drivers/gpu/drm/i915/intel_ddi.c  | 12 
>   drivers/gpu/drm/i915/intel_drv.h  |  1 +
>   drivers/gpu/drm/i915/intel_hdmi.c | 20 
>   3 files changed, 33 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 422ec81ef59b..a3600704e6d4 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1601,6 +1601,12 @@ static void intel_ddi_pre_enable(struct intel_encoder 
> *intel_encoder)
>   enum port port = intel_ddi_get_encoder_port(intel_encoder);
>   int type = intel_encoder->type;
>
> + if (type == INTEL_OUTPUT_HDMI) {
how to handle type2 active adapters here, which can show type = DP ?
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> + }
> +
>   intel_prepare_ddi_buffer(intel_encoder);
>
>   if (type == INTEL_OUTPUT_EDP) {
> @@ -1667,6 +1673,12 @@ static void intel_ddi_post_disable(struct 
> intel_encoder *intel_encoder)
>   DPLL_CTRL2_DDI_CLK_OFF(port)));
>   else if (INTEL_INFO(dev)->gen < 9)
>   I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
> +
> + if (type == INTEL_OUTPUT_HDMI) {
Same as above.

Regards
Shashank
> + struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
> + }
>   }
>
>   static void intel_enable_ddi(struct intel_encoder *intel_encoder)
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index e94d18fb2ff1..dbcb80c70e2e 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1419,6 +1419,7 @@ void intel_hdmi_init_connector(struct 
> intel_digital_port *intel_dig_port,
>   struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
>   bool intel_hdmi_compute_config(struct intel_encoder *encoder,
>  struct intel_crtc_state *pipe_config);
> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool 
> enable);
>
>
>   /* intel_lvds.c */
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 31ca11134294..c4d93e6b4bed 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -836,6 +836,22 @@ static void hsw_set_infoframes(struct drm_encoder 
> *encoder,
>   intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
>   }
>
> +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
> +{
> + struct drm_i915_private *dev_priv = to_i915(intel_hdmi_to_dev(hdmi));
> + struct i2c_adapter *adapter =
> + intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
> +
> + if (hdmi->dp_dual_mode.type < DRM_DP_DUAL_MODE_TYPE2_DVI)
> + return;
> +
> + DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS output\n",
> +   enable ? "Enabling" : "Disabling");
> +
> + drm_dp_dual_mode_set_tmds_output(hdmi->dp_dual_mode.type,
> +  adapter, enable);
> +}
> +
>   static void intel_hdmi_prepare(struct intel_encoder *encoder)
>   {
>   struct drm_device *dev = encoder->base.dev;
> @@ -845,6 +861,8 @@ static void intel_hdmi_prepare(struct intel_encoder 
> *encoder)
>   const struct drm_display_mode *adjusted_mode = 
> >config->base.adjusted_mode;
>   u32 hdmi_val;
>
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> +
>   hdmi_val = SDVO_ENCODING_HDMI;
>   if (!HAS_PCH_SPLIT(dev) && crtc->config->limited_color_range)
>   hdmi_val |= HDMI_COLOR_RANGE_16_235;
> @@ -1142,6 +1160,8 @@ static void intel_disable_hdmi(struct intel_encoder 
> *encoder)
>   }
>
>   intel_hdmi->set_infoframes(>base, false, NULL);
> +
> + intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
>   }
>
>   static void g4x_disable_hdmi(struct intel_encoder *encoder)
>

[PATCH] drm: Fix up markup fumble

[Daniel Vetter]

It's & for struct references, not #.

Signed-off-by: Daniel Vetter 
---
 include/drm/drm_modeset_helper_vtables.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/drm/drm_modeset_helper_vtables.h 
b/include/drm/drm_modeset_helper_vtables.h
index b61c2d45192e..d4619dc2eecb 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -672,7 +672,7 @@ struct drm_connector_helper_funcs {
 * fixed panel can also manually add specific modes using
 * drm_mode_probed_add(). Drivers which manually add modes should also
 * make sure that the @display_info, @width_mm and @height_mm fields of 
the
-* struct #drm_connector are filled in.
+* struct _connector are filled in.
 *
 * Virtual drivers that just want some standard VESA mode with a given
 * resolution can call drm_add_modes_noedid(), and mark the preferred
-- 
2.8.1

[PATCH v2 2/4] drm/i915: Respect DP++ adaptor TMDS clock limit

[Sharma, Shashank]

Reviewed-by: Shashank Sharma 

Regards
Shashank
On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrjälä 
>
> Try to detect the max TMDS clock limit for the DP++ adaptor (if any)
> and take it into account when checking the port clock.
>
> Note that as with the sink (HDMI vs. DVI) TMDS clock limit we'll ignore
> the adaptor TMDS clock limit in the modeset path, in case users are
> already "overclocking" their TMDS links. One subtle change here is that
> we'll have to respect the adaptor TMDS clock limit when we decide whether
> to do 12bpc or 8bpc, otherwise we might end up picking 12bpc and
> accidentally driving the TMDS link out of spec even when the user chose
> a mode that fits wihting the limits at 8bpc. This means you can't
> "overclock" your DP++ dongle at 12bpc anymore, but you can continue to
> do so at 8bpc.
>
> Note that for simplicity we'll use the I2C access method for all dual
> mode adaptors including type 2. Otherwise we'd have to start mixing
> DP AUX and HDMI together. In the future we may need to do that if we
> come across any board designs that don't hook up the DDC pins to the
> DP++ connectors. Such boards would obviously only work with type 2
> dual mode adaptors, and not type 1.
>
> v2: Store adaptor type under indel_hdmi->dp_dual_mode
>  Deal with DRM_DP_DUAL_MODE_UNKNOWN
>  Pass adaptor type to drm_dp_dual_mode_max_tmds_clock(),
>  and use it for type1 adaptors as well
>
> Cc: stable at vger.kernel.org
> Reported-by: Tore Anderson 
> Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> Cc: Paulo Zanoni 
> Cc: Shashank Sharma 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>   drivers/gpu/drm/i915/intel_drv.h  |  5 
>   drivers/gpu/drm/i915/intel_hdmi.c | 58 
> +--
>   2 files changed, 55 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 21dee3f89e84..e94d18fb2ff1 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -33,6 +33,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   #include 
> @@ -753,6 +754,10 @@ struct cxsr_latency {
>   struct intel_hdmi {
>   i915_reg_t hdmi_reg;
>   int ddc_bus;
> + struct {
> + enum drm_dp_dual_mode_type type;
> + int max_tmds_clock;
> + } dp_dual_mode;
>   bool limited_color_range;
>   bool color_range_auto;
>   bool has_hdmi_sink;
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index e1012d612024..31ca11134294 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1167,27 +1167,42 @@ static void pch_post_disable_hdmi(struct 
> intel_encoder *encoder)
>   intel_disable_hdmi(encoder);
>   }
>
> -static int hdmi_port_clock_limit(struct intel_hdmi *hdmi, bool 
> respect_dvi_limit)
> +static int intel_hdmi_source_max_tmds_clock(struct drm_i915_private 
> *dev_priv)
>   {
> - struct drm_device *dev = intel_hdmi_to_dev(hdmi);
> -
> - if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
> + if (IS_G4X(dev_priv))
>   return 165000;
> - else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
> + else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
>   return 30;
>   else
>   return 225000;
>   }
>
> +static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
> +  bool respect_downstream_limits)
> +{
> + struct drm_device *dev = intel_hdmi_to_dev(hdmi);
> + int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));
> +
> + if (respect_downstream_limits) {
> + if (hdmi->dp_dual_mode.max_tmds_clock)
> + max_tmds_clock = min(max_tmds_clock,
> +  hdmi->dp_dual_mode.max_tmds_clock);
> + if (!hdmi->has_hdmi_sink)
> + max_tmds_clock = min(max_tmds_clock, 165000);
> + }
> +
> + return max_tmds_clock;
> +}
> +
>   static enum drm_mode_status
>   hdmi_port_clock_valid(struct intel_hdmi *hdmi,
> -   int clock, bool respect_dvi_limit)
> +   int clock, bool respect_downstream_limits)
>   {
>   struct drm_device *dev = intel_hdmi_to_dev(hdmi);
>
>   if (clock < 25000)
>   return MODE_CLOCK_LOW;
> - if (clock > hdmi_port_clock_limit(hdmi, respect_dvi_limit))
> + if (clock > hdmi_port_clock_limit(hdmi, respect_downstream_limits))
>   return MODE_CLOCK_HIGH;
>
>   /* BXT DPLL can't generate 223-240 MHz */
> @@ -1311,7 +1326,7 @@ bool intel_hdmi_compute_config(struct intel_encoder 
> *encoder,
>* within limits.
>*/
>   if (pipe_config->pipe_bpp > 8*3 && pipe_config->has_hdmi_sink &&
> - hdmi_port_clock_valid(intel_hdmi, 

[PATCH v2] drm/exynos: fix cancel page flip code

[Andrzej Hajda]

Driver code did not remove event from the list of pending events before destroy.
As a result drm core later tried to inspect invalid memory location.
The patch replaces removal code with call to core helper.

The bug was detected using KASAN:

[   10.107249] 
==
[   10.107518] BUG: KASAN: use-after-free in drm_release+0xe9c/0x1000 at addr 
ffc089154a18
[   10.107784] Read of size 8 by task modetest/103
[   10.107931] 
=
[   10.113191] BUG kmalloc-128 (Not tainted): kasan: bad access detected
[   10.119608] 
-
[   10.119608]
[   10.129243] Disabling lock debugging due to kernel taint
[   10.134551] INFO: Allocated in drm_mode_page_flip_ioctl+0x500/0xa98 age=4 
cpu=0 pid=103
[   10.142532]  alloc_debug_processing+0x18c/0x198
[   10.147043]  ___slab_alloc.constprop.28+0x360/0x380
[   10.151906]  __slab_alloc.isra.25.constprop.27+0x54/0xa0
[   10.157197]  kmem_cache_alloc_trace+0x370/0x3b0
[   10.161709]  drm_mode_page_flip_ioctl+0x500/0xa98
[   10.166400]  drm_ioctl+0x4c4/0xb68
[   10.169787]  do_vfs_ioctl+0x16c/0xeb8
[   10.173429]  SyS_ioctl+0x8c/0xa0
[   10.176642]  el0_svc_naked+0x24/0x28
[   10.180204] INFO: Freed in exynos_drm_crtc_cancel_page_flip+0xe0/0x160 age=0 
cpu=0 pid=103
[   10.188447]  free_debug_processing+0x174/0x388
[   10.192871]  __slab_free+0x2e8/0x438
[   10.196431]  kfree+0x350/0x360
[   10.199469]  exynos_drm_crtc_cancel_page_flip+0xe0/0x160
[   10.204762]  exynos_drm_preclose+0x58/0xa0
[   10.208844]  drm_release+0x1f0/0x1000
[   10.212491]  __fput+0x1c4/0x5b8
[   10.215613]  fput+0xc/0x18
[   10.218654]  task_work_run+0x130/0x198
[   10.222385]  do_exit+0x700/0x2278
[   10.225681]  do_group_exit+0xe4/0x2c8
[   10.229327]  SyS_exit_group+0x1c/0x20
[   10.232973]  el0_svc_naked+0x24/0x28
[   10.236532] INFO: Slab 0xffbdc2a45500 objects=32 used=10 
fp=0xffc089154a00 flags=0x4080
[   10.245210] INFO: Object 0xffc089154a00 @offset=2560 
fp=0xffc089157600
[   10.245210]
...
[   10.384532] CPU: 0 PID: 103 Comm: modetest Tainted: GB   
4.5.0-rc3-00748-gd5e2881 #271
[   10.398325] Call trace:
[   10.400764] [] dump_backtrace+0x0/0x328
[   10.406141] [] show_stack+0x14/0x20
[   10.411176] [] dump_stack+0xb0/0xe8
[   10.416210] [] print_trailer+0xf8/0x160
[   10.421592] [] object_err+0x3c/0x50
[   10.426626] [] kasan_report_error+0x248/0x550
[   10.432527] [] __asan_report_load8_noabort+0x40/0x48
[   10.439039] [] drm_release+0xe9c/0x1000
[   10.19] [] __fput+0x1c4/0x5b8
[   10.449280] [] fput+0xc/0x18
[   10.454055] [] task_work_run+0x130/0x198
[   10.459522] [] do_exit+0x700/0x2278
[   10.464557] [] do_group_exit+0xe4/0x2c8
[   10.469939] [] SyS_exit_group+0x1c/0x20
[   10.475320] [] el0_svc_naked+0x24/0x28

Signed-off-by: Andrzej Hajda 
---
v2: use exynos_crtc->event under event_lock
---
 drivers/gpu/drm/exynos/exynos_drm_crtc.c | 15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 50dd33d..785ffa6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -233,20 +233,15 @@ void exynos_drm_crtc_cancel_page_flip(struct drm_crtc 
*crtc,
unsigned long flags;

spin_lock_irqsave(>dev->event_lock, flags);
+
e = exynos_crtc->event;
if (e && e->base.file_priv == file) {
exynos_crtc->event = NULL;
-   /*
-* event will be destroyed by core part
-* so below line should be removed later with core changes
-*/
-   e->base.destroy(>base);
-   /*
-* event_space will be increased by core part
-* so below line should be removed later with core changes.
-*/
-   file->event_space += sizeof(e->event);
atomic_dec(_crtc->pending_update);
}
+
spin_unlock_irqrestore(>dev->event_lock, flags);
+
+   if (e && e->base.file_priv == file)
+   drm_event_cancel_free(crtc->dev, >base);
 }
-- 
1.9.1

[PATCH v3 3/4] drm/i915: Enable/disable TMDS output buffers in DP++ adaptor as needed

[Ville Syrjälä]

On Wed, May 04, 2016 at 03:43:30PM +0530, Sharma, Shashank wrote:
> 
> On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > To save a bit of power, let's try to turn off the TMDS output buffers
> > in DP++ adaptors when we're not driving the port.
> >
> > v2: Let's not forget DDI, toss in a debug message while at it
> > v3: Just do the TMDS output control based on adaptor type. With the
> >  helper getting passed the type, we wouldn't actually have to
> >  check at all in the driver, but the check eliminates the debug
> >  output more honest
> >
> > Cc: stable at vger.kernel.org
> > Cc: Tore Anderson 
> > Cc: Paulo Zanoni 
> > Cc: Shashank Sharma 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/intel_ddi.c  | 12 
> >   drivers/gpu/drm/i915/intel_drv.h  |  1 +
> >   drivers/gpu/drm/i915/intel_hdmi.c | 20 
> >   3 files changed, 33 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 422ec81ef59b..a3600704e6d4 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1601,6 +1601,12 @@ static void intel_ddi_pre_enable(struct 
> > intel_encoder *intel_encoder)
> > enum port port = intel_ddi_get_encoder_port(intel_encoder);
> > int type = intel_encoder->type;
> >
> > +   if (type == INTEL_OUTPUT_HDMI) {
> how to handle type2 active adapters here, which can show type = DP ?

The dual mode concept shouldn't apply to active adapters. Those, as you
say, appear as DP and so will be handled as if they were native DP sinks
more or less.

Or are you aware of active DP dongles that also implement the dual mode
standatd? Apart from LSPCON of course. Actually I'm not sure how LSPCON
will handle this. If we drive it in PCON mode, would it still respect
the dual mode register settings, including the TMDS OE# state?

> > +   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> > +
> > +   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> > +   }
> > +
> > intel_prepare_ddi_buffer(intel_encoder);
> >
> > if (type == INTEL_OUTPUT_EDP) {
> > @@ -1667,6 +1673,12 @@ static void intel_ddi_post_disable(struct 
> > intel_encoder *intel_encoder)
> > DPLL_CTRL2_DDI_CLK_OFF(port)));
> > else if (INTEL_INFO(dev)->gen < 9)
> > I915_WRITE(PORT_CLK_SEL(port), PORT_CLK_SEL_NONE);
> > +
> > +   if (type == INTEL_OUTPUT_HDMI) {
> Same as above.
> 
> Regards
> Shashank
> > +   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
> > +
> > +   intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
> > +   }
> >   }
> >
> >   static void intel_enable_ddi(struct intel_encoder *intel_encoder)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index e94d18fb2ff1..dbcb80c70e2e 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1419,6 +1419,7 @@ void intel_hdmi_init_connector(struct 
> > intel_digital_port *intel_dig_port,
> >   struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder);
> >   bool intel_hdmi_compute_config(struct intel_encoder *encoder,
> >struct intel_crtc_state *pipe_config);
> > +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool 
> > enable);
> >
> >
> >   /* intel_lvds.c */
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index 31ca11134294..c4d93e6b4bed 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -836,6 +836,22 @@ static void hsw_set_infoframes(struct drm_encoder 
> > *encoder,
> > intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
> >   }
> >
> > +void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool 
> > enable)
> > +{
> > +   struct drm_i915_private *dev_priv = to_i915(intel_hdmi_to_dev(hdmi));
> > +   struct i2c_adapter *adapter =
> > +   intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
> > +
> > +   if (hdmi->dp_dual_mode.type < DRM_DP_DUAL_MODE_TYPE2_DVI)
> > +   return;
> > +
> > +   DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS output\n",
> > + enable ? "Enabling" : "Disabling");
> > +
> > +   drm_dp_dual_mode_set_tmds_output(hdmi->dp_dual_mode.type,
> > +adapter, enable);
> > +}
> > +
> >   static void intel_hdmi_prepare(struct intel_encoder *encoder)
> >   {
> > struct drm_device *dev = encoder->base.dev;
> > @@ -845,6 +861,8 @@ static void intel_hdmi_prepare(struct intel_encoder 
> > *encoder)
> > const struct drm_display_mode *adjusted_mode = 
> > >config->base.adjusted_mode;
> > u32 hdmi_val;
> >
> > +   intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
> > +
> > hdmi_val = SDVO_ENCODING_HDMI;
> >   

[PATCH v3 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[ville.syrj...@linux.intel.com]

From: Ville Syrjälä 

DP dual mode type 1 DVI adaptors aren't required to implement any
registers, so it's a bit hard to detect them. The best way would
be to check the state of the CONFIG1 pin, but we have no way to
do that. So as a last resort, check the VBT to see if the HDMI
port is in fact a dual mode capable DP port.

v2: Deal with VBT code reorganization
Deal with DRM_DP_DUAL_MODE_UNKNOWN
Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit
Accept both DP and HDMI dvo_port in VBT as my BSW
at least declare its DP port as HDMI :(
v3: Ignore DEVICE_TYPE_NOT_HDMI_OUTPUT (Shashanl)

Cc: stable at vger.kernel.org
Cc: Tore Anderson 
Reported-by: Tore Anderson 
Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
Cc: Paulo Zanoni 
Cc: Shashank Sharma 
Cc: Daniel Vetter 
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h   |  1 +
 drivers/gpu/drm/i915/intel_bios.c | 36 +++
 drivers/gpu/drm/i915/intel_hdmi.c | 30 +
 drivers/gpu/drm/i915/intel_vbt_defs.h | 12 
 4 files changed, 75 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ff6aaf0c4e1e..abe43922a08f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3489,6 +3489,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t 
size);
 bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
 bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
*i2c_pin);
 bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port port);
+bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum 
port port);
 bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum port 
*port);
 bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
 enum port port);
diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 81518116e00d..8b68c4882fba 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1597,6 +1597,42 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
*dev_priv, enum port port)
return false;
 }

+bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, enum 
port port)
+{
+   static const struct {
+   u16 dp, hdmi;
+   } port_mapping[] = {
+   /*
+* Buggy VBTs may declare DP ports as having
+* HDMI type dvo_port :( So let's check both.
+*/
+   [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
+   [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
+   [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
+   [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
+   };
+   int i;
+
+   if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
+   return false;
+
+   if (!dev_priv->vbt.child_dev_num)
+   return false;
+
+   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
+   const union child_device_config *p_child =
+   _priv->vbt.child_dev[i];
+
+   if ((p_child->common.dvo_port == port_mapping[port].dp ||
+p_child->common.dvo_port == port_mapping[port].hdmi) &&
+   (p_child->common.device_type & 
DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
+   (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
+   return true;
+   }
+
+   return false;
+}
+
 /**
  * intel_bios_is_dsi_present - is DSI present in VBT
  * @dev_priv:  i915 device instance
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index c4d93e6b4bed..6b52c6accf6a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1396,16 +1396,38 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
 }

 static void
-intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
+intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
 {
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
+   enum port port = hdmi_to_dig_port(hdmi)->port;
struct i2c_adapter *adapter =
intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
enum drm_dp_dual_mode_type type = drm_dp_dual_mode_detect(adapter);

-   if (type == DRM_DP_DUAL_MODE_NONE ||
-   type == DRM_DP_DUAL_MODE_UNKNOWN)
+   /*
+* Type 1 DVI adaptors are not required to implement any
+* registers, so we can't always detect their presence.
+* Ideally we should be able to check the state of the
+* CONFIG1 pin, but no such luck on our hardware.
+*
+* The only method left to us 

[PATCH] drm/core: Do not preserve framebuffer on rmfb, v4.

[Maarten Lankhorst]

It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.

drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impossible. There is no way to remove the framebuffer from the lists
and active planes without introducing a race because of the different
locking requirements. Instead call drm_framebuffer_remove from a
workqueue, which is unaffected by signals.

Changes since v1:
- Add comment.
Changes since v2:
- Add fastpath for refcount = 1. (danvet)
Changes since v3:
- Rebased.
- Restore lastclose framebuffer removal too.

Cc: stable at vger.kernel.org #v4.4+
Fixes: 13803132818c ("drm/core: Preserve the framebuffer after removing it.")
Testcase: kms_rmfb_basic
References: 
https://lists.freedesktop.org/archives/dri-devel/2016-March/102876.html
Cc: Thomas Hellstrom 
Cc: David Herrmann 
Reviewed-by: Daniel Vetter 
Tested-by: Thomas Hellstrom  #v3
---
 drivers/gpu/drm/drm_crtc.c | 63 --
 1 file changed, 56 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 9626a0cc050a..9a3d17b70091 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3440,6 +3440,24 @@ int drm_mode_addfb2(struct drm_device *dev,
return 0;
 }

+struct drm_mode_rmfb_work {
+   struct work_struct work;
+   struct list_head fbs;
+};
+
+static void drm_mode_rmfb_work_fn(struct work_struct *w)
+{
+   struct drm_mode_rmfb_work *arg = container_of(w, typeof(*arg), work);
+
+   while (!list_empty(>fbs)) {
+   struct drm_framebuffer *fb =
+   list_first_entry(>fbs, typeof(*fb), filp_head);
+
+   list_del_init(>filp_head);
+   drm_framebuffer_remove(fb);
+   }
+}
+
 /**
  * drm_mode_rmfb - remove an FB from the configuration
  * @dev: drm device for the ioctl
@@ -3480,12 +3498,29 @@ int drm_mode_rmfb(struct drm_device *dev,
list_del_init(>filp_head);
mutex_unlock(_priv->fbs_lock);

-   /* we now own the reference that was stored in the fbs list */
-   drm_framebuffer_unreference(fb);
-
/* drop the reference we picked up in framebuffer lookup */
drm_framebuffer_unreference(fb);

+   /*
+* we now own the reference that was stored in the fbs list
+*
+* drm_framebuffer_remove may fail with -EINTR on pending signals,
+* so run this in a separate stack as there's no way to correctly
+* handle this after the fb is already removed from the lookup table.
+*/
+   if (drm_framebuffer_read_refcount(fb) > 1) {
+   struct drm_mode_rmfb_work arg;
+
+   INIT_WORK_ONSTACK(, drm_mode_rmfb_work_fn);
+   INIT_LIST_HEAD();
+   list_add_tail(>filp_head, );
+
+   schedule_work();
+   flush_work();
+   destroy_work_on_stack();
+   } else
+   drm_framebuffer_unreference(fb);
+
return 0;

 fail_unref:
@@ -3635,7 +3670,6 @@ out_err1:
return ret;
 }

-
 /**
  * drm_fb_release - remove and free the FBs on this file
  * @priv: drm file for the ioctl
@@ -3650,6 +3684,9 @@ out_err1:
 void drm_fb_release(struct drm_file *priv)
 {
struct drm_framebuffer *fb, *tfb;
+   struct drm_mode_rmfb_work arg;
+
+   INIT_LIST_HEAD();

/*
 * When the file gets released that means no one else can access the fb
@@ -3662,10 +3699,22 @@ void drm_fb_release(struct drm_file *priv)
 * at it any more.
 */
list_for_each_entry_safe(fb, tfb, >fbs, filp_head) {
-   list_del_init(>filp_head);
+   if (drm_framebuffer_read_refcount(fb) > 1) {
+   list_move_tail(>filp_head, );
+   } else {
+   list_del_init(>filp_head);

-   /* This drops the fpriv->fbs reference. */
-   drm_framebuffer_unreference(fb);
+   /* This drops the fpriv->fbs reference. */
+   drm_framebuffer_unreference(fb);
+   }
+   }
+
+   if (!list_empty()) {
+   INIT_WORK_ONSTACK(, drm_mode_rmfb_work_fn);
+
+   schedule_work();
+   flush_work();
+   destroy_work_on_stack();
}
 }

-- 
2.5.5

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

which seems to be enough.
>
>
>> - no dmesg noise above debug level for stuff that we know can happen -
>>   dmesg noise counts as igt failures
>>
>
> okey. I don't think I have anything above debug level, unless things are
> going badly wrong.
>
> Just double checking though has made me think twice about a WARN_ON in
> gen7_oa_read for !oa_buffer_addr, which would be a bad situation but should
> either be removed (never expected), be a BUG_ON (since the code would deref
> NULL anyway) or more gracefully return an error if seen.
>
> I currently have some DRM_DRIVER_DEBUG errors for cases where userspace
> messes up what properties it gives to open a stream - hopefully that sound
> ok? I've found it quite helpful to have a readable error for otherwise
> vague EINVAL type errors.
>
> I have a debug message I print if we see an invalid HW report, which
> *shouldn't* happen but can happen (e.g. if the MUX delay or tail margin
> aren't well tuned) and it's helpful to have the feedback, in case we end up
> in a situation where we see this kind of message too frequently which might
> indicate an issue to investigate.
>
>
>> - reading 0 sounds more like bad synchronization.
>
>
> I suppose I haven't thoroughly considered if we should return zero in any
> case  - normally that would imply EOF so we get to choose what that implies
> here. I don't think the driver should ever return 0 from read() currently.
>
> A few concious choices re: read() return values have been:
>
> - never ever return partial records (or rather even if a partial record
> were literally copied into the userspace buffer, but an error were hit in
> the middle of copying a full sample then that record wouldn't be accounted
> for in the byte count returned.)
>
> - Don't throw away records successfully copied, due to a later error. This
> simplifies error handling paths internally and reporting
> EAGAIN/ENOSPC/EFAULT errors and means data isn't lost. The precedence for
> what we return is 1) did we successfully copy some reports? report bytes
> copied for complete records. 2) did we encounter an error? report that if
> so. 3) return -EAGAIN. (though for a blocking fd this will be handled
> internally).
>
>
>
>> Have you tried quiescing
>
> the entire gpu (to make sure nothing is happen) and disabling OA, then
>>   updating, and then restarting? At least on a very quick look I didn't
>>   spot that. Random delays freak me out a bit, but wouldn't be surprised
>>   if really needed.
>>
>
> Experimenting yesterday, it seems I can at least reduce the delay to
> around 15ms (granted that's still pretty huge), and it's also workable to
> have userspace sleep for this time (despite the mdelay I originally went
> with)
>
> Haven't tried this, but yeah could be interesting to experiment if the MUX
> config lands faster in different situation such as when the HW is idle.
>

Hmm, maybe a stretch, but 15ms is perhaps coincidentally close to the
vblank period, the MUX relates to a fabric across the whole gpu... not
totally in-plausible there could be an interaction there too. another one
to experiment with.

- Robert


>
> Thanks,
> - Robert
>
>
>>
>> Cheers, Daniel
>> --
>> Daniel Vetter
>> Software Engineer, Intel Corporation
>> http://blog.ffwll.ch
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/d6cca70b/attachment-0001.html>

[PATCH] drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked

[Daniel Vetter]

Embarrassingly while fixing up the old paths for i915 I managed to
misplace a locking check for the new _unlocked paths. That's what I
get for not retesting on radeon.

Fixes: 9f0ba539d13a ("drm/gem: support BO freeing without dev->struct_mutex")
Cc: Chris Wilson 
Cc: Alex Deucher 
Cc: Lucas Stach 
Tested-by: Chris Wilson 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_gem.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 973eb8805ce0..f716308fb48c 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -804,12 +804,13 @@ drm_gem_object_free(struct kref *kref)
container_of(kref, struct drm_gem_object, refcount);
struct drm_device *dev = obj->dev;

-   WARN_ON(!mutex_is_locked(>struct_mutex));
-
-   if (dev->driver->gem_free_object_unlocked)
+   if (dev->driver->gem_free_object_unlocked) {
dev->driver->gem_free_object_unlocked(obj);
-   else if (dev->driver->gem_free_object)
+   } else if (dev->driver->gem_free_object) {
+   WARN_ON(!mutex_is_locked(>struct_mutex));
+
dev->driver->gem_free_object(obj);
+   }
 }
 EXPORT_SYMBOL(drm_gem_object_free);

-- 
2.8.1

[PATCH v2 4/4] drm/i915: Determine DP++ type 1 DVI adaptor presence based on VBT

[Ville Syrjälä]

On Wed, May 04, 2016 at 03:54:41PM +0530, Sharma, Shashank wrote:
> 
> 
> On 5/3/2016 12:38 AM, ville.syrjala at linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > DP dual mode type 1 DVI adaptors aren't required to implement any
> > registers, so it's a bit hard to detect them. The best way would
> > be to check the state of the CONFIG1 pin, but we have no way to
> > do that. So as a last resort, check the VBT to see if the HDMI
> > port is in fact a dual mode capable DP port.
> >
> > v2: Deal with VBT code reorganization
> >  Deal with DRM_DP_DUAL_MODE_UNKNOWN
> >  Reduce DEVICE_TYPE_DP_DUAL_MODE_BITS a bit
> >  Accept both DP and HDMI dvo_port in VBT as my BSW
> >  at least declare its DP port as HDMI :(
> >
> > Cc: stable at vger.kernel.org
> > Cc: Tore Anderson 
> > Reported-by: Tore Anderson 
> > Fixes: 7a0baa623446 ("Revert "drm/i915: Disable 12bpc hdmi for now"")
> > Cc: Paulo Zanoni 
> > Cc: Shashank Sharma 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >   drivers/gpu/drm/i915/i915_drv.h   |  1 +
> >   drivers/gpu/drm/i915/intel_bios.c | 36 
> > +++
> >   drivers/gpu/drm/i915/intel_hdmi.c | 30 +
> >   drivers/gpu/drm/i915/intel_vbt_defs.h | 13 +
> >   4 files changed, 76 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index ff6aaf0c4e1e..abe43922a08f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3489,6 +3489,7 @@ bool intel_bios_is_valid_vbt(const void *buf, size_t 
> > size);
> >   bool intel_bios_is_tv_present(struct drm_i915_private *dev_priv);
> >   bool intel_bios_is_lvds_present(struct drm_i915_private *dev_priv, u8 
> > *i2c_pin);
> >   bool intel_bios_is_port_edp(struct drm_i915_private *dev_priv, enum port 
> > port);
> > +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, 
> > enum port port);
> >   bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum 
> > port *port);
> >   bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
> >  enum port port);
> > diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> > b/drivers/gpu/drm/i915/intel_bios.c
> > index 81518116e00d..8b68c4882fba 100644
> > --- a/drivers/gpu/drm/i915/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/intel_bios.c
> > @@ -1597,6 +1597,42 @@ bool intel_bios_is_port_edp(struct drm_i915_private 
> > *dev_priv, enum port port)
> > return false;
> >   }
> >
> > +bool intel_bios_is_port_dp_dual_mode(struct drm_i915_private *dev_priv, 
> > enum port port)
> > +{
> > +   static const struct {
> > +   u16 dp, hdmi;
> > +   } port_mapping[] = {
> > +   /*
> > +* Buggy VBTs may declare DP ports as having
> > +* HDMI type dvo_port :( So let's check both.
> > +*/
> > +   [PORT_B] = { DVO_PORT_DPB, DVO_PORT_HDMIB, },
> > +   [PORT_C] = { DVO_PORT_DPC, DVO_PORT_HDMIC, },
> > +   [PORT_D] = { DVO_PORT_DPD, DVO_PORT_HDMID, },
> > +   [PORT_E] = { DVO_PORT_DPE, DVO_PORT_HDMIE, },
> > +   };
> > +   int i;
> > +
> > +   if (port == PORT_A || port >= ARRAY_SIZE(port_mapping))
> > +   return false;
> > +
> > +   if (!dev_priv->vbt.child_dev_num)
> > +   return false;
> > +
> > +   for (i = 0; i < dev_priv->vbt.child_dev_num; i++) {
> > +   const union child_device_config *p_child =
> > +   _priv->vbt.child_dev[i];
> > +
> > +   if ((p_child->common.dvo_port == port_mapping[port].dp ||
> > +p_child->common.dvo_port == port_mapping[port].hdmi) &&
> > +   (p_child->common.device_type & 
> > DEVICE_TYPE_DP_DUAL_MODE_BITS) ==
> > +   (DEVICE_TYPE_DP_DUAL_MODE & DEVICE_TYPE_DP_DUAL_MODE_BITS))
> > +   return true;
> > +   }
> > +
> > +   return false;
> > +}
> > +
> >   /**
> >* intel_bios_is_dsi_present - is DSI present in VBT
> >* @dev_priv: i915 device instance
> > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > b/drivers/gpu/drm/i915/intel_hdmi.c
> > index c4d93e6b4bed..6b52c6accf6a 100644
> > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > @@ -1396,16 +1396,38 @@ intel_hdmi_unset_edid(struct drm_connector 
> > *connector)
> >   }
> >
> >   static void
> > -intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector)
> > +intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool 
> > has_edid)
> >   {
> > struct drm_i915_private *dev_priv = to_i915(connector->dev);
> > struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
> > +   enum port port = hdmi_to_dig_port(hdmi)->port;
> > struct i2c_adapter *adapter =
> > intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
> > enum drm_dp_dual_mode_type type = 

[PATCH 14/14] drm/amdgpu: fetch cu_info once at init

[Alex Deucher]

Fetch this info once at init and just store the results
for future requests.

Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h | 20 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c |  4 +---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c |  9 -
 drivers/gpu/drm/amd/amdgpu/cik.c|  1 -
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   | 23 +++
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.h   |  1 -
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   | 11 ---
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.h   |  1 -
 drivers/gpu/drm/amd/amdgpu/vi.c |  1 -
 9 files changed, 25 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 19ac6c5..f549474 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1147,6 +1147,12 @@ struct amdgpu_gca_config {
uint32_t macrotile_mode_array[16];
 };

+struct amdgpu_cu_info {
+   uint32_t number; /* total active CU number */
+   uint32_t ao_cu_mask;
+   uint32_t bitmap[4][4];
+};
+
 struct amdgpu_gfx {
struct mutexgpu_clock_mutex;
struct amdgpu_gca_configconfig;
@@ -1179,9 +1185,10 @@ struct amdgpu_gfx {
struct amdgpu_irq_src   priv_reg_irq;
struct amdgpu_irq_src   priv_inst_irq;
/* gfx status */
-   uint32_t gfx_current_status;
+   uint32_tgfx_current_status;
/* ce ram size*/
-   unsigned ce_ram_size;
+   unsignedce_ram_size;
+   struct amdgpu_cu_info   cu_info;
 };

 int amdgpu_ib_get(struct amdgpu_device *adev, struct amdgpu_vm *vm,
@@ -1793,13 +1800,6 @@ struct amdgpu_allowed_register_entry {
bool grbm_indexed;
 };

-struct amdgpu_cu_info {
-   uint32_t number; /* total active CU number */
-   uint32_t ao_cu_mask;
-   uint32_t bitmap[4][4];
-};
-
-
 /*
  * ASIC specific functions.
  */
@@ -1817,7 +1817,6 @@ struct amdgpu_asic_funcs {
u32 (*get_xclk)(struct amdgpu_device *adev);
/* get the gpu clock counter */
uint64_t (*get_gpu_clock_counter)(struct amdgpu_device *adev);
-   int (*get_cu_info)(struct amdgpu_device *adev, struct amdgpu_cu_info 
*info);
/* MM block clocks */
int (*set_uvd_clocks)(struct amdgpu_device *adev, u32 vclk, u32 dclk);
int (*set_vce_clocks)(struct amdgpu_device *adev, u32 evclk, u32 ecclk);
@@ -2208,7 +2207,6 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
 #define amdgpu_asic_read_disabled_bios(adev) 
(adev)->asic_funcs->read_disabled_bios((adev))
 #define amdgpu_asic_read_bios_from_rom(adev, b, l) 
(adev)->asic_funcs->read_bios_from_rom((adev), (b), (l))
 #define amdgpu_asic_read_register(adev, se, sh, offset, 
v)((adev)->asic_funcs->read_register((adev), (se), (sh), (offset), (v)))
-#define amdgpu_asic_get_cu_info(adev, info) 
(adev)->asic_funcs->get_cu_info((adev), (info))
 #define amdgpu_gart_flush_gpu_tlb(adev, vmid) 
(adev)->gart.gart_funcs->flush_gpu_tlb((adev), (vmid))
 #define amdgpu_gart_set_pte_pde(adev, pt, idx, addr, flags) 
(adev)->gart.gart_funcs->set_pte_pde((adev), (pt), (idx), (addr), (flags))
 #define amdgpu_vm_copy_pte(adev, ib, pe, src, count) 
((adev)->vm_manager.vm_pte_funcs->copy_pte((ib), (pe), (src), (count)))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
index 490464e..199f76b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c
@@ -793,7 +793,6 @@ static int amdgpu_cgs_query_system_info(struct cgs_device 
*cgs_device,
struct cgs_system_info *sys_info)
 {
CGS_FUNC_ADEV;
-   struct amdgpu_cu_info cu_info;

if (NULL == sys_info)
return -ENODEV;
@@ -818,8 +817,7 @@ static int amdgpu_cgs_query_system_info(struct cgs_device 
*cgs_device,
sys_info->value = adev->pg_flags;
break;
case CGS_SYSTEM_INFO_GFX_CU_INFO:
-   amdgpu_asic_get_cu_info(adev, _info);
-   sys_info->value = cu_info.number;
+   sys_info->value = adev->gfx.cu_info.number;
break;
default:
return -ENODEV;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 4ac83c8..c63866e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -427,7 +427,6 @@ static int amdgpu_info_ioctl(struct drm_device *dev, void 
*data, struct drm_file
}
case AMDGPU_INFO_DEV_INFO: {
struct drm_amdgpu_info_device dev_info = {};
-   struct amdgpu_cu_info cu_info;

dev_info.device_id = dev->pdev->device;
dev_info.chip_rev = adev->rev_id;
@@ -461,11 +460,11 @@ static int amdgpu_info_ioctl(struct 

[PATCH 13/14] drm/amd: cleanup remaining spaces and tabs v2

[Alex Deucher]

From: Christian König 

This is the result of running the following commands:
find drivers/gpu/drm/amd/ -name "*.h" -exec sed -i 's/[ \t]\+$//' {} \;
find drivers/gpu/drm/amd/ -name "*.c" -exec sed -i 's/[ \t]\+$//' {} \;
find drivers/gpu/drm/amd/ -name "*.h" -exec sed -i 's/ \+\t/\t/' {} \;
find drivers/gpu/drm/amd/ -name "*.c" -exec sed -i 's/ \+\t/\t/' {} \;

v2: drop changes to DAL and internal headers

Signed-off-by: Christian König 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 12 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c   |  6 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gds.h   |  6 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c   |  6 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c   |  6 +++---
 drivers/gpu/drm/amd/amdgpu/atom.h |  2 +-
 drivers/gpu/drm/amd/amdgpu/ci_dpm.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/cik_ih.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/cikd.h |  4 ++--
 drivers/gpu/drm/amd/amdgpu/cz_ih.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/cz_smumgr.h|  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c |  6 +++---
 drivers/gpu/drm/amd/amdgpu/vid.h  |  2 +-
 drivers/gpu/drm/amd/powerplay/hwmgr/fiji_hwmgr.c  |  6 +++---
 drivers/gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c |  8 
 drivers/gpu/drm/amd/powerplay/hwmgr/ppatomctrl.c  |  4 ++--
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.c |  8 
 drivers/gpu/drm/amd/powerplay/hwmgr/tonga_hwmgr.h | 18 +-
 drivers/gpu/drm/amd/powerplay/inc/hwmgr.h |  2 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h |  2 +-
 23 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 416e814..19ac6c5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -369,7 +369,7 @@ struct amdgpu_fence_driver {

 struct amdgpu_user_fence {
/* write-back bo */
-   struct amdgpu_bo*bo;
+   struct amdgpu_bo*bo;
/* write-back address offset to bo start */
uint32_toffset;
 };
@@ -776,7 +776,7 @@ struct amdgpu_ring {
struct amdgpu_device*adev;
const struct amdgpu_ring_funcs  *funcs;
struct amdgpu_fence_driver  fence_drv;
-   struct amd_gpu_schedulersched;
+   struct amd_gpu_schedulersched;

spinlock_t  fence_lock;
struct amdgpu_bo*ring_obj;
@@ -1246,7 +1246,7 @@ struct amdgpu_cs_parser {
 struct amdgpu_job {
struct amd_sched_jobbase;
struct amdgpu_device*adev;
-   struct amdgpu_vm*vm;
+   struct amdgpu_vm*vm;
struct amdgpu_ring  *ring;
struct amdgpu_sync  sync;
struct amdgpu_ib*ibs;
@@ -1700,7 +1700,7 @@ struct amdgpu_sdma {
struct amdgpu_sdma_instance instance[AMDGPU_MAX_SDMA_INSTANCES];
struct amdgpu_irq_src   trap_irq;
struct amdgpu_irq_src   illegal_inst_irq;
-   int num_instances;
+   int num_instances;
 };

 /*
@@ -1954,11 +1954,11 @@ struct amdgpu_device {
boolshutdown;
boolneed_dma32;
boolaccel_working;
-   struct work_struct  reset_work;
+   struct work_struct  reset_work;
struct notifier_block   acpi_nb;
struct amdgpu_i2c_chan  *i2c_bus[AMDGPU_MAX_I2C_BUS];
struct amdgpu_debugfs   debugfs[AMDGPU_DEBUGFS_MAX_COMPONENTS];
-   unsigneddebugfs_count;
+   unsigneddebugfs_count;
 #if defined(CONFIG_DEBUG_FS)
struct dentry   
*debugfs_regs[AMDGPU_DEBUGFS_MAX_COMPONENTS];
 #endif
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
index eacd810..35d0856 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c
@@ -263,7 +263,7 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, void *data,
for (i = 0; i < args->in.bo_number; ++i) {
if (copy_from_user([i], uptr, bytes))
goto error_free;
-   
+
uptr += args->in.bo_info_size;
}
}
@@ -271,7 +271,7 @@ int amdgpu_bo_list_ioctl(struct drm_device *dev, 

[PATCH 12/14] drm/amdgpu: remove define for reserved client ID

[Alex Deucher]

From: Christian König 

Just set it to zero instead.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index de5bfc7..416e814 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -363,7 +363,6 @@ struct amdgpu_fence_driver {
 /* some special values for the owner field */
 #define AMDGPU_FENCE_OWNER_UNDEFINED   ((void*)0ul)
 #define AMDGPU_FENCE_OWNER_VM  ((void*)1ul)
-#define AMDGPU_CLIENT_ID_RESERVED   2

 #define AMDGPU_FENCE_FLAG_64BIT (1 << 0)
 #define AMDGPU_FENCE_FLAG_INT   (1 << 1)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 67f6c2e..ea708cb 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1504,7 +1504,7 @@ void amdgpu_vm_manager_init(struct amdgpu_device *adev)
}

atomic_set(>vm_manager.vm_pte_next_ring, 0);
-   atomic64_set(>vm_manager.client_counter, 
AMDGPU_CLIENT_ID_RESERVED);
+   atomic64_set(>vm_manager.client_counter, 0);
 }

 /**
-- 
2.5.5

[PATCH 11/14] drm/amdgpu: remove owner cleanup v2

[Alex Deucher]

From: Christian König 

The client ID is now unique, so no need to resert the owner fields any more.

v2: remove unused variables as well

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou  (v1)
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index cd57898..67f6c2e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1457,7 +1457,6 @@ error_free_sched_entity:
 void amdgpu_vm_fini(struct amdgpu_device *adev, struct amdgpu_vm *vm)
 {
struct amdgpu_bo_va_mapping *mapping, *tmp;
-   struct amdgpu_vm_id *id, *id_tmp;
int i;

amd_sched_entity_fini(vm->entity.sched, >entity);
@@ -1481,18 +1480,6 @@ void amdgpu_vm_fini(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)

amdgpu_bo_unref(>page_directory);
fence_put(vm->page_directory_fence);
-
-   mutex_lock(>vm_manager.lock);
-   list_for_each_entry_safe(id, id_tmp, >vm_manager.ids_lru,
-list) {
-   if (!id)
-   continue;
-   if (atomic_long_read(>owner) == vm->client_id) {
-   atomic_long_set(>owner, 0);
-   id->pd_gpu_addr = 0;
-   }
-   }
-   mutex_unlock(>vm_manager.lock);
 }

 /**
-- 
2.5.5

[PATCH 10/14] drm/amdgpu: make the VMID owner always 64bit

[Alex Deucher]

From: Christian König 

Otherwise we could (in theory) run into problems on 32bit systems.

Signed-off-by: Christian König 
Reviewed-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 8e3b14d..de5bfc7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -896,7 +896,7 @@ struct amdgpu_vm_id {
struct amdgpu_sync  active;
struct fence*last_flush;
struct amdgpu_ring  *last_user;
-   atomic_long_t   owner;
+   atomic64_t  owner;

uint64_tpd_gpu_addr;
/* last flushed PD/PT update */
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 62ce725..cd57898 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -185,7 +185,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
amdgpu_ring *ring,
if (!id)
continue;

-   if (atomic_long_read(>owner) != vm->client_id)
+   if (atomic64_read(>owner) != vm->client_id)
continue;

if (pd_addr != id->pd_gpu_addr)
@@ -261,7 +261,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
amdgpu_ring *ring,

list_move_tail(>list, >vm_manager.ids_lru);
id->last_user = ring;
-   atomic_long_set(>owner, vm->client_id);
+   atomic64_set(>owner, vm->client_id);
vm->ids[ring->idx] = id;

*vm_id = id - adev->vm_manager.ids;
-- 
2.5.5

[PATCH 09/14] drm/amdgpu: two minor 80 char fixes

[Alex Deucher]

From: Christian König 

Signed-off-by: Christian König 
Reviewed-by: Tom St Denis 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   | 10 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c|  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c |  7 ---
 3 files changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 9d54d76..8e3b14d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -508,9 +508,10 @@ void amdgpu_gem_object_close(struct drm_gem_object *obj,
struct drm_file *file_priv);
 unsigned long amdgpu_gem_timeout(uint64_t timeout_ns);
 struct sg_table *amdgpu_gem_prime_get_sg_table(struct drm_gem_object *obj);
-struct drm_gem_object *amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-   struct 
dma_buf_attachment *attach,
-   struct sg_table *sg);
+struct drm_gem_object *
+amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
+struct dma_buf_attachment *attach,
+struct sg_table *sg);
 struct dma_buf *amdgpu_gem_prime_export(struct drm_device *dev,
struct drm_gem_object *gobj,
int flags);
@@ -1186,7 +1187,8 @@ struct amdgpu_gfx {

 int amdgpu_ib_get(struct amdgpu_device *adev, struct amdgpu_vm *vm,
  unsigned size, struct amdgpu_ib *ib);
-void amdgpu_ib_free(struct amdgpu_device *adev, struct amdgpu_ib *ib, struct 
fence *f);
+void amdgpu_ib_free(struct amdgpu_device *adev, struct amdgpu_ib *ib,
+   struct fence *f);
 int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs,
   struct amdgpu_ib *ib, struct fence *last_vm_update,
   struct amdgpu_job *job, struct fence **f);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 61ca7e1..32dd199 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -88,7 +88,8 @@ int amdgpu_ib_get(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,
  *
  * Free an IB (all asics).
  */
-void amdgpu_ib_free(struct amdgpu_device *adev, struct amdgpu_ib *ib, struct 
fence *f)
+void amdgpu_ib_free(struct amdgpu_device *adev, struct amdgpu_ib *ib,
+   struct fence *f)
 {
amdgpu_sa_bo_free(adev, >sa_bo, f);
 }
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
index be6388f..7700dc2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c
@@ -57,9 +57,10 @@ void amdgpu_gem_prime_vunmap(struct drm_gem_object *obj, 
void *vaddr)
ttm_bo_kunmap(>dma_buf_vmap);
 }

-struct drm_gem_object *amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
-   struct 
dma_buf_attachment *attach,
-   struct sg_table *sg)
+struct drm_gem_object *
+amdgpu_gem_prime_import_sg_table(struct drm_device *dev,
+struct dma_buf_attachment *attach,
+struct sg_table *sg)
 {
struct reservation_object *resv = attach->dmabuf->resv;
struct amdgpu_device *adev = dev->dev_private;
-- 
2.5.5

[PATCH 08/14] drm/amdgpu: hdp flush should always do

[Alex Deucher]

From: Monk Liu 

This fixes Tonga vm-fault issue when running disaster
(a multiple context GL heavy tests),
We should always flush & invalidate hdp no matter vm
used or not.

Signed-off-by: Monk Liu 
Reviewed-by: Christian König 
Reviewed-by: Chunming Zhou 
Signed-off-by: Alex Deucher 
Cc: stable at vger.kernel.org
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 12 +---
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 1693fc7e..61ca7e1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -164,11 +164,11 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
amdgpu_ring_undo(ring);
return r;
}
-
-   if (ring->funcs->emit_hdp_flush)
-   amdgpu_ring_emit_hdp_flush(ring);
}

+   if (ring->funcs->emit_hdp_flush)
+   amdgpu_ring_emit_hdp_flush(ring);
+
/* always set cond_exec_polling to CONTINUE */
*ring->cond_exe_cpu_addr = 1;

@@ -178,10 +178,8 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
}
ring->last_fence_context = fence_context;

-   if (vm) {
-   if (ring->funcs->emit_hdp_invalidate)
-   amdgpu_ring_emit_hdp_invalidate(ring);
-   }
+   if (ring->funcs->emit_hdp_invalidate)
+   amdgpu_ring_emit_hdp_invalidate(ring);

r = amdgpu_fence_emit(ring, );
if (r) {
-- 
2.5.5

[PATCH 07/14] drm/amd/amdgpu: Enable CG for UVD6 on Carrizo

[Alex Deucher]

From: Tom St Denis 

Tested via vdpau/mpv.

Signed-off-by: Tom St Denis 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/vi.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/vi.c b/drivers/gpu/drm/amd/amdgpu/vi.c
index 340a166..31dd630 100644
--- a/drivers/gpu/drm/amd/amdgpu/vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/vi.c
@@ -1193,7 +1193,8 @@ static int vi_common_early_init(void *handle)
adev->external_rev_id = adev->rev_id + 0x50;
break;
case CHIP_CARRIZO:
-   adev->cg_flags = AMD_CG_SUPPORT_GFX_MGCG |
+   adev->cg_flags = AMD_CG_SUPPORT_UVD_MGCG |
+   AMD_CG_SUPPORT_GFX_MGCG |
AMD_CG_SUPPORT_GFX_MGLS |
AMD_CG_SUPPORT_GFX_RLC_LS |
AMD_CG_SUPPORT_GFX_CP_LS |
-- 
2.5.5

[PATCH 06/14] drm/amdgpu: add pipeline sync for compute job

[Alex Deucher]

From: Chunming Zhou 

hardware ring is async processed, the job is executed in parallel.
In some case, this will result vm fault, like jobs with different vmids.

This works around a CPC hw issue which will eventually be fixed in fw.

Signed-off-by: Chunming Zhou 
Reviewed-by: Alex Deucher 
Reviewed-by: Christian König 
Reviewed-by: Monk Liu 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 692d0d02..62ce725 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -300,7 +300,8 @@ int amdgpu_vm_flush(struct amdgpu_ring *ring,
int r;

if (ring->funcs->emit_pipeline_sync && (
-   pd_addr != AMDGPU_VM_NO_FLUSH || gds_switch_needed))
+   pd_addr != AMDGPU_VM_NO_FLUSH || gds_switch_needed ||
+   ring->type == AMDGPU_RING_TYPE_COMPUTE))
amdgpu_ring_emit_pipeline_sync(ring);

if (ring->funcs->emit_vm_flush &&
-- 
2.5.5

[PATCH 05/14] drm/amdgpu: use fence_context to judge ctx switch

[Alex Deucher]

From: Monk Liu 

use ctx pointer is not safe, cuz they are likely already
be assigned to another ctx when doing comparing.

fence_context is always increasing and have rare chance
to overback to used number for jobs that scheduled to
ring continueonsly

Signed-off-by: Monk Liu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  8 
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c|  1 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c| 14 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.h   |  2 +-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 11 +--
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 11 +--
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c|  2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c |  2 +-
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.c |  1 +
 drivers/gpu/drm/amd/scheduler/gpu_scheduler.h |  1 +
 15 files changed, 31 insertions(+), 32 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 2ee99dc..9d54d76 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -283,7 +283,7 @@ struct amdgpu_ring_funcs {
int (*parse_cs)(struct amdgpu_cs_parser *p, uint32_t ib_idx);
/* command emit functions */
void (*emit_ib)(struct amdgpu_ring *ring,
-   struct amdgpu_ib *ib);
+   struct amdgpu_ib *ib, bool ctx_switch);
void (*emit_fence)(struct amdgpu_ring *ring, uint64_t addr,
   uint64_t seq, unsigned flags);
void (*emit_pipeline_sync)(struct amdgpu_ring *ring);
@@ -742,7 +742,6 @@ struct amdgpu_ib {
struct amdgpu_user_fence*user;
unsignedvm_id;
uint64_tvm_pd_addr;
-   struct amdgpu_ctx   *ctx;
uint32_tgds_base, gds_size;
uint32_tgws_base, gws_size;
uint32_toa_base, oa_size;
@@ -805,7 +804,7 @@ struct amdgpu_ring {
unsignedwptr_offs;
unsignednext_rptr_offs;
unsignedfence_offs;
-   struct amdgpu_ctx   *current_ctx;
+   uint64_t last_fence_context;
enum amdgpu_ring_type   type;
charname[16];
unsignedcond_exe_offs;
@@ -1253,6 +1252,7 @@ struct amdgpu_job {
struct fence*fence; /* the hw fence */
uint32_tnum_ibs;
void*owner;
+   uint64_tfence_context;
struct amdgpu_user_fence uf;
 };
 #define to_amdgpu_job(sched_job)   \
@@ -2219,7 +2219,7 @@ amdgpu_get_sdma_instance(struct amdgpu_ring *ring)
 #define amdgpu_ring_get_rptr(r) (r)->funcs->get_rptr((r))
 #define amdgpu_ring_get_wptr(r) (r)->funcs->get_wptr((r))
 #define amdgpu_ring_set_wptr(r) (r)->funcs->set_wptr((r))
-#define amdgpu_ring_emit_ib(r, ib) (r)->funcs->emit_ib((r), (ib))
+#define amdgpu_ring_emit_ib(r, ib, f) (r)->funcs->emit_ib((r), (ib), (f))
 #define amdgpu_ring_emit_pipeline_sync(r) (r)->funcs->emit_pipeline_sync((r))
 #define amdgpu_ring_emit_vm_flush(r, vmid, addr) 
(r)->funcs->emit_vm_flush((r), (vmid), (addr))
 #define amdgpu_ring_emit_fence(r, addr, seq, flags) 
(r)->funcs->emit_fence((r), (addr), (seq), (flags))
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 1a06596..8c3bf63 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -741,7 +741,6 @@ static int amdgpu_cs_ib_fill(struct amdgpu_device *adev,

ib->length_dw = chunk_ib->ib_bytes / 4;
ib->flags = chunk_ib->flags;
-   ib->ctx = parser->ctx;
j++;
}

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 0ed6430..1693fc7e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -120,7 +120,7 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
 {
struct amdgpu_device *adev = ring->adev;
struct amdgpu_ib *ib = [0];
-   struct amdgpu_ctx *ctx, *old_ctx;
+   uint64_t fence_context = 0, old = ring->last_fence_context;
struct fence *hwf;
struct amdgpu_vm *vm = NULL;
unsigned i, patch_offset = ~0;
@@ -130,9 +130,10 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned 
num_ibs,
if (num_ibs == 0)
return -EINVAL;

-   

[PATCH 04/14] drm/amdgpu: keep vm in job instead of ib (v2)

[Alex Deucher]

From: Monk Liu 

ib.vm is a legacy way to get vm, after scheduler
implemented vm should be get from job, and all ibs
from one job share the same vm, no need to keep ib.vm
just move vm field to job.

this patch as well add job as paramter to ib_schedule
so it can get vm from job->vm.

v2: agd: sqaush in:
drm/amdgpu: check if ring emit_vm_flush exists in vm flush

No vm flush on engines that don't support VM.

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

Signed-off-by: Monk Liu 
Reviewed-by: Alex Deucher 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h |  6 +++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c  |  3 ++-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c  | 16 
 drivers/gpu/drm/amd/amdgpu/amdgpu_job.c |  9 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c |  4 ++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c  |  3 ++-
 drivers/gpu/drm/amd/amdgpu/cik_sdma.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c   |  2 +-
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c   |  4 ++--
 drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c  |  2 +-
 drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c  |  2 +-
 12 files changed, 25 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 7bea3e2..2ee99dc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -740,7 +740,6 @@ struct amdgpu_ib {
uint64_tgpu_addr;
uint32_t*ptr;
struct amdgpu_user_fence*user;
-   struct amdgpu_vm*vm;
unsignedvm_id;
uint64_tvm_pd_addr;
struct amdgpu_ctx   *ctx;
@@ -763,7 +762,7 @@ enum amdgpu_ring_type {
 extern const struct amd_sched_backend_ops amdgpu_sched_ops;

 int amdgpu_job_alloc(struct amdgpu_device *adev, unsigned num_ibs,
-struct amdgpu_job **job);
+struct amdgpu_job **job, struct amdgpu_vm *vm);
 int amdgpu_job_alloc_with_ib(struct amdgpu_device *adev, unsigned size,
 struct amdgpu_job **job);

@@ -1191,7 +1190,7 @@ int amdgpu_ib_get(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,
 void amdgpu_ib_free(struct amdgpu_device *adev, struct amdgpu_ib *ib, struct 
fence *f);
 int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs,
   struct amdgpu_ib *ib, struct fence *last_vm_update,
-  struct fence **f);
+  struct amdgpu_job *job, struct fence **f);
 int amdgpu_ib_pool_init(struct amdgpu_device *adev);
 void amdgpu_ib_pool_fini(struct amdgpu_device *adev);
 int amdgpu_ib_ring_tests(struct amdgpu_device *adev);
@@ -1247,6 +1246,7 @@ struct amdgpu_cs_parser {
 struct amdgpu_job {
struct amd_sched_jobbase;
struct amdgpu_device*adev;
+   struct amdgpu_vm*vm;
struct amdgpu_ring  *ring;
struct amdgpu_sync  sync;
struct amdgpu_ib*ibs;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index 2ebba29..1a06596 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -120,6 +120,7 @@ static int amdgpu_cs_user_fence_chunk(struct 
amdgpu_cs_parser *p,
 int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void *data)
 {
struct amdgpu_fpriv *fpriv = p->filp->driver_priv;
+   struct amdgpu_vm *vm = >vm;
union drm_amdgpu_cs *cs = data;
uint64_t *chunk_array_user;
uint64_t *chunk_array;
@@ -214,7 +215,7 @@ int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, void 
*data)
}
}

-   ret = amdgpu_job_alloc(p->adev, num_ibs, >job);
+   ret = amdgpu_job_alloc(p->adev, num_ibs, >job, vm);
if (ret)
goto free_all_kdata;

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
index 0129617..0ed6430 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
@@ -74,7 +74,6 @@ int amdgpu_ib_get(struct amdgpu_device *adev, struct 
amdgpu_vm *vm,
ib->gpu_addr = amdgpu_sa_bo_gpu_addr(ib->sa_bo);
}

-   ib->vm = vm;
ib->vm_id = 0;

return 0;
@@ -117,13 +116,13 @@ void amdgpu_ib_free(struct amdgpu_device *adev, struct 
amdgpu_ib *ib, struct fen
  */
 int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs,
   struct amdgpu_ib *ibs, struct fence *last_vm_update,
-  struct fence **f)
+  struct amdgpu_job *job, struct fence **f)
 {
struct amdgpu_device *adev = ring->adev;
struct amdgpu_ib *ib = [0];
struct amdgpu_ctx *ctx, *old_ctx;
-   struct amdgpu_vm *vm;
struct fence *hwf;
+   

[PATCH 03/14] drm/amdgpu: make vmid owner be client_id

[Alex Deucher]

From: Chunming Zhou 

Using the pointer is not adequate.

Signed-off-by: Chunming Zhou 
Reviewed-by: Alex Deucher 
Reviewed-by: Monk Liu 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 275378c..2c3d955 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -185,7 +185,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
amdgpu_ring *ring,
if (!id)
continue;

-   if (atomic_long_read(>owner) != (long)vm)
+   if (atomic_long_read(>owner) != vm->client_id)
continue;

if (pd_addr != id->pd_gpu_addr)
@@ -261,7 +261,7 @@ int amdgpu_vm_grab_id(struct amdgpu_vm *vm, struct 
amdgpu_ring *ring,

list_move_tail(>list, >vm_manager.ids_lru);
id->last_user = ring;
-   atomic_long_set(>owner, (long)vm);
+   atomic_long_set(>owner, vm->client_id);
vm->ids[ring->idx] = id;

*vm_id = id - adev->vm_manager.ids;
@@ -1485,7 +1485,7 @@ void amdgpu_vm_fini(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)
 list) {
if (!id)
continue;
-   if (atomic_long_read(>owner) == (long)vm) {
+   if (atomic_long_read(>owner) == vm->client_id) {
atomic_long_set(>owner, 0);
id->pd_gpu_addr = 0;
}
-- 
2.5.5

[PATCH 02/14] drm/amdgpu: add client id for every vm

[Alex Deucher]

From: Chunming Zhou 

This adds a unique id for each vm client so we can
properly track them.

Signed-off-by: Chunming Zhou 
Reviewed-by: Alex Deucher 
Reviewed-by: Monk Liu 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h| 6 ++
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 ++
 2 files changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 1012bd3..7bea3e2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -363,6 +363,7 @@ struct amdgpu_fence_driver {
 /* some special values for the owner field */
 #define AMDGPU_FENCE_OWNER_UNDEFINED   ((void*)0ul)
 #define AMDGPU_FENCE_OWNER_VM  ((void*)1ul)
+#define AMDGPU_CLIENT_ID_RESERVED   2

 #define AMDGPU_FENCE_FLAG_64BIT (1 << 0)
 #define AMDGPU_FENCE_FLAG_INT   (1 << 1)
@@ -885,6 +886,9 @@ struct amdgpu_vm {

/* Scheduler entity for page table updates */
struct amd_sched_entity entity;
+
+   /* client id */
+   u64 client_id;
 };

 struct amdgpu_vm_id {
@@ -924,6 +928,8 @@ struct amdgpu_vm_manager {
struct amdgpu_ring  *vm_pte_rings[AMDGPU_MAX_RINGS];
unsignedvm_pte_num_rings;
atomic_tvm_pte_next_ring;
+   /* client id counter */
+   atomic64_t  client_counter;
 };

 void amdgpu_vm_manager_init(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index e06d066..275378c 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1386,6 +1386,7 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)
for (i = 0; i < AMDGPU_MAX_RINGS; ++i)
vm->ids[i] = NULL;
vm->va = RB_ROOT;
+   vm->client_id = atomic64_inc_return(>vm_manager.client_counter);
spin_lock_init(>status_lock);
INIT_LIST_HEAD(>invalidated);
INIT_LIST_HEAD(>cleared);
@@ -1514,6 +1515,7 @@ void amdgpu_vm_manager_init(struct amdgpu_device *adev)
}

atomic_set(>vm_manager.vm_pte_next_ring, 0);
+   atomic64_set(>vm_manager.client_counter, 
AMDGPU_CLIENT_ID_RESERVED);
 }

 /**
-- 
2.5.5

[PATCH 01/14] drm/amdgpu: fix wrong release of vmid owner

[Alex Deucher]

From: Chunming Zhou 

The release of the vmid owner was not handled
correctly.  We need to take the lock and walk
the lru list.

Signed-off-by: Chunming Zhou 
Reviewed-by: Alex Deucher 
Reviewed-by: Monk Liu 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
index 856116a..e06d066 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -1454,6 +1454,7 @@ error_free_sched_entity:
 void amdgpu_vm_fini(struct amdgpu_device *adev, struct amdgpu_vm *vm)
 {
struct amdgpu_bo_va_mapping *mapping, *tmp;
+   struct amdgpu_vm_id *id, *id_tmp;
int i;

amd_sched_entity_fini(vm->entity.sched, >entity);
@@ -1478,14 +1479,17 @@ void amdgpu_vm_fini(struct amdgpu_device *adev, struct 
amdgpu_vm *vm)
amdgpu_bo_unref(>page_directory);
fence_put(vm->page_directory_fence);

-   for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
-   struct amdgpu_vm_id *id = vm->ids[i];
-
+   mutex_lock(>vm_manager.lock);
+   list_for_each_entry_safe(id, id_tmp, >vm_manager.ids_lru,
+list) {
if (!id)
continue;
-
-   atomic_long_cmpxchg(>owner, (long)vm, 0);
+   if (atomic_long_read(>owner) == (long)vm) {
+   atomic_long_set(>owner, 0);
+   id->pd_gpu_addr = 0;
+   }
}
+   mutex_unlock(>vm_manager.lock);
 }

 /**
-- 
2.5.5

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

[Daniel Vetter]

On Wed, May 04, 2016 at 10:49:53AM +0100, Robert Bragg wrote:
> On Wed, May 4, 2016 at 10:09 AM, Martin Peres  linux.intel.com>
> wrote:
> 
> > On 03/05/16 23:03, Robert Bragg wrote:
> >
> >>
> >>
> >> On Tue, May 3, 2016 at 8:34 PM, Robert Bragg  >> > wrote:
> >>
> >> Sorry for the delay replying to this, I missed it.
> >>
> >> On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres  >> > wrote:
> >>
> >> On 20/04/16 17:23, Robert Bragg wrote:
> >>
> >> Gen graphics hardware can be set up to periodically write
> >> snapshots of
> >> performance counters into a circular buffer via its
> >> Observation
> >> Architecture and this patch exposes that capability to
> >> userspace via the
> >> i915 perf interface.
> >>
> >> Cc: Chris Wilson  >> >
> >> Signed-off-by: Robert Bragg  >> >
> >> Signed-off-by: Zhenyu Wang  >> >
> >>
> >> ---
> >>   drivers/gpu/drm/i915/i915_drv.h |  56 +-
> >>   drivers/gpu/drm/i915/i915_gem_context.c |  24 +-
> >>   drivers/gpu/drm/i915/i915_perf.c| 940
> >> +++-
> >>   drivers/gpu/drm/i915/i915_reg.h | 338 
> >>   include/uapi/drm/i915_drm.h |  70 ++-
> >>   5 files changed, 1408 insertions(+), 20 deletions(-)
> >>
> >> +
> >> +
> >> +   /* It takes a fairly long time for a new MUX
> >> configuration to
> >> +* be be applied after these register writes. This
> >> delay
> >> +* duration was derived empirically based on the
> >> render_basic
> >> +* config but hopefully it covers the maximum
> >> configuration
> >> +* latency...
> >> +*/
> >> +   mdelay(100);
> >>
> >>
> >> With such a HW and SW design, how can we ever expose hope to get
> >> any
> >> kind of performance when we are trying to monitor different
> >> metrics on each
> >> draw call? This may be acceptable for system monitoring, but it
> >> is problematic
> >> for the GL extensions :s
> >>
> >>
> >> Since it seems like we are going for a perf API, it means that
> >> for every change
> >> of metrics, we need to flush the commands, wait for the GPU to
> >> be done, then
> >> program the new set of metrics via an IOCTL, wait 100 ms, and
> >> then we may
> >> resume rendering ... until the next change. We are talking about
> >> a latency of
> >> 6-7 frames at 60 Hz here... this is non-negligeable...
> >>
> >>
> >> I understand that we have a ton of counters and we may hide
> >> latency by not
> >> allowing using more than half of the counters for every draw
> >> call or frame, but
> >> even then, this 100ms delay is killing this approach altogether.
> >>
> >>
> >>
> >>
> >> So revisiting this to double check how things fail with my latest
> >> driver/tests without the delay, I apparently can't reproduce test
> >> failures without the delay any more...
> >>
> >> I think the explanation is that since first adding the delay to the
> >> driver I also made the the driver a bit more careful to not forward
> >> spurious reports that look invalid due to a zeroed report id field, and
> >> that mechanism keeps the unit tests happy, even though there are still
> >> some number of invalid reports generated if we don't wait.
> >>
> >> One problem with simply having no delay is that the driver prints an
> >> error if it sees an invalid reports so I get a lot of 'Skipping
> >> spurious, invalid OA report' dmesg spam. Also this was intended more as
> >> a last resort mechanism, and I wouldn't feel too happy about squashing
> >> the error message and potentially sweeping other error cases under the
> >> carpet.
> >>
> >> Experimenting to see if the delay can at least be reduced, I brought the
> >> delay up in millisecond increments and found that although I still see a
> >> lot of spurious reports only waiting 1 or 5 milliseconds, at 10
> >> milliseconds its reduced quite a bit and at 15 milliseconds I don't seem
> >> to have any errors.
> >>
> >> 15 milliseconds is still a long time, but at least not as long as 100.
> >>
> >
> > OK, so the issue does not come from the HW after all, great!
> >
> 
> Erm, I'm not sure that's a conclusion we can make here...
> 
> The upshot here was really just reducing the delay from 100ms to 15ms.
> Previously I arrived at a workable delay by jumping the delay in orders of
> 

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

 margin
aren't well tuned) and it's helpful to have the feedback, in case we end up
in a situation where we see this kind of message too frequently which might
indicate an issue to investigate.


> - reading 0 sounds more like bad synchronization.


I suppose I haven't thoroughly considered if we should return zero in any
case  - normally that would imply EOF so we get to choose what that implies
here. I don't think the driver should ever return 0 from read() currently.

A few concious choices re: read() return values have been:

- never ever return partial records (or rather even if a partial record
were literally copied into the userspace buffer, but an error were hit in
the middle of copying a full sample then that record wouldn't be accounted
for in the byte count returned.)

- Don't throw away records successfully copied, due to a later error. This
simplifies error handling paths internally and reporting
EAGAIN/ENOSPC/EFAULT errors and means data isn't lost. The precedence for
what we return is 1) did we successfully copy some reports? report bytes
copied for complete records. 2) did we encounter an error? report that if
so. 3) return -EAGAIN. (though for a blocking fd this will be handled
internally).



> Have you tried quiescing

the entire gpu (to make sure nothing is happen) and disabling OA, then
>   updating, and then restarting? At least on a very quick look I didn't
>   spot that. Random delays freak me out a bit, but wouldn't be surprised
>   if really needed.
>

Experimenting yesterday, it seems I can at least reduce the delay to around
15ms (granted that's still pretty huge), and it's also workable to have
userspace sleep for this time (despite the mdelay I originally went with)

Haven't tried this, but yeah could be interesting to experiment if the MUX
config lands faster in different situation such as when the HW is idle.

Thanks,
- Robert


>
> Cheers, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/c0a76005/attachment-0001.html>

[PATCH i-g-t] tests/kms: Add test for testing rmfb framebuffer removal handling.

[Maarten Lankhorst]

Add some tests to BAT to ensure rmfb/lastclose handling doesn't break again.

The test will set framebuffers on each crtc, and then try rmfb or close.
Afterwards it rechecks to make sure the framebuffers are removed.

Signed-off-by: Maarten Lankhorst 
---
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b73f48d95568..92c84d697ded 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -97,6 +97,7 @@ TESTS_progs_M = \
kms_plane \
kms_psr_sink_crc \
kms_render \
+   kms_rmfb_basic \
kms_rotation_crc \
kms_setmode \
kms_universal_plane \
diff --git a/tests/kms_rmfb_basic.c b/tests/kms_rmfb_basic.c
new file mode 100644
index ..a3fde9f43788
--- /dev/null
+++ b/tests/kms_rmfb_basic.c
@@ -0,0 +1,180 @@
+/*
+ * Copyright © 2016 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.
+ */
+
+#include "igt.h"
+#include "drmtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#ifndef DRM_CAP_CURSOR_WIDTH
+#define DRM_CAP_CURSOR_WIDTH 0x8
+#endif
+#ifndef DRM_CAP_CURSOR_HEIGHT
+#define DRM_CAP_CURSOR_HEIGHT 0x9
+#endif
+
+struct rmfb_data {
+   int drm_fd;
+   igt_display_t display;
+};
+
+/*
+ * 1. Set primary plane to a known fb.
+ * 2. Make sure getcrtc returns the correct fb id.
+ * 3. Call rmfb on the fb.
+ * 4. Make sure getcrtc returns 0 fb id.
+ *
+ * RMFB is supposed to free the framebuffers from any and all planes,
+ * so test this and make sure it works.
+ */
+static bool
+test_rmfb(struct rmfb_data *data, igt_output_t *output, enum pipe pipe, bool 
reopen)
+{
+   struct igt_fb fb, argb_fb;
+   drmModeModeInfo *mode;
+   igt_plane_t *plane;
+   drmModeCrtc *crtc;
+   uint64_t cursor_width, cursor_height;
+
+   igt_output_set_pipe(output, pipe);
+   igt_display_commit(>display);
+
+   if (!output->valid) {
+   igt_output_set_pipe(output, PIPE_ANY);
+   return false;
+   }
+
+   mode = igt_output_get_mode(output);
+
+   igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE, );
+
+   igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_ARGB, LOCAL_DRM_FORMAT_MOD_NONE, _fb);
+
+   do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_WIDTH, _width));
+   if (cursor_width > mode->hdisplay)
+   cursor_width = mode->hdisplay;
+
+   do_or_die(drmGetCap(data->drm_fd, DRM_CAP_CURSOR_HEIGHT, 
_height));
+   if (cursor_height > mode->vdisplay)
+   cursor_height = mode->vdisplay;
+
+   /*
+* Make sure these buffers are suited for display use
+* because most of the modeset operations must be fast
+* later on.
+*/
+   for_each_plane_on_pipe(>display, pipe, plane) {
+   if (plane->is_cursor) {
+   igt_plane_set_fb(plane, _fb);
+   igt_fb_set_size(_fb, plane, cursor_width, 
cursor_height);
+   igt_plane_set_size(plane, cursor_width, cursor_height);
+   } else {
+   igt_plane_set_fb(plane, );
+   }
+   }
+
+   igt_display_commit2(>display, data->display.is_atomic ? 
COMMIT_ATOMIC : COMMIT_UNIVERSAL);
+
+   crtc = drmModeGetCrtc(data->drm_fd, output->config.crtc->crtc_id);
+
+   igt_assert_eq(crtc->buffer_id, fb.fb_id);
+
+   drmModeFreeCrtc(crtc);
+
+   if (reopen) {
+   close(data->drm_fd);
+
+   data->drm_fd = drm_open_driver_master(DRIVER_ANY);
+   drmSetClientCap(data->drm_fd, DRM_CLIENT_CAP_UNIVERSAL_PLANES, 
1);
+   drmSetClientCap(data->drm_fd, DRM_CLIENT_CAP_ATOMIC, 1);
+   } else {
+   igt_remove_fb(data->drm_fd, );
+   igt_remove_fb(data->drm_fd, _fb);
+ 

[pull] radeon and amdgpu drm-next-4.7

[Alex Deucher]

Hi Dave,

This is the first big radeon/amdgpu pull request for 4.7.  Highlights:
- Polaris support in amdgpu
  Current display stack on par with other asics, for advanced features DAL is 
required
  Power management support
  Support for GFX, Compute, SDMA, UVD, VCE
- VCE and UVD init/fini cleanup in radeon
- GPUVM improvements
- Scheduler improvements
- Clockgating improvements
- Powerplay improvements
- TTM changes to support driver specific LRU update mechanism
- Radeon support for new Mesa features
- ASYNC pageflip support for radeon
- Lots of bug fixes and code cleanups

The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:

  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into 
drm-next (2016-04-29 14:57:51 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.7

for you to fetch changes up to a56743f8e11a4254d00da739bab152331bda57e9:

  drm/amdgpu: Replace rcu_assign_pointer() with RCU_INIT_POINTER() (2016-05-02 
15:29:12 -0400)


Alex Deucher (37):
  drm/amd/powerplay: fix stutter setup in mclk level init
  drm/amdgpu: add new CG flag for ROM clockgating
  drm/amdgpu/gfx: add proper CG flags for fiji
  drm/amdgpu/sdma: add proper CG flags for fiji
  drm/amdgpu/common: add proper CG flags for fiji
  drm/amdgpu/gmc: add proper CG flags for fiji
  drm/amdgpu/gfx8: rename send_serdes_cmd
  drm/amdgpu/gfx: adjust gfx_v8_0_send_serdes_cmd for ST
  drm/amdgpu: add a new set of rlc function pointers
  drm/amdgpu/gfx: rework fiji cg functions so they can be shared
  drm/amdgpu: enable gfx clockgating for CZ
  drm/amdgpu: enable gfx clockgating for ST (v2)
  drm/amdgpu/vi: rename fiji cg functions
  drm/amdgpu: enable gmc clockgating for CZ
  drm/amdgpu: enable gmc clockgating for ST
  drm/amdgpu/sdma: rename fiji cg functions
  drm/amdgpu: enable sdma clockgating on CZ
  drm/amdgpu: enable sdma clockgating on ST
  drm/amd: add DCE 11.2 register headers
  drm/amdgpu: add ELM/BAF asic types
  drm/amdgpu: add ELM/BAF DCE11 configs (v2)
  drm/amdgpu: use defines for CRTCs and AMFT blocks
  drm/amdgpu: bump the afmt limit for CZ, ST, Polaris
  drm/amdgpu: update atombios.h (v2)
  drm/amdgpu/atom: add SetDCEClock helper
  drm/amdgpu/atom: add support for new SetPixelClock table
  drm/amdgpu/atom: add support for new DIGxEncoderControl cmd table
  drm/amdgpu/atom: add support for new UNIPHYTransmitterContol cmd table
  drm/amdgpu: add ELM/BAF support to dce_v11_0_pick_pll (v2)
  drm/amdgpu/dce11: update pll programming for ELM/BAF
  drm/amdgpu/dce11: add dce clock setting for ELM/BAF
  drm/amdgpu: add an interface to get gfx constants from atombios
  drm/amd/powerplay: fix copy paste error in error message
  drm/powerplay: add missing clockgating callback for tonga
  drm/amdgpu/fiji: set UVD CG state when enabling UVD DPM (v2)
  drm/amdgpu/uvd6: add bypass support for fiji (v3)
  drm/amdgpu: use drm_mode_vrefresh() rather than mode->vrefresh

Andrey Grodzovsky (1):
  drm/amdgpu: Set PFLIP_SUBMITTED for crtc after address update

Arindam Nath (3):
  drm/radeon: add support for loading new UVD fw
  drm/radeon: handle more than 10 UVD sessions
  drm/amdgpu: handle more than 10 UVD sessions (v2)

Bas Nieuwenhuizen (1):
  drm/radeon: Allow setting shader registers using DMA/COPY packet3 on SI.

Christian König (22):
  drm/amdgpu: drop the GTT power of two limit
  drm/amdgpu: change parameter passing in the VM code
  drm/amdgpu: use BO pages instead of GART array
  drm/amdgpu: remove GART page addr array
  drm/amdgpu: optionally enable GART debugfs file
  drm/amdgpu: merge VM manager and VM context ID structure
  drm/amdgpu: use a sync object for VMID fences v2
  drm/amdgpu: add a fence after the VM flush
  drm/amdgpu: reuse VMIDs already assigned to a process
  drm/amdgpu: use max_dw in ring_init
  drm/amdgpu: reduce the ring size for GFX
  drm/amdgpu: reduce the ring size for SDMA
  drm/amdgpu: use the ring name for debugfs (v2)
  drm/amdgpu: fix the coding style in amdgpu_ring.c
  drm/ttm: don't wait for BO on initial allocation
  drm/ttm: remove use_ticket parameter from ttm_bo_reserve
  drm/ttm: remove lazy parameter from ttm_bo_wait
  drm/ttm: remove unused validation sequence
  drm/ttm: add optional LRU removal callback v2
  drm/ttm: implement LRU add callbacks v2
  drm/amdgpu: group BOs by log2 of the size on the LRU v2
  drm/amdgpu: remove sorting of CS BOs

Chunming Zhou (4):
  drm/amdgpu: improve vmid assigment V2
  drm/amdgpu: double fence slot
  drm/amdgpu: only update last_flush when vmid doesn't have other new owner
  drm/amdgpu: fix error checking when reuse vmid on same ring

[PATCH] drm/edid : calculate vsync and hsync from range limits block according to the EDID 1.4

[Prosyak, Vitaly]

Reduce the image size.

Yes, this is unrelated to the previous patch, but for the  coding  it is 
important to have same style for range limit EIDD block.
I mean the following: for calculation  if mode is in range one style ,but for 
ranges retrieval another style.
I am proposing to follow the style which looks to me closer to the spec.

I have attached the screenshot demonstrates those magic numbers.
Vitaly

-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Tuesday, May 03, 2016 4:26 PM
To: Prosyak, Vitaly
Cc: dri-devel at lists.freedesktop.org
Subject: Re: [PATCH] drm/edid : calculate vsync and hsync from range limits 
block according to the EDID 1.4

On Tue, May 03, 2016 at 11:05:25AM -0400, Vitaly Prosyak wrote:
> Do calculation of vsync and hsync from range limits EDID block 
> according to the spec. EDID 1.4.
> 
> Signed-off-by: Vitaly Prosyak 

Seems unrelated to the previous patch, please submit in a separate series.

> ---
>  drivers/gpu/drm/drm_edid.c | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c 
> index 7e49962..601152b 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1977,11 +1977,11 @@ mode_in_hsync_range(const struct drm_display_mode 
> *mode,
>   int hsync, hmin, hmax;
>  
>   hmin = t[7];
> - if (edid->revision >= 4)
> - hmin += ((t[4] & 0x04) ? 255 : 0);
> + if (edid->revision >= 4 && ((t[4] & 0x0c) == 0x0c))
> + hmin += 255 ;
>   hmax = t[8];
> - if (edid->revision >= 4)
> - hmax += ((t[4] & 0x08) ? 255 : 0);
> + if (edid->revision >= 4 && (t[4] & 0x08))
> + hmax += 255;

Please don't reshuffle code without functional changes. Same above, for such 
small bugfixes it's best to only change what you need changed.

It might also be useful to introduce symbolic #defines for all these magic 
constants.
-Daniel


>   hsync = drm_mode_hsync(mode);
>  
>   return (hsync <= hmax && hsync >= hmin); @@ -1994,11 +1994,11 @@ 
> mode_in_vsync_range(const struct drm_display_mode *mode,
>   int vsync, vmin, vmax;
>  
>   vmin = t[5];
> - if (edid->revision >= 4)
> - vmin += ((t[4] & 0x01) ? 255 : 0);
> + if (edid->revision >= 4 && ((t[4] & 0x03) == 0x03))
> + vmin += 255;
>   vmax = t[6];
> - if (edid->revision >= 4)
> - vmax += ((t[4] & 0x02) ? 255 : 0);
> + if (edid->revision >= 4 && (t[4] & 0x02))
> + vmax += 255;
>   vsync = drm_mode_vrefresh(mode);
>  
>   return (vsync <= vmax && vsync >= vmin);
> --
> 1.9.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
-- next part --
A non-text attachment was scrubbed...
Name: range_limits_1.4_edid_block.JPG
Type: image/jpeg
Size: 177026 bytes
Desc: range_limits_1.4_edid_block.JPG
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/bb90e41a/attachment-0001.jpe>

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

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

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

--- Comment #4 from Andrzej Mendel-Nykorowycz  ---
Created attachment 123457
  --> https://bugs.freedesktop.org/attachment.cgi?id=123457=edit
dmesg

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

[PATCH 5/9] dt-bindings: msm/dsi: Some binding doc cleanups

[Archit Taneja]

On 05/03/2016 07:35 PM, Philipp Zabel wrote:
> Am Dienstag, den 03.05.2016, 16:27 +0530 schrieb Archit Taneja:
>> Some cleanups:
>>
>> - Use simpler names for DT nodes in the example
>> - Fix phandle for specifying data lane mapping in the example.
>> - Use references instead of dumping Document links everywhere
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   .../devicetree/bindings/display/msm/dsi.txt| 23 
>> +++---
>>   1 file changed, 12 insertions(+), 11 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
>> b/Documentation/devicetree/bindings/display/msm/dsi.txt
>> index f5948c4..bf41d7c 100644
>> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
>> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
>> @@ -11,8 +11,7 @@ Required properties:
>> be 0 or 1, since we have 2 DSI controllers at most for now.
>>   - interrupts: The interrupt signal from the DSI block.
>>   - power-domains: Should be < MDSS_GDSC>.
>> -- clocks: device clocks
>> -  See Documentation/devicetree/bindings/clocks/clock-bindings.txt for 
>> details.
>> +- clocks: Phandles to device clocks as descirbed in [1]
>
> s/descirbed/described/
>
>>   - clock-names: the following clocks are required:
>> * "mdp_core_clk"
>> * "iface_clk"
>> @@ -31,8 +30,7 @@ Required properties:
>>
>>   Optional properties:
>>   - panel at 0: Node of panel connected to this DSI controller.
>> -  See files in Documentation/devicetree/bindings/display/panel/ for each 
>> supported
>> -  panel.
>> +  See files in [2] for each supported panel.
>>   - qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
>> driving a panel which needs 2 DSI links.
>>   - qcom,master-dsi: Boolean value indicating if the DSI controller is 
>> driving
>> @@ -48,7 +46,7 @@ Optional properties:
>>
>> DSI Endpoint properties:
>> - remote-endpoint: set to phandle of the connected panel's endpoint.
>> -See Documentation/devicetree/bindings/graph.txt for device graph info.
>> +See [3] for device graph info.
>> - qcom,data-lane-map: this describes how the logical DSI lanes are mapped
>>   to the physical lanes on the given platform. The value contained in
>>   index n describes what logical data lane is mapped to the physical data
>> @@ -89,8 +87,7 @@ Required properties:
>>   - qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should
>> be 0 or 1, since we have 2 DSI PHYs at most for now.
>>   - power-domains: Should be < MDSS_GDSC>.
>> -- clocks: device clocks
>> -  See Documentation/devicetree/bindings/clocks/clock-bindings.txt for 
>> details.
>> +- clocks: Phandles to device clocks as descirbed in [1]
>
> s/descirbed/described/

Thanks, will fix these.

>
>>   - clock-names: the following clocks are required:
>> * "iface_clk"
>>   - vddio-supply: phandle to vdd-io regulator device node
>> @@ -99,8 +96,12 @@ Optional properties:
>>   - qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO 
>> mode PHY
>> regulator is wanted.
>>
>> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +[2] Documentation/devicetree/bindings/display/panel/
>> +[3] Documentation/devicetree/bindings/graph.txt
>> +
>>   Example:
>> -mdss_dsi0: qcom,mdss_dsi at fd922800 {
>> +dsi0: dsi at fd922800 {
>>  compatible = "qcom,mdss-dsi-ctrl";
>>  qcom,dsi-host-index = <0>;
>>  interrupt-parent = <_mdp>;
>> @@ -128,7 +129,7 @@ Example:
>>  vdd-supply = <_l22>;
>>  vddio-supply = <_l12>;
>>
>> -qcom,dsi-phy = <_dsi_phy0>;
>> +qcom,dsi-phy = <_phy0>;
>>
>>
>>  qcom,dual-dsi-mode;
>>  qcom,master-dsi;
>> @@ -156,12 +157,12 @@ Example:
>>  port {
>>  dsi0_out: endpoint {
>>  remote-endpoint = <_in>;
>> -lanes = <0 1 2 3>;
>> +qcom,data-lane-map = <0 1 2 3>;
>
> See my comment about the CSI-2 data-lanes binding in the other mail,
> could the existing binding be reused?

Yes, I'll incorporate the existing binding.

Thanks for the review.

Archit

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

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

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

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

--- Comment #3 from Andrzej Mendel-Nykorowycz  ---
Created attachment 123456
  --> https://bugs.freedesktop.org/attachment.cgi?id=123456=edit
Xorg.0.log

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

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

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

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

--- Comment #2 from Alex Deucher  ---
Please attach your xorg log and dmesg output.

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

[PATCH 8/9] dt-bindings: msm/dsi: Modify port and PHY bindings

[Archit Taneja]

On 05/03/2016 07:32 PM, Philipp Zabel wrote:
> Am Dienstag, den 03.05.2016, 16:28 +0530 schrieb Archit Taneja:
>> The DSI node now has two ports that describe the connection between the
>> MDP interface output and the DSI input, and the connection between the DSI
>> output and the connected panel/bridge. Update the properties and the
>> example.
>>
>> Also, use generic PHY bindings instead of the custom one.
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   .../devicetree/bindings/display/msm/dsi.txt| 53 
>> +++---
>>   1 file changed, 37 insertions(+), 16 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
>> b/Documentation/devicetree/bindings/display/msm/dsi.txt
>> index bf41d7c..0223f06 100644
>> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
>> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
>> @@ -25,12 +25,18 @@ Required properties:
>>   - vdd-supply: phandle to vdd regulator device node
>>   - vddio-supply: phandle to vdd-io regulator device node
>>   - vdda-supply: phandle to vdda regulator device node
>> -- qcom,dsi-phy: phandle to DSI PHY device node
>> +- phys: phandle to DSI PHY device node
>> +- phy-names: the name of the corresponding PHY device
>
> Should "dsi_phy" be specified here?
>
> Also is there any kind of system to the PHY naming? I've seen more
> bindings use hyphen instead of underscore in the name, for example.
> I have called the MediaTek MIPI_TX PHY "dphy" for no other reason than
> it's a MIPI D-PHY.

I agree with the hyphen part, I'll switch to that.

The DSI PHY block isn't only the D-PHY interface, it also contains a
PLL and some logic to support more complex configurations (for
example, syncing with the PHY connected to another DSI output). That's
the main reason why I left the name as "dsi_phy".

>
>>   - syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2)
>> +- ports: Contains 2 DSI controller ports as child nodes. Each port contains
>> +  an endpoint subnode as defined in [2] and [3]. port at 0 describes the
>> +  connection between the MDP interface output and the DSI input. port at 1
>> +  describes the connection between the DSI output and the connected
>> +  panel/bridge.
>>
>>   Optional properties:
>>   - panel at 0: Node of panel connected to this DSI controller.
>> -  See files in [2] for each supported panel.
>> +  See files in [4] for each supported panel.
>>   - qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
>> driving a panel which needs 2 DSI links.
>>   - qcom,master-dsi: Boolean value indicating if the DSI controller is 
>> driving
>> @@ -42,15 +48,15 @@ Optional properties:
>>   - pinctrl-names: the pin control state names; should contain "default"
>>   - pinctrl-0: the default pinctrl state (active)
>>   - pinctrl-n: the "sleep" pinctrl state
>> -- port: DSI controller output port, containing one endpoint subnode.
>>
>> DSI Endpoint properties:
>> -  - remote-endpoint: set to phandle of the connected panel's endpoint.
>> -See [3] for device graph info.
>> +  - remote-endpoint: For port at 0, set to phandle of the connected 
>> panel/bridge's
>> +input endpoint. For port at 1, set to the MDP interface output.
>> - qcom,data-lane-map: this describes how the logical DSI lanes are mapped
>>   to the physical lanes on the given platform. The value contained in
>>   index n describes what logical data lane is mapped to the physical data
>> -lane n (DATAn, where n lies between 0 and 3).
>> +lane n (DATAn, where n lies between 0 and 3). Only for the endpoint in
>> +port at 1.
>
> I approve of the of graph change, but I notice that the
> qcom,data-lane-map is very similar to the data-lanes property documented
> in Documentation/devicetree/bindings/media/video-interfaces.txt for MIPI
> CSI-2. Could that maybe be reused for DSI?

You're right. I missed out on the existing binding when I posted this.
One difference in this binding is that the indices here point to the
physical lanes, and the value contained in the index is the logical
lane (that's how it's described in the register documentation). For
the "data-lanes" property, it's the other way round. It's still
better to use the existing binding. I'll post a separate patch to
update this.


>
>>   For example:
>>
>> @@ -97,8 +103,9 @@ Optional properties:
>> regulator is wanted.
>>
>>   [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> -[2] Documentation/devicetree/bindings/display/panel/
>> -[3] Documentation/devicetree/bindings/graph.txt
>> +[2] Documentation/devicetree/bindings/graph.txt
>> +[3] Documentation/devicetree/bindings/media/video-interfaces.txt
>> +[4] Documentation/devicetree/bindings/display/panel/
>>
>>   Example:
>>  dsi0: dsi at fd922800 {
>> @@ -129,7 +136,8 @@ Example:
>>  vdd-supply = <_l22>;
>>  vddio-supply = <_l12>;
>>
>> -qcom,dsi-phy = <_phy0>;
>> +phys 

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

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

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

Alex Deucher  changed:

   What|Removed |Added

 Attachment #123454|text/plain  |image/jpg
  mime type||

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

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

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

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

--- Comment #1 from Andrzej Mendel-Nykorowycz  ---
Created attachment 123455
  --> https://bugs.freedesktop.org/attachment.cgi?id=123455=edit
lspci -nn

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

[Bug 95261] R5 M330 GPU lockup with DPM + high power states

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

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

Bug ID: 95261
   Summary: R5 M330 GPU lockup with DPM + high power states
   Product: DRI
   Version: DRI git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: andrzej.mendel at gmail.com

Created attachment 123454
  --> https://bugs.freedesktop.org/attachment.cgi?id=123454=edit
/var/log/syslog at the moment of hangup (photo)

System: Ubuntu 16.06 with Mesa git (padoka ppa) and kernel 4.6-rc6
GPU: Intel HD 5500 + AMD R5 M330 - all command below run with DRI_PRIME=1

I get GPU hangups, which result in freeze after a soft reset, whenever the load
is high enough to push the GPU into higher power states.

If I run, for example, glmark2, only the first frame gets rendered and then the
GPU lockups. After ~30s system freezes with information about GPU soft reset as
the last message in syslog (see attachment)

If I run a non-GPU-intensive commands (say, glxgears with vsync), then the GPU
stays in low power states and I do not get this hangup. If I force lower power
states (echo battery > /sys/class/drm/card1/device/power_dpm_state), I don't
get this hangup even with glmark2.

If I force high power states (echo performance >
/sys/class/drm/card1/device/power_dpm_state; echo high >
/sys/class/drm/card1/device/power_dpm_force_performance_level; echo on >
/sys/class/drm/card1/device/power/control) then I do not get the hangup as long
as there is no activity at all on the GPU. A simple glxgears is enough to
trigger a hangup in this situation.

This bug is present since at least kernel 4.2.

I would appreciate any info on how to debug this further and will provide more
info if requested.

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

[PATCH 2/3] drm: Add DP port types from DP 1.3 specification

[Mika Kahola]

On Tue, 2016-05-03 at 10:35 -0400, Ilia Mirkin wrote:
> 
> On May 3, 2016 9:49 AM, "Mika Kahola"  wrote:
> >
> > DP specification 1.3 defines DP downstream ports for
> > DP++ and wireless devices. Let's add these to port
> > definitions.
> >
> > Signed-off-by: Mika Kahola 
> > ---
> >  include/drm/drm_dp_helper.h | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/include/drm/drm_dp_helper.h
> b/include/drm/drm_dp_helper.h
> > index 92d9a52..9a15099 100644
> > --- a/include/drm/drm_dp_helper.h
> > +++ b/include/drm/drm_dp_helper.h
> > @@ -210,6 +210,8 @@
> >  # define DP_DS_PORT_TYPE_DVI   2
> >  # define DP_DS_PORT_TYPE_HDMI  3
> >  # define DP_DS_PORT_TYPE_NON_EDID  4
> > +# define DP_DP_PORT_TYPE_DP_DUALMODE5
> 
> DP_DS right? (Like all the others)
Indeed, that's a typo. I'll throw another round to fix this. Good catch!

Cheers,
Mika
> 
> > +# define DP_DS_PORT_TYPE_WIRELESS   6
> >  # define DP_DS_PORT_HPD(1 << 3)
> >  /* offset 1 for VGA is maximum megapixels per second / 8 */
> >  /* offset 2 */
> > --
> > 1.9.1
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 

-- 
Mika Kahola - Intel OTC

[pull] radeon and amdgpu drm-fixes-4.6

[Alex Deucher]

Hi Dave,

A few small fixes for 4.6:
- fix a hang in the display engine seen with some bad modes
- Metadata use after free fix

The following changes since commit ea99697814d6e64927e228675a6eb7fa76014648:

  Merge branch 'drm-fixes-4.6' of git://people.freedesktop.org/~agd5f/linux 
into drm-fixes (2016-04-29 14:31:44 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.6

for you to fetch changes up to 0126d4b9a516256f2432ca0dc78ab293a8255378:

  drm/amdgpu: make sure vertical front porch is at least 1 (2016-05-03 14:50:59 
-0400)


Alex Deucher (2):
  drm/radeon: make sure vertical front porch is at least 1
  drm/amdgpu: make sure vertical front porch is at least 1

Dave Airlie (1):
  drm/amdgpu: set metadata pointer to NULL after freeing.

 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 1 +
 drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 4 
 drivers/gpu/drm/radeon/atombios_encoders.c | 4 
 3 files changed, 9 insertions(+)

[PATCH 19/35] drm/imx: Use lockless gem BO free callback

[Philipp Zabel]

Am Mittwoch, den 04.05.2016, 12:28 +0200 schrieb Daniel Vetter:
> On Wed, Apr 27, 2016 at 02:01:35PM +0200, Philipp Zabel wrote:
> > Am Mittwoch, den 27.04.2016, 13:21 +0200 schrieb Daniel Vetter:
> > > On Wed, Apr 27, 2016 at 12:29:34PM +0200, Philipp Zabel wrote:
> > > > Am Dienstag, den 26.04.2016, 19:29 +0200 schrieb Daniel Vetter:
> > > > > No dev->struct_mutex anywhere to be seen.
> > > > > 
> > > > > Cc: Sascha Hauer 
> > > > > Cc: Philipp Zabel 
> > > > > Signed-off-by: Daniel Vetter 
> > > > > ---
> > > > >  drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
> > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> > > > > b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > > index e26dcdec2aba..2453fb1c68a7 100644
> > > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > > @@ -411,7 +411,7 @@ static struct drm_driver imx_drm_driver = {
> > > > >   .unload = imx_drm_driver_unload,
> > > > >   .lastclose  = imx_drm_driver_lastclose,
> > > > >   .set_busid  = drm_platform_set_busid,
> > > > > - .gem_free_object= drm_gem_cma_free_object,
> > > > > + .gem_free_object_unlocked = drm_gem_cma_free_object,
> > > > >   .gem_vm_ops = _gem_cma_vm_ops,
> > > > >   .dumb_create= drm_gem_cma_dumb_create,
> > > > >   .dumb_map_offset= drm_gem_cma_dumb_map_offset,
> > > > 
> > > > Applied to imx-drm/fixes, thank you.
> > > 
> > > And that compiles for you? Might want to drop the patch again before
> > > someone notices ;-)
> > 
> > Nope, dropped. Nobody will have to.
> 
> I presume you having tried to apply it is as good as an ack, so added to
> drm-misc.

Yes, thank you.

regards
Philipp

[PATCH 19/35] drm/imx: Use lockless gem BO free callback

[Daniel Vetter]

On Wed, Apr 27, 2016 at 02:01:35PM +0200, Philipp Zabel wrote:
> Am Mittwoch, den 27.04.2016, 13:21 +0200 schrieb Daniel Vetter:
> > On Wed, Apr 27, 2016 at 12:29:34PM +0200, Philipp Zabel wrote:
> > > Am Dienstag, den 26.04.2016, 19:29 +0200 schrieb Daniel Vetter:
> > > > No dev->struct_mutex anywhere to be seen.
> > > > 
> > > > Cc: Sascha Hauer 
> > > > Cc: Philipp Zabel 
> > > > Signed-off-by: Daniel Vetter 
> > > > ---
> > > >  drivers/gpu/drm/imx/imx-drm-core.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
> > > > b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > index e26dcdec2aba..2453fb1c68a7 100644
> > > > --- a/drivers/gpu/drm/imx/imx-drm-core.c
> > > > +++ b/drivers/gpu/drm/imx/imx-drm-core.c
> > > > @@ -411,7 +411,7 @@ static struct drm_driver imx_drm_driver = {
> > > > .unload = imx_drm_driver_unload,
> > > > .lastclose  = imx_drm_driver_lastclose,
> > > > .set_busid  = drm_platform_set_busid,
> > > > -   .gem_free_object= drm_gem_cma_free_object,
> > > > +   .gem_free_object_unlocked = drm_gem_cma_free_object,
> > > > .gem_vm_ops = _gem_cma_vm_ops,
> > > > .dumb_create= drm_gem_cma_dumb_create,
> > > > .dumb_map_offset= drm_gem_cma_dumb_map_offset,
> > > 
> > > Applied to imx-drm/fixes, thank you.
> > 
> > And that compiles for you? Might want to drop the patch again before
> > someone notices ;-)
> 
> Nope, dropped. Nobody will have to.

I presume you having tried to apply it is as good as an ack, so added to
drm-misc.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] drm/gem: support BO freeing without dev->struct_mutex

[Daniel Vetter]

On Tue, May 03, 2016 at 11:59:19AM -0400, Alex Deucher wrote:
> On Mon, May 2, 2016 at 4:40 AM, Daniel Vetter  
> wrote:
> > Finally all the core gem and a lot of drivers are entirely free of
> > dev->struct_mutex depencies, and we can start to have an entirely
> > lockless unref path.
> >
> > To make sure that no one who touches the core code accidentally breaks
> > existing drivers which still require dev->struct_mutex I've made the
> > might_lock check unconditional.
> >
> > While at it de-inline the ref/unref functions, they've become a bit
> > too big.
> >
> > v2: Make it not leak like a sieve.
> >
> > v3: Review from Lucas:
> > - drop != NULL in pointer checks.
> > - fixup copypasted kerneldoc to actually match the functions.
> >
> > v4:
> > Add __drm_gem_object_unreference as a fastpath helper for drivers who
> > abolished dev->struct_mutex, requested by Chris.
> >
> > v5: Fix silly mistake in drm_gem_object_unreference_unlocked caught by
> > intel-gfx CI - I checked for gem_free_object instead of
> > gem_free_object_unlocked ...
> >
> > Cc: Chris Wilson 
> > Cc: Alex Deucher 
> > Cc: Lucas Stach 
> > Reviewed-by: Lucas Stach  (v3)
> > Reviewed-by: Chris Wilson  (v4)
> > Signed-off-by: Daniel Vetter 
> 
> Reviewed-by: Alex Deucher 

Thanks for the review. I merged this one plus the driver patches acked by
maintainers to drm-misc.
-Daniel

> 
> > ---
> >  drivers/gpu/drm/drm_gem.c | 54 
> > ++-
> >  include/drm/drmP.h| 15 ++---
> >  include/drm/drm_gem.h | 48 +
> >  3 files changed, 80 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> > index 25dac31eef37..973eb8805ce0 100644
> > --- a/drivers/gpu/drm/drm_gem.c
> > +++ b/drivers/gpu/drm/drm_gem.c
> > @@ -806,12 +806,64 @@ drm_gem_object_free(struct kref *kref)
> >
> > WARN_ON(!mutex_is_locked(>struct_mutex));
> >
> > -   if (dev->driver->gem_free_object != NULL)
> > +   if (dev->driver->gem_free_object_unlocked)
> > +   dev->driver->gem_free_object_unlocked(obj);
> > +   else if (dev->driver->gem_free_object)
> > dev->driver->gem_free_object(obj);
> >  }
> >  EXPORT_SYMBOL(drm_gem_object_free);
> >
> >  /**
> > + * drm_gem_object_unreference_unlocked - release a GEM BO reference
> > + * @obj: GEM buffer object
> > + *
> > + * This releases a reference to @obj. Callers must not hold the
> > + * dev->struct_mutex lock when calling this function.
> > + *
> > + * See also __drm_gem_object_unreference().
> > + */
> > +void
> > +drm_gem_object_unreference_unlocked(struct drm_gem_object *obj)
> > +{
> > +   struct drm_device *dev;
> > +
> > +   if (!obj)
> > +   return;
> > +
> > +   dev = obj->dev;
> > +   might_lock(>struct_mutex);
> > +
> > +   if (dev->driver->gem_free_object_unlocked)
> > +   kref_put(>refcount, drm_gem_object_free);
> > +   else if (kref_put_mutex(>refcount, drm_gem_object_free,
> > +   >struct_mutex))
> > +   mutex_unlock(>struct_mutex);
> > +}
> > +EXPORT_SYMBOL(drm_gem_object_unreference_unlocked);
> > +
> > +/**
> > + * drm_gem_object_unreference - release a GEM BO reference
> > + * @obj: GEM buffer object
> > + *
> > + * This releases a reference to @obj. Callers must hold the 
> > dev->struct_mutex
> > + * lock when calling this function, even when the driver doesn't use
> > + * dev->struct_mutex for anything.
> > + *
> > + * For drivers not encumbered with legacy locking use
> > + * drm_gem_object_unreference_unlocked() instead.
> > + */
> > +void
> > +drm_gem_object_unreference(struct drm_gem_object *obj)
> > +{
> > +   if (obj) {
> > +   WARN_ON(!mutex_is_locked(>dev->struct_mutex));
> > +
> > +   kref_put(>refcount, drm_gem_object_free);
> > +   }
> > +}
> > +EXPORT_SYMBOL(drm_gem_object_unreference);
> > +
> > +/**
> >   * drm_gem_vm_open - vma->ops->open implementation for GEM
> >   * @vma: VM area structure
> >   *
> > diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> > index c81dd2250fc6..bd7b262d7af0 100644
> > --- a/include/drm/drmP.h
> > +++ b/include/drm/drmP.h
> > @@ -580,12 +580,21 @@ struct drm_driver {
> > void (*debugfs_cleanup)(struct drm_minor *minor);
> >
> > /**
> > -* Driver-specific constructor for drm_gem_objects, to set up
> > -* obj->driver_private.
> > +* @gem_free_object: deconstructor for drm_gem_objects
> >  *
> > -* Returns 0 on success.
> > +* This is deprecated and should not be used by new drivers. Use
> > +* @gem_free_object_unlocked instead.
> >  */
> > void (*gem_free_object) (struct drm_gem_object *obj);
> > +
> > +   /**
> > +* @gem_free_object_unlocked: deconstructor for drm_gem_objects
> > +*
> > +* This is for drivers which are not encumbered 

[PATCH 2/9] drm/msm: Drop the gpu binding

[Archit Taneja]

On 05/03/2016 06:12 PM, Rob Herring wrote:
> On Tue, May 3, 2016 at 5:57 AM, Archit Taneja  
> wrote:
>> The driver currently identifies the GPU components it needs by parsing
>> a phandle list from the 'gpus' DT property.
>>
>> This isn't the right binding to go with. So, for now, just search all
>> device nodes and find the gpu node we need by parsing a list of
>> compatible strings.
>>
>> Once we know how to link the kms and gpu drivers, we'll drop this method
>> and use the correct binding.
>>
>> Signed-off-by: Archit Taneja 
>> ---
>>   drivers/gpu/drm/msm/msm_drv.c | 26 +++---
>>   1 file changed, 19 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
>> index 30b8f3b..f717a69 100644
>> --- a/drivers/gpu/drm/msm/msm_drv.c
>> +++ b/drivers/gpu/drm/msm/msm_drv.c
>> @@ -1068,20 +1068,32 @@ static int compare_of(struct device *dev, void *data)
>>  return dev->of_node == data;
>>   }
>>
>> -static int add_components(struct device *dev, struct component_match 
>> **matchptr,
>> -   const char *name)
>> +static const char * const msm_compatible_gpus[] = {
>> +   "qcom,adreno-3xx",
>> +   "qcom,kgsl-3d0",
>> +};
>> +
>> +/*
>> + * We don't know what's the best binding to link the gpu with the drm 
>> device.
>> + * Fow now, we just hunt for all the possible gpus that we support, and add 
>> them
>> + * as components.
>> + */
>> +static int add_gpu_components(struct device *dev,
>> + struct component_match **matchptr)
>>   {
>> -   struct device_node *np = dev->of_node;
>>  unsigned i;
>>
>> -   for (i = 0; ; i++) {
>> +   for (i = 0; i < ARRAY_SIZE(msm_compatible_gpus); i++) {
>
> You can use of_find_matching_node() here instead of a loop.

I'll switch to that.

Thanks,
Archit

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

[Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

t
>> there's a separate MI_REPORT_PERF_COUNT command that Mesa writes either
>> side of a query which writes all the counters for the current OA config
>> (as configured via this i915 perf interface) to a buffer. In addition to
>> collecting reports via MI_REPORT_PERF_COUNT Mesa also configures the
>> unit for periodic sampling to be able to account for potential counter
>> overflow.
>>
>
> Oh, the overflow case is mean. Doesn't the spec mandate the application to
> read at least every second? This is the case for the timestamp queries.
>

For a Haswell GT3 system with 40EUs @ 1GHz some aggregate EU counters may
overflow their 32bits in approximately 40milliseconds. It should be pretty
unusual to see a draw call last that long, but not unimaginable. Might also
be a good draw call to focus on profiling too :-)

For Gen8+ a bunch of the A counters can be reported with 40bits to mitigate
this issue.


>
>
>>
>> It also might be worth keeping in mind that per draw queries will anyway
>> trash the pipelining of work, since it's necessary to put stalls between
>> the draw calls to avoid conflated metrics (not to do with the details of
>> this driver) so use cases will probably be limited to those that just
>> want the draw call numbers but don't mind ruining overall
>> frame/application performance. Periodic sampling or swap-to-swap queries
>> would be better suited to cases that should minimize their impact.
>>
>
> Yes, I agree that there will always be a cost, but with the design
> implemented in nouveau (which barely involves the CPU at all), the
> pipelining is almost unaffected. As in, monitoring every draw call with a
> different metric would lower the performance of glxgears (worst case I
> could think off) but still keep thousands of FPS.
>

I guess it just has different trade offs.

While it sounds like we have a typically higher cost to reconfigure OA (at
least if touching the MUX) once the config is fixed (which can be done
before measuring anything), then I guess the pipelining for queries might
be slightly better with MI_REPORT_PERF_COUNT commands than something
requiring interrupting + executing work on the cpu to switch config (even
if it's cheaper than an OA re-config). I guess nouveau would have the same
need to insert GPU pipeline stalls (just gpu syncing with gpu) to avoid
conflating neighbouring draw call metrics, and maybe the bubbles from those
that can swallow the latency of the software methods.

glxgears might not really exaggerate draw call pipeline stall issues with
only 6 cheap primitives per gear. glxgears hammers context switching more
so than drawing anything. I think a pessimal case would be an app that
depends on large numbers of draw calls per frame that each do enough real
work that stalling for their completion is also measurable.

Funnily enough enabling the OA unit with glxgears can be kind of
problematic for Gen8+ which automatically writes reports on context switch
due to the spam of generating all of those context switch reports.


>
>> The driver is already usable with gputop with this delay and considering
>> how config changes are typically associated with user interaction I
>> wouldn't see this as a show stopper - even though it's not ideal. I
>> think the assertions about it being unusable with GL, were a little
>> overstated based on making frequent OA config changes which is not
>> really how the interface is intended to be used.
>>
>
> Yeah, but a performance warning in mesa, I would be OK with this change.
> Thanks for taking the time to explain!


A performance warning sounds like a sensible idea yup.

Regards,
- Robert


>
>
>>
>> Thanks for starting to take a look through the code.
>>
>> Kind Regards,
>> - Robert
>>
>
> Martin
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/5c906ba4/attachment.html>

[PATCH 1/5] drm/displayid: Enhance version reporting

[Ville Syrjälä]

On Wed, May 04, 2016 at 06:36:48AM +1000, Dave Airlie wrote:
> From: Tomas Bzatek 
> 
> Cosmetic change, let's report more precise revisions and IDs.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=95207
> 
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_edid.c  | 6 +++---
>  include/drm/drm_displayid.h | 6 --
>  2 files changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9a9be9a..c8a3a55 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4168,8 +4168,8 @@ static int drm_parse_display_id(struct drm_connector 
> *connector,
>  
>   base = (struct displayid_hdr *)[idx];
>  
> - DRM_DEBUG_KMS("base revision 0x%x, length %d, %d %d\n",
> -   base->rev, base->bytes, base->prod_id, base->ext_count);
> + DRM_DEBUG_KMS("base revision v%d.%d, edid length %d, bytes %d, prod_id 
> %d ext_count %d\n",
> +   base->ver, base->rev, length, base->bytes, base->prod_id, 
> base->ext_count);
>  
>   if (base->bytes + 5 > length - idx)
>   return -EINVAL;
> @@ -4183,7 +4183,7 @@ static int drm_parse_display_id(struct drm_connector 
> *connector,
>   }
>  
>   block = (struct displayid_block *)[idx + 4];
> - DRM_DEBUG_KMS("block id %d, rev %d, len %d\n",
> + DRM_DEBUG_KMS("block id 0x%x, rev %d, len %d\n",
> block->tag, block->rev, block->num_bytes);
>  
>   switch (block->tag) {
> diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
> index 623b4e9..042f9fc 100644
> --- a/include/drm/drm_displayid.h
> +++ b/include/drm/drm_displayid.h
> @@ -52,7 +52,8 @@
>  #define PRODUCT_TYPE_DIRECT_DRIVE 6
>  
>  struct displayid_hdr {
> - u8 rev;
> + u8 rev:4;
> + u8 ver:4;
>   u8 bytes;
>   u8 prod_id;
>   u8 ext_count;
> @@ -60,7 +61,8 @@ struct displayid_hdr {
>  
>  struct displayid_block {
>   u8 tag;
> - u8 rev;
> + u8 rev:3;
> + u8 reserved:5;
>   u8 num_bytes;
>  } __packed;

Using bitfields in an architecture independent structure doesn't
feel like an entirely good idea to me.

-- 
Ville Syrjälä
Intel OTC

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

[Martin Peres]

On 03/05/16 23:03, Robert Bragg wrote:
>
>
> On Tue, May 3, 2016 at 8:34 PM, Robert Bragg  > wrote:
>
> Sorry for the delay replying to this, I missed it.
>
> On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres  > wrote:
>
> On 20/04/16 17:23, Robert Bragg wrote:
>
> Gen graphics hardware can be set up to periodically write
> snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to
> userspace via the
> i915 perf interface.
>
> Cc: Chris Wilson  >
> Signed-off-by: Robert Bragg  >
> Signed-off-by: Zhenyu Wang  >
> ---
>   drivers/gpu/drm/i915/i915_drv.h |  56 +-
>   drivers/gpu/drm/i915/i915_gem_context.c |  24 +-
>   drivers/gpu/drm/i915/i915_perf.c| 940
> +++-
>   drivers/gpu/drm/i915/i915_reg.h | 338 
>   include/uapi/drm/i915_drm.h |  70 ++-
>   5 files changed, 1408 insertions(+), 20 deletions(-)
>
> +
> +
> +   /* It takes a fairly long time for a new MUX
> configuration to
> +* be be applied after these register writes. This delay
> +* duration was derived empirically based on the
> render_basic
> +* config but hopefully it covers the maximum
> configuration
> +* latency...
> +*/
> +   mdelay(100);
>
>
> With such a HW and SW design, how can we ever expose hope to get any
> kind of performance when we are trying to monitor different
> metrics on each
> draw call? This may be acceptable for system monitoring, but it
> is problematic
> for the GL extensions :s
>
>
> Since it seems like we are going for a perf API, it means that
> for every change
> of metrics, we need to flush the commands, wait for the GPU to
> be done, then
> program the new set of metrics via an IOCTL, wait 100 ms, and
> then we may
> resume rendering ... until the next change. We are talking about
> a latency of
> 6-7 frames at 60 Hz here... this is non-negligeable...
>
>
> I understand that we have a ton of counters and we may hide
> latency by not
> allowing using more than half of the counters for every draw
> call or frame, but
> even then, this 100ms delay is killing this approach altogether.
>
>
>
>
> So revisiting this to double check how things fail with my latest
> driver/tests without the delay, I apparently can't reproduce test
> failures without the delay any more...
>
> I think the explanation is that since first adding the delay to the
> driver I also made the the driver a bit more careful to not forward
> spurious reports that look invalid due to a zeroed report id field, and
> that mechanism keeps the unit tests happy, even though there are still
> some number of invalid reports generated if we don't wait.
>
> One problem with simply having no delay is that the driver prints an
> error if it sees an invalid reports so I get a lot of 'Skipping
> spurious, invalid OA report' dmesg spam. Also this was intended more as
> a last resort mechanism, and I wouldn't feel too happy about squashing
> the error message and potentially sweeping other error cases under the
> carpet.
>
> Experimenting to see if the delay can at least be reduced, I brought the
> delay up in millisecond increments and found that although I still see a
> lot of spurious reports only waiting 1 or 5 milliseconds, at 10
> milliseconds its reduced quite a bit and at 15 milliseconds I don't seem
> to have any errors.
>
> 15 milliseconds is still a long time, but at least not as long as 100.

OK, so the issue does not come from the HW after all, great!

Now, my main question is, why are spurious events generated when 
changing the MUX's value? I can understand that we would need to ignore 
the reading that came right after the change, but other than this,  I am 
a bit at a loss.

I am a bit swamped with other tasks right now, but I would love to spend 
more time reviewing your code as I really want to see this upstream!

Martin

[Intel-gfx] [PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

[Martin Peres]

On 03/05/16 22:34, Robert Bragg wrote:
> Sorry for the delay replying to this, I missed it.

No worries!

>
> On Sat, Apr 23, 2016 at 11:34 AM, Martin Peres  > wrote:
>
> On 20/04/16 17:23, Robert Bragg wrote:
>
> Gen graphics hardware can be set up to periodically write
> snapshots of
> performance counters into a circular buffer via its Observation
> Architecture and this patch exposes that capability to userspace
> via the
> i915 perf interface.
>
> Cc: Chris Wilson  >
> Signed-off-by: Robert Bragg  >
> Signed-off-by: Zhenyu Wang  >
> ---
>   drivers/gpu/drm/i915/i915_drv.h |  56 +-
>   drivers/gpu/drm/i915/i915_gem_context.c |  24 +-
>   drivers/gpu/drm/i915/i915_perf.c| 940
> +++-
>   drivers/gpu/drm/i915/i915_reg.h | 338 
>   include/uapi/drm/i915_drm.h |  70 ++-
>   5 files changed, 1408 insertions(+), 20 deletions(-)
>
> +
> +
> +   /* It takes a fairly long time for a new MUX
> configuration to
> +* be be applied after these register writes. This delay
> +* duration was derived empirically based on the
> render_basic
> +* config but hopefully it covers the maximum configuration
> +* latency...
> +*/
> +   mdelay(100);
>
>
> With such a HW and SW design, how can we ever expose hope to get any
> kind of performance when we are trying to monitor different metrics
> on each
> draw call? This may be acceptable for system monitoring, but it is
> problematic
> for the GL extensions :s
>
>
> Since it seems like we are going for a perf API, it means that for
> every change
> of metrics, we need to flush the commands, wait for the GPU to be
> done, then
> program the new set of metrics via an IOCTL, wait 100 ms, and then
> we may
> resume rendering ... until the next change. We are talking about a
> latency of
> 6-7 frames at 60 Hz here... this is non-negligeable...
>
>
> I understand that we have a ton of counters and we may hide latency
> by not
> allowing using more than half of the counters for every draw call or
> frame, but
> even then, this 100ms delay is killing this approach altogether.
>
>
>
> Although I'm also really unhappy about introducing this delay recently,
> the impact of the delay is typically amortized somewhat by keeping a
> configuration open as long as possible.
>
> Even without this explicit delay here the OA unit isn't suited to being
> reconfigured on a per draw call basis, though it is able to support per
> draw call queries with the same config.
>
> The above assessment assumes wanting to change config between draw calls
> which is not something this driver aims to support - as the HW isn't
> really designed for that model.
>
> E.g. in the case of INTEL_performance_query, the backend keeps the i915
> perf stream open until all OA based query objects are deleted - so you
> have to be pretty explicit if you want to change config.

OK, I get your point. However, I still want to state that applications 
changing the set would see a disastrous effect as a 100 ms is enough to 
downclock both the CPU and GPU and that would dramatically alter the
metrics. Should we make it clear somewhere, either in the 
INTEL_performance_query or as a warning in mesa_performance if changing 
the set while running? I would think the latter would be preferable as 
it could also cover the case of the AMD extension which, IIRC, does not 
talk about the performance cost of changing the metrics. With this 
caveat made clear, it seems reasonable.

>
> Considering the sets available on Haswell:
> * Render Metrics Basic
> * Compute Metrics Basic
> * Compute Metrics Extended
> * Memory Reads Distribution
> * Memory Writes Distribution
> * Metric set SamplerBalance
>
> Each of these configs can expose around 50 counters as a set.
>
> A GL application is most likely just going to use the render basic set,
> and In the case of a tool like gputop/GPA then changing config would
> usually be driven by some user interaction to select a set of metrics,
> where even a 100ms delay will go unnoticed.

100 ms is becoming visible, but I agree, it would not be a show stopper 
for sure.

On the APITRACE side, this should not be an issue, because we do not 
change the set of metrics while running.

>
> In case you aren't familiar with how the GL_INTEL_performance_query side
> of things works for OA counters; one thing to be aware of is that
> there's a separate MI_REPORT_PERF_COUNT command that Mesa writes either
> side of a query which writes all 

[PATCH] drm/exynos: fix cancel page flip code

[Andrzej Hajda]

Hi Inki,

Gently ping.

Regards
Andrzej

On 03/24/2016 11:52 AM, Andrzej Hajda wrote:
> Driver code did not remove event from the list of pending events before 
> destroy.
> As a result drm core tried later to inspect invalid memory location.
> The patch replaces removal code with call to core helper.
> 
> The bug was detected using KASAN:
> 
> [   10.107249] 
> ==
> [   10.107518] BUG: KASAN: use-after-free in drm_release+0xe9c/0x1000 at addr 
> ffc089154a18
> [   10.107784] Read of size 8 by task modetest/103
> [   10.107931] 
> =
> [   10.113191] BUG kmalloc-128 (Not tainted): kasan: bad access detected
> [   10.119608] 
> -
> [   10.119608]
> [   10.129243] Disabling lock debugging due to kernel taint
> [   10.134551] INFO: Allocated in drm_mode_page_flip_ioctl+0x500/0xa98 age=4 
> cpu=0 pid=103
> [   10.142532]alloc_debug_processing+0x18c/0x198
> [   10.147043]___slab_alloc.constprop.28+0x360/0x380
> [   10.151906]__slab_alloc.isra.25.constprop.27+0x54/0xa0
> [   10.157197]kmem_cache_alloc_trace+0x370/0x3b0
> [   10.161709]drm_mode_page_flip_ioctl+0x500/0xa98
> [   10.166400]drm_ioctl+0x4c4/0xb68
> [   10.169787]do_vfs_ioctl+0x16c/0xeb8
> [   10.173429]SyS_ioctl+0x8c/0xa0
> [   10.176642]el0_svc_naked+0x24/0x28
> [   10.180204] INFO: Freed in exynos_drm_crtc_cancel_page_flip+0xe0/0x160 
> age=0 cpu=0 pid=103
> [   10.188447]free_debug_processing+0x174/0x388
> [   10.192871]__slab_free+0x2e8/0x438
> [   10.196431]kfree+0x350/0x360
> [   10.199469]exynos_drm_crtc_cancel_page_flip+0xe0/0x160
> [   10.204762]exynos_drm_preclose+0x58/0xa0
> [   10.208844]drm_release+0x1f0/0x1000
> [   10.212491]__fput+0x1c4/0x5b8
> [   10.215613]fput+0xc/0x18
> [   10.218654]task_work_run+0x130/0x198
> [   10.222385]do_exit+0x700/0x2278
> [   10.225681]do_group_exit+0xe4/0x2c8
> [   10.229327]SyS_exit_group+0x1c/0x20
> [   10.232973]el0_svc_naked+0x24/0x28
> [   10.236532] INFO: Slab 0xffbdc2a45500 objects=32 used=10 
> fp=0xffc089154a00 flags=0x4080
> [   10.245210] INFO: Object 0xffc089154a00 @offset=2560 
> fp=0xffc089157600
> [   10.245210]
> ...
> [   10.384532] CPU: 0 PID: 103 Comm: modetest Tainted: GB   
> 4.5.0-rc3-00748-gd5e2881 #271
> [   10.398325] Call trace:
> [   10.400764] [] dump_backtrace+0x0/0x328
> [   10.406141] [] show_stack+0x14/0x20
> [   10.411176] [] dump_stack+0xb0/0xe8
> [   10.416210] [] print_trailer+0xf8/0x160
> [   10.421592] [] object_err+0x3c/0x50
> [   10.426626] [] kasan_report_error+0x248/0x550
> [   10.432527] [] __asan_report_load8_noabort+0x40/0x48
> [   10.439039] [] drm_release+0xe9c/0x1000
> [   10.19] [] __fput+0x1c4/0x5b8
> [   10.449280] [] fput+0xc/0x18
> [   10.454055] [] task_work_run+0x130/0x198
> [   10.459522] [] do_exit+0x700/0x2278
> [   10.464557] [] do_group_exit+0xe4/0x2c8
> [   10.469939] [] SyS_exit_group+0x1c/0x20
> [   10.475320] [] el0_svc_naked+0x24/0x28
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c | 26 +++---
>  1 file changed, 7 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index 50dd33d..e78c36d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -229,24 +229,12 @@ void exynos_drm_crtc_cancel_page_flip(struct drm_crtc 
> *crtc,
>   struct drm_file *file)
>  {
>   struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> - struct drm_pending_vblank_event *e;
> - unsigned long flags;
> + struct drm_pending_vblank_event *e = exynos_crtc->event;
>  
> - spin_lock_irqsave(>dev->event_lock, flags);
> - e = exynos_crtc->event;
> - if (e && e->base.file_priv == file) {
> - exynos_crtc->event = NULL;
> - /*
> -  * event will be destroyed by core part
> -  * so below line should be removed later with core changes
> -  */
> - e->base.destroy(>base);
> - /*
> -  * event_space will be increased by core part
> -  * so below line should be removed later with core changes.
> -  */
> - file->event_space += sizeof(e->event);
> - atomic_dec(_crtc->pending_update);
> - }
> - spin_unlock_irqrestore(>dev->event_lock, flags);
> + if (!e || e->base.file_priv != file)
> + return;
> +
> + exynos_crtc->event = NULL;
> + atomic_dec(_crtc->pending_update);
> + drm_event_cancel_free(crtc->dev, >base);
>  }
> 

[PATCH 3/6] drm/exynos/hdmi: expose HDMI-PHY clock as pipeline clock

[Andrzej Hajda]

Hi Inki,

It looks like this patch felt through the cracks.
It is a part of "drm/exynos: add pipeline clock support" patchset.
Other patches from the patchset were taken already.
Could you queue it to next pull request?

Regards
Andrzej

On 03/23/2016 02:25 PM, Andrzej Hajda wrote:
> HDMI-PHY clock should be accessible from other components in the pipeline.
> 
> Signed-off-by: Andrzej Hajda 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c | 67 
> ++--
>  1 file changed, 48 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 49a5902..0d1c2f0 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -146,6 +146,7 @@ struct hdmi_context {
>   struct clk  **clk_muxes;
>   struct regulator_bulk_data  regul_bulk[ARRAY_SIZE(supply)];
>   struct regulator*reg_hdmi_en;
> + struct exynos_drm_clk   phy_clk;
>  };
>  
>  static inline struct hdmi_context *encoder_to_hdmi(struct drm_encoder *e)
> @@ -1448,7 +1449,6 @@ static void hdmiphy_conf_apply(struct hdmi_context 
> *hdata)
>  
>  static void hdmi_conf_apply(struct hdmi_context *hdata)
>  {
> - hdmiphy_conf_apply(hdata);
>   hdmi_start(hdata, false);
>   hdmi_conf_init(hdata);
>   hdmi_audio_init(hdata);
> @@ -1481,10 +1481,8 @@ static void hdmi_set_refclk(struct hdmi_context 
> *hdata, bool on)
>  SYSREG_HDMI_REFCLK_INT_CLK, on ? ~0 : 0);
>  }
>  
> -static void hdmi_enable(struct drm_encoder *encoder)
> +static void hdmiphy_enable(struct hdmi_context *hdata)
>  {
> - struct hdmi_context *hdata = encoder_to_hdmi(encoder);
> -
>   if (hdata->powered)
>   return;
>  
> @@ -1500,11 +1498,40 @@ static void hdmi_enable(struct drm_encoder *encoder)
>  
>   hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, 0, HDMI_PHY_POWER_OFF_EN);
>  
> - hdmi_conf_apply(hdata);
> + hdmiphy_conf_apply(hdata);
>  
>   hdata->powered = true;
>  }
>  
> +static void hdmiphy_disable(struct hdmi_context *hdata)
> +{
> + if (!hdata->powered)
> + return;
> +
> + hdmi_reg_writemask(hdata, HDMI_CON_0, 0, HDMI_EN);
> +
> + hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0, HDMI_PHY_POWER_OFF_EN);
> +
> + hdmi_set_refclk(hdata, false);
> +
> + regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
> + PMU_HDMI_PHY_ENABLE_BIT, 0);
> +
> + regulator_bulk_disable(ARRAY_SIZE(supply), hdata->regul_bulk);
> +
> + pm_runtime_put_sync(hdata->dev);
> +
> + hdata->powered = false;
> +}
> +
> +static void hdmi_enable(struct drm_encoder *encoder)
> +{
> + struct hdmi_context *hdata = encoder_to_hdmi(encoder);
> +
> + hdmiphy_enable(hdata);
> + hdmi_conf_apply(hdata);
> +}
> +
>  static void hdmi_disable(struct drm_encoder *encoder)
>  {
>   struct hdmi_context *hdata = encoder_to_hdmi(encoder);
> @@ -1528,22 +1555,9 @@ static void hdmi_disable(struct drm_encoder *encoder)
>   if (funcs && funcs->disable)
>   (*funcs->disable)(crtc);
>  
> - hdmi_reg_writemask(hdata, HDMI_CON_0, 0, HDMI_EN);
> -
>   cancel_delayed_work(>hotplug_work);
>  
> - hdmi_reg_writemask(hdata, HDMI_PHY_CON_0, ~0, HDMI_PHY_POWER_OFF_EN);
> -
> - hdmi_set_refclk(hdata, false);
> -
> - regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
> - PMU_HDMI_PHY_ENABLE_BIT, 0);
> -
> - regulator_bulk_disable(ARRAY_SIZE(supply), hdata->regul_bulk);
> -
> - pm_runtime_put_sync(hdata->dev);
> -
> - hdata->powered = false;
> + hdmiphy_disable(hdata);
>  }
>  
>  static const struct drm_encoder_helper_funcs 
> exynos_hdmi_encoder_helper_funcs = {
> @@ -1627,6 +1641,17 @@ static int hdmi_clk_init(struct hdmi_context *hdata)
>   return hdmi_clks_get(hdata, _data->clk_muxes, hdata->clk_muxes);
>  }
>  
> +static void hdmiphy_clk_enable(struct exynos_drm_clk *clk, bool enable)
> +{
> + struct hdmi_context *hdata = container_of(clk, struct hdmi_context,
> +   phy_clk);
> +
> + if (enable)
> + hdmiphy_enable(hdata);
> + else
> + hdmiphy_disable(hdata);
> +}
> +
>  static int hdmi_resources_init(struct hdmi_context *hdata)
>  {
>   struct device *dev = hdata->dev;
> @@ -1710,6 +1735,10 @@ static int hdmi_bind(struct device *dev, struct device 
> *master, void *data)
>   if (pipe < 0)
>   return pipe;
>  
> + hdata->phy_clk.enable = hdmiphy_clk_enable;
> +
> + exynos_drm_crtc_from_pipe(drm_dev, pipe)->pipe_clk = >phy_clk;
> +
>   encoder->possible_crtcs = 1 << pipe;
>  
>   DRM_DEBUG_KMS("possible_crtcs = 0x%x\n", encoder->possible_crtcs);
> 

[PATCH -fixes] drm/vmwgfx: Kill some lockdep warnings

[Thomas Hellstrom]

Some global KMS state that is elsewhere protected by the mode_config
mutex here needs to be protected with a local mutex. Remove corresponding
lockdep checks and introduce a new driver-private global_kms_state_mutex,
and make sure its locking order is *after* the crtc locks in order to
avoid having to release those when the new mutex is taken.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Brian Paul 
Reviewed-by: Sinclair Yeh 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |  1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 27 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  3 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  3 +++
 5 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 6cbb7d4..f2cf923 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -628,6 +628,7 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
mutex_init(_priv->cmdbuf_mutex);
mutex_init(_priv->release_mutex);
mutex_init(_priv->binding_mutex);
+   mutex_init(_priv->global_kms_state_mutex);
rwlock_init(_priv->resource_lock);
ttm_lock_init(_priv->reservation_sem);
spin_lock_init(_priv->hw_lock);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 019a6ca..6db358a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -412,6 +412,7 @@ struct vmw_private {
struct drm_property *implicit_placement_property;
unsigned num_implicit;
struct vmw_framebuffer *implicit_fb;
+   struct mutex global_kms_state_mutex;

/*
 * Context and surface management.
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 4742ec4..b07543b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2143,13 +2143,13 @@ int vmw_kms_fbdev_init_data(struct vmw_private 
*dev_priv,
 void vmw_kms_del_active(struct vmw_private *dev_priv,
struct vmw_display_unit *du)
 {
-   lockdep_assert_held_once(_priv->dev->mode_config.mutex);
-
+   mutex_lock(_priv->global_kms_state_mutex);
if (du->active_implicit) {
if (--(dev_priv->num_implicit) == 0)
dev_priv->implicit_fb = NULL;
du->active_implicit = false;
}
+   mutex_unlock(_priv->global_kms_state_mutex);
 }

 /**
@@ -2165,8 +2165,7 @@ void vmw_kms_add_active(struct vmw_private *dev_priv,
struct vmw_display_unit *du,
struct vmw_framebuffer *vfb)
 {
-   lockdep_assert_held_once(_priv->dev->mode_config.mutex);
-
+   mutex_lock(_priv->global_kms_state_mutex);
WARN_ON_ONCE(!dev_priv->num_implicit && dev_priv->implicit_fb);

if (!du->active_implicit && du->is_implicit) {
@@ -2174,6 +2173,7 @@ void vmw_kms_add_active(struct vmw_private *dev_priv,
du->active_implicit = true;
dev_priv->num_implicit++;
}
+   mutex_unlock(_priv->global_kms_state_mutex);
 }

 /**
@@ -2190,16 +2190,13 @@ bool vmw_kms_crtc_flippable(struct vmw_private 
*dev_priv,
struct drm_crtc *crtc)
 {
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
+   bool ret;

-   lockdep_assert_held_once(_priv->dev->mode_config.mutex);
-
-   if (!du->is_implicit)
-   return true;
-
-   if (dev_priv->num_implicit != 1)
-   return false;
+   mutex_lock(_priv->global_kms_state_mutex);
+   ret = !du->is_implicit || dev_priv->num_implicit == 1;
+   mutex_unlock(_priv->global_kms_state_mutex);

-   return true;
+   return ret;
 }

 /**
@@ -2214,16 +2211,18 @@ void vmw_kms_update_implicit_fb(struct vmw_private 
*dev_priv,
struct vmw_display_unit *du = vmw_crtc_to_du(crtc);
struct vmw_framebuffer *vfb;

-   lockdep_assert_held_once(_priv->dev->mode_config.mutex);
+   mutex_lock(_priv->global_kms_state_mutex);

if (!du->is_implicit)
-   return;
+   goto out_unlock;

vfb = vmw_framebuffer_to_vfb(crtc->primary->fb);
WARN_ON_ONCE(dev_priv->num_implicit != 1 &&
 dev_priv->implicit_fb != vfb);

dev_priv->implicit_fb = vfb;
+out_unlock:
+   mutex_unlock(_priv->global_kms_state_mutex);
 }

 /**
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 0ea22fd..b74eae2 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -285,14 +285,17 @@ static int vmw_sou_crtc_set_config(struct drm_mode_set 
*set)
}

/* Only one active implicit frame-buffer at a time. */
+   mutex_lock(_priv->global_kms_state_mutex);
if 

[PATCH 3/3] drm/fb_helper: Fix a few typos

[Lyude]

s/modest/modeset/
s/aftert/after/

Signed-off-by: Lyude 
---
 drivers/gpu/drm/drm_fb_helper.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 15204c0..7778a0e 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2104,8 +2104,8 @@ out:
  * cmdline option.
  *
  * The other option is to just disable fbdev emulation since very likely the
- * first modest from userspace will crash in the same way, and is even easier 
to
- * debug. This can be done by setting the drm_kms_helper.fbdev_emulation=0
+ * first modeset from userspace will crash in the same way, and is even easier
+ * to debug. This can be done by setting the drm_kms_helper.fbdev_emulation=0
  * kernel cmdline option.
  *
  * RETURNS:
@@ -2150,7 +2150,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config);
  * hotplug interrupt).
  *
  * Note that drivers may call this even before calling
- * drm_fb_helper_initial_config but only aftert drm_fb_helper_init. This allows
+ * drm_fb_helper_initial_config but only after drm_fb_helper_init. This allows
  * for a race-free fbcon setup and will make sure that the fbdev emulation will
  * not miss any hotplug events.
  *
-- 
2.5.5

[PATCH 2/3] drm/fb_helper: Fix references to dev->mode_config.num_connector

[Lyude]

During boot, MST hotplugs are generally expected (even if no physical
hotplugging occurs) and result in DRM's connector topology changing.
This means that using num_connector from the current mode configuration
can lead to the number of connectors changing under us. This can lead to
some nasty scenarios in fbcon:

- We allocate an array to the size of dev->mode_config.num_connectors.
- MST hotplug occurs, dev->mode_config.num_connectors gets incremented.
- We try to loop through each element in the array using the new value
  of dev->mode_config.num_connectors, and end up going out of bounds
  since dev->mode_config.num_connectors is now larger then the array we
  allocated.

fb_helper->connector_count however, will always remain consistent while
we do a modeset in fb_helper.

Cc: stable at vger.kernel.org
Signed-off-by: Lyude 
---
 drivers/gpu/drm/drm_fb_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 855108e..15204c0 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1914,7 +1914,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
if (modes[n] == NULL)
return best_score;

-   crtcs = kzalloc(dev->mode_config.num_connector *
+   crtcs = kzalloc(fb_helper->connector_count *
sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
if (!crtcs)
return best_score;
@@ -1960,7 +1960,7 @@ static int drm_pick_crtcs(struct drm_fb_helper *fb_helper,
if (score > best_score) {
best_score = score;
memcpy(best_crtcs, crtcs,
-  dev->mode_config.num_connector *
+  fb_helper->connector_count *
   sizeof(struct drm_fb_helper_crtc *));
}
}
-- 
2.5.5

[PATCH 1/3] drm/i915/fbdev: Fix num_connector references in intel_fb_initial_config()

[Lyude]

During boot time, MST devices usually send a ton of hotplug events
irregardless of whether or not any physical hotplugs actually occurred.
Hotplugs mean connectors being created/destroyed, and the number of DRM
connectors changing under us. This isn't a problem if we use
fb_helper->connector_count since we only set it once in the code,
however if we use num_connector from struct drm_mode_config we risk it's
value changing under us. On top of that, there's even a chance that
dev->mode_config.num_connector != fb_helper->connector_count. If the
number of connectors happens to increase under us, we'll end up using
the wrong array size for memcpy and start writing beyond the actual
length of the array, occasionally resulting in kernel panics.

Cc: stable at vger.kernel.org
Signed-off-by: Lyude 
---
 drivers/gpu/drm/i915/intel_fbdev.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
b/drivers/gpu/drm/i915/intel_fbdev.c
index 97a91e6..c607217 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -366,12 +366,12 @@ static bool intel_fb_initial_config(struct drm_fb_helper 
*fb_helper,
uint64_t conn_configured = 0, mask;
int pass = 0;

-   save_enabled = kcalloc(dev->mode_config.num_connector, sizeof(bool),
+   save_enabled = kcalloc(fb_helper->connector_count, sizeof(bool),
   GFP_KERNEL);
if (!save_enabled)
return false;

-   memcpy(save_enabled, enabled, dev->mode_config.num_connector);
+   memcpy(save_enabled, enabled, fb_helper->connector_count);
mask = (1 << fb_helper->connector_count) - 1;
 retry:
for (i = 0; i < fb_helper->connector_count; i++) {
@@ -510,7 +510,7 @@ retry:
if (fallback) {
 bail:
DRM_DEBUG_KMS("Not using firmware configuration\n");
-   memcpy(enabled, save_enabled, dev->mode_config.num_connector);
+   memcpy(enabled, save_enabled, fb_helper->connector_count);
kfree(save_enabled);
return false;
}
-- 
2.5.5

[PATCH 5/5] drm/edid: add displayid detailed 1 timings to the modelist.

[Jani Nikula]

On Tue, 03 May 2016, Dave Airlie  wrote:
> From: Dave Airlie 
>
> The tiled 5K Dell monitor appears to be hiding it's tiled mode
> inside the displayid timings block, this patch parses this
> blocks and adds the modes to the modelist.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95207
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_edid.c  | 105 
> 
>  include/drm/drm_displayid.h |  17 +++
>  2 files changed, 122 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index e85d828..aca9e25 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3925,6 +3925,110 @@ static int validate_displayid(u8 *displayid, int 
> length, int idx)
>   return 0;
>  }
>  
> +static struct drm_display_mode *drm_mode_displayid_detailed(struct 
> drm_device *dev,
> + struct 
> displayid_detailed_timings_1 *timings)
> +{
> + struct drm_display_mode *mode;
> + unsigned pixel_clock = (timings->pixel_clock[0] |
> + (timings->pixel_clock[1] << 8) |
> + (timings->pixel_clock[2] << 16));
> + unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1;
> + unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1;
> + unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8) 
> + 1;
> + unsigned hsync_width = (timings->hsw[0] | timings->hsw[1] << 8) + 1;
> + unsigned vactive = (timings->vactive[0] | timings->vactive[1] << 8) + 1;
> + unsigned vblank = (timings->vblank[0] | timings->vblank[1] << 8) + 1;
> + unsigned vsync = (timings->vsync[0] | (timings->vsync[1] & 0x7f) << 8) 
> + 1;
> + unsigned vsync_width = (timings->vsw[0] | timings->vsw[1] << 8) + 1;
> + bool hsync_positive = (timings->hsync[1] >> 7) & 0x1;
> + bool vsync_positive = (timings->vsync[1] >> 7) & 0x1;
> + mode = drm_mode_create(dev);
> + if (!mode)
> + return NULL;
> +
> + mode->clock = pixel_clock * 10;
> + mode->hdisplay = hactive;
> + mode->hsync_start = mode->hdisplay + hsync;
> + mode->hsync_end = mode->hsync_start + hsync_width;
> + mode->htotal = mode->hdisplay + hblank;
> +
> + mode->vdisplay = vactive;
> + mode->vsync_start = mode->vdisplay + vsync;
> + mode->vsync_end = mode->vsync_start + vsync_width;
> + mode->vtotal = mode->vdisplay + vblank;
> +
> + mode->flags = 0;
> + mode->flags |= hsync_positive ? DRM_MODE_FLAG_PHSYNC : 
> DRM_MODE_FLAG_NHSYNC;
> + mode->flags |= vsync_positive ? DRM_MODE_FLAG_PVSYNC : 
> DRM_MODE_FLAG_NVSYNC;
> + mode->type = DRM_MODE_TYPE_DRIVER;
> +
> + if (timings->flags & 0x80)
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> + mode->vrefresh = drm_mode_vrefresh(mode);
> + drm_mode_set_name(mode);
> +
> + return mode;
> +}
> +
> +static int add_displayid_detailed_1_modes(struct drm_connector *connector,
> +   struct displayid_block *block)
> +{
> + struct displayid_detailed_timing_block *det = (struct 
> displayid_detailed_timing_block *)block;
> + int i;
> + int num_timings;
> + struct drm_display_mode *newmode;
> + int num_modes = 0;
> + /* blocks must be multiple of 20 bytes length */
> + if (block->num_bytes % 20)
> + return 0;
> +
> + num_timings = block->num_bytes / 20;
> + for (i = 0; i < num_timings; i++) {
> + struct displayid_detailed_timings_1 *timings = >timings[i];
> +
> + newmode = drm_mode_displayid_detailed(connector->dev, timings);
> + if (!newmode)
> + continue;
> +
> + drm_mode_probed_add(connector, newmode);
> + num_modes++;
> + }
> + return num_modes;
> +}
> +
> +static int add_displayid_detailed_modes(struct drm_connector *connector,
> + struct edid *edid)
> +{
> + u8 *displayid;
> + int ret;
> + int idx = 1;
> + int length = EDID_LENGTH;
> + struct displayid_block *block;
> + int num_modes = 0;
> +
> + displayid = drm_find_displayid_extension(edid);
> + if (!displayid)
> + return 0;
> +
> + ret = validate_displayid(displayid, length, idx);
> + if (ret)
> + return 0;
> +
> + idx += sizeof(struct displayid_hdr);
> + while (block = (struct displayid_block *)[idx],
> +idx + sizeof(struct displayid_block) <= length &&
> +idx + sizeof(struct displayid_block) + block->num_bytes <= 
> length &&
> +block->num_bytes > 0) {
> + idx += block->num_bytes + sizeof(struct displayid_block);
> + switch (block->tag) {
> + case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
> + num_modes += add_displayid_detailed_1_modes(connector, 
> block);
> +

[PATCH 3/5] drm/edid: move displayid tiled block parsing into separate function.

[Jani Nikula]

On Tue, 03 May 2016, Dave Airlie  wrote:
> From: Dave Airlie 
>
> This just makes the code easier to follow.

Swapping the order of patches 2 and 3 would make the patch series easier
to follow. ;)

BR,
Jani.

>
> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_edid.c | 110 
> -
>  1 file changed, 59 insertions(+), 51 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 1a364b3..e4c681f 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -4152,6 +4152,60 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct 
> hdmi_vendor_infoframe *frame,
>  }
>  EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);
>  
> +static int drm_parse_tiled_block(struct drm_connector *connector,
> +  struct displayid_block *block)
> +{
> + struct displayid_tiled_block *tile = (struct displayid_tiled_block 
> *)block;
> + u16 w, h;
> + u8 tile_v_loc, tile_h_loc;
> + u8 num_v_tile, num_h_tile;
> + struct drm_tile_group *tg;
> +
> + w = tile->tile_size[0] | tile->tile_size[1] << 8;
> + h = tile->tile_size[2] | tile->tile_size[3] << 8;
> +
> + num_v_tile = (tile->topo[0] & 0xf) | (tile->topo[2] & 0x30);
> + num_h_tile = (tile->topo[0] >> 4) | ((tile->topo[2] >> 2) & 0x30);
> + tile_v_loc = (tile->topo[1] & 0xf) | ((tile->topo[2] & 0x3) << 4);
> + tile_h_loc = (tile->topo[1] >> 4) | (((tile->topo[2] >> 2) & 0x3) << 4);
> +
> + connector->has_tile = true;
> + if (tile->tile_cap & 0x80)
> + connector->tile_is_single_monitor = true;
> +
> + connector->num_h_tile = num_h_tile + 1;
> + connector->num_v_tile = num_v_tile + 1;
> + connector->tile_h_loc = tile_h_loc;
> + connector->tile_v_loc = tile_v_loc;
> + connector->tile_h_size = w + 1;
> + connector->tile_v_size = h + 1;
> +
> + DRM_DEBUG_KMS("tile cap 0x%x\n", tile->tile_cap);
> + DRM_DEBUG_KMS("tile_size %d x %d\n", w + 1, h + 1);
> + DRM_DEBUG_KMS("topo num tiles %dx%d, location %dx%d\n",
> +   num_h_tile + 1, num_v_tile + 1, tile_h_loc, tile_v_loc);
> + DRM_DEBUG_KMS("vend %c%c%c\n", tile->topology_id[0], 
> tile->topology_id[1], tile->topology_id[2]);
> +
> + tg = drm_mode_get_tile_group(connector->dev, tile->topology_id);
> + if (!tg) {
> + tg = drm_mode_create_tile_group(connector->dev, 
> tile->topology_id);
> + }
> + if (!tg)
> + return -ENOMEM;
> +
> + if (connector->tile_group != tg) {
> + /* if we haven't got a pointer,
> +take the reference, drop ref to old tile group */
> + if (connector->tile_group) {
> + drm_mode_put_tile_group(connector->dev, 
> connector->tile_group);
> + }
> + connector->tile_group = tg;
> + } else
> + /* if same tile group, then release the ref we just took. */
> + drm_mode_put_tile_group(connector->dev, tg);
> + return 0;
> +}
> +
>  static int drm_parse_display_id(struct drm_connector *connector,
>   u8 *displayid, int length,
>   bool is_edid_extension)
> @@ -4162,6 +4216,7 @@ static int drm_parse_display_id(struct drm_connector 
> *connector,
>   struct displayid_block *block;
>   u8 csum = 0;
>   int i;
> + int ret;
>  
>   if (is_edid_extension)
>   idx = 1;
> @@ -4192,57 +4247,10 @@ static int drm_parse_display_id(struct drm_connector 
> *connector,
> block->tag, block->rev, block->num_bytes);
>  
>   switch (block->tag) {
> - case DATA_BLOCK_TILED_DISPLAY: {
> - struct displayid_tiled_block *tile = (struct 
> displayid_tiled_block *)block;
> -
> - u16 w, h;
> - u8 tile_v_loc, tile_h_loc;
> - u8 num_v_tile, num_h_tile;
> - struct drm_tile_group *tg;
> -
> - w = tile->tile_size[0] | tile->tile_size[1] << 8;
> - h = tile->tile_size[2] | tile->tile_size[3] << 8;
> -
> - num_v_tile = (tile->topo[0] & 0xf) | (tile->topo[2] & 
> 0x30);
> - num_h_tile = (tile->topo[0] >> 4) | ((tile->topo[2] >> 
> 2) & 0x30);
> - tile_v_loc = (tile->topo[1] & 0xf) | ((tile->topo[2] & 
> 0x3) << 4);
> - tile_h_loc = (tile->topo[1] >> 4) | (((tile->topo[2] >> 
> 2) & 0x3) << 4);
> -
> - connector->has_tile = true;
> - if (tile->tile_cap & 0x80)
> - connector->tile_is_single_monitor = true;
> -
> - connector->num_h_tile = num_h_tile + 1;
> - connector->num_v_tile = num_v_tile + 1;
> - connector->tile_h_loc = tile_h_loc;
> - 

[PATCH] drm/exynos: fix cancel page flip code

[Daniel Stone]

Hi Andrzej,

On 24 March 2016 at 10:52, Andrzej Hajda  wrote:
> @@ -229,24 +229,12 @@ void exynos_drm_crtc_cancel_page_flip(struct drm_crtc 
> *crtc,
> struct drm_file *file)
>  {
> struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(crtc);
> -   struct drm_pending_vblank_event *e;
> -   unsigned long flags;
> +   struct drm_pending_vblank_event *e = exynos_crtc->event;
>
> -   spin_lock_irqsave(>dev->event_lock, flags);
> -   e = exynos_crtc->event;
> -   if (e && e->base.file_priv == file) {
> -   exynos_crtc->event = NULL;
> -   /*
> -* event will be destroyed by core part
> -* so below line should be removed later with core changes
> -*/
> -   e->base.destroy(>base);
> -   /*
> -* event_space will be increased by core part
> -* so below line should be removed later with core changes.
> -*/
> -   file->event_space += sizeof(e->event);
> -   atomic_dec(_crtc->pending_update);
> -   }
> -   spin_unlock_irqrestore(>dev->event_lock, flags);
> +   if (!e || e->base.file_priv != file)
> +   return;
> +
> +   exynos_crtc->event = NULL;
> +   atomic_dec(_crtc->pending_update);
> +   drm_event_cancel_free(crtc->dev, >base);

Accessing and manipulating exynos_crtc->event should still be done
under event_lock, to avoid racing with the IRQ handler.

Cheers,
Daniel

[PATCH 5/9] drm/i915: Enable i915 perf stream for Haswell OA unit

[Robert Bragg]

seconds is still a long time, but at least not as long as 100.
>>
>
> OK, so the issue does not come from the HW after all, great!
>

Erm, I'm not sure that's a conclusion we can make here...

The upshot here was really just reducing the delay from 100ms to 15ms.
Previously I arrived at a workable delay by jumping the delay in orders of
magnitude with 10ms failing, 100ms passing and I didn't try and refine it
further. Here I've looked at delays between 10 and 100ms.

The other thing is observing that because the kernel is checking for
invalid reports (generated by the hardware) before forwarding to userspace
the lack of a delay no longer triggers i-g-t failures because the invalid
data won't reach i-g-t any more - though the invalid reports are still a
thing to avoid.


> Now, my main question is, why are spurious events generated when changing
> the MUX's value? I can understand that we would need to ignore the reading
> that came right after the change, but other than this,  I am a bit at a
> loss.
>

The MUX selects 16 signals that the OA unit can turn into 16 separate
counters by basically counting the signal changes. (there's some fancy
fixed function logic that can affect this but that's the general idea).

If the MUX is in the middle of being re-programmed then some subset of
those 16 signals are for who knows what.

After programming the MUX we will go on to configure the OA unit and the
tests will enable periodic sampling which (if we have no delay) will sample
the OA counters that are currently being fed by undefined signals.

So as far as that goes it makes sense to me to expect bad data if we don't
wait for the MUX config to land properly. Something I don't really know is
how come we're seemingly lucky to have the reports be cleanly invalid with
a zero report-id, instead of just having junk data that would be harder to
recognise.


> I am a bit swamped with other tasks right now, but I would love to spend
> more time reviewing your code as I really want to see this upstream!
>

No worries.

I can hopefully send out my i-g-t tests this afternoon too which should
hopefully give us all the pieces to be able seriously consider hopefully
landing things soon.

Regards,
- Robert


> Martin
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160504/b0bd7e71/attachment-0001.html>

[PATCH] drm/edid : cache edid range limits in drm connector

[Jani Nikula]

On Wed, 04 May 2016, "Prosyak, Vitaly"  wrote:
> We are going to use min/max vertical refresh rate when enter/exit to
> the dynamic refresh rate mode ,it is known as 'freesync', enter/exit
> to full screen games.

As Daniel said, we should see the patch using them too. It's hard to say
whether this is the right thing to do otherwise.

BR,
Jani.

> Right , we may have a helper function which extracts these properties and 
> store wherever need it.
> But this an alternative solution  with additional helper adds some code 
> duplication into drm_edid.c  since the case already present in the code:
> case 0x01: /* just the ranges, no formula */ Also these values are parsed 
> during each mode enumeration.
>
> Why I put into connector: 
> Drm connector have already similar items from EDID: drm_tile_group ,etc...
>
> Vitaly
> -Original Message-.
>
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel 
> Vetter
> Sent: Tuesday, May 03, 2016 4:24 PM
> To: Prosyak, Vitaly
> Cc: dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH] drm/edid : cache edid range limits in drm connector
>
> On Tue, May 03, 2016 at 11:05:24AM -0400, Vitaly Prosyak wrote:
>> Cache in drm connector the edid range limits properties:
>> min/max vertical refresh rates and max pixel clock.
>> It would be used when enter to drr mode.
>> 
>> Signed-off-by: Vitaly Prosyak 
>
> Where's the patches that will use this? It might make sense to instead have 
> some helper functions to compute these values, so that drivers can store them 
> wherever they want/need. But impossible to tell without the users of this 
> stuff.
> -Daniel
>
>> ---
>>  drivers/gpu/drm/drm_edid.c | 11 +++
>>  include/drm/drm_crtc.h |  5 +
>>  2 files changed, 16 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c 
>> index 04cb487..7e49962 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -2190,6 +2190,17 @@ do_inferred_modes(struct detailed_timing *timing, 
>> void *c)
>>timing);
>>  break;
>>  case 0x01: /* just the ranges, no formula */
>> +closure->connector->min_vfreq = range->min_vfreq;
>> +closure->connector->max_vfreq = range->max_vfreq;
>> +if (closure->edid->revision >= 4) {
>> +if ((range->flags & 0x03) == 0x3)
>> +closure->connector->min_vfreq += 255;
>> +if (range->flags & 0x02)
>> +closure->connector->max_vfreq += 255;
>> +}
>> +closure->connector->max_pixel_clock_khz =
>> +range_pixel_clock(closure->edid, (u8 *)timing);
>> +break;
>>  default:
>>  break;
>>  }
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
>> c5b4b81..85fc554 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -1230,6 +1230,11 @@ struct drm_connector {
>>  uint8_t num_h_tile, num_v_tile;
>>  uint8_t tile_h_loc, tile_v_loc;
>>  uint16_t tile_h_size, tile_v_size;
>> +
>> +/*EDID range limits for drr*/
>> +int min_vfreq ;
>> +int max_vfreq ;
>> +int max_pixel_clock_khz;
>>  };
>>  
>>  /**
>> --
>> 1.9.1
>> 
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 87682] Horizontal lines in radeon driver on kernel 3.15 and upwards

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

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

--- Comment #7 from Thom  ---
Ok, I did my first bisect, it worked out well but I encountered something that
puzzles me a bit.
Here is the last part of the bisect:

3.15.0-rc3-00725-g1465967  bad

Bisecting: 658 revisions left to test after this (roughly 9 steps)
[e9dba837640d960f56bef22ff08611955ff8a5b4] Merge tag 'pm+acpi-3.15-rc3' of
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm

3.15.0-rc2-00219-ge9dba83  bad

Bisecting: 355 revisions left to test after this (roughly 8 steps)
[6e66d5dab5d530a368314eb631201a02aabb075d] Merge branch 'for-next' of
git://git.samba.org/sfrench/cifs-2.6


3.15.0-rc1-00303-g6e66d5d good

Bisecting: 176 revisions left to test after this (roughly 8 steps)
[4d0fa8a0f01272d4de33704f20303dcecdb55df1] Merge tag 'gpio-v3.15-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio

3.15.0-rc2-00042-g4d0fa8a good

Bisecting: 99 revisions left to test after this (roughly 7 steps)
[76e7745e8e4330fdb30f049303d524261c0b7a2c] Merge tag 'zynq-dt-fixes-for-3.15'
of git://git.xilinx.com/linux-xlnx into fixes

3.15.0-rc2-00077-g76e7745 good (how can this be ??)

Bisecting: 49 revisions left to test after this (roughly 6 steps)
[92891ed6b1fdb49655f9a071ef2880a567807375] Merge branch 'fixes_for_v3.15' of
git://git.linaro.org/people/mszyprowski/linux-dma-mapping

3.15.0-rc2-00092-g92891ed bad

Bisecting: 22 revisions left to test after this (roughly 5 steps)
[1aae31c8306e5f1bdeafd87b2cd9e3f0df3709e5] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input

3.15.0-rc2-00069-g1aae31c bad

Bisecting: 13 revisions left to test after this (roughly 4 steps)
[7740fc52105c9e6d2beac389a9ae0ce7138cf5ab] Input: soc_button_array - fix a
crash during rmmod

3.14.0-rc4-00065-g7740fc5 good

Bisecting: 6 revisions left to test after this (roughly 3 steps)
[3ed9a335cfc64b2c83545f341cdddf2347b12b97] drm/radeon/pm: don't walk the crtc
list before it has been initialized (v2)

3.15.0-rc1-00075-g3ed9a33 bad

Bisecting: 3 revisions left to test after this (roughly 2 steps)
[c2fb3094669a3205f16a32f4119d0afe40b1a1fd] drm/radeon: improve PLL limit
handling in post div calculation

3.15.0-rc1-00071-gc2fb309 bad

Bisecting: 0 revisions left to test after this (roughly 1 step)
[24315814239a3fdb306244c99bd076bc79db4ade] drm/radeon: use fixed PPL ref
divider if needed

3.15.0-rc1-00070-g2431581 good

c2fb3094669a3205f16a32f4119d0afe40b1a1fd is the first bad commit

commit c2fb3094669a3205f16a32f4119d0afe40b1a1fd
Author: Christian K�nig 
Date:   Sun Apr 20 13:24:32 2014 +0200

drm/radeon: improve PLL limit handling in post div calculation

This improves the PLL parameters when we work at
the limits of the allowed ranges.

Signed-off-by: Christian K�nig 

:04 04 5c3ac5ddf911c2c1f8926ecde2d83fdbcd6bb269
4731ceed6e1c149abd6fda6a06318700750f8

So far so good, but what I'm puzzled about is this:

As far as I understand; 3.15.0-rc2-00077-g76e7745 is a later revision (good)
than 3.15.0-rc2-00069-g1aae31c (bad) and an earlier revision than
3.15.0-rc2-00092-g92891ed (bad) which doesn't seem to make sense to me.

It is as if someone did a patch to improve on 3.15.0-rc1-00071-gc2fb309 but
that it got revoked afterwards, is that possible ?

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

drm/radeon/kms: add dpm support for KB/KV

[Dan Carpenter]

Same thing in kv_init_fps_limits from amdgpu.

drivers/gpu/drm/amd/amdgpu/kv_dpm.c:1446 kv_init_fps_limits() error: wrong 
number of bits for 'cpu_to_be16' (8 vs 16) left= 'pi->fps_low_t' pi->fps_low_t 
= (__builtin_bswap16(((tmp

regards,
dan carpenter

[PULL] drm-amdkfd-next

[Oded Gabbay]

Hi Dave,

Here are a few amdkfd patches for 4.7, all of them fixes according to 
the Coccinelle tool.

Thanks,

Oded

The following changes since commit b89359bdf0f1e95a4c5f92300594ba9dde323fc4:

  Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into 
drm-next (2016-04-29 14:57:51 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2016-05-04

for you to fetch changes up to eb026024c24bbeb18e08d973e950f76c0d97a3c0:

  amdkfd: Trim unnescessary intermediate err var in kfd_chardev.c (2016-05-01 
00:06:29 +1000)


Edward O'Callaghan (3):
  amdkfd: Use the canonical form in branch predicates
  amdkfd: Trim off unnescessary semicolon from kfd_packet_manager.c
  amdkfd: Trim unnescessary intermediate err var in kfd_chardev.c

 drivers/gpu/drm/amd/amdkfd/kfd_chardev.c  |  5 ++---
 drivers/gpu/drm/amd/amdkfd/kfd_device_queue_manager.c | 10 +-
 drivers/gpu/drm/amd/amdkfd/kfd_events.c   |  4 ++--
 drivers/gpu/drm/amd/amdkfd/kfd_kernel_queue.c |  2 +-
 drivers/gpu/drm/amd/amdkfd/kfd_packet_manager.c   | 12 ++--
 5 files changed, 16 insertions(+), 17 deletions(-)

[PATCH] drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked

[Alex Deucher]

On Wed, May 4, 2016 at 8:29 AM, Daniel Vetter  wrote:
> Embarrassingly while fixing up the old paths for i915 I managed to
> misplace a locking check for the new _unlocked paths. That's what I
> get for not retesting on radeon.
>
> Fixes: 9f0ba539d13a ("drm/gem: support BO freeing without dev->struct_mutex")
> Cc: Chris Wilson 
> Cc: Alex Deucher 
> Cc: Lucas Stach 
> Tested-by: Chris Wilson 
> Signed-off-by: Daniel Vetter 

Reviewed-by: Alex Deucher 

> ---
>  drivers/gpu/drm/drm_gem.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 973eb8805ce0..f716308fb48c 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -804,12 +804,13 @@ drm_gem_object_free(struct kref *kref)
> container_of(kref, struct drm_gem_object, refcount);
> struct drm_device *dev = obj->dev;
>
> -   WARN_ON(!mutex_is_locked(>struct_mutex));
> -
> -   if (dev->driver->gem_free_object_unlocked)
> +   if (dev->driver->gem_free_object_unlocked) {
> dev->driver->gem_free_object_unlocked(obj);
> -   else if (dev->driver->gem_free_object)
> +   } else if (dev->driver->gem_free_object) {
> +   WARN_ON(!mutex_is_locked(>struct_mutex));
> +
> dev->driver->gem_free_object(obj);
> +   }
>  }
>  EXPORT_SYMBOL(drm_gem_object_free);
>
> --
> 2.8.1
>

[PATCH 9/9] dt-bindings: msm/dsi: Add assigned clocks bindings

[Rob Herring]

On Tue, May 03, 2016 at 04:28:01PM +0530, Archit Taneja wrote:
> The PLL in the DSI PHY block generates 2 clock outputs (Byte and Pixel
> clocks) that are fed into the Multimedia Clock Controller (MMCC). The MMCC
> uses these as source clocks for some of its RCGs to generate clocks that
> finally feed to the DSI host controller.
> 
> Use the assigned clocks DT bindings to set up the MMCC RCGs that feed to
> the DSI host. Use the DSI PHY provided clocks to set up the parents
> of these assigned clocks.
> 
> Signed-off-by: Archit Taneja 
> ---
>  Documentation/devicetree/bindings/display/msm/dsi.txt | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt 
> b/Documentation/devicetree/bindings/display/msm/dsi.txt
> index 0223f06..686f475 100644
> --- a/Documentation/devicetree/bindings/display/msm/dsi.txt
> +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt
> @@ -22,6 +22,10 @@ Required properties:
>* "core_clk"
>For DSIv2, we need an additional clock:
> * "src_clk"
> +- assigned-clocks: Parents of "byte_clk" and "pixel_clk" for the given 
> platform.
> +  See [1] for more details.
> +- assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided
> +  by a DSI PHY block.
>  - vdd-supply: phandle to vdd regulator device node
>  - vddio-supply: phandle to vdd-io regulator device node
>  - vdda-supply: phandle to vdda regulator device node
> @@ -90,6 +94,8 @@ Required properties:
>* "dsi_pll"
>* "dsi_phy"
>* "dsi_phy_regulator"
> +- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, 
> creating
> +  2 clocks: A byte clock (index 0), and a pixel clock (index 1).

You can't really add new required properties unless they are for a new 
compatible string.

Rob

[PATCH 4/9] dt-bindings: msm/mdp: Remove connector and gpu bindings

[Rob Herring]

On Tue, May 03, 2016 at 04:27:56PM +0530, Archit Taneja wrote:
> The MDP DT node now contains a list of ports that describe how it connects
> to external encoder interfaces like DSI and HDMI. These follow the
> standard of_graph bindings, and allow us to get rid of the 'connectors'
> phandle that contained a list of all the external encoders connected to
> MDP.
> 
> The GPU phandle is removed too until we figure out what's the right way
> to specify it in DT.

[...]

> +  For MDP4, the output port mappings are:
> + Port 0 -> LCDC/LVDS
> + Port 1 -> DSI1 Cmd/Video
> + Port 2 -> DSI2 Cmd/Video
> + Port 3 -> DTV
> +
> + For MDP5, the availability of output ports vary across each SoC revision, 
> but
> + they generally have the following mapping:
> + Port 0 -> MDP_INTF0 (eDP)
> + Port 1 -> MDP_INTF1 (DSI1)
> + Port 2 -> MDP_INTF2 (DSI2)
> + Port 3 -> MDP_INTF3 (HDMI)
> +
> + See drivers/gpu/drm/msm/mdp/mdp5/mdp5_cfg.c to see what all INTFs a 
> particular
> + SoC revision has enabled.

The binding doc shouldn't depend on kernel code. You need to document it 
here.

Rob

[PATCH 2/2] drm/exynos/dsi: use of_graph_get_endpoint_by_regs helper

[Andrzej Hajda]

On 05/03/2016 03:47 PM, Philipp Zabel wrote:
> This allows to remove the local of_graph_get_port_by_reg(),
> of_graph_get_endpoint_by_reg(), and of_get_child_by_name_reg()
> functions.
> 
> Signed-off-by: Philipp Zabel 

Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c | 57 
> ++---
>  1 file changed, 3 insertions(+), 54 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 63c84a1..61251fe 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -1641,50 +1641,6 @@ static const struct drm_encoder_funcs 
> exynos_dsi_encoder_funcs = {
>  
>  MODULE_DEVICE_TABLE(of, exynos_dsi_of_match);
>  
> -/* of_* functions will be removed after merge of of_graph patches */
> -static struct device_node *
> -of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 
> reg)
> -{
> - struct device_node *np;
> -
> - for_each_child_of_node(parent, np) {
> - u32 r;
> -
> - if (!np->name || of_node_cmp(np->name, name))
> - continue;
> -
> - if (of_property_read_u32(np, "reg", ) < 0)
> - r = 0;
> -
> - if (reg == r)
> - break;
> - }
> -
> - return np;
> -}
> -
> -static struct device_node *of_graph_get_port_by_reg(struct device_node 
> *parent,
> - u32 reg)
> -{
> - struct device_node *ports, *port;
> -
> - ports = of_get_child_by_name(parent, "ports");
> - if (ports)
> - parent = ports;
> -
> - port = of_get_child_by_name_reg(parent, "port", reg);
> -
> - of_node_put(ports);
> -
> - return port;
> -}
> -
> -static struct device_node *
> -of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
> -{
> - return of_get_child_by_name_reg(port, "endpoint", reg);
> -}
> -
>  static int exynos_dsi_of_read_u32(const struct device_node *np,
> const char *propname, u32 *out_value)
>  {
> @@ -1706,7 +1662,7 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>  {
>   struct device *dev = dsi->dev;
>   struct device_node *node = dev->of_node;
> - struct device_node *port, *ep;
> + struct device_node *ep;
>   int ret;
>  
>   ret = exynos_dsi_of_read_u32(node, "samsung,pll-clock-frequency",
> @@ -1714,16 +1670,9 @@ static int exynos_dsi_parse_dt(struct exynos_dsi *dsi)
>   if (ret < 0)
>   return ret;
>  
> - port = of_graph_get_port_by_reg(node, DSI_PORT_OUT);
> - if (!port) {
> - dev_err(dev, "no output port specified\n");
> - return -EINVAL;
> - }
> -
> - ep = of_graph_get_endpoint_by_reg(port, 0);
> - of_node_put(port);
> + ep = of_graph_get_endpoint_by_regs(node, DSI_PORT_OUT, 0);
>   if (!ep) {
> - dev_err(dev, "no endpoint specified in output port\n");
> + dev_err(dev, "no output port with endpoint specified\n");
>   return -EINVAL;
>   }
>  
> 

[PATCH 1/2] drm/exynos/dpi: use of_graph_get_endpoint_by_regs helper

[Andrzej Hajda]

On 05/03/2016 03:47 PM, Philipp Zabel wrote:
> This allows to remove the local of_graph_get_port_by_reg(),
> of_graph_get_endpoint_by_reg(), of_get_child_by_name_reg(),
> and of_graph_get_remote_port_parent() functions.
> 
> Signed-off-by: Philipp Zabel 

Thanks for the patch.

Reviewed-by: Andrzej Hajda 
--
Regards
Andrzej

> ---
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c | 69 
> +
>  1 file changed, 2 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> index 75e570f..5e38e74 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  
>  #include 
> @@ -164,67 +165,6 @@ static const struct drm_encoder_funcs 
> exynos_dpi_encoder_funcs = {
>   .destroy = drm_encoder_cleanup,
>  };
>  
> -/* of_* functions will be removed after merge of of_graph patches */
> -static struct device_node *
> -of_get_child_by_name_reg(struct device_node *parent, const char *name, u32 
> reg)
> -{
> - struct device_node *np;
> -
> - for_each_child_of_node(parent, np) {
> - u32 r;
> -
> - if (!np->name || of_node_cmp(np->name, name))
> - continue;
> -
> - if (of_property_read_u32(np, "reg", ) < 0)
> - r = 0;
> -
> - if (reg == r)
> - break;
> - }
> -
> - return np;
> -}
> -
> -static struct device_node *of_graph_get_port_by_reg(struct device_node 
> *parent,
> - u32 reg)
> -{
> - struct device_node *ports, *port;
> -
> - ports = of_get_child_by_name(parent, "ports");
> - if (ports)
> - parent = ports;
> -
> - port = of_get_child_by_name_reg(parent, "port", reg);
> -
> - of_node_put(ports);
> -
> - return port;
> -}
> -
> -static struct device_node *
> -of_graph_get_endpoint_by_reg(struct device_node *port, u32 reg)
> -{
> - return of_get_child_by_name_reg(port, "endpoint", reg);
> -}
> -
> -static struct device_node *
> -of_graph_get_remote_port_parent(const struct device_node *node)
> -{
> - struct device_node *np;
> - unsigned int depth;
> -
> - np = of_parse_phandle(node, "remote-endpoint", 0);
> -
> - /* Walk 3 levels up only if there is 'ports' node. */
> - for (depth = 3; depth && np; depth--) {
> - np = of_get_next_parent(np);
> - if (depth == 2 && of_node_cmp(np->name, "ports"))
> - break;
> - }
> - return np;
> -}
> -
>  enum {
>   FIMD_PORT_IN0,
>   FIMD_PORT_IN1,
> @@ -237,12 +177,7 @@ static struct device_node 
> *exynos_dpi_of_find_panel_node(struct device *dev)
>  {
>   struct device_node *np, *ep;
>  
> - np = of_graph_get_port_by_reg(dev->of_node, FIMD_PORT_RGB);
> - if (!np)
> - return NULL;
> -
> - ep = of_graph_get_endpoint_by_reg(np, 0);
> - of_node_put(np);
> + ep = of_graph_get_endpoint_by_regs(dev->of_node, FIMD_PORT_RGB, 0);
>   if (!ep)
>   return NULL;
>  
> 

[Bug 95247] System hangs after ~10 minutes when using Radeon R9 390

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

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

--- Comment #3 from Oded Gabbay  ---
Could you please attach dmesg and "lspci -nn" ?

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

[PATCH 5/5] drm/edid: add displayid detailed 1 timings to the modelist.

[Dave Airlie]

From: Dave Airlie 

The tiled 5K Dell monitor appears to be hiding it's tiled mode
inside the displayid timings block, this patch parses this
blocks and adds the modes to the modelist.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=95207
Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_edid.c  | 105 
 include/drm/drm_displayid.h |  17 +++
 2 files changed, 122 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e85d828..aca9e25 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3925,6 +3925,110 @@ static int validate_displayid(u8 *displayid, int 
length, int idx)
return 0;
 }

+static struct drm_display_mode *drm_mode_displayid_detailed(struct drm_device 
*dev,
+   struct 
displayid_detailed_timings_1 *timings)
+{
+   struct drm_display_mode *mode;
+   unsigned pixel_clock = (timings->pixel_clock[0] |
+   (timings->pixel_clock[1] << 8) |
+   (timings->pixel_clock[2] << 16));
+   unsigned hactive = (timings->hactive[0] | timings->hactive[1] << 8) + 1;
+   unsigned hblank = (timings->hblank[0] | timings->hblank[1] << 8) + 1;
+   unsigned hsync = (timings->hsync[0] | (timings->hsync[1] & 0x7f) << 8) 
+ 1;
+   unsigned hsync_width = (timings->hsw[0] | timings->hsw[1] << 8) + 1;
+   unsigned vactive = (timings->vactive[0] | timings->vactive[1] << 8) + 1;
+   unsigned vblank = (timings->vblank[0] | timings->vblank[1] << 8) + 1;
+   unsigned vsync = (timings->vsync[0] | (timings->vsync[1] & 0x7f) << 8) 
+ 1;
+   unsigned vsync_width = (timings->vsw[0] | timings->vsw[1] << 8) + 1;
+   bool hsync_positive = (timings->hsync[1] >> 7) & 0x1;
+   bool vsync_positive = (timings->vsync[1] >> 7) & 0x1;
+   mode = drm_mode_create(dev);
+   if (!mode)
+   return NULL;
+
+   mode->clock = pixel_clock * 10;
+   mode->hdisplay = hactive;
+   mode->hsync_start = mode->hdisplay + hsync;
+   mode->hsync_end = mode->hsync_start + hsync_width;
+   mode->htotal = mode->hdisplay + hblank;
+
+   mode->vdisplay = vactive;
+   mode->vsync_start = mode->vdisplay + vsync;
+   mode->vsync_end = mode->vsync_start + vsync_width;
+   mode->vtotal = mode->vdisplay + vblank;
+
+   mode->flags = 0;
+   mode->flags |= hsync_positive ? DRM_MODE_FLAG_PHSYNC : 
DRM_MODE_FLAG_NHSYNC;
+   mode->flags |= vsync_positive ? DRM_MODE_FLAG_PVSYNC : 
DRM_MODE_FLAG_NVSYNC;
+   mode->type = DRM_MODE_TYPE_DRIVER;
+
+   if (timings->flags & 0x80)
+   mode->type |= DRM_MODE_TYPE_PREFERRED;
+   mode->vrefresh = drm_mode_vrefresh(mode);
+   drm_mode_set_name(mode);
+
+   return mode;
+}
+
+static int add_displayid_detailed_1_modes(struct drm_connector *connector,
+ struct displayid_block *block)
+{
+   struct displayid_detailed_timing_block *det = (struct 
displayid_detailed_timing_block *)block;
+   int i;
+   int num_timings;
+   struct drm_display_mode *newmode;
+   int num_modes = 0;
+   /* blocks must be multiple of 20 bytes length */
+   if (block->num_bytes % 20)
+   return 0;
+
+   num_timings = block->num_bytes / 20;
+   for (i = 0; i < num_timings; i++) {
+   struct displayid_detailed_timings_1 *timings = >timings[i];
+
+   newmode = drm_mode_displayid_detailed(connector->dev, timings);
+   if (!newmode)
+   continue;
+
+   drm_mode_probed_add(connector, newmode);
+   num_modes++;
+   }
+   return num_modes;
+}
+
+static int add_displayid_detailed_modes(struct drm_connector *connector,
+   struct edid *edid)
+{
+   u8 *displayid;
+   int ret;
+   int idx = 1;
+   int length = EDID_LENGTH;
+   struct displayid_block *block;
+   int num_modes = 0;
+
+   displayid = drm_find_displayid_extension(edid);
+   if (!displayid)
+   return 0;
+
+   ret = validate_displayid(displayid, length, idx);
+   if (ret)
+   return 0;
+
+   idx += sizeof(struct displayid_hdr);
+   while (block = (struct displayid_block *)[idx],
+  idx + sizeof(struct displayid_block) <= length &&
+  idx + sizeof(struct displayid_block) + block->num_bytes <= 
length &&
+  block->num_bytes > 0) {
+   idx += block->num_bytes + sizeof(struct displayid_block);
+   switch (block->tag) {
+   case DATA_BLOCK_TYPE_1_DETAILED_TIMING:
+   num_modes += add_displayid_detailed_1_modes(connector, 
block);
+   break;
+   }
+   }
+   return num_modes;
+}
+
 /**
  * drm_add_edid_modes - add modes 

[PATCH 4/5] drm/edid: move displayid validation to it's own function.

[Dave Airlie]

From: Dave Airlie 

We need to use this for validating modeline additions.

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

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e4c681f..e85d828 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3901,6 +3901,30 @@ static void drm_add_display_info(struct edid *edid,
info->color_formats |= DRM_COLOR_FORMAT_YCRCB422;
 }

+static int validate_displayid(u8 *displayid, int length, int idx)
+{
+   int i;
+   u8 csum = 0;
+   struct displayid_hdr *base;
+
+   base = (struct displayid_hdr *)[idx];
+
+   DRM_DEBUG_KMS("base revision v%d.%d, edid length %d, bytes %d, prod_id 
%d ext_count %d\n",
+ base->ver, base->rev, length, base->bytes, base->prod_id,
+ base->ext_count);
+
+   if (base->bytes + 5 > length - idx)
+   return -EINVAL;
+   for (i = idx; i <= base->bytes + 5; i++) {
+   csum += displayid[i];
+   }
+   if (csum) {
+   DRM_ERROR("DisplayID checksum invalid, remainder is %d\n", 
csum);
+   return -EINVAL;
+   }
+   return 0;
+}
+
 /**
  * drm_add_edid_modes - add modes from EDID data, if available
  * @connector: connector we're probing
@@ -4212,30 +4236,15 @@ static int drm_parse_display_id(struct drm_connector 
*connector,
 {
/* if this is an EDID extension the first byte will be 0x70 */
int idx = 0;
-   struct displayid_hdr *base;
struct displayid_block *block;
-   u8 csum = 0;
-   int i;
int ret;

if (is_edid_extension)
idx = 1;

-   base = (struct displayid_hdr *)[idx];
-
-   DRM_DEBUG_KMS("base revision v%d.%d, edid length %d, bytes %d, prod_id 
%d ext_count %d\n",
- base->ver, base->rev, length, base->bytes, base->prod_id, 
base->ext_count);
-
-   if (base->bytes + 5 > length - idx)
-   return -EINVAL;
-
-   for (i = idx; i <= base->bytes + 5; i++) {
-   csum += displayid[i];
-   }
-   if (csum) {
-   DRM_ERROR("DisplayID checksum invalid, remainder is %d\n", 
csum);
-   return -EINVAL;
-   }
+   ret = validate_displayid(displayid, length, idx);
+   if (ret)
+   return ret;

idx += sizeof(struct displayid_hdr);
while (block = (struct displayid_block *)[idx],
-- 
2.5.5

[PATCH 3/5] drm/edid: move displayid tiled block parsing into separate function.

[Dave Airlie]

From: Dave Airlie 

This just makes the code easier to follow.

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

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1a364b3..e4c681f 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4152,6 +4152,60 @@ drm_hdmi_vendor_infoframe_from_display_mode(struct 
hdmi_vendor_infoframe *frame,
 }
 EXPORT_SYMBOL(drm_hdmi_vendor_infoframe_from_display_mode);

+static int drm_parse_tiled_block(struct drm_connector *connector,
+struct displayid_block *block)
+{
+   struct displayid_tiled_block *tile = (struct displayid_tiled_block 
*)block;
+   u16 w, h;
+   u8 tile_v_loc, tile_h_loc;
+   u8 num_v_tile, num_h_tile;
+   struct drm_tile_group *tg;
+
+   w = tile->tile_size[0] | tile->tile_size[1] << 8;
+   h = tile->tile_size[2] | tile->tile_size[3] << 8;
+
+   num_v_tile = (tile->topo[0] & 0xf) | (tile->topo[2] & 0x30);
+   num_h_tile = (tile->topo[0] >> 4) | ((tile->topo[2] >> 2) & 0x30);
+   tile_v_loc = (tile->topo[1] & 0xf) | ((tile->topo[2] & 0x3) << 4);
+   tile_h_loc = (tile->topo[1] >> 4) | (((tile->topo[2] >> 2) & 0x3) << 4);
+
+   connector->has_tile = true;
+   if (tile->tile_cap & 0x80)
+   connector->tile_is_single_monitor = true;
+
+   connector->num_h_tile = num_h_tile + 1;
+   connector->num_v_tile = num_v_tile + 1;
+   connector->tile_h_loc = tile_h_loc;
+   connector->tile_v_loc = tile_v_loc;
+   connector->tile_h_size = w + 1;
+   connector->tile_v_size = h + 1;
+
+   DRM_DEBUG_KMS("tile cap 0x%x\n", tile->tile_cap);
+   DRM_DEBUG_KMS("tile_size %d x %d\n", w + 1, h + 1);
+   DRM_DEBUG_KMS("topo num tiles %dx%d, location %dx%d\n",
+ num_h_tile + 1, num_v_tile + 1, tile_h_loc, tile_v_loc);
+   DRM_DEBUG_KMS("vend %c%c%c\n", tile->topology_id[0], 
tile->topology_id[1], tile->topology_id[2]);
+
+   tg = drm_mode_get_tile_group(connector->dev, tile->topology_id);
+   if (!tg) {
+   tg = drm_mode_create_tile_group(connector->dev, 
tile->topology_id);
+   }
+   if (!tg)
+   return -ENOMEM;
+
+   if (connector->tile_group != tg) {
+   /* if we haven't got a pointer,
+  take the reference, drop ref to old tile group */
+   if (connector->tile_group) {
+   drm_mode_put_tile_group(connector->dev, 
connector->tile_group);
+   }
+   connector->tile_group = tg;
+   } else
+   /* if same tile group, then release the ref we just took. */
+   drm_mode_put_tile_group(connector->dev, tg);
+   return 0;
+}
+
 static int drm_parse_display_id(struct drm_connector *connector,
u8 *displayid, int length,
bool is_edid_extension)
@@ -4162,6 +4216,7 @@ static int drm_parse_display_id(struct drm_connector 
*connector,
struct displayid_block *block;
u8 csum = 0;
int i;
+   int ret;

if (is_edid_extension)
idx = 1;
@@ -4192,57 +4247,10 @@ static int drm_parse_display_id(struct drm_connector 
*connector,
  block->tag, block->rev, block->num_bytes);

switch (block->tag) {
-   case DATA_BLOCK_TILED_DISPLAY: {
-   struct displayid_tiled_block *tile = (struct 
displayid_tiled_block *)block;
-
-   u16 w, h;
-   u8 tile_v_loc, tile_h_loc;
-   u8 num_v_tile, num_h_tile;
-   struct drm_tile_group *tg;
-
-   w = tile->tile_size[0] | tile->tile_size[1] << 8;
-   h = tile->tile_size[2] | tile->tile_size[3] << 8;
-
-   num_v_tile = (tile->topo[0] & 0xf) | (tile->topo[2] & 
0x30);
-   num_h_tile = (tile->topo[0] >> 4) | ((tile->topo[2] >> 
2) & 0x30);
-   tile_v_loc = (tile->topo[1] & 0xf) | ((tile->topo[2] & 
0x3) << 4);
-   tile_h_loc = (tile->topo[1] >> 4) | (((tile->topo[2] >> 
2) & 0x3) << 4);
-
-   connector->has_tile = true;
-   if (tile->tile_cap & 0x80)
-   connector->tile_is_single_monitor = true;
-
-   connector->num_h_tile = num_h_tile + 1;
-   connector->num_v_tile = num_v_tile + 1;
-   connector->tile_h_loc = tile_h_loc;
-   connector->tile_v_loc = tile_v_loc;
-   connector->tile_h_size = w + 1;
-   connector->tile_v_size = h + 1;
-
-   DRM_DEBUG_KMS("tile cap 0x%x\n", tile->tile_cap);
-  

[PATCH 2/5] drm/displayid: Iterate over all DisplayID blocks

[Dave Airlie]

From: Tomas Bzatek 

This will iterate over all DisplayID blocks found in the buffer.
Previously only the first block was parsed.

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

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

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index c8a3a55..1a364b3 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4182,66 +4182,72 @@ static int drm_parse_display_id(struct drm_connector 
*connector,
return -EINVAL;
}

-   block = (struct displayid_block *)[idx + 4];
-   DRM_DEBUG_KMS("block id 0x%x, rev %d, len %d\n",
- block->tag, block->rev, block->num_bytes);
-
-   switch (block->tag) {
-   case DATA_BLOCK_TILED_DISPLAY: {
-   struct displayid_tiled_block *tile = (struct 
displayid_tiled_block *)block;
-
-   u16 w, h;
-   u8 tile_v_loc, tile_h_loc;
-   u8 num_v_tile, num_h_tile;
-   struct drm_tile_group *tg;
-
-   w = tile->tile_size[0] | tile->tile_size[1] << 8;
-   h = tile->tile_size[2] | tile->tile_size[3] << 8;
-
-   num_v_tile = (tile->topo[0] & 0xf) | (tile->topo[2] & 0x30);
-   num_h_tile = (tile->topo[0] >> 4) | ((tile->topo[2] >> 2) & 
0x30);
-   tile_v_loc = (tile->topo[1] & 0xf) | ((tile->topo[2] & 0x3) << 
4);
-   tile_h_loc = (tile->topo[1] >> 4) | (((tile->topo[2] >> 2) & 
0x3) << 4);
-
-   connector->has_tile = true;
-   if (tile->tile_cap & 0x80)
-   connector->tile_is_single_monitor = true;
-
-   connector->num_h_tile = num_h_tile + 1;
-   connector->num_v_tile = num_v_tile + 1;
-   connector->tile_h_loc = tile_h_loc;
-   connector->tile_v_loc = tile_v_loc;
-   connector->tile_h_size = w + 1;
-   connector->tile_v_size = h + 1;
-
-   DRM_DEBUG_KMS("tile cap 0x%x\n", tile->tile_cap);
-   DRM_DEBUG_KMS("tile_size %d x %d\n", w + 1, h + 1);
-   DRM_DEBUG_KMS("topo num tiles %dx%d, location %dx%d\n",
-  num_h_tile + 1, num_v_tile + 1, tile_h_loc, tile_v_loc);
-   DRM_DEBUG_KMS("vend %c%c%c\n", tile->topology_id[0], 
tile->topology_id[1], tile->topology_id[2]);
-
-   tg = drm_mode_get_tile_group(connector->dev, tile->topology_id);
-   if (!tg) {
-   tg = drm_mode_create_tile_group(connector->dev, 
tile->topology_id);
-   }
-   if (!tg)
-   return -ENOMEM;
-
-   if (connector->tile_group != tg) {
-   /* if we haven't got a pointer,
-  take the reference, drop ref to old tile group */
-   if (connector->tile_group) {
-   drm_mode_put_tile_group(connector->dev, 
connector->tile_group);
+   idx += sizeof(struct displayid_hdr);
+   while (block = (struct displayid_block *)[idx],
+  idx + sizeof(struct displayid_block) <= length &&
+  idx + sizeof(struct displayid_block) + block->num_bytes <= 
length &&
+  block->num_bytes > 0) {
+   idx += block->num_bytes + sizeof(struct displayid_block);
+   DRM_DEBUG_KMS("block id 0x%x, rev %d, len %d\n",
+ block->tag, block->rev, block->num_bytes);
+
+   switch (block->tag) {
+   case DATA_BLOCK_TILED_DISPLAY: {
+   struct displayid_tiled_block *tile = (struct 
displayid_tiled_block *)block;
+
+   u16 w, h;
+   u8 tile_v_loc, tile_h_loc;
+   u8 num_v_tile, num_h_tile;
+   struct drm_tile_group *tg;
+
+   w = tile->tile_size[0] | tile->tile_size[1] << 8;
+   h = tile->tile_size[2] | tile->tile_size[3] << 8;
+
+   num_v_tile = (tile->topo[0] & 0xf) | (tile->topo[2] & 
0x30);
+   num_h_tile = (tile->topo[0] >> 4) | ((tile->topo[2] >> 
2) & 0x30);
+   tile_v_loc = (tile->topo[1] & 0xf) | ((tile->topo[2] & 
0x3) << 4);
+   tile_h_loc = (tile->topo[1] >> 4) | (((tile->topo[2] >> 
2) & 0x3) << 4);
+
+   connector->has_tile = true;
+   if (tile->tile_cap & 0x80)
+   connector->tile_is_single_monitor = true;
+
+   connector->num_h_tile = num_h_tile + 1;
+   connector->num_v_tile = num_v_tile + 1;
+   connector->tile_h_loc = tile_h_loc;
+   connector->tile_v_loc = tile_v_loc;
+   

[PATCH 1/5] drm/displayid: Enhance version reporting

[Dave Airlie]

From: Tomas Bzatek 

Cosmetic change, let's report more precise revisions and IDs.

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

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_edid.c  | 6 +++---
 include/drm/drm_displayid.h | 6 --
 2 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9a9be9a..c8a3a55 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -4168,8 +4168,8 @@ static int drm_parse_display_id(struct drm_connector 
*connector,

base = (struct displayid_hdr *)[idx];

-   DRM_DEBUG_KMS("base revision 0x%x, length %d, %d %d\n",
- base->rev, base->bytes, base->prod_id, base->ext_count);
+   DRM_DEBUG_KMS("base revision v%d.%d, edid length %d, bytes %d, prod_id 
%d ext_count %d\n",
+ base->ver, base->rev, length, base->bytes, base->prod_id, 
base->ext_count);

if (base->bytes + 5 > length - idx)
return -EINVAL;
@@ -4183,7 +4183,7 @@ static int drm_parse_display_id(struct drm_connector 
*connector,
}

block = (struct displayid_block *)[idx + 4];
-   DRM_DEBUG_KMS("block id %d, rev %d, len %d\n",
+   DRM_DEBUG_KMS("block id 0x%x, rev %d, len %d\n",
  block->tag, block->rev, block->num_bytes);

switch (block->tag) {
diff --git a/include/drm/drm_displayid.h b/include/drm/drm_displayid.h
index 623b4e9..042f9fc 100644
--- a/include/drm/drm_displayid.h
+++ b/include/drm/drm_displayid.h
@@ -52,7 +52,8 @@
 #define PRODUCT_TYPE_DIRECT_DRIVE 6

 struct displayid_hdr {
-   u8 rev;
+   u8 rev:4;
+   u8 ver:4;
u8 bytes;
u8 prod_id;
u8 ext_count;
@@ -60,7 +61,8 @@ struct displayid_hdr {

 struct displayid_block {
u8 tag;
-   u8 rev;
+   u8 rev:3;
+   u8 reserved:5;
u8 num_bytes;
 } __packed;

-- 
2.5.5

[rfc] drm/edid: add support for displayid timings

[Dave Airlie]

It appears that Dell 5K monitors hide some mode timings
in the displayid block, this set of patches fixes up a few
bits of displayid support, then add support for extracting
the type 1 detailed timings that the Dell monitors use.

The first two patches are missing signoff but I've asked
for Tomas to provide them.

This at least gets the modelines into the modelist.

Dave.