[Bug 81281] 8970M boot problems since 3.13 with dpm

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

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

sharkgoesmad  changed:

   What|Removed |Added

 CC||sharkgoesmad at gmail.com
 Regression|No  |Yes

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

[Bug 81281] 8970M boot problems since 3.13 with dpm

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

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

--- Comment #1 from sharkgoesmad  ---
Created attachment 144541
  --> https://bugzilla.kernel.org/attachment.cgi?id=144541=edit
Xorg.0.log.old

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

[Bug 81281] New: 8970M boot problems since 3.13 with dpm

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

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

Bug ID: 81281
   Summary: 8970M boot problems since 3.13 with dpm
   Product: Drivers
   Version: 2.5
Kernel Version: 3.16.0-rc5
  Hardware: All
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI - non Intel)
  Assignee: drivers_video-dri at kernel-bugs.osdl.org
  Reporter: sharkgoesmad at gmail.com
Regression: No

Created attachment 144531
  --> https://bugzilla.kernel.org/attachment.cgi?id=144531=edit
syslog

I am using MSI GX60 3BE 240US, which is a AMD/AMD hybrid, sporting a10-5750m
Richland apu and super-powerful HD 8970M.

Since kernel 3.13, my laptop is unable to boot unless ran with radeon.dpm=0.
Worth to note that 3.12 with radeon.dpm=1 works mighty fine.

While trying different kernel versions and inspecting syslog, it seems that in
all cases the problem starts with the following line:

[drm:r600_ring_test] *ERROR* radeon: ring 0 test failed
(scratch(0x850C)=0xCAFEDEAD)

In 3.13-3.15 it results in system restart when the login screen shows up. In
3.16 however, the screen freezes and no restart occurs. The system responds
normally when pressing power button and shuts down.

Attached is the piece of the syslog and Xorg.0.log when ran with 3.16-rc5.

Any help would be greatly appreciated. Thanks.

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

[PATCH -next] drm/i915: Remove duplicated include from intel_dsi_panel_vbt.c

[weiyj...@163.com]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 47c7584..1439516 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -31,7 +31,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "i915_drv.h"
 #include "intel_drv.h"
 #include "intel_dsi.h"

[PATCH -next] drm: Remove duplicated include from drm_plane_helper.c

[weiyj...@163.com]

From: Wei Yongjun 

Remove duplicated include.

Signed-off-by: Wei Yongjun 
---
 drivers/gpu/drm/drm_plane_helper.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 6d13314..64ce96c 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 

 #define SUBPIXEL_MASK 0x

[PATCH] drm/rcar-du: Fix maximum frame buffer pitch computation

[Laurent Pinchart]

The maximum pitch constraint for the hardware is expressed in pixels.
Convert it to bytes to validate frame buffer creation, as frame buffer
pitches are expressed in bytes.

Reported-by: Phil Edworthy 
Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 3875854..7eabbd7 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -135,7 +135,9 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file 
*file_priv,
 {
struct rcar_du_device *rcdu = dev->dev_private;
const struct rcar_du_format_info *format;
+   unsigned int max_pitch;
unsigned int align;
+   unsigned int bpp;

format = rcar_du_format_info(mode_cmd->pixel_format);
if (format == NULL) {
@@ -144,13 +146,20 @@ rcar_du_fb_create(struct drm_device *dev, struct drm_file 
*file_priv,
return ERR_PTR(-EINVAL);
}

+   /*
+* The pitch and alignment constraints are expressed in pixels on the
+* hardware side and in bytes in the DRM API.
+*/
+   bpp = format->planes == 2 ? 1 : format->bpp / 8;
+   max_pitch =  4096 * bpp;
+
if (rcar_du_needs(rcdu, RCAR_DU_QUIRK_ALIGN_128B))
align = 128;
else
-   align = 16 * format->bpp / 8;
+   align = 16 * bpp;

if (mode_cmd->pitches[0] & (align - 1) ||
-   mode_cmd->pitches[0] >= 8192) {
+   mode_cmd->pitches[0] >= max_pitch) {
dev_dbg(dev->dev, "invalid pitch value %u\n",
mode_cmd->pitches[0]);
return ERR_PTR(-EINVAL);
-- 
Regards,

Laurent Pinchart

[Bug 79157] [Tesseract Game] Grainy SSAO on RadeonSI

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

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

--- Comment #4 from smoki  ---

 This seems fixed in current git 10.3-devel :).

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

Re: [Radeon RV280] radeon_cs_gem.c:181: cs_gem_write_reloc: Assertion »boi->space_accounted« failed, core dumped

[Jochen Rollwagen]

I think i probably hit a regression in the mesa libraries since older 
versions of mesa used to work. I'll try to downgrade from 10.1.6 and see 
what happens.

Am 27.07.2014 um 14:47 schrieb Marek Ol??k:
> I think the problem is the driver hasn't called
> radeon_cs_space_add_persistent_bo.
>
> Marek
>
> On Fri, Jul 25, 2014 at 6:32 PM, Jochen Rollwagen  
> wrote:
>> I've recently ported the peopsxgl OpenGL-GPU-Plugin for the pcsx
>> Playstation1 Emulator to the Powerpc-architecture. When running certain
>> games (for instance "Vagrant Stories") during longer cut-scenes i get a
>> reproducible crash of the radeon drm driver (i.e. it always crashes at
>> certain points in the scene) with the following message (in german):
>>
>> pcsx: radeon_cs_gem.c:181: cs_gem_write_reloc: Zusicherung
>> ?boi->space_accounted? nicht erf?llt.
>> Abgebrochen (Speicherabzug geschrieben)
>>
>> This happens with all the latest 3.10, 3.12 and 3.14 kernels.
>>
>> Other than that i'm running the latest xorg-ati driver, libdrm and mesa from
>> git on a Mac Mini G4 (PowerPC).
>>
>> OpenGL vendor string: Mesa Project
>> OpenGL renderer string: Mesa DRI R200 (RV280 5962)  TCL DRI2
>> OpenGL version string: 1.3 Mesa 10.1.6 (git-42f86ef)
>>
>> I guess the issue is memory/vm/swap-related since the machine only has 1 gb
>> RAM. The GPU has 64 MB VRAM.
>>
>> Any ideas what i could do to avoid these crashes ?
>>
>>
>>
>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 79980] Random radeonsi crashes

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

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

--- Comment #58 from agapito  ---
3.16 rc7 solved this bug! but i need more testing.

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

[PATCH] drm: add checking DRM_FORMAT_NV12MT

[Ville Syrjälä]

On Mon, Jul 28, 2014 at 11:56:59AM -0400, Rob Clark wrote:
> On Mon, Jul 28, 2014 at 12:47 AM, Joonyoung Shim
>  wrote:
> > If user NV12MT uses as pixel format, the Addfb2 ioctl is failed because
> > of missing to check DRM_FORMAT_NV12MT. The NV12MT pixel format is
> > supported by exynos4 and some qualcomm chipset and it is used by exynos
> > drm driver.
> 
> tbh, format_check() should probably just be made to respect the
> formats advertised by all the planes..

That can't be done until all drivers are converted to primary/cursor
planes. Also I'm not sure if we should allow it even then since that
would make it quite easy to sneak in new driver specific formats
without anyone necessarily reviewing them.

> 
> BR,
> -R
> 
> > Signed-off-by: Joonyoung Shim 
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 1ccf5cb..5d7bd49 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -2960,6 +2960,7 @@ static int format_check(const struct drm_mode_fb_cmd2 
> > *r)
> > case DRM_FORMAT_NV61:
> > case DRM_FORMAT_NV24:
> > case DRM_FORMAT_NV42:
> > +   case DRM_FORMAT_NV12MT:
> > case DRM_FORMAT_YUV410:
> > case DRM_FORMAT_YVU410:
> > case DRM_FORMAT_YUV411:
> > @@ -4800,6 +4801,7 @@ int drm_format_num_planes(uint32_t format)
> > case DRM_FORMAT_NV61:
> > case DRM_FORMAT_NV24:
> > case DRM_FORMAT_NV42:
> > +   case DRM_FORMAT_NV12MT:
> > return 2;
> > default:
> > return 1;
> > @@ -4835,6 +4837,7 @@ int drm_format_plane_cpp(uint32_t format, int plane)
> > case DRM_FORMAT_NV61:
> > case DRM_FORMAT_NV24:
> > case DRM_FORMAT_NV42:
> > +   case DRM_FORMAT_NV12MT:
> > return plane ? 2 : 1;
> > case DRM_FORMAT_YUV410:
> > case DRM_FORMAT_YVU410:
> > @@ -4878,6 +4881,7 @@ int drm_format_horz_chroma_subsampling(uint32_t 
> > format)
> > case DRM_FORMAT_NV21:
> > case DRM_FORMAT_NV16:
> > case DRM_FORMAT_NV61:
> > +   case DRM_FORMAT_NV12MT:
> > case DRM_FORMAT_YUV422:
> > case DRM_FORMAT_YVU422:
> > case DRM_FORMAT_YUV420:
> > @@ -4907,6 +4911,7 @@ int drm_format_vert_chroma_subsampling(uint32_t 
> > format)
> > case DRM_FORMAT_YVU420:
> > case DRM_FORMAT_NV12:
> > case DRM_FORMAT_NV21:
> > +   case DRM_FORMAT_NV12MT:
> > return 2;
> > default:
> > return 1;
> > --
> > 1.8.1.2
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[PATCH v2 00/11] ARM: dts: zynq: Prepare Parallella

[Lars-Peter Clausen]

On 07/28/2014 06:17 PM, Andreas F?rber wrote:
> Hi Lars-Peter,
>
> Am 25.07.2014 01:00, schrieb Andreas F?rber:
>> most notably I'm missing
>> ADI ADV7513 and AXI-HDMI support
> [...]
>> Cc: Lars-Peter Clausen  (HDMI)
>
> Could you please enlighten us what the status of upstreaming
> ADV7511/ADV7513 support is? It is declared "work in progress" here:
>
> http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511
>
> I see some adv7511 V4L bits in drivers/media/i2c/adv7511.c, but no
> drivers/gpu/drm/i2c/adv7511_{core,audio}.c as on the xcomm_zynq branch,
> nor any devicetree documentation. Patchwork doesn't show any recent
> submissions to LKML.
>
> Is any major rework needed for you to get the 3.14.12 based driver upstream?
>

It's complicated. The plan for the driver was to wait for the common display 
framework (CDF) and convert it to use CDF and then submit it upstream. The 
CDF has been rejected though. Meanwhile the V4L2 adv7511 driver has been 
merged. So now we are in the ugly situation that we have two different 
drivers for two different frameworks. To fix this we need to merge these two 
drivers while still exposing the interfaces to both frameworks.

> AXI SPDIF I found in 3.16, as you noticed; what about AXI HDMI? [*]
> Is there any work ongoing to get that upstream as well?

We need to teach the DMAengine framework about cyclic interleaved transfers 
before the AXI HDMI driver can be submitted upstream.

- Lars

[PATCH v2 00/11] ARM: dts: zynq: Prepare Parallella

[Andreas Färber]

Hi Lars-Peter,

Am 25.07.2014 01:00, schrieb Andreas F?rber:
> most notably I'm missing 
> ADI ADV7513 and AXI-HDMI support
[...]
> Cc: Lars-Peter Clausen  (HDMI)

Could you please enlighten us what the status of upstreaming
ADV7511/ADV7513 support is? It is declared "work in progress" here:

http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511

I see some adv7511 V4L bits in drivers/media/i2c/adv7511.c, but no
drivers/gpu/drm/i2c/adv7511_{core,audio}.c as on the xcomm_zynq branch,
nor any devicetree documentation. Patchwork doesn't show any recent
submissions to LKML.

Is any major rework needed for you to get the 3.14.12 based driver upstream?

AXI SPDIF I found in 3.16, as you noticed; what about AXI HDMI? [*]
Is there any work ongoing to get that upstream as well?

Any pointers appreciated.

Thanks,
Andreas

[*]
http://wiki.analog.com/resources/tools-software/linux-drivers/platforms/zynq

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Andrzej Hajda]

On 07/28/2014 04:00 AM, Inki Dae wrote:
> This patch adds below two flags for LPM transfer, and it attaches LPM flags
> to a msg in accordance with master's mode_flags set by LCD Panel driver.
> 
> MIPI_DSI_MODE_CMD_LPM
> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
> command data to Panel device in Low Power Mode.

What do you mean by command data? It could be:
- all transfer in command mode of operations,
- transfer initialized by the driver by writing to DSIM registers.

> 
> MIPI_DSI_MODE_VIDEO_LPM
> - If this flag is set by Panel driver, MIPI-DSI controller will tranfer
> image data to Panel device in Low Power Mode.

What is the meaning of this flag in case of command mode of operation?

Maybe it would be better to create flags based on source of data/FIFOs:
- commands send by SFR registers,
- commands generated from data sent from Display Controller.


> 
> And above two flags can be combined together to transfer command and video
> data to Panel device.
> 
> MIPI DSI spec says,
>  "the host processor controls the desired mode of clock operation.
>   Host protocol and applications control Clock Lane operating mode
>   (High Speed or Low Power mode). System designers are responsible
>   for understanding the clock requirements for peripherals attached
>   to DSI and controlling clock behavior in accordance with those
>   requirements."
> 
> Some LCD Panel devices, nt35502a, would need LPM transfer support
> because they should receive some initial commands with LPM by default
> hardware setting.


Is this requirement for initial commands, or for all commands.
Btw what is the mode of operation of nt35502a? What flags do you need
for it?



> 
> Changelog v2: just add more descriptions.
> 
> Signed-off-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/drm_mipi_dsi.c |3 +++
>  include/drm/drm_mipi_dsi.h |4 
>  2 files changed, 7 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index e633df2..6b2bbda 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, 
> unsigned int channel,
>   break;
>   }
>  
> + if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
> + msg.flags = MIPI_DSI_MSG_USE_LPM;
> +
>   return ops->transfer(dsi->host, );
>  }

Shouldn't this be also the same for dcs read?

Anyway I think check in the DSIM should be used instead, as panel driver
can issue other dsi transfers without MIPI_DSI_MSG_USE_LPM flag set.

Regards
Andrzej


>  EXPORT_SYMBOL(mipi_dsi_dcs_write);
> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> index 944f33f..1c41e49 100644
> --- a/include/drm/drm_mipi_dsi.h
> +++ b/include/drm/drm_mipi_dsi.h
> @@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
>  #define MIPI_DSI_MODE_VSYNC_FLUSHBIT(8)
>  /* disable EoT packets in HS mode */
>  #define MIPI_DSI_MODE_EOT_PACKET BIT(9)
> +/* command low power mode */
> +#define MIPI_DSI_MODE_CMD_LPMBIT(10)
> +/* video low power mode */
> +#define MIPI_DSI_MODE_VIDEO_LPM  BIT(11)
>  
>  enum mipi_dsi_pixel_format {
>   MIPI_DSI_FMT_RGB888,
> 

[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Andrzej Hajda]

On 07/28/2014 04:00 AM, Inki Dae wrote:
> This patch adds LPM transfer support for video or command data.
>
> With this patch, Exynos MIPI DSI controller can transfer command or
> video data with HS or LP mode in accordance with mode_flags set
> by LCD Panel driver.
>
> Changelog v2: Enable High Speed clock only in case of stand by request.
>
> Signed-off-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 --
>  1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> index 5e78d45..1bed105 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
> @@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi 
> *dsi)
>   | DSIM_ESC_PRESCALER(esc_div)
>   | DSIM_LANE_ESC_CLK_EN_CLK
>   | DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
> - | DSIM_BYTE_CLK_SRC(0)
> - | DSIM_TX_REQUEST_HSCLK;
> + | DSIM_BYTE_CLK_SRC(0);
> +
> + if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
> + reg |= DSIM_TX_REQUEST_HSCLK;
> +
>   writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
>  
>   return 0;
> @@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi 
> *dsi)
>   writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
>  }
>  
> +static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
> + bool enable)
> +{
> + u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
> +
> + reg &= ~DSIM_TX_REQUEST_HSCLK;
> + if (enable)
> + reg |= DSIM_TX_REQUEST_HSCLK;
> +
> + writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
> +}
> +

I have tested DSIM_TX_REQUEST_HSCLK bit on trats device(video mode HS) -
it works with and without the bit set.
So I start to suspect this bit is not just for simply enable/disable HS
clock as function name suggests, do you know what is its
exact meaning? The specs are quite succinct on it.
On the other side I have found DSIM_TX_LPDT_LP and DSIM_CMD_LPDT_LP bits
in DSIM_ESCMODE register
which seems to be related to flags you have introduced:
- DSIM_CMD_LPDT_LP - transmit commands in LP mode,
- DSIM_TX_LPDT_LP - transmit data in LP mode.
The former is already triggered by MIPI_DSI_MSG_USE_LPM flag. Why do not
you use the latter?

Regards
Andrzej

>  static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
>  {
>   u32 reg;
> @@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct 
> exynos_dsi *dsi, bool enable)
>  {
>   u32 reg;
>  
> + if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
> + exynos_dsi_enable_hs_clock(dsi, true);
> +
>   reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
>   if (enable)
>   reg |= DSIM_MAIN_STAND_BY;

[PATCH libdrm] libdrm: Fix drm.h include in qxl drm header file

[Andreas Boll]

2014-07-28 17:06 GMT+02:00 Emil Velikov :
> On 28/07/14 15:35, Andreas Boll wrote:
>> ping
>>
>> 2014-05-05 23:54 GMT+02:00 Andreas Boll :
>>> Use "drm.h" instead of "drm/drm.h" as used in the other header files.
>>> Fixes xserver-xorg-video-qxl build with KMS support on Debian, where this
>>> file is installed in /usr/include/libdrm.
>>>
> I believe that's the default location for most linux distributions. Seems like
> not many of us build the qxl ddx :\
>
> FWIW
> Reviewed-by: Emil Velikov 
>

Thanks!
Pushed.

>>> Fixes Debian bug #746807
>>>
>>> Reported-by: Bastian Blank 
>>> Signed-off-by: Andreas Boll 
>>> ---
>>>  include/drm/qxl_drm.h | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h
>>> index 5d7de70..1e331a8 100644
>>> --- a/include/drm/qxl_drm.h
>>> +++ b/include/drm/qxl_drm.h
>>> @@ -25,7 +25,7 @@
>>>  #define QXL_DRM_H
>>>
>>>  #include 
>>> -#include "drm/drm.h"
>>> +#include "drm.h"
>>>
>>>  /* Please note that modifications to all structs defined here are
>>>   * subject to backwards-compatibility constraints.
>>> --
>>> 1.9.2
>>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>

[PATCH 1/5] drm/radeon: add userptr support v5

[Daniel Vetter]

On Mon, Jul 28, 2014 at 01:30:08PM +0200, Christian K?nig wrote:
> +struct dma_buf *radeon_gem_prime_export(struct drm_device *dev,
> + struct drm_gem_object *gobj,
> + int flags)
> +{
> + struct radeon_bo *bo = gem_to_radeon_bo(gobj);
> + if (radeon_ttm_tt_has_userptr(bo->tbo.ttm))
> + return ERR_PTR(-EPERM);

dma-buf is used by wayland and dri3, so this won't cut it. Instead you
need to reject any real device attachments with a special ->attach
callback to make sure that dma-bufs are still useful as buffer cookies,
but not for actual cross-device sharing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 07/12] drm: drop redundant drm_file->is_master

[David Herrmann]

Hi

On Fri, Jul 25, 2014 at 9:56 AM, Daniel Vetter  wrote:
> On Thu, Jul 24, 2014 at 11:38:28PM +0200, David Herrmann wrote:
>> On Thu, Jul 24, 2014 at 11:52 AM, Daniel Vetter  wrote:
>> > On Wed, Jul 23, 2014 at 05:26:42PM +0200, David Herrmann wrote:
>> >> +static inline bool drm_is_master(const struct drm_file *file)
>> >> +{
>> >
>> > Hm, we don't have any means to synchronize is_master checks with
>> > concurrent ioctls and stuff. Do we care? Orthogonal issue really.
>>
>> We don't.. My drm-master reworks contains a comment about that. It's
>> not really problematic as all ioctls run for a determinate time in
>> kernel-code except for drm_read(), but drm_read() is per-file, not
>> per-device, so we're fine. However, with unfortunate timings, we might
>> really end up with problems.
>>
>> vmwgfx solves this by using separate locks and verifying them against
>> the current master. it's not perfect and I'm not sure I like it better
>> than no locks, but at least they were aware of the problem.
>>
>> Btw., the only thing I know how to solve it properly is to make
>> "master_mutex" an rwlock and all f_op entries take the read-lock,
>> while master modifications take the write-lock. Not sure it's worth
>> it, though.
>
> Imo that's terrible. And I'm not even sure we need to care, e.g. if we do
> a master switch to a different compositor any ioctl the new compositor
> does will grab some locks, which will force the old ioctl to complete.
>
> Well mostly, and only if we don't do lockless tricks or lock-dropping and
> it's racy.

There is always a race! Like this:

CPU A:
1: enter drm_ioctl()
2: check file->is_master
3: enter drm_some_ioctl()
4: acquire some DRM internal locks

If CPU B acquires DRM-Master between step 2 and 3, CPU A might execute
an ioctl with an arbitrary delay. Maybe CPU B even executed some ioctl
after acquiring DRM-Master before CPU A had the chance to enter the
ioctl it's about to execute.

Not that I care much, but we have to remember that those races always
exist. Given that DRM-Master is privileged, this is not really
high-priority to fix..

> I guess a proper fix would be to wait for all ioctls on a device to
> complete. The vfs doesn't have any cool infrastructure for this as part of
> the general revoke work that we could reuse?

What the VFS rework does is this:

if (!atomic_inc_unless_negative(file->sth))
return -ENODEV;
ret = file->f_op->some_op();
atomic_dec(file->sth);
return ret;

That is, it wraps all calls to a file-operation with an
atomic-counter. However, there's only one counter per open-file, not
one per file-operation. If we'd want that for DRM-Master, we couldn't
use it as otherwise all file-operations would be blocked. Furthermore,
VFS only allows disabling an open-file. Once disabled, you cannot
enable it again.

So I don't think a read/write lock is a bad idea. RCU doesn't work as
our ioctls are way to heavy for rcu_read_lock(), SRCU is basically
rw-sem for our use-case. A hand-crafted atomic counter is also
equivalent to rw-sem. So yeah, it might lock nasty, but any other
solution will just hide the fact that we have a read/write lock.

Anyhow, I'm not working on a fix, so if no-one else looks at it, we
can just ignore it.

Thanks
David

[PATCH] work around warning in i915_gem_gtt

[Daniel Vetter]

On Mon, Jul 28, 2014 at 01:20:58PM +0200, Pavel Machek wrote:
> 
> Gcc warns that addr might be used uninitialized. It may not, but I see
> why gcc gets confused.
> 
> Additionally, hiding code with side-effects inside WARN_ON() argument
> seems uncool, so I moved it outside.
> 
> Signed-off-by: Pavel Machek 
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8b3cde7..8fcc974 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -1448,7 +1448,7 @@ static void gen6_ggtt_insert_entries(struct 
> i915_address_space *vm,
>   (gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm + first_entry;
>   int i = 0;
>   struct sg_page_iter sg_iter;
> - dma_addr_t addr;
> + dma_addr_t addr = 0;

I want to have a /* shuts up gcc */ for these kinds of things, where we
need to help out the compiler. Added and merged, thanks.
-Daniel

>  
>   for_each_sg_page(st->sgl, _iter, st->nents, 0) {
>   addr = sg_page_iter_dma_address(_iter);
> @@ -1462,9 +1462,10 @@ static void gen6_ggtt_insert_entries(struct 
> i915_address_space *vm,
>* of NUMA access patterns. Therefore, even with the way we assume
>* hardware should work, we must keep this posting read for paranoia.
>*/
> - if (i != 0)
> - WARN_ON(readl(_entries[i-1]) !=
> - vm->pte_encode(addr, level, true));
> + if (i != 0) {
> + unsigned long gtt = readl(_entries[i-1]);
> + WARN_ON(gtt != vm->pte_encode(addr, level, true));
> + }
>  
>   /* This next bit makes the above posting read even more important. We
>* want to flush the TLBs only after we're certain all the PTE updates
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH 0/8] Upstreaming the Android build and misc fixes

[Daniel Vetter]

On Mon, Jul 28, 2014 at 01:01:19PM +0100, Emil Velikov wrote:
> On 28/07/14 08:07, Daniel Vetter wrote:
> > On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote:
> >> A few updates:
> >>
> >>  - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed 
> >> to
> >> *_H_FILES
> >>  - Including the platform Android.mk files individually is not the right 
> >> way
> >> to do. One needs to construct an array/list of Android.mks and include it.
> >>
> >>  - The series including the above fixes can be found in branch 
> >> fixes+android
> >> over at https://github.com/evelikov/libdrm.
> > 
> > Adding Tim Gore who's working on Android.mk support for i-g-t from our
> > side and probably knows whom to poke for the intel side of things for
> > libdrm Android ports.
> > -Daniel
> > 
> Thank you Daniel,
> 
> In case it was not clear enough, some of these patches are taken from
> android-ia/external/drm. The very same are written by Intel employees AFAICT
> :) Would be great to hear if anyone is against the idea of getting Android.mks
> in the canonical repo.

Oh, that's kinda why I want to drag the relevant people in from Intel's
side. Responsibility for Android builds have shifted around a bit the past
few years and Intel is big, so I'm trying to get hold off the right
person. No success thus far :(

But personally I want this, just need to make sure that our own Android
guys see it and can start to help out. Occasionally it takes a while until
they dare to walk out of their hidings ;-)
-Daniel
> 
> 
> -Emil
> 
> >>
> >> -Emil
> >>
> >> On 27/07/14 19:25, Emil Velikov wrote:
> >>> Hello list,
> >>>
> >>> Recently I've had a go at the Anroid builds and I felt ... inspired that
> >>> there are (at least) two downstream repositories that have the relevant
> >>> Android build, yet all of them use 6+month old libdrm.
> >>> Making even builds a pain in the neck :'(
> >>>
> >>> Are there any objections if we get the android build upstream ? AFAICS
> >>> it's nicely isolated from everything else + I've managed to reuse all
> >>> the source/headers lists.
> >>>
> >>> Note that the series lacks a couple of patches from the downstream
> >>> repos, yet adds support for radeon, nouveau and freedreno :)
> >>>
> >>> The missing fixes are - s/mmap/mmap64/, dma-bufs support + other intel
> >>> specific "hacks". If people are happy with the series then we can take
> >>> a look at the final bits.
> >>>
> >>>
> >>> Cheers,
> >>> Emil
> >>>
> >>
> >> ___
> >> dri-devel mailing list
> >> dri-devel at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> > 
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 79571] [Regression][radeon] Using Weston while playing video on X with VDPAU in background causes kernel panic.

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

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

M132  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |PATCH_ALREADY_AVAILABLE

--- Comment #3 from M132  ---
Alex Deucher, you're probably right as I couldn't reproduce this on 3.16-rc6.

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

[PATCH] drm/exynos: hdmi: add null check for hdmiphy_port

[Seung-Woo Kim]

The hdmiphy can be apb and hdmiphy_port can be null. So before
accessing hdmiphy_port, it should be checked.

Signed-off-by: Seung-Woo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index fd8141f..54d97f7 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2520,7 +2520,8 @@ static int hdmi_remove(struct platform_device *pdev)
if (hdata->res.reg_hdmi_en)
regulator_disable(hdata->res.reg_hdmi_en);

-   put_device(>hdmiphy_port->dev);
+   if (hdata->hdmiphy_port)
+   put_device(>hdmiphy_port->dev);
put_device(>ddc_adpt->dev);

pm_runtime_disable(>dev);
-- 
1.7.4.1

[PATCH] drm/radeon: load the lm63 driver for an lm64 thermal chip.

[Alex Deucher]

Looks like the lm63 driver supports the lm64 as well.

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

diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c 
b/drivers/gpu/drm/radeon/radeon_atombios.c
index fda1e41..2bbf016 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -1963,7 +1963,7 @@ static const char *thermal_controller_names[] = {
"adm1032",
"adm1030",
"max6649",
-   "lm64",
+   "lm63", /* lm64 */
"f75375",
"asc7xxx",
 };
@@ -1974,7 +1974,7 @@ static const char *pp_lib_thermal_controller_names[] = {
"adm1032",
"adm1030",
"max6649",
-   "lm64",
+   "lm63", /* lm64 */
"f75375",
"RV6xx",
"RV770",
-- 
1.8.3.1

[PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Sjoerd Simons]

Hey Inki,

On Mon, 2014-07-28 at 23:17 +0900, Inki Dae wrote:
> On 2014? 07? 28? 17:30, Sjoerd Simons wrote:
> Sorry for late,
> 
> I don't see why Exynos drm driver should be auto-loaded module. I think
> all devices covered by Exynos drm framework are not hot-plugged. Maybe
> there is my missing point. So can you explain why Exynos drm driver
> should be auto-loaded module?

The background for this is that I'm building a distribution-style
multiplatform kernel, that is to say a kernel which can boot on a big
set of different ARM boards. As such, the intention is to keep the core
zImage as small as possible and essentially build things as far as
possible as loadable modules. So in a sense, all of the hardware is
"hotplugged", depending on which board the kernel is actually booted on!

For that use-case, exynosdrm needs to be able to build as a module
(which it already can!) and it needs the required meta-data for
userspace to know when it should be loaded. The latter is what my patch
adds. 

-- 
Sjoerd Simons 
Collabora Ltd.
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/14894732/attachment.bin>

[PATCH 00/19] atomic, remixed

[Daniel Vetter]

On Mon, Jul 28, 2014 at 1:17 PM, Rob Clark  wrote:
> On Sun, Jul 27, 2014 at 5:41 PM, Daniel Vetter  
> wrote:
>> Hi all,
>>
>> So I've figured instead of just talking I should draw up my ideas for atomic
>> helpers and related stuff in some draft patches. Major differences compared 
>> to
>> Rob's series:
>>
>> - The software side state update is done synchronously, at least when using 
>> the
>>   helper code. Drivers are free to do whatever they want, as usual. This has 
>> a
>>   bunch of nice upsides:
>>
>>   + All the tricky locking dances can be abolished, and if the ordering and
>> synchronization is done correctly async worker threads don't need any
>> modeset state locking at all. I'm fairly sure that Rob's scheme won't 
>> blow
>> up, but I much prefer we don't need it at all.
>>
>>   + In Rob's patches any atomic operation must wait for outstanding updates 
>> to
>> complete. Otherwise the software state isn't committed yet. With the
>> synchronous updates we can immediately proceed with the state 
>> construction
>> and verification and will only block right before applying the state 
>> update.
>> And even for that drivers can implement cancellation of the previous 
>> update.
>
> fwiw, the rough plan here for my version was to (since state was
> refcnt'd) eventually allow things to chain up (ie. copying N+1'th
> state from N'th state, rather than mode objects themselves) which
> could be done without locks for check-only..
>
> That said, I'm not super sold on the idea that userspace needs to be
> able to queue up multiple frames ahead.. but it was something that
> people ask for from time to time..

We should still be able to queue up more than one update I think - the
drm-visible software state will always reflect the latest update, even
when it's not yet put into the hw. Internally the driver can keep a
linked-list (maybe we could move that to the official drm_atomic_state
even) to know where it is exactly with pushing out updates.

One issue though with either approach is canceling updates in-between.
I guess a lot of this will be highly driver-specific. In a way
canceling an entire queue is just a more generic version of the "how
can we cancel the current pending update" issue. So I think we should
postpone the queue problem until we have the normal cancel solved (for
lower-latency gaming).

Also I think queued updates will only be worth it for some very
special workloads like video display, when shutting down both the cpu
and gpu is actually possible and might be worth some power saving. And
hw engineers seem to flip-flop on whether that's worth it for video or
whether it's better to have a slow, but power-sipping special decoder
which feeds out frames constantly instead of the rush-stop-rush-stop
queued frames would need.

>> This has the nice benefit that check-only operations (which compositors 
>> need
>> to do right after having completed the current frame to know how to 
>> render
>> the next one) can be done without blocking for completion of the previous
>> update.
>>
>> - Internal interfaces for atomic updates don't need to go through properties,
>>   but can directly set the state. Drivers can always compare updates in their
>>   ->check hook later on, so we don't lose expressiveness in the interface. 
>> But
>>   the resulting code in the callers looks much better.
>
> hmm, in cases where drivers have to fwd one property to another object
> or other sort of side effect, I think my way was nicer, imho ;-)

Well for driver-private properties you can do that still. E.g. with
panel upscaling which you internally implement you could push that to
the crtc.

> Sure, we can figure it out in check_hook later, but it is a bit
> awkward.  And means we need to be careful about sequence of checks
> (potentially having to re-check) of different objects.  Looks worse to
> me ;-)

Otoh you can't just chase the connector_state->crtc link, since we
don't promise to deliver the state updates in any order. So that might
still change. I think in the end you really have to do all that
cross-object verification/propagation only in the ->check function,
and can't do it any earlier.

Also I hope that most hw really sets e.g. plane coordinates in their
plane functions, otherwise kms would be a serious misfit ;-) So
hopefully not too much forwarding of state required.

Wrt sequencing checks correctly: We have that problem any way, but the
upside is that the order in which the atomic_check helper callbacks
are run is well-defined. But the order in which ->atomic_set_prop is
run is totally abitrary. So you can't really rely on any ordering in
there (which rather seriously restricts what you can check).

>>   In general I've ditched a lot of interfaces where drivers could overwrite
>>   default behaviour and boiled down the interface two state handling 
>> functions
>>   (duplicate+destroy), setting driver-private properties and check/commit.
>>
>> - There is a 

[PATCH libdrm] libdrm: Fix drm.h include in qxl drm header file

[Andreas Boll]

ping

2014-05-05 23:54 GMT+02:00 Andreas Boll :
> Use "drm.h" instead of "drm/drm.h" as used in the other header files.
> Fixes xserver-xorg-video-qxl build with KMS support on Debian, where this
> file is installed in /usr/include/libdrm.
>
> Fixes Debian bug #746807
>
> Reported-by: Bastian Blank 
> Signed-off-by: Andreas Boll 
> ---
>  include/drm/qxl_drm.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h
> index 5d7de70..1e331a8 100644
> --- a/include/drm/qxl_drm.h
> +++ b/include/drm/qxl_drm.h
> @@ -25,7 +25,7 @@
>  #define QXL_DRM_H
>
>  #include 
> -#include "drm/drm.h"
> +#include "drm.h"
>
>  /* Please note that modifications to all structs defined here are
>   * subject to backwards-compatibility constraints.
> --
> 1.9.2
>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #14 from Aaron B  ---
(In reply to comment #13)
> (In reply to comment #6)
> > Chromium randomly crashes with RadeonSI driver when using Chromium. Most
> > usually with Youtube videos.
> 
> Using Flash or HTML5 video? Fullscreen or windowed? ...

I use HTML5 video. But it's a Chromium issue in general, flash video just helps
it happen faster. It also happens a lot when switching tabs, clicking on
content that adds a new element on the page over top of everything else, or
loading more objects. Good examples are opening the comments section on Yahoo,
and the mousing over of names on facebook. Think it'd be useful to try to
attach a gdb session to Chromium? In the dmesg log, every time the problem
happens, Chromium does receive a segfault.

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

[PATCH libdrm] libdrm: Fix drm.h include in qxl drm header file

[Emil Velikov]

On 28/07/14 15:35, Andreas Boll wrote:
> ping
> 
> 2014-05-05 23:54 GMT+02:00 Andreas Boll :
>> Use "drm.h" instead of "drm/drm.h" as used in the other header files.
>> Fixes xserver-xorg-video-qxl build with KMS support on Debian, where this
>> file is installed in /usr/include/libdrm.
>>
I believe that's the default location for most linux distributions. Seems like
not many of us build the qxl ddx :\

FWIW
Reviewed-by: Emil Velikov 

>> Fixes Debian bug #746807
>>
>> Reported-by: Bastian Blank 
>> Signed-off-by: Andreas Boll 
>> ---
>>  include/drm/qxl_drm.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/drm/qxl_drm.h b/include/drm/qxl_drm.h
>> index 5d7de70..1e331a8 100644
>> --- a/include/drm/qxl_drm.h
>> +++ b/include/drm/qxl_drm.h
>> @@ -25,7 +25,7 @@
>>  #define QXL_DRM_H
>>
>>  #include 
>> -#include "drm/drm.h"
>> +#include "drm.h"
>>
>>  /* Please note that modifications to all structs defined here are
>>   * subject to backwards-compatibility constraints.
>> --
>> 1.9.2
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[PATCH] radeon: fix typo in sample split / fixes MSAA on Hawaii

[Michel Dänzer]

On 27.07.2014 03:12, Marek Ol??k wrote:
> From: Marek Ol??k 
> 
> ---
>  radeon/radeon_surface.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/radeon/radeon_surface.c b/radeon/radeon_surface.c
> index 9c3a192..8a1fe7d 100644
> --- a/radeon/radeon_surface.c
> +++ b/radeon/radeon_surface.c
> @@ -1914,7 +1914,7 @@ static void cik_get_2d_params(struct 
> radeon_surface_manager *surf_man,
>  sample_split = 1;
>  break;
>  case CIK__SAMPLE_SPLIT__2:
> -sample_split = 1;
> +sample_split = 2;
>  break;
>  case CIK__SAMPLE_SPLIT__4:
>  sample_split = 4;
> 

Reviewed-by: Michel D?nzer 


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

[Bug 81837] [radeonsi] memory leaks in OpenCL

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

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

--- Comment #1 from Tom Stellard  ---
Is this a regression?  If so, can you bisect?

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

drm/i915: CONFIG_DRM_I915_UMS

[Paul Bolle]

On Sat, 2014-07-26 at 01:44 +0200, Daniel Vetter wrote:
> On Fri, Jul 25, 2014 at 2:14 PM, Paul Bolle  wrote:
> > Your commit 2225a28fd916 ("drm/i915: Ditch UMS config option") is
> > included in today's linux-next (ie, next-20140725). It removes the
> > Kconfig symbol DRM_I915_UMS.
> >
> > It didn't remove the two (negative) checks for CONFIG_DRM_I915_UMS.
> > These checks are superfluous as they now will always evaluate to true.
> > Is the trivial cleanup to remove them already queued somewhere?
> 
> No, and intentionally.

So this was not by mistake, which is good to know.

>  Actually removing the code for
> user-mode-setting isn't just removing these two blocks,

Just to be clear: I'm only suggesting to remove the two lines reading
#ifndef CONFIG_DRM_I915_UMS

and their corresponding #endif lines.

>  but requires
> the gutting of roughly 10k lines splattered all over the driver.
> Essentially all the code that checks for
> !drm_core_check_feature(DRIVER_MODESET) needs to go. That's not quite
> as trivial, and before I do that I want to make really sure that
> really no one misses this option.
>
> So probably after 3.17 is out the door for a bit.

None of what I brought up is urgent. But I do hope you don't mind me
sending a reminder if these few (preprocessor) lines are staying around
longer than expected.


Paul Bolle

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #115 from Kai  ---
(In reply to comment #106)
> Playing streams (live and recorded broadcasts) from Twitch with this setup
> is, however, neigh impossible. With the open driver and GLAMOR acceleration,
> X uses 80 % CPU time on one core and the video becomes a dia show. The Flash
> plugin is at 40 % CPU time (different core), but that's roughly the same as
> with fglrx. (For reference: my CPU is an Intel Core i7-3770K.)

After some further testing yesterday I could only reproduce the stalling of X
with "recorded brodcasts" on Twitch. It doesn't matter what stream quality you
pick (if you're patient enough to get that menu open). X starts hogging all
resources on one CPU core as soon as you load any recording (I tried four
different recordings). Live broadcasts/streams worked normally yesterday
afternoon/evening and today.


(In reply to comment #114)
> (In reply to comment #108)
> > Btw, watching a video on Twitch spams my Xorg.0.log with *tons* of:
> > > [ 21013.158] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> > > completion event has impossible msc 2822274 < target_msc 2822275
> 
> These are fixed in drm-fixes-3.16, but that hasn't been merged into
> drm-next-3.17-wip yet.

Ah, ok. I found
<http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.16=f53f81b2576a9bd3af947e2b1c3a46dfab51c5ef>.
Is that the correct commit for Hawaii? Doesn't look like the appropriate commit
to me (so much "Evergreen" everywhere), but it was the only one a search for
radeon_dri2_flip_event_handler yielded.

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

[PATCH 0/2] Update copyright notices for Renesas DRM drivers

[Laurent Pinchart]

Hi Dave,

On Wednesday 02 July 2014 16:42:09 Laurent Pinchart wrote:
> Hi Dave,
> 
> Could you please pick those two patches up for v3.17 ?

Am I missing something ? Is there a secret e-mail address I need to send my 
patches to to get them picked up ? This is a trivial change first submitted in 
February (!).

> On Thursday 06 February 2014 18:41:56 Laurent Pinchart wrote:
> > The "Renesas Corporation" listed in the copyright notices doesn't exist.
> > Replace it with "Renesas Electronics Corporation" and update the
> > copyright years.
> > 
> > Laurent Pinchart (2):
> >   drm/rcar-du: Update copyright notice
> >   drm/shmob: Update copyright notice
> >  
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.h  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_encoder.c  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_encoder.h  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_group.c| 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_group.h| 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.c  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_kms.h  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h  | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_plane.c| 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_plane.h| 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_vgacon.c   | 2 +-
> >  drivers/gpu/drm/rcar-du/rcar_du_vgacon.h   | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_backlight.c | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_backlight.h | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_crtc.c  | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_crtc.h  | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_drv.c   | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_drv.h   | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_kms.c   | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_kms.h   | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_plane.c | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_plane.h | 2 +-
> >  drivers/gpu/drm/shmobile/shmob_drm_regs.h  | 2 +-
> >  29 files changed, 29 insertions(+), 29 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH] drm: add checking DRM_FORMAT_NV12MT

[Joonyoung Shim]

If user NV12MT uses as pixel format, the Addfb2 ioctl is failed because
of missing to check DRM_FORMAT_NV12MT. The NV12MT pixel format is
supported by exynos4 and some qualcomm chipset and it is used by exynos
drm driver.

Signed-off-by: Joonyoung Shim 
---
 drivers/gpu/drm/drm_crtc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1ccf5cb..5d7bd49 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2960,6 +2960,7 @@ static int format_check(const struct drm_mode_fb_cmd2 *r)
case DRM_FORMAT_NV61:
case DRM_FORMAT_NV24:
case DRM_FORMAT_NV42:
+   case DRM_FORMAT_NV12MT:
case DRM_FORMAT_YUV410:
case DRM_FORMAT_YVU410:
case DRM_FORMAT_YUV411:
@@ -4800,6 +4801,7 @@ int drm_format_num_planes(uint32_t format)
case DRM_FORMAT_NV61:
case DRM_FORMAT_NV24:
case DRM_FORMAT_NV42:
+   case DRM_FORMAT_NV12MT:
return 2;
default:
return 1;
@@ -4835,6 +4837,7 @@ int drm_format_plane_cpp(uint32_t format, int plane)
case DRM_FORMAT_NV61:
case DRM_FORMAT_NV24:
case DRM_FORMAT_NV42:
+   case DRM_FORMAT_NV12MT:
return plane ? 2 : 1;
case DRM_FORMAT_YUV410:
case DRM_FORMAT_YVU410:
@@ -4878,6 +4881,7 @@ int drm_format_horz_chroma_subsampling(uint32_t format)
case DRM_FORMAT_NV21:
case DRM_FORMAT_NV16:
case DRM_FORMAT_NV61:
+   case DRM_FORMAT_NV12MT:
case DRM_FORMAT_YUV422:
case DRM_FORMAT_YVU422:
case DRM_FORMAT_YUV420:
@@ -4907,6 +4911,7 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
case DRM_FORMAT_YVU420:
case DRM_FORMAT_NV12:
case DRM_FORMAT_NV21:
+   case DRM_FORMAT_NV12MT:
return 2;
default:
return 1;
-- 
1.8.1.2

[PATCH 5/5] drm/radeon: allow userptr write access under certain conditions

[Christian König]

From: Christian K?nig 

It needs to be anonymous memory (no file mappings)
and we are requried to install an MMU notifier.

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 29e353f..6a7bfc2 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -287,19 +287,24 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void 
*data,
if (offset_in_page(args->addr | args->size))
return -EINVAL;

-   /* we only support read only mappings for now */
-   if (!(args->flags & RADEON_GEM_USERPTR_READONLY))
-   return -EACCES;
-
/* reject unknown flag values */
if (args->flags & ~(RADEON_GEM_USERPTR_READONLY |
RADEON_GEM_USERPTR_ANONONLY | RADEON_GEM_USERPTR_VALIDATE |
RADEON_GEM_USERPTR_REGISTER))
return -EINVAL;

-   /* readonly pages not tested on older hardware */
-   if (rdev->family < CHIP_R600)
-   return -EINVAL;
+   if (args->flags & RADEON_GEM_USERPTR_READONLY) {
+   /* readonly pages not tested on older hardware */
+   if (rdev->family < CHIP_R600)
+   return -EINVAL;
+
+   } else if (!(args->flags & RADEON_GEM_USERPTR_ANONONLY) ||
+  !(args->flags & RADEON_GEM_USERPTR_REGISTER)) {
+
+   /* if we want to write to it we must require anonymous
+  memory and install a MMU notifier */
+   return -EACCES;
+   }

down_read(>exclusive_lock);

-- 
1.9.1

[PATCH 4/5] drm/radeon: add userptr flag to register MMU notifier

[Christian König]

From: Christian K?nig 

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/Kconfig|   1 +
 drivers/gpu/drm/radeon/Makefile|   2 +-
 drivers/gpu/drm/radeon/radeon.h|  12 ++
 drivers/gpu/drm/radeon/radeon_device.c |   2 +
 drivers/gpu/drm/radeon/radeon_gem.c|   9 +-
 drivers/gpu/drm/radeon/radeon_mn.c | 270 +
 drivers/gpu/drm/radeon/radeon_object.c |   1 +
 include/uapi/drm/radeon_drm.h  |   1 +
 8 files changed, 296 insertions(+), 2 deletions(-)
 create mode 100644 drivers/gpu/drm/radeon/radeon_mn.c

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 9b2eedc..2745284 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -115,6 +115,7 @@ config DRM_RADEON
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+   select MMU_NOTIFIER
help
  Choose this option if you have an ATI Radeon graphics card.  There
  are both PCI and AGP versions.  You don't need to choose this to
diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile
index 1b04002..c66143d 100644
--- a/drivers/gpu/drm/radeon/Makefile
+++ b/drivers/gpu/drm/radeon/Makefile
@@ -80,7 +80,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o rv740_dpm.o \
rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o trinity_dpm.o 
\
trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
-   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o
+   ci_dpm.o dce6_afmt.o radeon_vm.o radeon_ucode.o radeon_mn.o

 # add async DMA block
 radeon-y += \
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 2b363f3..57fd145 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -65,6 +65,7 @@
 #include 
 #include 
 #include 
+#include 

 #include 
 #include 
@@ -483,6 +484,9 @@ struct radeon_bo {

struct ttm_bo_kmap_obj  dma_buf_vmap;
pid_t   pid;
+
+   struct radeon_mn*mn;
+   struct interval_tree_node   mn_it;
 };
 #define gem_to_radeon_bo(gobj) container_of((gobj), struct radeon_bo, gem_base)

@@ -1721,6 +1725,11 @@ void radeon_test_ring_sync(struct radeon_device *rdev,
   struct radeon_ring *cpB);
 void radeon_test_syncing(struct radeon_device *rdev);

+/*
+ * MMU Notifier
+ */
+int radeon_mn_register(struct radeon_bo *bo, unsigned long addr);
+void radeon_mn_unregister(struct radeon_bo *bo);

 /*
  * Debugfs
@@ -2362,6 +2371,9 @@ struct radeon_device {
/* tracking pinned memory */
u64 vram_pin_size;
u64 gart_pin_size;
+
+   struct mutexmn_lock;
+   DECLARE_HASHTABLE(mn_hash, 7);
 };

 bool radeon_is_px(struct drm_device *dev);
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index afcfe8a..3bced2d 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1269,6 +1269,8 @@ int radeon_device_init(struct radeon_device *rdev,
init_rwsem(>pm.mclk_lock);
init_rwsem(>exclusive_lock);
init_waitqueue_head(>irq.vblank_queue);
+   mutex_init(>mn_lock);
+   hash_init(rdev->mn_hash);
r = radeon_gem_init(rdev);
if (r)
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 3ffb2f3..29e353f 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -293,7 +293,8 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void 
*data,

/* reject unknown flag values */
if (args->flags & ~(RADEON_GEM_USERPTR_READONLY |
-   RADEON_GEM_USERPTR_ANONONLY | RADEON_GEM_USERPTR_VALIDATE))
+   RADEON_GEM_USERPTR_ANONONLY | RADEON_GEM_USERPTR_VALIDATE |
+   RADEON_GEM_USERPTR_REGISTER))
return -EINVAL;

/* readonly pages not tested on older hardware */
@@ -314,6 +315,12 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void 
*data,
if (r)
goto release_object;

+   if (args->flags & RADEON_GEM_USERPTR_REGISTER) {
+   r = radeon_mn_register(bo, args->addr);
+   if (r)
+   goto release_object;
+   }
+
if (args->flags & RADEON_GEM_USERPTR_VALIDATE) {
down_read(>mm->mmap_sem);
r = radeon_bo_reserve(bo, true);
diff --git a/drivers/gpu/drm/radeon/radeon_mn.c 
b/drivers/gpu/drm/radeon/radeon_mn.c
new file mode 100644
index 000..ef0f9b4
--- /dev/null
+++ b/drivers/gpu/drm/radeon/radeon_mn.c
@@ -0,0 +1,270 @@
+/*
+ * Copyright 2014 Advanced Micro Devices, Inc.
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a

[PATCH 3/5] drm/radeon: add userptr flag to directly validate the BO to GTT

[Christian König]

From: Christian K?nig 

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 18 +-
 include/uapi/drm/radeon_drm.h   |  1 +
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index e2c6f44..3ffb2f3 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -293,7 +293,7 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void 
*data,

/* reject unknown flag values */
if (args->flags & ~(RADEON_GEM_USERPTR_READONLY |
-   RADEON_GEM_USERPTR_ANONONLY))
+   RADEON_GEM_USERPTR_ANONONLY | RADEON_GEM_USERPTR_VALIDATE))
return -EINVAL;

/* readonly pages not tested on older hardware */
@@ -314,6 +314,22 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void 
*data,
if (r)
goto release_object;

+   if (args->flags & RADEON_GEM_USERPTR_VALIDATE) {
+   down_read(>mm->mmap_sem);
+   r = radeon_bo_reserve(bo, true);
+   if (r) {
+   up_read(>mm->mmap_sem);
+   goto release_object;
+   }
+
+   radeon_ttm_placement_from_domain(bo, RADEON_GEM_DOMAIN_GTT);
+   r = ttm_bo_validate(>tbo, >placement, true, false);
+   radeon_bo_unreserve(bo);
+   up_read(>mm->mmap_sem);
+   if (r)
+   goto release_object;
+   }
+
r = drm_gem_handle_create(filp, gobj, );
/* drop reference from allocate - handle holds it now */
drm_gem_object_unreference_unlocked(gobj);
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index 4080ad3..026111b 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -812,6 +812,7 @@ struct drm_radeon_gem_create {

 #define RADEON_GEM_USERPTR_READONLY(1 << 0)
 #define RADEON_GEM_USERPTR_ANONONLY(1 << 1)
+#define RADEON_GEM_USERPTR_VALIDATE(1 << 2)

 struct drm_radeon_gem_userptr {
uint64_taddr;
-- 
1.9.1

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory

[Christian König]

From: Christian K?nig 

Signed-off-by: Christian K?nig 
---
 drivers/gpu/drm/radeon/radeon_gem.c | 3 ++-
 drivers/gpu/drm/radeon/radeon_ttm.c | 8 
 include/uapi/drm/radeon_drm.h   | 3 ++-
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_gem.c 
b/drivers/gpu/drm/radeon/radeon_gem.c
index 05b9661..e2c6f44 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -292,7 +292,8 @@ int radeon_gem_userptr_ioctl(struct drm_device *dev, void 
*data,
return -EACCES;

/* reject unknown flag values */
-   if (args->flags & ~RADEON_GEM_USERPTR_READONLY)
+   if (args->flags & ~(RADEON_GEM_USERPTR_READONLY |
+   RADEON_GEM_USERPTR_ANONONLY))
return -EINVAL;

/* readonly pages not tested on older hardware */
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index dbc15ec..7a21478 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -541,6 +541,14 @@ static int radeon_ttm_tt_pin_userptr(struct ttm_tt *ttm)
   ttm->num_pages * PAGE_SIZE))
return -EFAULT;

+   if (gtt->userflags & RADEON_GEM_USERPTR_ANONONLY) {
+   unsigned long end = gtt->userptr + ttm->num_pages * PAGE_SIZE;
+   struct vm_area_struct *vma;
+   vma = find_vma(gtt->usermm, gtt->userptr);
+   if (!vma || vma->vm_file || vma->vm_end < end)
+   return -EPERM;
+   }
+
do {
unsigned num_pages = ttm->num_pages - pinned;
uint64_t userptr = gtt->userptr + pinned * PAGE_SIZE;
diff --git a/include/uapi/drm/radeon_drm.h b/include/uapi/drm/radeon_drm.h
index a18ec54..4080ad3 100644
--- a/include/uapi/drm/radeon_drm.h
+++ b/include/uapi/drm/radeon_drm.h
@@ -810,7 +810,8 @@ struct drm_radeon_gem_create {
uint32_tflags;
 };

-#define RADEON_GEM_USERPTR_READONLY0x1
+#define RADEON_GEM_USERPTR_READONLY(1 << 0)
+#define RADEON_GEM_USERPTR_ANONONLY(1 << 1)

 struct drm_radeon_gem_userptr {
uint64_taddr;
-- 
1.9.1

[PATCH 1/5] drm/radeon: add userptr support v5

[Christian König]

From: Christian K?nig 

This patch adds an IOCTL for turning a pointer supplied by
userspace into a buffer object.

It imposes several restrictions upon the memory being mapped:

1. It must be page aligned (both start/end addresses, i.e ptr and size).

2. It must be normal system memory, not a pointer into another map of IO
space (e.g. it must not be a GTT mmapping of another object).

3. The BO is mapped into GTT, so the maximum amount of memory mapped at
all times is still the GTT limit.

4. The BO is only mapped readonly for now, so no write support.

5. List of backing pages is only acquired once, so they represent a
snapshot of the first use.

Exporting and sharing as well as mapping of buffer objects created by
this function is forbidden and results in an -EPERM.

v2: squash all previous changes into first public version
v3: fix tabs, map readonly, don't use MM callback any more
v4: set TTM_PAGE_FLAG_SG so that TTM never messes with the pages,
pin/unpin pages on bind/unbind instead of populate/unpopulate
v5: rebased on 3.17-wip, IOCTL renamed to userptr, reject any unknown
flags, better handle READONLY flag, improve permission check

Signed-off-by: Christian K?nig 
Reviewed-by: Alex Deucher  (v4)
Reviewed-by: J?r?me Glisse  (v4)
---
 drivers/gpu/drm/radeon/radeon.h|   5 ++
 drivers/gpu/drm/radeon/radeon_cs.c |  25 ++-
 drivers/gpu/drm/radeon/radeon_drv.c|   5 +-
 drivers/gpu/drm/radeon/radeon_gem.c|  68 ++
 drivers/gpu/drm/radeon/radeon_kms.c|   1 +
 drivers/gpu/drm/radeon/radeon_object.c |   3 +
 drivers/gpu/drm/radeon/radeon_prime.c  |  10 +++
 drivers/gpu/drm/radeon/radeon_ttm.c| 127 +
 drivers/gpu/drm/radeon/radeon_vm.c |   3 +
 include/uapi/drm/radeon_drm.h  |  11 +++
 10 files changed, 255 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index cd0d960..2b363f3 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -2128,6 +2128,8 @@ int radeon_gem_info_ioctl(struct drm_device *dev, void 
*data,
  struct drm_file *filp);
 int radeon_gem_create_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp);
+int radeon_gem_userptr_ioctl(struct drm_device *dev, void *data,
+struct drm_file *filp);
 int radeon_gem_pin_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
 int radeon_gem_unpin_ioctl(struct drm_device *dev, void *data,
@@ -2858,6 +2860,9 @@ extern void radeon_legacy_set_clock_gating(struct 
radeon_device *rdev, int enabl
 extern void radeon_atom_set_clock_gating(struct radeon_device *rdev, int 
enable);
 extern void radeon_ttm_placement_from_domain(struct radeon_bo *rbo, u32 
domain);
 extern bool radeon_ttm_bo_is_radeon_bo(struct ttm_buffer_object *bo);
+extern int radeon_ttm_tt_set_userptr(struct ttm_tt *ttm, uint64_t addr,
+uint32_t flags);
+extern bool radeon_ttm_tt_has_userptr(struct ttm_tt *ttm);
 extern void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc 
*mc, u64 base);
 extern void radeon_gtt_location(struct radeon_device *rdev, struct radeon_mc 
*mc);
 extern int radeon_resume_kms(struct drm_device *dev, bool resume, bool fbcon);
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c 
b/drivers/gpu/drm/radeon/radeon_cs.c
index ee712c1..1321491 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -78,7 +78,8 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser *p)
struct radeon_cs_chunk *chunk;
struct radeon_cs_buckets buckets;
unsigned i, j;
-   bool duplicate;
+   bool duplicate, need_mmap_lock = false;
+   int r;

if (p->chunk_relocs_idx == -1) {
return 0;
@@ -164,6 +165,19 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser 
*p)
p->relocs[i].allowed_domains = domain;
}

+   if (radeon_ttm_tt_has_userptr(p->relocs[i].robj->tbo.ttm)) {
+   uint32_t domain = p->relocs[i].prefered_domains;
+   if (!(domain & RADEON_GEM_DOMAIN_GTT)) {
+   DRM_ERROR("Only RADEON_GEM_DOMAIN_GTT is "
+ "allowed for userptr BOs\n");
+   return -EINVAL;
+   }
+   need_mmap_lock = true;
+   domain = RADEON_GEM_DOMAIN_GTT;
+   p->relocs[i].prefered_domains = domain;
+   p->relocs[i].allowed_domains = domain;
+   }
+
p->relocs[i].tv.bo = >relocs[i].robj->tbo;
p->relocs[i].handle = r->handle;

@@ -176,8 +190,15 @@ static int radeon_cs_parser_relocs(struct radeon_cs_parser 
*p)

[Bug 81678] X crashes on start (integrated 7640G + discrete 7500M/7600M)

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

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

--- Comment #9 from Andrey Volkov  ---
(In reply to comment #8)
> (In reply to comment #6)
> > This bug occurs on my PC. So, I can answer your questions.
> 
> So Igor reported the bug on your behalf?
> 
Yes. I reported the bug on the Russian Fedora project bugtracker
(http://redmine.russianfedora.pro/issues/1356), and, after that, he reported
the bug on this bugtracker.

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

[PATCH] work around warning in i915_gem_gtt

[Pavel Machek]

Gcc warns that addr might be used uninitialized. It may not, but I see
why gcc gets confused.

Additionally, hiding code with side-effects inside WARN_ON() argument
seems uncool, so I moved it outside.

Signed-off-by: Pavel Machek 

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8b3cde7..8fcc974 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1448,7 +1448,7 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
(gen6_gtt_pte_t __iomem *)dev_priv->gtt.gsm + first_entry;
int i = 0;
struct sg_page_iter sg_iter;
-   dma_addr_t addr;
+   dma_addr_t addr = 0;

for_each_sg_page(st->sgl, _iter, st->nents, 0) {
addr = sg_page_iter_dma_address(_iter);
@@ -1462,9 +1462,10 @@ static void gen6_ggtt_insert_entries(struct 
i915_address_space *vm,
 * of NUMA access patterns. Therefore, even with the way we assume
 * hardware should work, we must keep this posting read for paranoia.
 */
-   if (i != 0)
-   WARN_ON(readl(_entries[i-1]) !=
-   vm->pte_encode(addr, level, true));
+   if (i != 0) {
+   unsigned long gtt = readl(_entries[i-1]);
+   WARN_ON(gtt != vm->pte_encode(addr, level, true));
+   }

/* This next bit makes the above posting read even more important. We
 * want to flush the TLBs only after we're certain all the PTE updates

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 0/8] Upstreaming the Android build and misc fixes

[Emil Velikov]

On 28/07/14 08:07, Daniel Vetter wrote:
> On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote:
>> A few updates:
>>
>>  - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to
>> *_H_FILES
>>  - Including the platform Android.mk files individually is not the right way
>> to do. One needs to construct an array/list of Android.mks and include it.
>>
>>  - The series including the above fixes can be found in branch fixes+android
>> over at https://github.com/evelikov/libdrm.
> 
> Adding Tim Gore who's working on Android.mk support for i-g-t from our
> side and probably knows whom to poke for the intel side of things for
> libdrm Android ports.
> -Daniel
> 
Thank you Daniel,

In case it was not clear enough, some of these patches are taken from
android-ia/external/drm. The very same are written by Intel employees AFAICT
:) Would be great to hear if anyone is against the idea of getting Android.mks
in the canonical repo.


-Emil

>>
>> -Emil
>>
>> On 27/07/14 19:25, Emil Velikov wrote:
>>> Hello list,
>>>
>>> Recently I've had a go at the Anroid builds and I felt ... inspired that
>>> there are (at least) two downstream repositories that have the relevant
>>> Android build, yet all of them use 6+month old libdrm.
>>> Making even builds a pain in the neck :'(
>>>
>>> Are there any objections if we get the android build upstream ? AFAICS
>>> it's nicely isolated from everything else + I've managed to reuse all
>>> the source/headers lists.
>>>
>>> Note that the series lacks a couple of patches from the downstream
>>> repos, yet adds support for radeon, nouveau and freedreno :)
>>>
>>> The missing fixes are - s/mmap/mmap64/, dma-bufs support + other intel
>>> specific "hacks". If people are happy with the series then we can take
>>> a look at the final bits.
>>>
>>>
>>> Cheers,
>>> Emil
>>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

[Bug 81837] New: [radeonsi] memory leaks in OpenCL

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

size  : 5836800 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 5836800 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 5836800 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 5836800 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 5836800 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 5836800 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 5836800 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 5832704 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 5832704 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 1048576 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
radeon: Failed to allocate virtual address for buffer:
radeon:size  : 1048576 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 2
radeon:va: 0xfff2b000
?? ???

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

[PATCH] drm: add checking DRM_FORMAT_NV12MT

[Rob Clark]

On Mon, Jul 28, 2014 at 12:47 AM, Joonyoung Shim
 wrote:
> If user NV12MT uses as pixel format, the Addfb2 ioctl is failed because
> of missing to check DRM_FORMAT_NV12MT. The NV12MT pixel format is
> supported by exynos4 and some qualcomm chipset and it is used by exynos
> drm driver.

tbh, format_check() should probably just be made to respect the
formats advertised by all the planes..

BR,
-R

> Signed-off-by: Joonyoung Shim 
> ---
>  drivers/gpu/drm/drm_crtc.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 1ccf5cb..5d7bd49 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2960,6 +2960,7 @@ static int format_check(const struct drm_mode_fb_cmd2 
> *r)
> case DRM_FORMAT_NV61:
> case DRM_FORMAT_NV24:
> case DRM_FORMAT_NV42:
> +   case DRM_FORMAT_NV12MT:
> case DRM_FORMAT_YUV410:
> case DRM_FORMAT_YVU410:
> case DRM_FORMAT_YUV411:
> @@ -4800,6 +4801,7 @@ int drm_format_num_planes(uint32_t format)
> case DRM_FORMAT_NV61:
> case DRM_FORMAT_NV24:
> case DRM_FORMAT_NV42:
> +   case DRM_FORMAT_NV12MT:
> return 2;
> default:
> return 1;
> @@ -4835,6 +4837,7 @@ int drm_format_plane_cpp(uint32_t format, int plane)
> case DRM_FORMAT_NV61:
> case DRM_FORMAT_NV24:
> case DRM_FORMAT_NV42:
> +   case DRM_FORMAT_NV12MT:
> return plane ? 2 : 1;
> case DRM_FORMAT_YUV410:
> case DRM_FORMAT_YVU410:
> @@ -4878,6 +4881,7 @@ int drm_format_horz_chroma_subsampling(uint32_t format)
> case DRM_FORMAT_NV21:
> case DRM_FORMAT_NV16:
> case DRM_FORMAT_NV61:
> +   case DRM_FORMAT_NV12MT:
> case DRM_FORMAT_YUV422:
> case DRM_FORMAT_YVU422:
> case DRM_FORMAT_YUV420:
> @@ -4907,6 +4911,7 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
> case DRM_FORMAT_YVU420:
> case DRM_FORMAT_NV12:
> case DRM_FORMAT_NV21:
> +   case DRM_FORMAT_NV12MT:
> return 2;
> default:
> return 1;
> --
> 1.8.1.2
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Ajay kumar]

Hi Andreas,

On 7/27/14, Andreas F?rber  wrote:
> Hi Ajay,
>
> Am 25.07.2014 21:22, schrieb Ajay Kumar:
>> This series is based on exynos-drm-next branch of Inki Dae's tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
>>
>> I have tested this after adding few DT changes for exynos5250-snow,
>> exynos5420-peach-pit and exynos5800-peach-pi boards.
>
> I'm trying to test this with a modified exynos5250-spring DT based off
> kgene's for-next branch due to DT, and I run into the following:
>
>   CC  drivers/gpu/drm/bridge/ptn3460.o
> drivers/gpu/drm/bridge/ptn3460.c: In function ?ptn3460_post_encoder_init?:
> drivers/gpu/drm/bridge/ptn3460.c:275:2: error: implicit declaration of
> function ?drm_connector_register? [-Werror=implicit-function-declaration]
>   drm_connector_register(_bridge->connector);
>   ^
Hope this might help:
http://www.spinics.net/lists/dri-devel/msg60578.html

Switch back to drm_sysfs_connector_add if your kernel doesn't have this patch.

Ajay

> cc1: some warnings being treated as errors
> scripts/Makefile.build:257: recipe for target
> 'drivers/gpu/drm/bridge/ptn3460.o' failed
> make[4]: *** [drivers/gpu/drm/bridge/ptn3460.o] Error 1
> scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm/bridge'
> failed
> make[3]: *** [drivers/gpu/drm/bridge] Error 2
> make[3]: *** Warte auf noch nicht beendete Prozesse...
> scripts/Makefile.build:404: recipe for target 'drivers/gpu/drm' failed
> make[2]: *** [drivers/gpu/drm] Error 2
> scripts/Makefile.build:404: recipe for target 'drivers/gpu' failed
> make[1]: *** [drivers/gpu] Error 2
> Makefile:899: recipe for target 'drivers' failed
> make: *** [drivers] Error 2
>
> Any hint which prerequisite I'm missing? Didn't spot it in Inki's tree,
> and it must be new since v4.
>
> Thanks,
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
>

[PATCH 00/19] atomic, remixed

[Daniel Vetter]

On Sun, Jul 27, 2014 at 11:41:29PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> So I've figured instead of just talking I should draw up my ideas for atomic
> helpers and related stuff in some draft patches. Major differences compared to
> Rob's series:
> 
> - The software side state update is done synchronously, at least when using 
> the
>   helper code. Drivers are free to do whatever they want, as usual. This has a
>   bunch of nice upsides:
> 
>   + All the tricky locking dances can be abolished, and if the ordering and
> synchronization is done correctly async worker threads don't need any
> modeset state locking at all. I'm fairly sure that Rob's scheme won't blow
> up, but I much prefer we don't need it at all.
> 
>   + In Rob's patches any atomic operation must wait for outstanding updates to
> complete. Otherwise the software state isn't committed yet. With the
> synchronous updates we can immediately proceed with the state construction
> and verification and will only block right before applying the state 
> update.
> And even for that drivers can implement cancellation of the previous 
> update.
> 
> This has the nice benefit that check-only operations (which compositors 
> need
> to do right after having completed the current frame to know how to render
> the next one) can be done without blocking for completion of the previous
> update.
> 
> - Internal interfaces for atomic updates don't need to go through properties,
>   but can directly set the state. Drivers can always compare updates in their
>   ->check hook later on, so we don't lose expressiveness in the interface. But
>   the resulting code in the callers looks much better.
> 
>   In general I've ditched a lot of interfaces where drivers could overwrite
>   default behaviour and boiled down the interface two state handling functions
>   (duplicate+destroy), setting driver-private properties and check/commit.
> 
> - There is a clear helper separation between core code which should be used to
>   use the atomic interface to drivers, and helper functions. Core never uses
>   helper functions so that we can keep the clear separation we have in all 
> other
>   places in the kms api.
> 
>   There's a set of helpers sitting in-between to implement legacy interfaces 
> on
>   top of atomic. Those _only_ use the core atomic interfaces.
> 
> - I've added a new set of plane helpers. Mostly this was motivated to make the
>   atomic helpers work on less stellar hardware where you can't just stream the
>   state and then atomically commit with some GO bits. But those helpers should
>   also be useful for more gradual transitions of drivers to the atomic
>   interface. Since a requirement for atomic is to have universal plane support
>   they can be used bare-bones just for that, without all the other atomic
>   baggage (i.e. all the state tracking for crtcs/connectors).
> 
> - State tracking for connectors. i915 has piles of relevant connector
>   properties, which we want to save/restore in atomic ops (e.g. hdmi metadata
>   and stuff).
> 
> - fbdev panic locking is implemented with trylock instead of nolock.
> 
> - I've thought a bit about resume. See the proposed state handling for the
>   default reset functions and the addition of a plane reset callback.
> 
> There's also a metric pile of stuff missing:
> 
> - It's completely untested (except for the parts touching currently used code)
>   since I lack suitable hw. Converting i915 is just a bit too much of a pain 
> for
>   a quick w/e code draft ;-)
> 
> - I didn't add all the properties for things currently exposed through ioctl
>   structures. Since the interface here doesn't force internal code to use
>   properties for everything (which really makes things look much better) we
>   don't have a need for that until we merge the actual atomic ioctl. So I left
>   that out.
> 
> - I didn't write code for the fbdev helper to use atomic. The w/e ran out of
>   time for that ...
> 
> - Kerneldoc is occasionally not updated or still missing.
> 
> Anyway I think this draft code is good enough to explain how I'd like to 
> address
> some of the concerns I have with the current atomic code. Comments, flames and
> ideas highly welcome. And if anyone is insane enought to try this on real
> hardware, that would certainly be interesting and I'm very much willing to 
> help
> out as much as possible ... i915 just really isn't suitable since it won't be
> using the helpers, and all the other hw I have here doesn't support planes.

The entire thing is available as a git tree at

git://people.freedesktop.org/~danvet/drm colder-fusion

I've already pushed a bit more polish on top.
-Daniel

> 
> Cheers, Daniel
> 
> Daniel Vetter (18):
>   drm: Add atomic driver interface definitions for objects
>   drm: Add drm_plane/connector_index
>   drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]
>   drm: Handle legacy per-crtc locking with full acquire 

[Bug 75276] Implement VGPR Register Spilling

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

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

--- Comment #32 from Christoph Haag  ---
Created attachment 103583
  --> https://bugs.freedesktop.org/attachment.cgi?id=103583=edit
backtrace of unreal engine effects demo with debug

(In reply to comment #31)
> (In reply to comment #30)
> > But every demo segfaults. Mostly in LLVMBuildBitCast().
> [...]
> > This is still a problem with register spilling that just looks different,
> > right?
> 
> No, that sounds like bug 81834.

So I built mesa with debug symbols and I guess debugging enables some
assertions because now fails at some assertion about Register.Index stuff. Full
backtrace attached.

(bug 81834 doesn't say what versions he uses. I use upstream llvm 214022 and
mesa git with the small patch I mentioned)

Of course it could be both problems at the same time.

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

[PATCH v2 2/2] drm/exynos: dsi: add LPM (Low Power Mode) transfer support

[Inki Dae]

This patch adds LPM transfer support for video or command data.

With this patch, Exynos MIPI DSI controller can transfer command or
video data with HS or LP mode in accordance with mode_flags set
by LCD Panel driver.

Changelog v2: Enable High Speed clock only in case of stand by request.

Signed-off-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 --
 1 file changed, 20 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c 
b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 5e78d45..1bed105 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -493,8 +493,11 @@ static int exynos_dsi_enable_clock(struct exynos_dsi *dsi)
| DSIM_ESC_PRESCALER(esc_div)
| DSIM_LANE_ESC_CLK_EN_CLK
| DSIM_LANE_ESC_CLK_EN_DATA(BIT(dsi->lanes) - 1)
-   | DSIM_BYTE_CLK_SRC(0)
-   | DSIM_TX_REQUEST_HSCLK;
+   | DSIM_BYTE_CLK_SRC(0);
+
+   if (!(dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM))
+   reg |= DSIM_TX_REQUEST_HSCLK;
+
writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);

return 0;
@@ -553,6 +556,18 @@ static void exynos_dsi_set_phy_ctrl(struct exynos_dsi *dsi)
writel(reg, dsi->reg_base + DSIM_PHYTIMING2_REG);
 }

+static void exynos_dsi_enable_hs_clock(struct exynos_dsi *dsi,
+   bool enable)
+{
+   u32 reg = readl(dsi->reg_base + DSIM_CLKCTRL_REG);
+
+   reg &= ~DSIM_TX_REQUEST_HSCLK;
+   if (enable)
+   reg |= DSIM_TX_REQUEST_HSCLK;
+
+   writel(reg, dsi->reg_base + DSIM_CLKCTRL_REG);
+}
+
 static void exynos_dsi_disable_clock(struct exynos_dsi *dsi)
 {
u32 reg;
@@ -705,6 +720,9 @@ static void exynos_dsi_set_display_enable(struct exynos_dsi 
*dsi, bool enable)
 {
u32 reg;

+   if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_LPM) && enable)
+   exynos_dsi_enable_hs_clock(dsi, true);
+
reg = readl(dsi->reg_base + DSIM_MDRESOL_REG);
if (enable)
reg |= DSIM_MAIN_STAND_BY;
-- 
1.7.9.5

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

[Inki Dae]

This patch adds below two flags for LPM transfer, and it attaches LPM flags
to a msg in accordance with master's mode_flags set by LCD Panel driver.

MIPI_DSI_MODE_CMD_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
command data to Panel device in Low Power Mode.

MIPI_DSI_MODE_VIDEO_LPM
- If this flag is set by Panel driver, MIPI-DSI controller will tranfer
image data to Panel device in Low Power Mode.

And above two flags can be combined together to transfer command and video
data to Panel device.

MIPI DSI spec says,
 "the host processor controls the desired mode of clock operation.
  Host protocol and applications control Clock Lane operating mode
  (High Speed or Low Power mode). System designers are responsible
  for understanding the clock requirements for peripherals attached
  to DSI and controlling clock behavior in accordance with those
  requirements."

Some LCD Panel devices, nt35502a, would need LPM transfer support
because they should receive some initial commands with LPM by default
hardware setting.

Changelog v2: just add more descriptions.

Signed-off-by: Inki Dae 
Acked-by: Kyungmin Park 
---
 drivers/gpu/drm/drm_mipi_dsi.c |3 +++
 include/drm/drm_mipi_dsi.h |4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index e633df2..6b2bbda 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -232,6 +232,9 @@ int mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, 
unsigned int channel,
break;
}

+   if (dsi->mode_flags & MIPI_DSI_MODE_CMD_LPM)
+   msg.flags = MIPI_DSI_MSG_USE_LPM;
+
return ops->transfer(dsi->host, );
 }
 EXPORT_SYMBOL(mipi_dsi_dcs_write);
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 944f33f..1c41e49 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -94,6 +94,10 @@ void mipi_dsi_host_unregister(struct mipi_dsi_host *host);
 #define MIPI_DSI_MODE_VSYNC_FLUSH  BIT(8)
 /* disable EoT packets in HS mode */
 #define MIPI_DSI_MODE_EOT_PACKET   BIT(9)
+/* command low power mode */
+#define MIPI_DSI_MODE_CMD_LPM  BIT(10)
+/* video low power mode */
+#define MIPI_DSI_MODE_VIDEO_LPMBIT(11)

 enum mipi_dsi_pixel_format {
MIPI_DSI_FMT_RGB888,
-- 
1.7.9.5

[PATCH v2 0/2] drm/mipi-dsi: support lpm (low power mode) transfer

[Inki Dae]

This patch series adds lpm tranfer support for video and command data.

for this, this patch adds two flags, and makes mipi dsi host to send
commands to lcd panel device with lpm if mode_flags of lcd panel driver
includes lpm flag.

and also it applies this feature to exynos mipi dsi driver.

Changelog v2:
- Add more describtions.
- Enable High Speed clock only in case of stand by request.

Inki Dae (2):
  drm/mipi-dsi: add (LPM) Low Power Mode transfer support
  drm/exynos: dsi: add LPM (Low Power Mode) transfer support

 drivers/gpu/drm/drm_mipi_dsi.c  |3 +++
 drivers/gpu/drm/exynos/exynos_drm_dsi.c |   22 --
 include/drm/drm_mipi_dsi.h  |4 
 3 files changed, 27 insertions(+), 2 deletions(-)

-- 
1.7.9.5

[PATCH 00/19] atomic, remixed

[Daniel Vetter]

On Sun, Jul 27, 2014 at 11:41:29PM +0200, Daniel Vetter wrote:
> - I've added a new set of plane helpers. Mostly this was motivated to make the
>   atomic helpers work on less stellar hardware where you can't just stream the
>   state and then atomically commit with some GO bits. But those helpers should
>   also be useful for more gradual transitions of drivers to the atomic
>   interface. Since a requirement for atomic is to have universal plane support
>   they can be used bare-bones just for that, without all the other atomic
>   baggage (i.e. all the state tracking for crtcs/connectors).

Maybe a short elaboration on how to smoothly transition to atomic is in
order:
1. Implement the plane helpers for the primary plane, use the with the
crtc helper set_config function through the provided ->mode_set_base and
->mode_set callbacks.

2. Expose a proper primary plane with the plan helpers and test it a bit
(since with primary planes we now allow an enabled crtc with the primary
plane off).

3. Convert all other planes (cursor, overlay) over to the primary plane
helpers. You should move any constraint checking for planes into the
atomic_check callback.

4. Roll out your atomic state handling functions for crtc/plane. Using the
provided default handlers in the helper library is probably the best.
Plane/crtc helpers will automatically switch to those when available. From
here on you can also start to track plane/crtc state in your own
subclassed structures.

5. Audit all your ->mode_fixup functions to make sure they don't depend
upon the connector->encoder and encoder->crtc links. That's the big
difference between atomic and crtc helpers.

6. Wire up the set_config implementation from the atomic helpers and test
it.

7. Go through all the connectors individually and convert them to atomic
state handling. If a connector has no driver-private properties then you
can just wire up the default functions and the atomic set_prop
implementation from the helpers. Otherwise you need to subclass the state
structure.

8. Add ->atomic_check functions for crtcs to check additional constraints
that need checking for global modesets. If you have global/shared
resources (e.g. plls) add a modeset_lock for them and grab it if you need
to change anything. Make sure you wire up the backoff logic correctly
(CONFIG_DEBUG_WW_MUTEX_SLOWPATH is your friend).

That's all - each step is fairly well-contained and can be tested on its
own.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[PATCH v5 00/11] Add DRM for stih4xx platforms

[Benjamin Gaignard]

Hello Dave,

You can found the patcheset with Rob's reviewed-by tag here:
git://git.linaro.org/people/benjamin.gaignard/kernel.git
on drm_kms_for_next-v7 branch

It is the same code (drm_kms_for_next-v6) than what Rob has reviewed,
rebased (and tested) on top of drm-next.
The only changes are clocks typo (upper to lower case) in binding documentation.

Regards,
Benjamin


2014-07-28 1:23 GMT+02:00 Dave Airlie :
> On 16 July 2014 04:33, Rob Clark  wrote:
>> On Tue, Jul 15, 2014 at 5:41 AM, Benjamin Gaignard
>>  wrote:
>>> Hi all,
>>>
>>> Does version 6 fit to all your expectations ?
>>> If yes will you consider to merge it into drm-next ?
>>> If no, please tell me what need to be fixed.
>>
>>
>> I had another pass over the driver, and didn't find anything to
>> complain about, so for the series:
>>
>> Reviewed-by: Rob Clark 
>
> Can I see a git tree of this with Rob's R-B on it?
>
> based off drm-next if possible,
>
> I'd like to do a quick pre-merge review of it, but I usually don't
> find anything too major.
>
> Dave.



-- 
Benjamin Gaignard

Graphic Working Group

Linaro.org ? Open source software for ARM SoCs

Follow Linaro: Facebook | Twitter | Blog

[PATCH 0/3] drm/exynos: Allow module to be autoloaded

[Sjoerd Simons]

Hey Inki,

On Mon, 2014-07-21 at 08:50 +0200, Sjoerd Simons wrote:
> Hey Inki,
> 
> On Mon, 2014-07-21 at 12:02 +0900, Inki Dae wrote:
> > On 2014? 07? 19? 05:36, Sjoerd Simons wrote:
> > > The exynos DRM module currently is not automatically loaded when build as 
> > > a
> > > module. This is due to the simple fact that it doesn't have any
> > > MODULE_DEVICE_TABLE entries whatsoever... Most of these were removed 
> > > previously
> > > as it wasn't possible at the time to have multiple calls to 
> > > MODULE_DEVICE_TABLE
> > > in one module, however commit 21bdd17b21b45ea solved that.
> > > 
> > > The first two patches revert the previous removals of MODULE_DEVICE_TABLE
> > > calls, while the last one adds calls for the remaining OF match tables 
> > > without a
> > > MODULE_DEVICE_TABLE call.
> 
> > Exynos drm follows single-driver model. So each usb driver of Exynos drm
> > wouldn't need its own MODULE_DEVICE_TABLE.
> 
> Strictly speaking you're right, for module autoloading to work the
> module just needs to have one that matches. So in principle all other
> entries are redundant.
> 
> However for exynos drm there does not seem to be one main device which
> is guaranteed to always be present which can be used to key the module
> autoloading of. So you still need seperate MODULE_DEVICE_TABLE entries
> for all the various subdrivers to ensure autoloading actually happens,
> especially since the various subdrivers can be seperately enabled
> at build time. 

Been about a week since this last mail. If you have any suggestions on a
better approach or on how to move this forward, i'd be very grateful to
hear as i think i've addressed your original comment on the set in the
previous reply?

-- 
Sjoerd Simons 
Collabora Ltd.
-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140728/16c29e60/attachment-0001.bin>

[Bug 75276] Implement VGPR Register Spilling

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

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

--- Comment #31 from Michel D?nzer  ---
(In reply to comment #30)
> But every demo segfaults. Mostly in LLVMBuildBitCast().
[...]
> This is still a problem with register spilling that just looks different,
> right?

No, that sounds like bug 81834.

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

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #13 from Michel D?nzer  ---
(In reply to comment #6)
> Chromium randomly crashes with RadeonSI driver when using Chromium. Most
> usually with Youtube videos.

Using Flash or HTML5 video? Fullscreen or windowed? ...

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

[Bug 81678] X crashes on start (integrated 7640G + discrete 7500M/7600M)

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

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

Michel D?nzer  changed:

   What|Removed |Added

   Assignee|xorg-team at lists.x.org   |dri-devel at 
lists.freedesktop
   ||.org
 QA Contact|xorg-team at lists.x.org   |
Product|xorg|DRI
  Component|Lib/pciaccess   |DRM/Radeon

--- Comment #8 from Michel D?nzer  ---
(In reply to comment #6)
> This bug occurs on my PC. So, I can answer your questions.

So Igor reported the bug on your behalf?


> http://4.firepic.org/4/images/2014-07/25/16gbn0d01uyu.jpg

[...]

> BUG: unable to handle kernel paging request at 2180

I believe this oops might be the central issue, or at least one that needs to
be resolved.

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

[PATCH v5 00/11] Add DRM for stih4xx platforms

[Dave Airlie]

On 16 July 2014 04:33, Rob Clark  wrote:
> On Tue, Jul 15, 2014 at 5:41 AM, Benjamin Gaignard
>  wrote:
>> Hi all,
>>
>> Does version 6 fit to all your expectations ?
>> If yes will you consider to merge it into drm-next ?
>> If no, please tell me what need to be fixed.
>
>
> I had another pass over the driver, and didn't find anything to
> complain about, so for the series:
>
> Reviewed-by: Rob Clark 

Can I see a git tree of this with Rob's R-B on it?

based off drm-next if possible,

I'd like to do a quick pre-merge review of it, but I usually don't
find anything too major.

Dave.

[PATCH 0/8] Upstreaming the Android build and misc fixes

[Daniel Vetter]

On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote:
> A few updates:
>
>  - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to
> *_H_FILES
>  - Including the platform Android.mk files individually is not the right way
> to do. One needs to construct an array/list of Android.mks and include it.
>
>  - The series including the above fixes can be found in branch fixes+android
> over at https://github.com/evelikov/libdrm.

Adding Tim Gore who's working on Android.mk support for i-g-t from our
side and probably knows whom to poke for the intel side of things for
libdrm Android ports.
-Daniel

>
> -Emil
>
> On 27/07/14 19:25, Emil Velikov wrote:
> > Hello list,
> >
> > Recently I've had a go at the Anroid builds and I felt ... inspired that
> > there are (at least) two downstream repositories that have the relevant
> > Android build, yet all of them use 6+month old libdrm.
> > Making even builds a pain in the neck :'(
> >
> > Are there any objections if we get the android build upstream ? AFAICS
> > it's nicely isolated from everything else + I've managed to reuse all
> > the source/headers lists.
> >
> > Note that the series lacks a couple of patches from the downstream
> > repos, yet adds support for radeon, nouveau and freedreno :)
> >
> > The missing fixes are - s/mmap/mmap64/, dma-bufs support + other intel
> > specific "hacks". If people are happy with the series then we can take
> > a look at the final bits.
> >
> >
> > Cheers,
> > Emil
> >
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

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

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

--- Comment #4 from Michel D?nzer  ---
(In reply to comment #3)
> (In reply to comment #2)
> > Can you resolve the r600_dri.so symbols?
> 
> If you'll explain me how to.

First of all, make sure r600_dri.so has debugging symbols, i.e. is built with
-g and not stripped.

If the Mozilla crash reporter still doesn't resolve the symbols then, try

 addr2line  -e /path/to/r600_dri.so

for every r600_dri.so frame.

BTW, I notice the crash involves libgallium.so.0.0.0, which is an Ubuntu
specialty. Can your reproduce the problem with a build of upstream Mesa 10.1?

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

[PATCH 00/19] atomic, remixed

[Rob Clark]

On Sun, Jul 27, 2014 at 5:41 PM, Daniel Vetter  
wrote:
> Hi all,
>
> So I've figured instead of just talking I should draw up my ideas for atomic
> helpers and related stuff in some draft patches. Major differences compared to
> Rob's series:
>
> - The software side state update is done synchronously, at least when using 
> the
>   helper code. Drivers are free to do whatever they want, as usual. This has a
>   bunch of nice upsides:
>
>   + All the tricky locking dances can be abolished, and if the ordering and
> synchronization is done correctly async worker threads don't need any
> modeset state locking at all. I'm fairly sure that Rob's scheme won't blow
> up, but I much prefer we don't need it at all.
>
>   + In Rob's patches any atomic operation must wait for outstanding updates to
> complete. Otherwise the software state isn't committed yet. With the
> synchronous updates we can immediately proceed with the state construction
> and verification and will only block right before applying the state 
> update.
> And even for that drivers can implement cancellation of the previous 
> update.

fwiw, the rough plan here for my version was to (since state was
refcnt'd) eventually allow things to chain up (ie. copying N+1'th
state from N'th state, rather than mode objects themselves) which
could be done without locks for check-only..

That said, I'm not super sold on the idea that userspace needs to be
able to queue up multiple frames ahead.. but it was something that
people ask for from time to time..

> This has the nice benefit that check-only operations (which compositors 
> need
> to do right after having completed the current frame to know how to render
> the next one) can be done without blocking for completion of the previous
> update.
>
> - Internal interfaces for atomic updates don't need to go through properties,
>   but can directly set the state. Drivers can always compare updates in their
>   ->check hook later on, so we don't lose expressiveness in the interface. But
>   the resulting code in the callers looks much better.

hmm, in cases where drivers have to fwd one property to another object
or other sort of side effect, I think my way was nicer, imho ;-)

Sure, we can figure it out in check_hook later, but it is a bit
awkward.  And means we need to be careful about sequence of checks
(potentially having to re-check) of different objects.  Looks worse to
me ;-)

>   In general I've ditched a lot of interfaces where drivers could overwrite
>   default behaviour and boiled down the interface two state handling functions
>   (duplicate+destroy), setting driver-private properties and check/commit.
>
> - There is a clear helper separation between core code which should be used to
>   use the atomic interface to drivers, and helper functions. Core never uses
>   helper functions so that we can keep the clear separation we have in all 
> other
>   places in the kms api.
>
>   There's a set of helpers sitting in-between to implement legacy interfaces 
> on
>   top of atomic. Those _only_ use the core atomic interfaces.
>
> - I've added a new set of plane helpers. Mostly this was motivated to make the
>   atomic helpers work on less stellar hardware where you can't just stream the
>   state and then atomically commit with some GO bits. But those helpers should
>   also be useful for more gradual transitions of drivers to the atomic
>   interface. Since a requirement for atomic is to have universal plane support
>   they can be used bare-bones just for that, without all the other atomic
>   baggage (i.e. all the state tracking for crtcs/connectors).
>
> - State tracking for connectors. i915 has piles of relevant connector
>   properties, which we want to save/restore in atomic ops (e.g. hdmi metadata
>   and stuff).
>
> - fbdev panic locking is implemented with trylock instead of nolock.
>
> - I've thought a bit about resume. See the proposed state handling for the
>   default reset functions and the addition of a plane reset callback.
>
> There's also a metric pile of stuff missing:
>
> - It's completely untested (except for the parts touching currently used code)
>   since I lack suitable hw. Converting i915 is just a bit too much of a pain 
> for
>   a quick w/e code draft ;-)
>
> - I didn't add all the properties for things currently exposed through ioctl
>   structures. Since the interface here doesn't force internal code to use
>   properties for everything (which really makes things look much better) we
>   don't have a need for that until we merge the actual atomic ioctl. So I left
>   that out.
>
> - I didn't write code for the fbdev helper to use atomic. The w/e ran out of
>   time for that ...
>
> - Kerneldoc is occasionally not updated or still missing.

Unless I'm missing something you also completely lost all the core
crtc and plane check code (except for what you left in legacy
codepaths.. tbh, this was one thing that I liked about my 

[Bug 78453] [HAWAII] Get acceleration working

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

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

--- Comment #114 from Michel D?nzer  ---
(In reply to comment #108)
> Btw, watching a video on Twitch spams my Xorg.0.log with *tons* of:
> > [ 21013.158] (WW) RADEON(0): radeon_dri2_flip_event_handler: Pageflip 
> > completion event has impossible msc 2822274 < target_msc 2822275

These are fixed in drm-fixes-3.16, but that hasn't been merged into
drm-next-3.17-wip yet.

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

[PATCH 0/8] Upstreaming the Android build and misc fixes

[Emil Velikov]

A few updates:

 - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to
*_H_FILES
 - Including the platform Android.mk files individually is not the right way
to do. One needs to construct an array/list of Android.mks and include it.

 - The series including the above fixes can be found in branch fixes+android
over at https://github.com/evelikov/libdrm.

-Emil

On 27/07/14 19:25, Emil Velikov wrote:
> Hello list,
> 
> Recently I've had a go at the Anroid builds and I felt ... inspired that
> there are (at least) two downstream repositories that have the relevant
> Android build, yet all of them use 6+month old libdrm.
> Making even builds a pain in the neck :'(
> 
> Are there any objections if we get the android build upstream ? AFAICS 
> it's nicely isolated from everything else + I've managed to reuse all 
> the source/headers lists.
> 
> Note that the series lacks a couple of patches from the downstream 
> repos, yet adds support for radeon, nouveau and freedreno :)
> 
> The missing fixes are - s/mmap/mmap64/, dma-bufs support + other intel 
> specific "hacks". If people are happy with the series then we can take
> a look at the final bits.
> 
> 
> Cheers,
> Emil
> 

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

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

--- Comment #12 from Michel D?nzer  ---
(In reply to comment #11)
> I'm guessing as of this patch this can be closed?
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> ?id=2062afb4f804afef61cbe62a30cac9a46e58e067

No, that's unrelated.

BTW, the backtraces in Xorg log files aren't useful for diagnosing this kind of
problem, so there's no point in attaching more Xorg log files just for that.

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

[PATCH 19/19] drm/atomic-helpers: functions for state duplicate/destroy/reset

[Daniel Vetter]

The atomic users and helpers assume that there is always a obj->state
structure around. Which means drivers need to somehow create that at
driver load time. Also it should obviously reset hardware state, so
needs to be reset upon resume.

Finally the destroy/duplicate_state functions are an awful lot of
boilerplate if the driver doesn't need anything beyond the default
state objects.

So add helper functions for all of this.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 21 +
 include/drm/drm_atomic_helper.h | 19 +++
 2 files changed, 40 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index b1ef7a1e038c..9e188605f72f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1547,3 +1547,24 @@ backoff:
goto retry;
 }
 EXPORT_SYMBOL(drm_atomic_helper_page_flip);
+
+void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc)
+{
+   kfree(crtc->state);
+   crtc->state = kzalloc(sizeof(*crtc->state), GFP_KERNEL);
+}
+EXPORT_SYMBOL(drm_atomic_helper_crtc_reset);
+
+struct drm_crtc_state *
+drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc)
+{
+   return kmemdup(crtc->state, sizeof(*crtc->state), GFP_KERNEL);
+}
+EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
+
+void drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
+ struct drm_crtc_state *state)
+{
+   kfree(state);
+}
+EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 3400c2b7e6ae..dccc44065abf 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -75,5 +75,24 @@ int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
struct drm_pending_vblank_event *event,
uint32_t flags);

+/* default implementations for state handling */
+void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
+struct drm_crtc_state *
+drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc);
+void drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
+ struct drm_crtc_state *state);
+
+void drm_atomic_helper_plane_reset(struct drm_plane *plane);
+struct drm_plane_state *
+drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane);
+void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
+ struct drm_plane_state *state);
+
+void drm_atomic_helper_connector_reset(struct drm_connector *connector);
+struct drm_connector_state *
+drm_atomic_helper_connector_duplicate_state(struct drm_connector *connector);
+void drm_atomic_helper_connector_destroy_state(struct drm_connector *connector,
+ struct drm_connector_state *state);
+

 #endif /* DRM_ATOMIC_HELPER_H_ */
-- 
2.0.1

[PATCH 18/19] drm: trylock modest locking for fbdev panics

[Daniel Vetter]

In the fbdev code we want to do trylocks only to avoid deadlocks and
other ugly issues. Thus far we've only grabbed the overall modeset
lock, but that already failed to exclude a pile of potential
concurrent operations. With proper atomic support this will be worse.

So add a trylock mode to the modeset locking code which attempts all
locks only with trylocks, if possible. We need to track this in the
locking functions themselves and can't restrict this to drivers since
driver-private w/w mutexes must be treated the same way.

There's still the issue that other driver private locks aren't handled
here at all, but well can't have everything. With this we will at
least not regress, even once atomic allows lots of concurrent kms
activity.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_fb_helper.c| 10 
 drivers/gpu/drm/drm_modeset_lock.c | 51 +++---
 include/drm/drm_modeset_lock.h |  6 +
 3 files changed, 47 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 3144db9dc0f1..66a438ab4e7f 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -419,11 +419,11 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (dev->switch_power_state == DRM_SWITCH_POWER_OFF)
continue;

-   /* NOTE: we use lockless flag below to avoid grabbing other
-* modeset locks.  So just trylock the underlying mutex
-* directly:
+   /*
+* NOTE: Use trylock mode to avoid deadlocks and sleeping in
+* panic context.
 */
-   if (!mutex_trylock(>mode_config.mutex)) {
+   if (!__drm_modeset_lock_all(dev, true)) {
error = true;
continue;
}
@@ -432,7 +432,7 @@ static bool drm_fb_helper_force_kernel_mode(void)
if (ret)
error = true;

-   mutex_unlock(>mode_config.mutex);
+   drm_modeset_unlock_all(dev);
}
return error;
 }
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index 412b396af740..42ba9ca699ad 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -56,27 +56,27 @@
  */


-/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
- *
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
- */
-void drm_modeset_lock_all(struct drm_device *dev)
+int __drm_modeset_lock_all(struct drm_device *dev,
+  bool trylock)
 {
struct drm_mode_config *config = >mode_config;
struct drm_modeset_acquire_ctx *ctx;
int ret;

-   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
-   if (WARN_ON(!ctx))
-   return;
+   ctx = kzalloc(sizeof(*ctx),
+ trylock ? GFP_ATOMIC : GFP_KERNEL);
+   if (!ctx)
+   return -ENOMEM;

-   mutex_lock(>mutex);
+   if (trylock) {
+   if (!mutex_trylock(>mutex))
+   return -EBUSY;
+   } else {
+   mutex_lock(>mutex);
+   }

drm_modeset_acquire_init(ctx, 0);
+   ctx->trylock_only = trylock;

 retry:
ret = drm_modeset_lock(>connection_mutex, ctx);
@@ -95,13 +95,29 @@ retry:

drm_warn_on_modeset_not_all_locked(dev);

-   return;
+   return 0;

 fail:
if (ret == -EDEADLK) {
drm_modeset_backoff(ctx);
goto retry;
}
+
+   return ret;
+}
+EXPORT_SYMBOL(__drm_modeset_lock_all);
+
+/**
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
+ *
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
+ */
+void drm_modeset_lock_all(struct drm_device *dev)
+{
+   WARN_ON(__drm_modeset_lock_all(dev, false) != 0);
 }
 EXPORT_SYMBOL(drm_modeset_lock_all);

@@ -287,7 +303,12 @@ static inline int modeset_lock(struct drm_modeset_lock 
*lock,

WARN_ON(ctx->contended);

-   if (interruptible && slow) {
+   if (ctx->trylock_only) {
+   if (!ww_mutex_trylock(>mutex))
+   return -EBUSY;
+   else
+   return 0;
+   } else if (interruptible && slow) {
ret = ww_mutex_lock_slow_interruptible(>mutex, 
>ww_ctx);
} else if (interruptible) {
ret = ww_mutex_lock_interruptible(>mutex, >ww_ctx);
diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h
index d38e1508f11a..a3f736d24382 100644
--- a/include/drm/drm_modeset_lock.h
+++ b/include/drm/drm_modeset_lock.h
@@ -53,6 +53,11 @@ struct 

[PATCH 17/19] drm/atomic-helper: implement ->page_flip

[Daniel Vetter]

Currently there is no way to implement async flips using atomic, that
essentially requires us to be able to cancel pending requests
mid-flight.

To be able to do that (and I guess we want this since vblank synced
updates whic opportunistically cancel still pending updates seem to be
wanted) we'd need to add a mandatory cancellation mode. Depending upon
the exact semantics we decide upon that could mean that userspace will
not get completion events, or will get them all stacked up.

So reject async updates for now. Also async updates usually means not
vblank synced at all, and I guess for drivers which want to support
this they should simply add a special pageflip handler (since usually
you need a special flip cmd to achieve this). That kind of async flip
is pretty much exclusively just used for games and benchmarks where
dropping just one frame means you'll get a headshot or something bad
like that ... And so slight amounts of tearing is acceptable.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 84 +
 include/drm/drm_atomic_helper.h |  5 +++
 2 files changed, 89 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 423f6bcec362..b1ef7a1e038c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1463,3 +1463,87 @@ backoff:
goto retry;
 }
 EXPORT_SYMBOL(drm_atomic_helper_connector_set_property);
+
+/**
+ * drm_atomic_helper_set_config - set a new config from userspace
+ * @crtc: DRM crtc
+ * @fb: DRM framebuffer
+ * @event: optional DRM event to signal upon completion
+ * @flags: flip flags for non-vblank sync'ed updates
+ *
+ * Provides a default page flip using the atomic driver interface.
+ *
+ * Note that for now so called async page flips (i.e. updates which are not
+ * synchronized to vblank) are not supported, since the atomic interfaces have
+ * no provisions for this yet.
+ *
+ * Returns:
+ * Returns 0 on success, negative errno numbers on failure.
+ */
+int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   struct drm_pending_vblank_event *event,
+   uint32_t flags)
+{
+   struct drm_plane *plane = crtc->primary;
+   struct drm_atomic_state *state;
+   struct drm_plane_state *plane_state;
+   struct drm_crtc_state *crtc_state;
+   int ret = 0;
+
+   if (flags & DRM_MODE_PAGE_FLIP_ASYNC)
+   return -EINVAL;
+
+   state = drm_atomic_state_alloc(plane->dev);
+   if (!state)
+   return -ENOMEM;
+
+   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+retry:
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state)) {
+   ret = PTR_ERR(crtc_state);
+   if (ret == -EDEADLK)
+   goto backoff;
+   else
+   goto fail;
+   }
+   crtc_state->event = event;
+
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   if (ret == -EDEADLK)
+   goto backoff;
+   else
+   goto fail;
+   }
+
+   plane_state->crtc = crtc;
+   plane_state->fb = fb;
+
+   ret = drm_atomic_async_commit(state);
+   if (ret == -EDEADLK)
+   goto backoff;
+
+   /* Driver takes ownership of state on successful async commit. */
+   if (ret == 0)
+   return 0;
+fail:
+   drm_atomic_state_free(state);
+
+   return ret;
+backoff:
+   drm_atomic_legacy_backoff(state);
+   drm_atomic_state_clear(state);
+
+   /*
+* Someone might have exchanged the framebuffer while we dropped locks
+* in the backoff code. We need to fix up the fb refcount tracking the
+* core does for us.
+*/
+   plane->old_fb = plane->fb;
+
+   goto retry;
+}
+EXPORT_SYMBOL(drm_atomic_helper_page_flip);
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 0f48e0ffb614..3400c2b7e6ae 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -70,5 +70,10 @@ int drm_atomic_helper_plane_set_property(struct drm_plane 
*plane,
 int drm_atomic_helper_connector_set_property(struct drm_connector *connector,
struct drm_property *property,
uint64_t val);
+int drm_atomic_helper_page_flip(struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   struct drm_pending_vblank_event *event,
+   uint32_t flags);
+

 #endif /* DRM_ATOMIC_HELPER_H_ */
-- 
2.0.1

[PATCH 16/19] drm/atomic-helpers: document how to implement async commit

[Daniel Vetter]

No helper function to do it all yet provided since no driver has
support for driver core fences yet. Which we'd need to make the
implementation really generic.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9f7c45b91fe2..423f6bcec362 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -716,6 +716,43 @@ int drm_atomic_helper_commit(struct drm_device *dev,
 EXPORT_SYMBOL(drm_atomic_helper_commit);

 /**
+ * DOC: Implementing async commit
+ *
+ * For now the atomic helpers don't support async commit directly. If there is
+ * real need it could be added though, using the dma-buf fence infrastructure
+ * for generic synchronization with outstanding rendering.
+ *
+ * For now drivers have to implement async commit themselves, with the 
following
+ * sequence being the recommened one:
+ *
+ * 1. Run drm_atomic_helper_prepare_planes() first. This is the only function
+ * which commit needs to call which can fail, so we want to run it first and
+ * synchronously.
+ *
+ * 2. Synchronize with any outstanding async commit worker threads which might
+ * affect the new state update. This can be done by either cancelling or
+ * flushing the work items, depending upon whether the driver can deal with
+ * cancelled updates. Note that it is important to ensure that the framebuffer
+ * cleanup is still done when cancelling.
+ *
+ * For sufficient parallelism it is recommended to have a work item per crtc
+ * (for updates which don't touch global state) and a global one. Then we only
+ * need to synchronize with the crtc work items for changed crtcs and the 
global
+ * work item, which allows nice concurrent updates on disjoint sets of crtcs.
+ *
+ * 3. The software state is updated synchronously with
+ * drm_atomic_helper_swap_state. Doing this under the protection of all modeset
+ * locks means concurrent callers never see inconsistent state. And doing this
+ * while it's guranateed that no relevant async worker runs means that async
+ * workers do not need grab any locks. Actually they must not grab locks, for
+ * otherwise the work flushing will deadlock.
+ *
+ * 4. Schedule a work item to do all subsequent steps, using the split-out
+ * commit helpers: a) pre-plane commit b) plane commit c) post-plane commit and
+ * then cleaning up the framebuffers after one vblank has passed.
+ */
+
+/**
  * drm_atomic_helper_prepare_planes - prepare plane resources after commit
  * @dev: DRM device
  * @state: atomic state object with old state structures
-- 
2.0.1

[PATCH 15/19] drm/plane-helper: Add async mode to prepare_fb

[Daniel Vetter]

Currently all helpers use ->prepare_fb for synchronous state updates,
so we need the driver callback to wait for any outstanding rendering.

But with async commit we really only want to reserve the framebuffer,
but not stall for rendering. That should be done in the asynchronous
worker.

So add a boolean for this.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 12 +---
 drivers/gpu/drm/drm_crtc_helper.c   |  2 +-
 drivers/gpu/drm/drm_plane_helper.c  |  4 ++--
 include/drm/drm_atomic_helper.h |  3 ++-
 include/drm/drm_plane_helper.h  |  3 ++-
 5 files changed, 16 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 1b13394cf020..9f7c45b91fe2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -673,7 +673,7 @@ int drm_atomic_helper_commit(struct drm_device *dev,
if (async)
return -EBUSY;

-   ret = drm_atomic_helper_prepare_planes(dev, state);
+   ret = drm_atomic_helper_prepare_planes(dev, state, false);
if (ret)
return ret;

@@ -719,16 +719,22 @@ EXPORT_SYMBOL(drm_atomic_helper_commit);
  * drm_atomic_helper_prepare_planes - prepare plane resources after commit
  * @dev: DRM device
  * @state: atomic state object with old state structures
+ * @async: asynchronous commit
  *
  * This function prepares plane state, specifically framebuffers, for the new
  * configuration. If any failure is encountered this function will call
  * ->cleanup_fb on any already successfully prepared framebuffer.
  *
+ * If @async is true the driver callbacks should not wait for outstanding
+ * render, but instead ensure that the asynchronous commit work item is stalled
+ * sufficiently long.
+ *
  * Returns:
  * 0 on success, negative error code on failure.
  */
 int drm_atomic_helper_prepare_planes(struct drm_device *dev,
-struct drm_atomic_state *state)
+struct drm_atomic_state *state,
+bool async)
 {
int nplanes = dev->mode_config.num_total_plane;
int ret, i;
@@ -746,7 +752,7 @@ int drm_atomic_helper_prepare_planes(struct drm_device *dev,
fb = state->plane_states[i]->fb;

if (fb && funcs->prepare_fb) {
-   ret = funcs->prepare_fb(plane, fb);
+   ret = funcs->prepare_fb(plane, fb, async);
if (ret)
goto fail;
}
diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 7e838104e72e..1382842782f3 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -993,7 +993,7 @@ int drm_helper_crtc_mode_set_base(struct drm_crtc *crtc, 
int x, int y,
}

if (plane_funcs->prepare_fb) {
-   ret = plane_funcs->prepare_fb(plane, plane_state->fb);
+   ret = plane_funcs->prepare_fb(plane, plane_state->fb, false);
if (ret)
goto fail;
}
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 7befbf017afe..6903f50012c5 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -435,7 +435,7 @@ int drm_plane_helper_update(struct drm_plane *plane, struct 
drm_crtc *crtc,
}

if (plane_funcs->prepare_fb) {
-   ret = plane_funcs->prepare_fb(plane, fb);
+   ret = plane_funcs->prepare_fb(plane, fb, false);
if (ret)
goto fail;
}
@@ -514,7 +514,7 @@ int drm_plane_helper_disable(struct drm_plane *plane)
}

if (plane_funcs->prepare_fb) {
-   ret = plane_funcs->prepare_fb(plane, fb);
+   ret = plane_funcs->prepare_fb(plane, fb, false);
if (ret)
goto fail;
}
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 8cd6fe7a48e5..0f48e0ffb614 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -40,7 +40,8 @@ void drm_atomic_helper_commit_post_planes(struct drm_device 
*dev,
  struct drm_atomic_state *old_state);

 int drm_atomic_helper_prepare_planes(struct drm_device *dev,
-struct drm_atomic_state *state);
+struct drm_atomic_state *state,
+bool async);
 void drm_atomic_helper_commit_planes(struct drm_device *dev,
 struct drm_atomic_state *state);
 void drm_atomic_helper_cleanup_planes(struct drm_device *dev,
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index a6f3a8ed3394..48543149055b 100644
--- a/include/drm/drm_plane_helper.h

[PATCH 14/19] drm/atomic-helper: implementatations for legacy interfaces

[Daniel Vetter]

Well, except page_flip since that requires async commit, which isn't
there yet.

For the functions which changes planes there's a bit of trickery
involved to keep the fb refcounting working. But otherwise fairly
straight-forward atomic updates.

The property setting functions are still a bit incomplete. Once we
have generic properties (e.g. rotation, but also all the properties
needed by the atomic ioctl) we need to filter those out and parse them
in the helper. Preferrably with the same function as used by the real
atomic ioctl implementation.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_atomic_helper.c | 481 
 include/drm/drm_atomic_helper.h |  21 ++
 2 files changed, 502 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index d5d2eb2908cc..1b13394cf020 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -939,3 +939,484 @@ void drm_atomic_helper_swap_state(struct drm_device *dev,
}
 }
 EXPORT_SYMBOL(drm_atomic_helper_swap_state);
+
+/**
+ * drm_atomic_helper_update_plane - Helper for primary plane update using 
atomic
+ * @plane: plane object to update
+ * @crtc: owning CRTC of owning plane
+ * @fb: framebuffer to flip onto plane
+ * @crtc_x: x offset of primary plane on crtc
+ * @crtc_y: y offset of primary plane on crtc
+ * @crtc_w: width of primary plane rectangle on crtc
+ * @crtc_h: height of primary plane rectangle on crtc
+ * @src_x: x offset of @fb for panning
+ * @src_y: y offset of @fb for panning
+ * @src_w: width of source rectangle in @fb
+ * @src_h: height of source rectangle in @fb
+ *
+ * Provides a default plane update handler using the atomic driver interface.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int drm_atomic_helper_update_plane(struct drm_plane *plane,
+  struct drm_crtc *crtc,
+  struct drm_framebuffer *fb,
+  int crtc_x, int crtc_y,
+  unsigned int crtc_w, unsigned int crtc_h,
+  uint32_t src_x, uint32_t src_y,
+  uint32_t src_w, uint32_t src_h)
+{
+   struct drm_atomic_state *state;
+   struct drm_plane_state *plane_state;
+   int ret = 0;
+
+   state = drm_atomic_state_alloc(plane->dev);
+   if (!state)
+   return -ENOMEM;
+
+   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(crtc);
+retry:
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   if (ret == -EDEADLK)
+   goto backoff;
+   else
+   goto fail;
+   }
+
+   plane_state->crtc = crtc;
+   plane_state->fb = fb;
+   plane_state->crtc_x = crtc_x;
+   plane_state->crtc_y = crtc_y;
+   plane_state->crtc_h = crtc_h;
+   plane_state->crtc_w = crtc_w;
+   plane_state->src_x = src_x;
+   plane_state->src_y = src_y;
+   plane_state->src_h = src_h;
+   plane_state->src_w = src_w;
+
+   ret = drm_atomic_commit(state);
+   if (ret == -EDEADLK)
+   goto backoff;
+fail:
+   drm_atomic_state_free(state);
+
+   return ret;
+backoff:
+   drm_atomic_legacy_backoff(state);
+   drm_atomic_state_clear(state);
+
+   /*
+* Someone might have exchanged the framebuffer while we dropped locks
+* in the backoff code. We need to fix up the fb refcount tracking the
+* core does for us.
+*/
+   plane->old_fb = plane->fb;
+
+   goto retry;
+}
+EXPORT_SYMBOL(drm_atomic_helper_update_plane);
+
+/**
+ * drm_atomic_helper_disable_plane - Helper for primary plane disable using * 
atomic
+ * @plane: plane to disable
+ *
+ * Provides a default plane disablle handler using the atomic driver interface.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int drm_atomic_helper_disable_plane(struct drm_plane *plane)
+{
+   struct drm_atomic_state *state;
+   struct drm_plane_state *plane_state;
+   int ret = 0;
+
+   state = drm_atomic_state_alloc(plane->dev);
+   if (!state)
+   return -ENOMEM;
+
+   state->acquire_ctx = drm_modeset_legacy_acquire_ctx(plane->crtc);
+retry:
+   plane_state = drm_atomic_get_plane_state(state, plane);
+   if (IS_ERR(plane_state)) {
+   ret = PTR_ERR(plane_state);
+   if (ret == -EDEADLK)
+   goto backoff;
+   else
+   goto fail;
+   }
+
+   plane_state->crtc = NULL;
+   plane_state->fb = NULL;
+   plane_state->crtc_x = 0;
+   plane_state->crtc_y = 0;
+   plane_state->crtc_h = 0;
+   plane_state->crtc_w = 0;
+   plane_state->src_x = 0;
+   plane_state->src_y = 0;
+   

[PATCH 13/19] drm: Move ->old_fb from crtc to plane

[Daniel Vetter]

Atomic implemenations for legacy ioctls must be able to drop locks.
Which doesn't cause havoc since we only do that while constructing
the new state, so no driver or hardware state change has happened.

The only troubling bit is the fb refcounting the core does - if
someone else has snuck in then it might potentially unref an
outdated framebuffer. To fix that move the old_fb temporary storage
into struct drm_plane for all ioctls, so that the atomic helpers can
update it.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 40 
 include/drm/drm_crtc.h |  8 
 2 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e33aa3a3a8a5..ff705ea3f50e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -1200,19 +1200,21 @@ EXPORT_SYMBOL(drm_plane_index);
  */
 void drm_plane_force_disable(struct drm_plane *plane)
 {
-   struct drm_framebuffer *old_fb = plane->fb;
int ret;

-   if (!old_fb)
+   if (!plane->fb)
return;

+   plane->old_fb = plane->fb;
ret = plane->funcs->disable_plane(plane);
if (ret) {
DRM_ERROR("failed to disable plane with busy fb\n");
+   plane->old_fb = NULL;
return;
}
/* disconnect the plane from the fb and crtc: */
-   __drm_framebuffer_unreference(old_fb);
+   __drm_framebuffer_unreference(plane->old_fb);
+   plane->old_fb = NULL;
plane->fb = NULL;
plane->crtc = NULL;
 }
@@ -2188,7 +2190,7 @@ static int setplane_internal(struct drm_plane *plane,
 uint32_t src_w, uint32_t src_h)
 {
struct drm_device *dev = plane->dev;
-   struct drm_framebuffer *old_fb = NULL;
+   struct drm_framebuffer *old_fb;
int ret = 0;
unsigned int fb_width, fb_height;
int i;
@@ -2196,14 +2198,16 @@ static int setplane_internal(struct drm_plane *plane,
/* No fb means shut it down */
if (!fb) {
drm_modeset_lock_all(dev);
-   old_fb = plane->fb;
+   plane->old_fb = plane->fb;
ret = plane->funcs->disable_plane(plane);
if (!ret) {
plane->crtc = NULL;
plane->fb = NULL;
} else {
-   old_fb = NULL;
+   plane->old_fb = NULL;
}
+   old_fb = plane->old_fb;
+   plane->old_fb = NULL;
drm_modeset_unlock_all(dev);
goto out;
}
@@ -2245,7 +2249,7 @@ static int setplane_internal(struct drm_plane *plane,
}

drm_modeset_lock_all(dev);
-   old_fb = plane->fb;
+   plane->old_fb = plane->fb;
ret = plane->funcs->update_plane(plane, crtc, fb,
 crtc_x, crtc_y, crtc_w, crtc_h,
 src_x, src_y, src_w, src_h);
@@ -2254,8 +2258,10 @@ static int setplane_internal(struct drm_plane *plane,
plane->fb = fb;
fb = NULL;
} else {
-   old_fb = NULL;
+   plane->old_fb = NULL;
}
+   old_fb = plane->old_fb;
+   plane->old_fb = NULL;
drm_modeset_unlock_all(dev);

 out:
@@ -2369,7 +2375,7 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
 * crtcs. Atomic modeset will have saner semantics ...
 */
list_for_each_entry(tmp, >dev->mode_config.crtc_list, head)
-   tmp->old_fb = tmp->primary->fb;
+   tmp->primary->old_fb = tmp->primary->fb;

fb = set->fb;

@@ -2382,8 +2388,9 @@ int drm_mode_set_config_internal(struct drm_mode_set *set)
list_for_each_entry(tmp, >dev->mode_config.crtc_list, head) {
if (tmp->primary->fb)
drm_framebuffer_reference(tmp->primary->fb);
-   if (tmp->old_fb)
-   drm_framebuffer_unreference(tmp->old_fb);
+   if (tmp->primary->old_fb)
+   drm_framebuffer_unreference(tmp->primary->old_fb);
+   tmp->primary->old_fb = NULL;
}

return ret;
@@ -4458,7 +4465,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
 {
struct drm_mode_crtc_page_flip *page_flip = data;
struct drm_crtc *crtc;
-   struct drm_framebuffer *fb = NULL, *old_fb = NULL;
+   struct drm_framebuffer *fb = NULL;
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
int ret = -EINVAL;
@@ -4530,7 +4537,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
(void (*) (struct drm_pending_event *)) kfree;
}

-   old_fb = crtc->primary->fb;
+   crtc->primary->old_fb = crtc->primary->fb;
ret = crtc->funcs->page_flip(crtc, fb, e, page_flip->flags);
if 

[PATCH 12/19] drm: Atomic crtc/connector updates using crtc helper interfaces

[Daniel Vetter]

So this is finally the integration of the crtc helper interfaces into
the atomic helper functions.

In the check function we now have a few steps:

- First we update the output routing and figure out which crtcs need a
  full mode set. Suitable encoders are selected using ->best_encoder,
  with the same semantics as the crtc helpers of implicitly disabling
  all connectors currently using the encoder.

- Then we pull all other connectors into the state update which feed
  from a crtc which changes. This must be done do catch mode changes
  and similar updates - atomic updates are differences on top of the
  current state.

- Then we call all the various ->mode_fixup to compute the adjusted
  mode. Note that here we have a slight semantic difference compared
  to the crtc helpers: We have not yet updated the encoder->crtc link
  when calling the encoder's ->mode_fixup function. But that's a
  requirement when converting to atomic since we want to prepare the
  entire state completely contained with the over drm_atomic_state
  structure. So this must be carefully checked when converting drivers
  over to atomic helpers.

- Finally we do call the atomic_check functions on planes and crtcs.

The commit function is also quite a beast:

- The only step that can fail is done first, namely pinning the
  framebuffers. After that we cross the point of no return, an async
  commit would push all that into the worker thread.

- The disabling of encoders and connectors is a bit tricky, since
  depending upon the final state we need to select different crtc
  helper functions.

- Software tracking is a bit clarified compared to the crtc helpers:
  We commit the software state before starting to touch the hardware,
  like crtc helpers. But since we just swap them we still have the old
  state (i.e. the current hw state) around, which is really handy to
  write simple disable functions. So no more
  drm_crtc_helper_disable_all_unused_functions kind of fun because
  we're leaving unused crtcs/encoders behind. Everything gets shut
  down in-order now, which is one of the key differences of the i915
  helpers compared to crtc helpers and a really nice additional
  guarantee.

- Like with the plane helpers the atomic commit function waits for one
  vblank to pass before calling the framebuffer cleanup function.

Compared to Rob's helper approach there's a bunch of upsides:

- All the interfaces which can fail are called in the ->check hook
  (i.e. ->best_match and the various ->mode_fixup hooks). This means
  that drivers can just reuse those functions and don't need to move
  everything into ->atomic_check callbacks. If drivers have no need
  for additional constraint checking beyong their existing crtc
  helper callbacks they don't need to do anything.

- The actual commit operation is properly stage: First we prepare
  framebuffers, which can potentially still fail (due to memory
  exhausting). This is important for the async case, where this must
  be done synchronously to correctly return errors.

- The output configuration changes (done with crtc helper functions)
  and the plane update (using atomic plane helpers) are correctly
  interleaved: First we shut down any crtcs that need changing, then
  we update planes and finally we enable everything again. Hardware
  without GO bits must be more careful with ordering, which this
  sequence enables.

- Also for hardware with shared output resources (like display PLLs)
  we first must shut down the old configuration before we can enable
  the new one. Otherwise we can hit an impossible intermediate state
  where there's not enough PLLs (which is the point behind atomic
  updates).

v2:
- Ensure that users of ->check update crtc_state->enable correctly.
- Update the legacy state in crtc/plane structures. Eventually we want
  to remove that, but for now the drm core still expects this (especially
  the plane->fb pointer).

v3: A few changes for better async handling:

- Reorder the software side state commit so that it happens all before
  we touch the hardware. This way async support becomes very easy
  since we can punt all the actual hw touching to a worker thread. And
  as long as we synchronize with that thread (flushing or cancelling,
  depending upon what the driver can handle) before we commit the next
  software state there's no need for any locking in the worker thread
  at all. Which greatly simplifies things.

  And as long as we synchronize with all relevant threads we can have
  a lot of them (e.g. per-crtc for per-crtc updates) running in
  parallel.

- Expose pre/post plane commit steps separately. We need to expose the
  actual hw commit step anyway for drivers to be able to implement
  asynchronous commit workers. But if we expose pre/post and plane
  commit steps individually we allow drivers to selectively use atomic
  helpers.

- I've forgotten to call encoder/bridge ->mode_set functions, fix
  this.

Signed-off-by: Daniel Vetter 
---
 

[PATCH 11/19] drm/crtc-helper: Transitional functions using atomic plane helpers

[Daniel Vetter]

These two functions allow drivers to reuse their atomic plane helpers
functions for the primary plane to implement the interfaces required
by the crtc helpers for the legacy ->set_config callback.

This is purely transitional and won't be used once the driver is fully
converted. But it allows partial conversions to the atomic plane
helpers which are functional.

v2:
- Use ->atomic_duplicate_state if available.
- Don't forget to run crtc_funcs->atomic_check.

v3: Shift source coordinates correctly for 16.16 fixed point.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc_helper.c | 138 ++
 include/drm/drm_crtc.h|   3 +
 include/drm/drm_crtc_helper.h |   7 ++
 3 files changed, 148 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 6c65a0a28fbd..751dcc9ba163 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 

 MODULE_AUTHOR("David Airlie, Jesse Barnes");
@@ -888,3 +889,140 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
drm_modeset_unlock_all(dev);
 }
 EXPORT_SYMBOL(drm_helper_resume_force_mode);
+
+/**
+ * drm_helper_crtc_mode_set - mode_set implementation for atomic plane helpers
+ *
+ * This function implements a callback useable as the ->mode_set callback
+ * required by the crtc helpers. Besides the atomic plane helper functions for
+ * the primary plane the driver must also provide the ->mode_set_nofb callback
+ * to set up the crtc.
+ *
+ * This is a transitional helper useful for converting drivers to the atomic
+ * interfaces.
+ */
+int drm_helper_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode 
*mode,
+struct drm_display_mode *adjusted_mode, int x, int 
y,
+struct drm_framebuffer *old_fb)
+{
+   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
+   int ret;
+
+   if (crtc->funcs->atomic_duplicate_state)
+   crtc_state = crtc->funcs->atomic_duplicate_state(crtc);
+   else if (crtc->state)
+   crtc_state = kmemdup(crtc->state, sizeof(*crtc_state),
+GFP_KERNEL);
+   else
+   crtc_state = kzalloc(sizeof(*crtc_state), GFP_KERNEL);
+   if (!crtc_state)
+   return -ENOMEM;
+
+   crtc_state->enable = true;
+   crtc_state->planes_changed = true;
+   drm_mode_copy(_state->mode, mode);
+   drm_mode_copy(_state->adjusted_mode, adjusted_mode);
+
+   if (crtc_funcs->atomic_check) {
+   ret = crtc_funcs->atomic_check(crtc, crtc_state);
+   if (ret) {
+   kfree(crtc_state);
+
+   return ret;
+   }
+   }
+
+   swap(crtc->state, crtc_state);
+
+   crtc_funcs->mode_set_nofb(crtc);
+
+   kfree(crtc_state);
+
+   return drm_helper_crtc_mode_set_base(crtc, x, y, old_fb);
+}
+EXPORT_SYMBOL(drm_helper_crtc_mode_set);
+
+/**
+ * drm_helper_crtc_mode_set_base - mode_set_base implementation for atomic 
plane helpers
+ *
+ * This function implements a callback useable as the ->mode_set_base used
+ * required by the crtc helpers. The driver must provide the atomic plane 
helper
+ * functions for the primary plane.
+ *
+ * This is a transitional helper useful for converting drivers to the atomic
+ * interfaces.
+ */
+int drm_helper_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
+ struct drm_framebuffer *old_fb)
+{
+   struct drm_plane_state *plane_state;
+   struct drm_plane_helper_funcs *plane_funcs;
+   struct drm_crtc_helper_funcs *crtc_funcs;
+   struct drm_plane *plane = crtc->primary;
+   int ret;
+
+   if (plane->funcs->atomic_duplicate_state)
+   plane_state = plane->funcs->atomic_duplicate_state(plane);
+   else if (plane->state)
+   plane_state = kmemdup(plane->state, sizeof(*plane_state),
+ GFP_KERNEL);
+   else
+   plane_state = kzalloc(sizeof(*plane_state), GFP_KERNEL);
+   if (!plane_state)
+   return -ENOMEM;
+
+   plane_state->crtc = crtc;
+   plane_state->fb = crtc->primary->fb;
+   plane_state->crtc_x = 0;
+   plane_state->crtc_y = 0;
+   plane_state->crtc_h = crtc->mode.hdisplay;
+   plane_state->crtc_w = crtc->mode.vdisplay;
+   plane_state->src_x = x << 16;
+   plane_state->src_y = y << 16;
+   plane_state->src_h = crtc->mode.hdisplay << 16;
+   plane_state->src_w = crtc->mode.hdisplay << 16;
+
+   plane_funcs = plane->helper_private;
+
+   if (plane_funcs->atomic_check) {
+   ret = plane_funcs->atomic_check(plane, plane_state);
+   if (ret)
+   goto fail;
+   }
+
+  

[PATCH 10/19] drm/plane-helper: transitional atomic plane helpers

[Daniel Vetter]

Converting a driver to the atomic interface can be a daunting
undertaking. One of the prerequisites is to have full universal planes
support.

To make that transition a bit easier this pathc provides plane helpers
which use the new atomic helper callbacks just only for the plane
changes. This way the plane update functionality can be tested without
being forced to convert everything at once.

Of course a real atomic update capable driver will implement the
all plane properties through the atomic interface, so these helpers
are mostly transitional. But they can be used to enable proper
universal plane support, especially once the crtc helpers have also
been adapted.

v2: Use ->atomic_duplicate_state if available.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_plane_helper.c | 181 -
 1 file changed, 180 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 827ec1a3040b..7befbf017afe 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 

 #define SUBPIXEL_MASK 0x

@@ -369,3 +369,182 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
return drm_crtc_init_with_planes(dev, crtc, primary, NULL, funcs);
 }
 EXPORT_SYMBOL(drm_crtc_init);
+
+/**
+ * drm_primary_helper_update() - Helper for primary plane update
+ * @plane: plane object to update
+ * @crtc: owning CRTC of owning plane
+ * @fb: framebuffer to flip onto plane
+ * @crtc_x: x offset of primary plane on crtc
+ * @crtc_y: y offset of primary plane on crtc
+ * @crtc_w: width of primary plane rectangle on crtc
+ * @crtc_h: height of primary plane rectangle on crtc
+ * @src_x: x offset of @fb for panning
+ * @src_y: y offset of @fb for panning
+ * @src_w: width of source rectangle in @fb
+ * @src_h: height of source rectangle in @fb
+ *
+ * Provides a default plane update handler using the atomic plane update
+ * functions. It is fully left to the driver to check plane constraints and
+ * handle corner-cases like a fully occluded or otherwise invisible plane.
+ *
+ * This is useful for piecewise transitioning of a driver to the atomic 
helpers.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
+ */
+int drm_plane_helper_update(struct drm_plane *plane, struct drm_crtc *crtc,
+   struct drm_framebuffer *fb,
+   int crtc_x, int crtc_y,
+   unsigned int crtc_w, unsigned int crtc_h,
+   uint32_t src_x, uint32_t src_y,
+   uint32_t src_w, uint32_t src_h)
+{
+   struct drm_plane_state *plane_state;
+   struct drm_plane_helper_funcs *plane_funcs;
+   struct drm_crtc_helper_funcs *crtc_funcs;
+   int ret;
+
+   if (plane->funcs->atomic_duplicate_state)
+   plane_state = plane->funcs->atomic_duplicate_state(plane);
+   else if (plane->state)
+   plane_state = kmemdup(plane->state, sizeof(*plane_state),
+ GFP_KERNEL);
+   else
+   plane_state = kzalloc(sizeof(*plane_state), GFP_KERNEL);
+   if (!plane_state)
+   return -ENOMEM;
+
+   plane_state->crtc = crtc;
+   plane_state->fb = fb;
+   plane_state->crtc_x = crtc_x;
+   plane_state->crtc_y = crtc_y;
+   plane_state->crtc_h = crtc_h;
+   plane_state->crtc_w = crtc_w;
+   plane_state->src_x = src_x;
+   plane_state->src_y = src_y;
+   plane_state->src_h = src_h;
+   plane_state->src_w = src_w;
+
+   plane_funcs = plane->helper_private;
+
+   if (plane_funcs->atomic_check) {
+   ret = plane_funcs->atomic_check(plane, plane_state);
+   if (ret)
+   goto fail;
+   }
+
+   if (plane_funcs->prepare_fb) {
+   ret = plane_funcs->prepare_fb(plane, fb);
+   if (ret)
+   goto fail;
+   }
+
+   /* Point of no return, commit sw state. */
+   swap(plane->state, plane_state);
+   fb = plane_state->fb;
+
+   crtc_funcs = crtc->helper_private;
+
+   if (crtc_funcs && crtc_funcs->atomic_begin)
+   crtc_funcs->atomic_begin(crtc);
+
+   plane_funcs->atomic_update(plane);
+
+   if (crtc_funcs && crtc_funcs->atomic_flush)
+   crtc_funcs->atomic_flush(crtc);
+
+   /* There's no way to figure out whether the crtc is running. */
+   ret = drm_crtc_vblank_get(crtc);
+   if (ret == 0) {
+   drm_crtc_vblank_wait(crtc);
+   drm_crtc_vblank_put(crtc);
+   }
+
+   if (plane_funcs->cleanup_fb && fb)
+   plane_funcs->cleanup_fb(plane, fb);
+fail:
+   kfree(plane_state);
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_plane_helper_update);
+
+/**
+ * drm_primary_helper_disable() - Helper for primary plane disable

[PATCH 09/19] drm/i915: Use generic vblank wait

[Daniel Vetter]

This has the upside that it will no longer steal interrupts from the
interrutp handler on pre-g4x. Furthermore this will now scream properly
on all platforms if we don't have hw counters enabled.

Not yet tested.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_display.c | 41 +---
 1 file changed, 1 insertion(+), 40 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 99eb7cad62a8..d139970023ac 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -891,17 +891,6 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct 
drm_i915_private *dev_priv,
return intel_crtc->config.cpu_transcoder;
 }

-static void g4x_wait_for_vblank(struct drm_device *dev, int pipe)
-{
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 frame, frame_reg = PIPE_FRMCOUNT_GM45(pipe);
-
-   frame = I915_READ(frame_reg);
-
-   if (wait_for(I915_READ_NOTRACE(frame_reg) != frame, 50))
-   WARN(1, "vblank wait timed out\n");
-}
-
 /**
  * intel_wait_for_vblank - wait for vblank on a given pipe
  * @dev: drm device
@@ -912,35 +901,7 @@ static void g4x_wait_for_vblank(struct drm_device *dev, 
int pipe)
  */
 void intel_wait_for_vblank(struct drm_device *dev, int pipe)
 {
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   int pipestat_reg = PIPESTAT(pipe);
-
-   if (IS_G4X(dev) || INTEL_INFO(dev)->gen >= 5) {
-   g4x_wait_for_vblank(dev, pipe);
-   return;
-   }
-
-   /* Clear existing vblank status. Note this will clear any other
-* sticky status fields as well.
-*
-* This races with i915_driver_irq_handler() with the result
-* that either function could miss a vblank event.  Here it is not
-* fatal, as we will either wait upon the next vblank interrupt or
-* timeout.  Generally speaking intel_wait_for_vblank() is only
-* called during modeset at which time the GPU should be idle and
-* should *not* be performing page flips and thus not waiting on
-* vblanks...
-* Currently, the result of us stealing a vblank from the irq
-* handler is that a single frame will be skipped during swapbuffers.
-*/
-   I915_WRITE(pipestat_reg,
-  I915_READ(pipestat_reg) | PIPE_VBLANK_INTERRUPT_STATUS);
-
-   /* Wait for vblank interrupt bit to set */
-   if (wait_for(I915_READ(pipestat_reg) &
-PIPE_VBLANK_INTERRUPT_STATUS,
-50))
-   DRM_DEBUG_KMS("vblank wait timed out\n");
+   drm_vblank_wait(dev, pipe);
 }

 static bool pipe_dsl_stopped(struct drm_device *dev, enum pipe pipe)
-- 
2.0.1

[PATCH 08/19] drm/irq: Implement a generic vblank_wait function

[Daniel Vetter]

As usual in both a crtc index and a struct drm_crtc * version.

The function assumes that no one drivers their display below 10Hz, and
it will complain if the vblank wait takes longer than that.

v2: Also check dev->max_vblank_counter since some drivers register a
fake get_vblank_counter function.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c | 45 +
 include/drm/drmP.h|  2 ++
 2 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0de123afdb34..76024fdde452 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -999,6 +999,51 @@ void drm_crtc_vblank_put(struct drm_crtc *crtc)
 EXPORT_SYMBOL(drm_crtc_vblank_put);

 /**
+ * drm_vblank_wait - wait for one vblank
+ * @dev: DRM device
+ * @crtc: crtc index
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_vblank_wait(struct drm_device *dev, int crtc)
+{
+   int ret;
+   u32 last;
+
+   ret = drm_vblank_get(dev, crtc);
+   if (WARN_ON(ret))
+   return;
+
+   last = drm_vblank_count(dev, crtc);
+
+#define C (last != drm_vblank_count(dev, crtc))
+   ret = wait_event_timeout(dev->vblank[crtc].queue,
+C, msecs_to_jiffies(100));
+
+   WARN_ON(ret == 0);
+#undef C
+
+   drm_vblank_put(dev, crtc);
+}
+EXPORT_SYMBOL(drm_vblank_wait);
+
+/**
+ * drm_crtc_vblank_wait - wait for one vblank
+ * @crtc: DRM crtc
+ *
+ * This waits for one vblank to pass on @crtc, using the irq driver interfaces.
+ * It is a failure to call this when the vblank irq for @crtc is disable, e.g.
+ * due to lack of driver support or because the crtc is off.
+ */
+void drm_crtc_vblank_wait(struct drm_crtc *crtc)
+{
+   drm_vblank_wait(crtc->dev, drm_crtc_index(crtc));
+}
+EXPORT_SYMBOL(drm_crtc_vblank_wait);
+
+/**
  * drm_vblank_off - disable vblank events on a CRTC
  * @dev: DRM device
  * @crtc: CRTC in question
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 06a673894c47..f72e5ef5f7b0 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1355,6 +1355,8 @@ extern int drm_vblank_get(struct drm_device *dev, int 
crtc);
 extern void drm_vblank_put(struct drm_device *dev, int crtc);
 extern int drm_crtc_vblank_get(struct drm_crtc *crtc);
 extern void drm_crtc_vblank_put(struct drm_crtc *crtc);
+extern void drm_vblank_wait(struct drm_device *dev, int crtc);
+extern void drm_crtc_vblank_wait(struct drm_crtc *crtc);
 extern void drm_vblank_off(struct drm_device *dev, int crtc);
 extern void drm_vblank_on(struct drm_device *dev, int crtc);
 extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
-- 
2.0.1

[PATCH 07/19] drm: Add drm_crtc_vblank_waitqueue()

[Daniel Vetter]

From: Ville Syrj?l? 

Add a small static inline helper to grab the vblank wait queue based on
the drm_crtc.

This is useful for drivers to do internal vblank waits using
wait_event() & co.

v2: Pimp commit message (Daniel)
Add kernel doc (Daniel)

Suggested-by: Daniel Vetter 
Signed-off-by: Ville Syrj?l? 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/drm.tmpl |  1 +
 include/drm/drmP.h | 11 +++
 2 files changed, 12 insertions(+)

diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 1d3756d3176c..972759489376 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -3400,6 +3400,7 @@ void (*disable_vblank) (struct drm_device *dev, int 
crtc);
 
   Vertical Blanking and Interrupt Handling Functions 
Reference
 !Edrivers/gpu/drm/drm_irq.c
+!Iinclude/drm/drmP.h drm_crtc_vblank_waitqueue
 
   

diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9b6a445f8602..06a673894c47 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1372,6 +1372,17 @@ extern int drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
 extern void drm_calc_timestamping_constants(struct drm_crtc *crtc,
const struct drm_display_mode 
*mode);

+/**
+ * drm_crtc_vblank_waitqueue - get vblank waitqueue for the CRTC
+ * @crtc: which CRTC's vblank waitqueue to retrieve
+ *
+ * This function returns a pointer to the vblank waitqueue for the CRTC.
+ * Drivers can use this to implement vblank waits using wait_event() & co.
+ */
+static inline wait_queue_head_t *drm_crtc_vblank_waitqueue(struct drm_crtc 
*crtc)
+{
+   return >dev->vblank[drm_crtc_index(crtc)].queue;
+}

 /* Modesetting support */
 extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
-- 
2.0.1

[PATCH 06/19] drm: Add atomic/plane helpers

[Daniel Vetter]

This is the first cut of atomic helper code. As-is it's only useful to
implement a pure atomic interface for plane updates.

Later patches will integrate this with the crtc helpers so that full
atomic updates are possible. We also need a pile of helpers to aid
drivers in transitioning from the legacy world to the shiny new atomic
age.

Finally we need helpers to implement legacy ioctls on top of the
atomic interface.

The design of the helpers is fairly simple, but has a unfortunate
large interface:
- We have ->atomic_check callbacks for crtcs and planes. The idea is
  that connectors don't need any checking, and if they do they can
  adjust the relevant crtc driver-private state. So no connector hooks
  should be needed. Also the crtc helpers integration will do the
  ->best_encoder checks, so no need for that.

- Framebuffer pinning needs to be done before we can commit to the hw
  state. This is especially important for async updates where we must
  pin all buffers before returning to userspace, so that really only
  hw failures can happen in the asynchronous worker.

  Hence we add ->prepare_fb and ->cleanup_fb hooks for this resources
  management.

- The actual atomic plane commit can't fail (except hw woes), so has
  void return type. It has three stages:
  1. Prepare all affected crtcs with crtc->atomic_begin. Drivers can
  use this to unset the GO bit or similar latches to prevent plane
  updates.
  2. Update plane state by looping over all changed planes and calling
  plane->atomic_update. Presuming the hardware is sane and has GO bits
  drivers can simply bash the state into the hardware in this
  function. Other drivers might use this to precompute hw state for
  the final step.
  3. Finally latch the update for the next vblank with
  crtc->atomic_flush. Note that this function doesn't need to wait for
  the vblank to happen even for the synchronous case.

v2: Clear drm__state->state to NULL when swapping in state.

v3: Add TODO that we don't short-circuit plane updates for now. Likely
no one will care.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/Makefile|   2 +-
 drivers/gpu/drm/drm_atomic_helper.c | 349 
 include/drm/drm_atomic_helper.h |  44 +
 include/drm/drm_crtc.h  |   5 +
 include/drm/drm_crtc_helper.h   |   6 +
 include/drm/drm_plane_helper.h  |  30 
 6 files changed, 435 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_atomic_helper.c
 create mode 100644 include/drm/drm_atomic_helper.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 82e922c02c6d..aae92c684f95 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -25,7 +25,7 @@ drm-$(CONFIG_OF) += drm_of.o
 drm-usb-y   := drm_usb.o

 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
-   drm_plane_helper.o drm_dp_mst_topology.o
+   drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o
 drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o
 drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o
 drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
new file mode 100644
index ..71e7025068f7
--- /dev/null
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -0,0 +1,349 @@
+/*
+ * Copyright (C) 2014 Red Hat
+ * Copyright (C) 2014 Intel Corp.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Rob Clark 
+ * Daniel Vetter 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+static void
+drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
+   struct drm_plane_state *plane_state,
+   struct drm_plane *plane)
+{
+   struct drm_crtc_state *crtc_state;
+
+   /*
+* TODO: For now we don't 

[PATCH 05/19] drm: Global atomic state handling

[Daniel Vetter]

Some differences compared to Rob's patches again:
- Dropped the committed and checked booleans. Checking will be
  internally enforced by always calling ->atomic_check before
  ->atomic_commit. And async handling needs to be solved differently
  because the current scheme completely side-steps ww mutex deadlock
  avoidance (and so either reinvents a new deadlock avoidance wheel or
  like the current code just deadlocks).

- State for connectors needed to be added, since now they have a
  full-blown drm_connector_state (so that drivers have something to
  attach their own stuff to).

- Refcounting is gone. I plane to solve async updates differently,
  since the lock-passing scheme doesn't cut it (since it abuses ww
  mutexes). Essentially what we need for async is a simple ownership
  transfer from the caller to the driver. That doesn't need full-blown
  refcounting.

- The acquire ctx is a pointer. Real atomic callers should have that
  on their stack, legacy entry points need to put the right one
  (obtained by drm_modeset_legacy_acuire_ctx) in there.

- I've dropped all hooks except check/commit. All the begin/end
  handling is done by core functions and is the same.

- commit/check are just thin wrappers that ensure that ->check is
  always called.

- To help out with locking in the legacy implementations I've added a
  helper to just grab all locks in the backoff case.

v2: Add notices that check/commit can fail with EDEADLK.

v3:
- More consistent naming for state_alloc.
- Add state_clear which is needed for backoff and retry.

v4: Planes/connectors can switch between crtcs, and we need to be
careful that we grab the state (and locks) for both the old and new
crtc. Improve the interface functions to ensure this.

v5: Add functions to grab affected connectors for a crtc and to recompute
the crtc->enable state. This is useful for both helper and atomic ioctl
code when e.g. removing a connector.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/Makefile |   2 +-
 drivers/gpu/drm/drm_atomic.c | 529 +++
 include/drm/drm_atomic.h |  63 ++
 include/drm/drm_crtc.h   |  23 ++
 4 files changed, 616 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/drm_atomic.c
 create mode 100644 include/drm/drm_atomic.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 61d9e9c6bc10..82e922c02c6d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
-   drm_modeset_lock.o
+   drm_modeset_lock.o drm_atomic.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o
 drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
new file mode 100644
index ..29e77fe24e06
--- /dev/null
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -0,0 +1,529 @@
+/*
+ * Copyright (C) 2014 Red Hat
+ * Copyright (C) 2014 Intel Corp.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Rob Clark 
+ * Daniel Vetter 
+ */
+
+
+#include 
+#include 
+#include 
+
+static void kfree_state(struct drm_atomic_state *state)
+{
+   kfree(state->connectors);
+   kfree(state->connector_states);
+   kfree(state->crtcs);
+   kfree(state->crtc_states);
+   kfree(state->planes);
+   kfree(state->plane_states);
+   kfree(state);
+}
+
+/**
+ * drm_atomic_state_alloc - allocate atomic state
+ * @dev DRM device
+ *
+ * This allocates an empty atomic state to track updates.
+ */
+struct drm_atomic_state *
+drm_atomic_state_alloc(struct drm_device *dev)
+{
+   struct drm_atomic_state *state;
+
+   state = kzalloc(sizeof(*state), 

[PATCH 04/19] drm: Handle legacy per-crtc locking with full acquire ctx

[Daniel Vetter]

So drivers using the atomic interfaces expect that they can acquire
additional locks internal to the driver as-needed. Examples would be
locks to protect shared state like shared display PLLs.

Unfortunately the legacy ioctls assume that all locking is fully done
by the drm core. Now for those paths which grab all locks we already
have to keep around an acquire context in dev->mode_config. Helper
functions that implement legacy interfaces in terms of atomic support
can therefore grab this acquire contexts and reuse it.

The only interfaces left are the cursor and pageflip ioctls. So add
functions to grab the crtc lock these need using an acquire context
and preserve it for atomic drivers to reuse.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c |  8 ++--
 drivers/gpu/drm/drm_modeset_lock.c | 86 ++
 include/drm/drm_crtc.h |  6 +++
 include/drm/drm_modeset_lock.h |  5 +++
 4 files changed, 101 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index acb3b3121f67..e33aa3a3a8a5 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2714,7 +2714,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
if (crtc->cursor)
return drm_mode_cursor_universal(crtc, req, file_priv);

-   drm_modeset_lock(>mutex, NULL);
+   drm_modeset_lock_crtc(crtc);
if (req->flags & DRM_MODE_CURSOR_BO) {
if (!crtc->funcs->cursor_set && !crtc->funcs->cursor_set2) {
ret = -ENXIO;
@@ -2738,7 +2738,7 @@ static int drm_mode_cursor_common(struct drm_device *dev,
}
}
 out:
-   drm_modeset_unlock(>mutex);
+   drm_modeset_unlock_crtc(crtc);

return ret;

@@ -4474,7 +4474,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
if (!crtc)
return -ENOENT;

-   drm_modeset_lock(>mutex, NULL);
+   drm_modeset_lock_crtc(crtc);
if (crtc->primary->fb == NULL) {
/* The framebuffer is currently unbound, presumably
 * due to a hotplug event, that userspace has not
@@ -4558,7 +4558,7 @@ out:
drm_framebuffer_unreference(fb);
if (old_fb)
drm_framebuffer_unreference(old_fb);
-   drm_modeset_unlock(>mutex);
+   drm_modeset_unlock_crtc(crtc);

return ret;
 }
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index 73e6534fd0aa..412b396af740 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -130,6 +130,90 @@ void drm_modeset_unlock_all(struct drm_device *dev)
 EXPORT_SYMBOL(drm_modeset_unlock_all);

 /**
+ * drm_modeset_lock_crtc - lock crtc with hidden acquire ctx
+ * @crtc: drm crtc
+ *
+ * This function locks the given crtc using a hidden acquire context. This is
+ * necessary so that drivers internally using the atomic interfaces can grab
+ * furether locks with the lock acquire context.
+ */
+void drm_modeset_lock_crtc(struct drm_crtc *crtc)
+{
+   struct drm_modeset_acquire_ctx *ctx;
+   int ret;
+
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+   if (WARN_ON(!ctx))
+   return;
+
+   drm_modeset_acquire_init(ctx, 0);
+
+retry:
+   ret = drm_modeset_lock(>mutex, ctx);
+   if (ret)
+   goto fail;
+
+   WARN_ON(crtc->acquire_ctx);
+
+   /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_all():
+*/
+   crtc->acquire_ctx = ctx;
+
+   return;
+
+fail:
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff(ctx);
+   goto retry;
+   }
+}
+EXPORT_SYMBOL(drm_modeset_lock_crtc);
+
+/**
+ * drm_modeset_legacy_acquire_ctx - find acquire ctx for legacy ioctls
+ * crtc: drm crtc
+ *
+ * Legacy ioctl operations like cursor updates or page flips only have per-crtc
+ * locking, and store the acquire ctx in the corresponding crtc. All other
+ * legacy operations take all locks and use a global acquire context. This
+ * function grabs the right one.
+ */
+struct drm_modeset_acquire_ctx *
+drm_modeset_legacy_acquire_ctx(struct drm_crtc *crtc)
+{
+   if (crtc->acquire_ctx)
+   return crtc->acquire_ctx;
+
+   WARN_ON(!crtc->dev->mode_config.acquire_ctx);
+
+   return crtc->dev->mode_config.acquire_ctx;
+}
+EXPORT_SYMBOL(drm_modeset_legacy_acquire_ctx);
+
+/**
+ * drm_modeset_unlock_crtc - drop all modeset locks
+ * @crtc: drm crtc
+ *
+ * This drops the crtc lock acquire with drm_modeset_lock_crtc() and all other
+ * locks acquired through the hidden context.
+ */
+void drm_modeset_unlock_crtc(struct drm_crtc *crtc)
+{
+   struct drm_modeset_acquire_ctx *ctx = crtc->acquire_ctx;
+
+   if (WARN_ON(!ctx))
+   return;
+
+   crtc->acquire_ctx = NULL;
+   drm_modeset_drop_locks(ctx);
+   

[PATCH 03/19] drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]

[Daniel Vetter]

Somehow we've forgotten about this little bit of OCD.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 95 --
 drivers/gpu/drm/drm_modeset_lock.c | 95 ++
 include/drm/drm_crtc.h |  4 --
 include/drm/drm_modeset_lock.h |  5 ++
 4 files changed, 100 insertions(+), 99 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index fdea713767b4..acb3b3121f67 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -45,101 +45,6 @@ static struct drm_framebuffer 
*add_framebuffer_internal(struct drm_device *dev,
struct drm_mode_fb_cmd2 
*r,
struct drm_file 
*file_priv);

-/**
- * drm_modeset_lock_all - take all modeset locks
- * @dev: drm device
- *
- * This function takes all modeset locks, suitable where a more fine-grained
- * scheme isn't (yet) implemented. Locks must be dropped with
- * drm_modeset_unlock_all.
- */
-void drm_modeset_lock_all(struct drm_device *dev)
-{
-   struct drm_mode_config *config = >mode_config;
-   struct drm_modeset_acquire_ctx *ctx;
-   int ret;
-
-   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
-   if (WARN_ON(!ctx))
-   return;
-
-   mutex_lock(>mutex);
-
-   drm_modeset_acquire_init(ctx, 0);
-
-retry:
-   ret = drm_modeset_lock(>connection_mutex, ctx);
-   if (ret)
-   goto fail;
-   ret = drm_modeset_lock_all_crtcs(dev, ctx);
-   if (ret)
-   goto fail;
-
-   WARN_ON(config->acquire_ctx);
-
-   /* now we hold the locks, so now that it is safe, stash the
-* ctx for drm_modeset_unlock_all():
-*/
-   config->acquire_ctx = ctx;
-
-   drm_warn_on_modeset_not_all_locked(dev);
-
-   return;
-
-fail:
-   if (ret == -EDEADLK) {
-   drm_modeset_backoff(ctx);
-   goto retry;
-   }
-}
-EXPORT_SYMBOL(drm_modeset_lock_all);
-
-/**
- * drm_modeset_unlock_all - drop all modeset locks
- * @dev: device
- *
- * This function drop all modeset locks taken by drm_modeset_lock_all.
- */
-void drm_modeset_unlock_all(struct drm_device *dev)
-{
-   struct drm_mode_config *config = >mode_config;
-   struct drm_modeset_acquire_ctx *ctx = config->acquire_ctx;
-
-   if (WARN_ON(!ctx))
-   return;
-
-   config->acquire_ctx = NULL;
-   drm_modeset_drop_locks(ctx);
-   drm_modeset_acquire_fini(ctx);
-
-   kfree(ctx);
-
-   mutex_unlock(>mode_config.mutex);
-}
-EXPORT_SYMBOL(drm_modeset_unlock_all);
-
-/**
- * drm_warn_on_modeset_not_all_locked - check that all modeset locks are locked
- * @dev: device
- *
- * Useful as a debug assert.
- */
-void drm_warn_on_modeset_not_all_locked(struct drm_device *dev)
-{
-   struct drm_crtc *crtc;
-
-   /* Locking is currently fubar in the panic handler. */
-   if (oops_in_progress)
-   return;
-
-   list_for_each_entry(crtc, >mode_config.crtc_list, head)
-   WARN_ON(!drm_modeset_is_locked(>mutex));
-
-   WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex));
-   WARN_ON(!mutex_is_locked(>mode_config.mutex));
-}
-EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
-
 /* Avoid boilerplate.  I'm tired of typing. */
 #define DRM_ENUM_NAME_FN(fnname, list) \
const char *fnname(int val) \
diff --git a/drivers/gpu/drm/drm_modeset_lock.c 
b/drivers/gpu/drm/drm_modeset_lock.c
index 0dc57d5ecd10..73e6534fd0aa 100644
--- a/drivers/gpu/drm/drm_modeset_lock.c
+++ b/drivers/gpu/drm/drm_modeset_lock.c
@@ -57,6 +57,101 @@


 /**
+ * drm_modeset_lock_all - take all modeset locks
+ * @dev: drm device
+ *
+ * This function takes all modeset locks, suitable where a more fine-grained
+ * scheme isn't (yet) implemented. Locks must be dropped with
+ * drm_modeset_unlock_all.
+ */
+void drm_modeset_lock_all(struct drm_device *dev)
+{
+   struct drm_mode_config *config = >mode_config;
+   struct drm_modeset_acquire_ctx *ctx;
+   int ret;
+
+   ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
+   if (WARN_ON(!ctx))
+   return;
+
+   mutex_lock(>mutex);
+
+   drm_modeset_acquire_init(ctx, 0);
+
+retry:
+   ret = drm_modeset_lock(>connection_mutex, ctx);
+   if (ret)
+   goto fail;
+   ret = drm_modeset_lock_all_crtcs(dev, ctx);
+   if (ret)
+   goto fail;
+
+   WARN_ON(config->acquire_ctx);
+
+   /* now we hold the locks, so now that it is safe, stash the
+* ctx for drm_modeset_unlock_all():
+*/
+   config->acquire_ctx = ctx;
+
+   drm_warn_on_modeset_not_all_locked(dev);
+
+   return;
+
+fail:
+   if (ret == -EDEADLK) {
+   drm_modeset_backoff(ctx);
+   goto retry;
+   }
+}

[PATCH 02/19] drm: Add drm_plane/connector_index

[Daniel Vetter]

In the atomic state we'll have an array of states for crtcs, planes
and connectors and need to be able to at them by their index. We
already have a drm_crtc_index function so add the missing ones for
planes and connectors.

If it later on turns out that the list walking is too expensive we can
add the index to the relevant modeset objects.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c | 46 ++
 include/drm/drm_crtc.h |  3 +++
 2 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0f934a58702d..fdea713767b4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -937,6 +937,29 @@ void drm_connector_cleanup(struct drm_connector *connector)
 EXPORT_SYMBOL(drm_connector_cleanup);

 /**
+ * drm_plane_index - find the index of a registered CRTC
+ * @plane: CRTC to find index for
+ *
+ * Given a registered CRTC, return the index of that CRTC within a DRM
+ * device's list of CRTCs.
+ */
+unsigned int drm_connector_index(struct drm_connector *connector)
+{
+   unsigned int index = 0;
+   struct drm_connector *tmp;
+
+   list_for_each_entry(tmp, >dev->mode_config.connector_list, 
head) {
+   if (tmp == connector)
+   return index;
+
+   index++;
+   }
+
+   BUG();
+}
+EXPORT_SYMBOL(drm_connector_index);
+
+/**
  * drm_connector_register - register a connector
  * @connector: the connector to register
  *
@@ -1239,6 +1262,29 @@ void drm_plane_cleanup(struct drm_plane *plane)
 EXPORT_SYMBOL(drm_plane_cleanup);

 /**
+ * drm_plane_index - find the index of a registered CRTC
+ * @plane: CRTC to find index for
+ *
+ * Given a registered CRTC, return the index of that CRTC within a DRM
+ * device's list of CRTCs.
+ */
+unsigned int drm_plane_index(struct drm_plane *plane)
+{
+   unsigned int index = 0;
+   struct drm_plane *tmp;
+
+   list_for_each_entry(tmp, >dev->mode_config.plane_list, head) {
+   if (tmp == plane)
+   return index;
+
+   index++;
+   }
+
+   BUG();
+}
+EXPORT_SYMBOL(drm_plane_index);
+
+/**
  * drm_plane_force_disable - Forcibly disable a plane
  * @plane: plane to disable
  *
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a1a8c694e765..d6546fd1e00c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -680,6 +680,7 @@ struct drm_plane_state {
/* Source values are 16.16 fixed point */
uint32_t src_x, src_y;
uint32_t src_h, src_w;
+
struct drm_atomic_state *state;
 };

@@ -1052,6 +1053,7 @@ int drm_connector_register(struct drm_connector 
*connector);
 void drm_connector_unregister(struct drm_connector *connector);

 extern void drm_connector_cleanup(struct drm_connector *connector);
+extern unsigned int drm_connector_index(struct drm_connector *crtc);
 /* helper to unplug all connectors from sysfs for device */
 extern void drm_connector_unplug_all(struct drm_device *dev);

@@ -1091,6 +1093,7 @@ extern int drm_plane_init(struct drm_device *dev,
  const uint32_t *formats, uint32_t format_count,
  bool is_primary);
 extern void drm_plane_cleanup(struct drm_plane *plane);
+extern unsigned int drm_plane_index(struct drm_plane *crtc);
 extern void drm_plane_force_disable(struct drm_plane *plane);
 extern int drm_crtc_check_viewport(const struct drm_crtc *crtc,
   int x, int y,
-- 
2.0.1

[PATCH 01/19] drm: Add atomic driver interface definitions for objects

[Daniel Vetter]

Heavily based upon Rob Clark's atomic series.
- Dropped the connctor state from the crtc state, instead opting for a
  full-blown connector state. The only thing it has is the desired
  crtc, but drivers which have connector properties have now a
  data-structure to subclass.

- Rename create_state to duplicate_state. Especially for legacy ioctls
  we want updates on top of existing state, so we need a way to get at
  the current state. We need to be careful to clear the backpointers
  correctly though. We need to be careful though with the ->state
  backpointer we need while constructing the atomic state.

- Drop property values. Drivers with properties simply need to
  subclass the datastructures and track the decoded values in there. I
  also think that common properties (like rotation) should be decoded
  and stored in the core structures.

- Create a new set of ->atomic_set_prop functions, for smoother
  transitions from legacy to atomic operations.

- Pass the ->atomic_set_prop ioctl the right structure to avoid
  chasing pointers in drivers.

- Drop temporary boolean state for now until we resurrect them with
  the helper functions.

- Drop invert_dimensions. For now we don't need any checking since
  that's done by the higher-level legacy ioctls. But even then we
  should also add rotation/flip tracking to the core drm_crtc_state,
  not just whether the dimensions are inverted.

- Track crtc state with an enable/disable. That's equivalent to
  mode_valid, but a bit clearer that it means the entire crtc.

The global interface will follow in subsequent patches.

v2: We need to allow drivers to somehow set up the initial state and
clear it on resume. So add a plane->reset callback for that. Helpers
will be provided with default behaviour for all these.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_crtc.c |   5 ++
 include/drm/drm_crtc.h | 149 +
 2 files changed, 154 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 805240b11229..0f934a58702d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4623,9 +4623,14 @@ out:
 void drm_mode_config_reset(struct drm_device *dev)
 {
struct drm_crtc *crtc;
+   struct drm_crtc *plane;
struct drm_encoder *encoder;
struct drm_connector *connector;

+   list_for_each_entry(plane, >mode_config.plane_list, head)
+   if (plane->funcs->reset)
+   plane->funcs->reset(plane);
+
list_for_each_entry(crtc, >mode_config.crtc_list, head)
if (crtc->funcs->reset)
crtc->funcs->reset(crtc);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f1105d0da059..a1a8c694e765 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -228,6 +228,25 @@ struct drm_encoder;
 struct drm_pending_vblank_event;
 struct drm_plane;
 struct drm_bridge;
+struct drm_atomic_state;
+
+/**
+ * drm_crtc_state - mutable crtc state
+ * @mode_valid: a valid mode has been set
+ * @set_config: needs modeset (crtc->set_config())
+ * @connectors_change: the connector-ids array has changed
+ * @mode: current mode timings
+ * @event: pending pageflip event
+ */
+struct drm_crtc_state {
+   bool enable: 1;
+
+   struct drm_display_mode mode;
+
+   struct drm_pending_vblank_event *event;
+
+   struct drm_atomic_state *state;
+};

 /**
  * drm_crtc_funcs - control CRTCs for a given device
@@ -291,6 +310,15 @@ struct drm_crtc_funcs {

int (*set_property)(struct drm_crtc *crtc,
struct drm_property *property, uint64_t val);
+
+   /* atomic update handling */
+   struct drm_crtc_state *(*atomic_duplicate_state)(struct drm_crtc *crtc);
+   void (*atomic_destroy_state)(struct drm_crtc *crtc,
+struct drm_crtc_state *cstate);
+   int (*atomic_set_property)(struct drm_crtc *crtc,
+  struct drm_crtc_state *state,
+  struct drm_property *property,
+  uint64_t val);
 };

 /**
@@ -375,8 +403,38 @@ struct drm_crtc {
void *helper_private;

struct drm_object_properties properties;
+
+   struct drm_crtc_state *state;
 };

+static inline struct drm_crtc_state *
+drm_crtc_duplicate_state(struct drm_crtc *crtc)
+{
+   if (crtc->funcs->atomic_duplicate_state)
+   return crtc->funcs->atomic_duplicate_state(crtc);
+   return kmemdup(crtc->state, sizeof(struct drm_crtc_state), GFP_KERNEL);
+}
+
+static inline void
+drm_crtc_destroy_state(struct drm_crtc *crtc,
+  struct drm_crtc_state *cstate)
+{
+   if (crtc->funcs->atomic_destroy_state)
+   crtc->funcs->atomic_destroy_state(crtc, cstate);
+   else
+   kfree(cstate);
+}
+
+
+/**
+ * drm_connector_state - mutable connector state
+ * @crtc: 

[PATCH 00/19] atomic, remixed

[Daniel Vetter]

Hi all,

So I've figured instead of just talking I should draw up my ideas for atomic
helpers and related stuff in some draft patches. Major differences compared to
Rob's series:

- The software side state update is done synchronously, at least when using the
  helper code. Drivers are free to do whatever they want, as usual. This has a
  bunch of nice upsides:

  + All the tricky locking dances can be abolished, and if the ordering and
synchronization is done correctly async worker threads don't need any
modeset state locking at all. I'm fairly sure that Rob's scheme won't blow
up, but I much prefer we don't need it at all.

  + In Rob's patches any atomic operation must wait for outstanding updates to
complete. Otherwise the software state isn't committed yet. With the
synchronous updates we can immediately proceed with the state construction
and verification and will only block right before applying the state update.
And even for that drivers can implement cancellation of the previous update.

This has the nice benefit that check-only operations (which compositors need
to do right after having completed the current frame to know how to render
the next one) can be done without blocking for completion of the previous
update.

- Internal interfaces for atomic updates don't need to go through properties,
  but can directly set the state. Drivers can always compare updates in their
  ->check hook later on, so we don't lose expressiveness in the interface. But
  the resulting code in the callers looks much better.

  In general I've ditched a lot of interfaces where drivers could overwrite
  default behaviour and boiled down the interface two state handling functions
  (duplicate+destroy), setting driver-private properties and check/commit.

- There is a clear helper separation between core code which should be used to
  use the atomic interface to drivers, and helper functions. Core never uses
  helper functions so that we can keep the clear separation we have in all other
  places in the kms api.

  There's a set of helpers sitting in-between to implement legacy interfaces on
  top of atomic. Those _only_ use the core atomic interfaces.

- I've added a new set of plane helpers. Mostly this was motivated to make the
  atomic helpers work on less stellar hardware where you can't just stream the
  state and then atomically commit with some GO bits. But those helpers should
  also be useful for more gradual transitions of drivers to the atomic
  interface. Since a requirement for atomic is to have universal plane support
  they can be used bare-bones just for that, without all the other atomic
  baggage (i.e. all the state tracking for crtcs/connectors).

- State tracking for connectors. i915 has piles of relevant connector
  properties, which we want to save/restore in atomic ops (e.g. hdmi metadata
  and stuff).

- fbdev panic locking is implemented with trylock instead of nolock.

- I've thought a bit about resume. See the proposed state handling for the
  default reset functions and the addition of a plane reset callback.

There's also a metric pile of stuff missing:

- It's completely untested (except for the parts touching currently used code)
  since I lack suitable hw. Converting i915 is just a bit too much of a pain for
  a quick w/e code draft ;-)

- I didn't add all the properties for things currently exposed through ioctl
  structures. Since the interface here doesn't force internal code to use
  properties for everything (which really makes things look much better) we
  don't have a need for that until we merge the actual atomic ioctl. So I left
  that out.

- I didn't write code for the fbdev helper to use atomic. The w/e ran out of
  time for that ...

- Kerneldoc is occasionally not updated or still missing.

Anyway I think this draft code is good enough to explain how I'd like to address
some of the concerns I have with the current atomic code. Comments, flames and
ideas highly welcome. And if anyone is insane enought to try this on real
hardware, that would certainly be interesting and I'm very much willing to help
out as much as possible ... i915 just really isn't suitable since it won't be
using the helpers, and all the other hw I have here doesn't support planes.

Cheers, Daniel

Daniel Vetter (18):
  drm: Add atomic driver interface definitions for objects
  drm: Add drm_plane/connector_index
  drm: Move modeset_lock_all helpers to drm_modeset_lock.[hc]
  drm: Handle legacy per-crtc locking with full acquire ctx
  drm: Global atomic state handling
  drm: Add atomic/plane helpers
  drm/irq: Implement a generic vblank_wait function
  drm/i915: Use generic vblank wait
  drm/plane-helper: transitional atomic plane helpers
  drm/crtc-helper: Transitional functions using atomic plane helpers
  drm: Atomic crtc/connector updates using crtc helper interfaces
  drm: Move ->old_fb from crtc to plane
  drm/atomic-helper: implementatations for legacy 

[PATCH] drm/radeon: adjust default radeon_vm_block_size v2

[Alex Deucher]

On Sat, Jul 26, 2014 at 9:34 AM, Christian K?nig
 wrote:
> Hey Alex,
>
> can you use this version instead of the one you already have in
> drm-next-3.17-wip? It depends on a change from drm-fixes-3.16, so you need
> to merge (or rebase) your -next branch to apply it.
>
> Apart from that I also have a couple of more VM changes for 3.17, but those
> need a merge with the latest 3.16 fixes as well.
>


Ok.  I'll drop the patch for now.  I'll send a pull with all the
additional patches that depend on fixes once Dave merges it.

Alex

> Thanks,
> Christian.
>
> Am 19.07.2014 um 13:55 schrieb Christian K?nig:
>
>> From: Christian K?nig 
>>
>> v2: rebase on vm_size scale change. Adjust vm_size default to 8,
>>  Better handle the default and smaller values.
>>
>> Signed-off-by: Christian K?nig 
>> ---
>>   drivers/gpu/drm/radeon/radeon_device.c | 14 +-
>>   drivers/gpu/drm/radeon/radeon_drv.c|  6 +++---
>>   2 files changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
>> b/drivers/gpu/drm/radeon/radeon_device.c
>> index a8537d7..38e13b0 100644
>> --- a/drivers/gpu/drm/radeon/radeon_device.c
>> +++ b/drivers/gpu/drm/radeon/radeon_device.c
>> @@ -1077,7 +1077,19 @@ static void radeon_check_arguments(struct
>> radeon_device *rdev)
>> /* defines number of bits in page table versus page directory,
>>  * a page is 4KB so we have 12 bits offset, minimum 9 bits in the
>>  * page table and the remaining bits are in the page directory */
>> -   if (radeon_vm_block_size < 9) {
>> +   if (radeon_vm_block_size == -1) {
>> +
>> +   /* Total bits covered by PD + PTs */
>> +   unsigned bits = ilog2(radeon_vm_size) + 17;
>> +
>> +   /* Make sure the PD is 4K in size up to 8GB address space.
>> +  Above that split equal between PD and PTs */
>> +   if (radeon_vm_size <= 8)
>> +   radeon_vm_block_size = bits - 9;
>> +   else
>> +   radeon_vm_block_size = (bits + 3) / 2;
>> +
>> +   } else if (radeon_vm_block_size < 9) {
>> dev_warn(rdev->dev, "VM page table size (%d) to small\n",
>>  radeon_vm_block_size);
>> radeon_vm_block_size = 9;
>> diff --git a/drivers/gpu/drm/radeon/radeon_drv.c
>> b/drivers/gpu/drm/radeon/radeon_drv.c
>> index e9e3610..59b74d2 100644
>> --- a/drivers/gpu/drm/radeon/radeon_drv.c
>> +++ b/drivers/gpu/drm/radeon/radeon_drv.c
>> @@ -173,8 +173,8 @@ int radeon_dpm = -1;
>>   int radeon_aspm = -1;
>>   int radeon_runtime_pm = -1;
>>   int radeon_hard_reset = 0;
>> -int radeon_vm_size = 4;
>> -int radeon_vm_block_size = 9;
>> +int radeon_vm_size = 8;
>> +int radeon_vm_block_size = -1;
>>   int radeon_deep_color = 0;
>> MODULE_PARM_DESC(no_wb, "Disable AGP writeback for scratch
>> registers");
>> @@ -246,7 +246,7 @@ module_param_named(hard_reset, radeon_hard_reset, int,
>> 0444);
>>   MODULE_PARM_DESC(vm_size, "VM address space size in gigabytes (default
>> 4GB)");
>>   module_param_named(vm_size, radeon_vm_size, int, 0444);
>>   -MODULE_PARM_DESC(vm_block_size, "VM page table size in bits (default
>> 9)");
>> +MODULE_PARM_DESC(vm_block_size, "VM page table size in bits (default
>> depending on vm_size)");
>>   module_param_named(vm_block_size, radeon_vm_block_size, int, 0444);
>> MODULE_PARM_DESC(deep_color, "Deep Color support (1 = enable, 0 =
>> disable (default))");
>
>