linux-next: manual merge of the drm-misc tree with Linus' tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the drm-misc tree got conflicts in:

  drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
  drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
  drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c

between commit:

  8fbf9d92a7bc ("drm/vmwgfx: Implement the cursor_set2 callback v2")

from Linus' tree and commit:

  d7955fcff889 ("drm/vmwgfx: Constify function pointer structs")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwellsfr at canb.auug.org.au

diff --cc drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index 78693a0a598c,2def684e61a4..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@@ -294,8 -294,8 +294,8 @@@ static int vmw_ldu_crtc_set_config(stru
return vmw_ldu_commit_list(dev_priv);
  }

- static struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
+ static const struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
 -  .cursor_set = vmw_du_crtc_cursor_set,
 +  .cursor_set2 = vmw_du_crtc_cursor_set2,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
.destroy = vmw_ldu_crtc_destroy,
diff --cc drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 7ba5a00b3b68,ecac70af032a..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@@ -530,8 -530,8 +530,8 @@@ out_no_fence
return ret;
  }

- static struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
+ static const struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
 -  .cursor_set = vmw_du_crtc_cursor_set,
 +  .cursor_set2 = vmw_du_crtc_cursor_set2,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
.destroy = vmw_sou_crtc_destroy,
diff --cc drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index 58c38e7723d8,87fc00af8d28..
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@@ -1040,8 -1040,8 +1040,8 @@@ out_finish
  /*
   *  Screen Target CRTC dispatch table
   */
- static struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
+ static const struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
 -  .cursor_set = vmw_du_crtc_cursor_set,
 +  .cursor_set2 = vmw_du_crtc_cursor_set2,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
.destroy = vmw_stdu_crtc_destroy,

[PATCH v10 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Heiko,

On 12/15/2015 08:06 AM, Heiko Stübner wrote:
> Hi Yakir,
>
> Am Montag, 7. Dezember 2015, 14:37:19 schrieb Yakir Yang:
>> The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
>> share the same IP, so a lot of parts can be re-used. I split the common
>> code into bridge directory, then rk3288 and exynos only need to keep
>> some platform code. Cause I can't find the exact IP name of exynos dp
>> controller, so I decide to name dp core driver with "analogix" which I
>> find in rk3288 eDP TRM
> so it looks like the hotplug works nicely now. I was able to test it
> sucessfully on both a Jerry and a Minnie device without needing to force
> hotplug :-) .
>
> As I needed to adapt some patches when applying the lastest ones, I think it
> would be good for a full send of the latest version as v11.

Got it, will send soon  ;)

> When going over the patches before sending, please also fix the indentation
> issues in analogix_dp_core.h - both newly added elements to analogix_dp_device
> use spaces between type and name, where the rest uses tabs.
> [This should of course be fixed in the patches adding these lines :-) ]

Done,

Thanks,
- Yakir

>
> Heiko
>
>
>

[PATCH v11 0/19] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi all,

   The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM

But  there are still three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
   dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
   between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
   register).

This series have been well tested on Rockchip platform with eDP panel on
Jerry Chromebook and Display Port Monitor on RK3288 board. Also I have
tested on Samsung Snow and Peach Pit Chromebooks, and thanks to Javier at 
Samsung
help to retest the whole series on Samsung Exynos5800 Peach Pi Chromebook,
glad to say that things works rightlly.

Thanks,
- Yakir


Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10:
- Add the ack from Rob Herring
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)
- Add the ack from Rob Herring
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9:
- Document more details for 'ports' property.
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)
- Modify the commit subject name. (Heiko)
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)
- Remove the specific address in the example node name. (Heiko)

Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)
- Simplify the commit message. (Kishon)

Changes in v6:
- Fix the Kconfig recursive dependency (Javier)
- Fix Peach Pit hpd property name error:
-   hpd-gpio = <&gpx2 6 0>;
+   hpd-gpios = <&gpx2 6 0>;

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).
- Correct the misspell in commit message. (Krzysztof)
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierr

[PATCH v11 01/19] drm: bridge: analogix/dp: split exynos dp driver to bridge directory

[Yakir Yang]

Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.

Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp_resume()"
"analogix_dp_detect()" and "analogix_dp_get_modes()"

The bind/unbind symbols is used for analogix platform driver to connect
with analogix_dp core driver. And the detect/get_modes is used for analogix
platform driver to init the connector.

They reason why connector need register in helper driver is rockchip drm
haven't implement the atomic API, but Exynos drm have implement it, so
there would need two different connector helper functions, that's why we
leave the connector register in helper driver.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11:
- Uses tabs to fix the indentation issues in analogix_dp_core.h (Heiko)

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix the Kconfig recursive dependency (Javier)

Changes in v5:
- Correct the check condition of gpio_is_valid when driver try to get
  the "hpd-gpios" DT propery. (Heiko)
- Move the platform attach callback in the front of core driver bridge
  attch function. Cause once platform failed at attach, core driver should
  still failed, so no need to init connector before platform attached 
(Krzysztof)
- Keep code style no changes with the previous exynos_dp_code.c in this
  patch, and update commit message about the new export symbol (Krzysztof)
- Gather the device type patch (v4 11/16) into this one. (Krzysztof)
- leave out the connector registration to analogix platform driver. (Thierry)

Changes in v4:
- Update "analogix,hpd-gpios" to "hpd-gpios" DT propery. (Rob)
- Rename "analogix_dp-exynos.c" file name to "exynos_dp.c" (Jingoo)
- Create a separate folder for analogix code in bridge/ (Archit)

Changes in v3:
- Move exynos's video_timing code to analogix_dp-exynos platform driver,
  add get_modes method to struct analogix_dp_plat_data. (Thierry)
- Rename some "samsung*" dts propery to "analogix*". (Heiko)

Changes in v2:
- Remove new copyright (Jingoo)
- Fix compiled failed due to analogix_dp_device misspell

 drivers/gpu/drm/bridge/Kconfig |2 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/analogix/Kconfig|3 +
 drivers/gpu/drm/bridge/analogix/Makefile   |1 +
 .../analogix/analogix_dp_core.c}   |  799 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  277 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 1263 
 .../analogix/analogix_dp_reg.h}|  258 ++--
 drivers/gpu/drm/exynos/Kconfig |3 +-
 drivers/gpu/drm/exynos/Makefile|2 +-
 drivers/gpu/drm/exynos/exynos_dp.c |  384 ++
 drivers/gpu/drm/exynos/exynos_dp_core.h|  282 -
 drivers/gpu/drm/exynos/exynos_dp_reg.c | 1263 
 include/drm/bridge/analogix_dp.h   |   41 +
 14 files changed, 2399 insertions(+), 2180 deletions(-)
 create mode 100644 drivers/gpu/drm/bridge/analogix/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/analogix/Makefile
 rename drivers/gpu/drm/{exynos/exynos_dp_core.c => 
bridge/analogix/analogix_dp_core.c} (50%)
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
 create mode 100644 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
 rename drivers/gpu/drm/{exynos/exynos_dp_reg.h => 
bridge/analogix/analogix_dp_reg.h} (64%)
 create mode 100644 drivers/gpu/drm/exynos/exynos_dp.c
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_core.h
 delete mode 100644 drivers/gpu/drm/exynos/exynos_dp_reg.c
 create mode 100644 include/drm/bridge/analogix_dp.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 27e2022..efd94e0 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -40,4 +40,6 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.

+source "drivers/gpu/drm/bridge/analogix/Kconfig"
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index f13c33d..ff821f4 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_DRM_DW_HDMI) += dw-hdmi.o
 obj-$(CONFIG_DRM_DW_HDMI_AHB_AUDIO) += dw-hdmi-ahb-audio.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANALOGIX_DP) += analogix/
diff --git a/drivers/gpu/drm/bridge/analogix/Kconfig 
b/drivers/gpu/drm/bridge/analogix/Kconfig
new file mode 100644
index 000..80f286f
--- /dev/null
+++ b/drivers/gpu/drm/bridge/analogix/Kconfig
@@ -0,0 +1,3 @@
+config DRM_ANALOGIX_DP
+   

[PATCH v11 02/19] drm: bridge: analogix/dp: fix some obvious code style

[Yakir Yang]

Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.

Signed-off-by: Yakir Yang 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Resequence this patch after analogix_dp driver have been split
  from exynos_dp code, and rephrase reasonable commit message, and
  remove some controversial style (Krzysztof)
-   analogix_dp_write_byte_to_dpcd(
-   dp, DP_TEST_RESPONSE,
+   analogix_dp_write_byte_to_dpcd(dp,
+   DP_TEST_RESPONSE,
DP_TEST_EDID_CHECKSUM_WRITE);

Changes in v4: None
Changes in v3: None
Changes in v2:
- Improved commit message more readable, and avoid using some
  uncommon style like bellow: (Joe Preches)
-  retval = exynos_dp_read_bytes_from_i2c(...
  ...);
+  retval =
+  exynos_dp_read_bytes_from_i2c(..);

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 129 ++---
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  72 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 124 ++--
 3 files changed, 163 insertions(+), 162 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index fb8bda8..4a05c2b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -61,7 +61,7 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)

while (analogix_dp_get_plug_in_status(dp) != 0) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
dev_err(dp->dev, "failed to get hpd plug status\n");
return -ETIMEDOUT;
}
@@ -98,8 +98,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)

/* Read Extension Flag, Number of 128-byte EDID extension blocks */
retval = analogix_dp_read_byte_from_i2c(dp, I2C_EDID_DEVICE_ADDR,
-   EDID_EXTENSION_FLAG,
-   &extend_block);
+   EDID_EXTENSION_FLAG,
+   &extend_block);
if (retval)
return retval;

@@ -107,7 +107,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
dev_dbg(dp->dev, "EDID data includes a single extension!\n");

/* Read EDID data */
-   retval = analogix_dp_read_bytes_from_i2c(dp, 
I2C_EDID_DEVICE_ADDR,
+   retval = analogix_dp_read_bytes_from_i2c(dp,
+   I2C_EDID_DEVICE_ADDR,
EDID_HEADER_PATTERN,
EDID_BLOCK_LENGTH,
&edid[EDID_HEADER_PATTERN]);
@@ -138,7 +139,7 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)
}

analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
-   &test_vector);
+   &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
DP_TEST_EDID_CHECKSUM,
@@ -152,10 +153,8 @@ static int analogix_dp_read_edid(struct analogix_dp_device 
*dp)

/* Read EDID data */
retval = analogix_dp_read_bytes_from_i2c(dp,
-   I2C_EDID_DEVICE_ADDR,
-   EDID_HEADER_PATTERN,
-   EDID_BLOCK_LENGTH,
-   &edid[EDID_HEADER_PATTERN]);
+   I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN,
+   EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]);
if (retval != 0) {
dev_err(dp->dev, "EDID Read failed!\n");
return -EIO;
@@ -166,16 +165,13 @@ static int analogix_dp_read_edid(struct 
analogix_dp_device *dp)
return -EIO;
}

-   analogix_dp_read_byte_from_dpcd(dp,
-   DP_TEST_REQUEST,
-   &test_vector);
+   analogix_dp_read_byte_from_dpcd(dp, DP_TEST_REQUEST,
+   &test_vector);
if (test_vector & DP_TEST_LINK_EDID_READ) {
analogix_dp_write_byte_to_dpcd(dp,
-   DP_TEST_EDID_CHECKSUM,
-

[Intel-gfx] [RFC libdrm] intel: Add support for softpin

[Song, Ruiling]

> -Original Message-
> From: Kristian Høgsberg [mailto:hoegsberg at gmail.com]
> Sent: Tuesday, December 15, 2015 4:09 AM
> To: Song, Ruiling ; krh at bitplanet.net; 
> Winiarski,
> Michal 
> Cc: intel-gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben
> Widawsky ; dri-devel at lists.freedesktop.org; Yang,
> Rong R 
> Subject: RE: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> 
> Kristian Høgsberg  writes:
> 
> > "Song, Ruiling"  writes:
> >
> >>> -Original Message-
> >>> From: hoegsberg at gmail.com [mailto:hoegsberg at gmail.com] On Behalf
> Of
> >>> Kristian H?gsberg
> >>> Sent: Monday, December 14, 2015 1:34 PM
> >>> To: Song, Ruiling 
> >>> Cc: Winiarski, Michal ; intel-
> >>> gfx at lists.freedesktop.org; mesa-dev at lists.freedesktop.org; Ben
> Widawsky
> >>> ; dri-devel at lists.freedesktop.org
> >>> Subject: Re: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> >>>
> >>> On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling 
> >>> wrote:
> >>> >> -Original Message-
> >>> >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On
> >>> Behalf
> >>> >> Of Micha? Winiarski
> >>> >> Sent: Wednesday, September 9, 2015 10:07 PM
> >>> >> To: intel-gfx at lists.freedesktop.org
> >>> >> Cc: Ben Widawsky ; dri-
> >>> devel at lists.freedesktop.org;
> >>> >> mesa-dev at lists.freedesktop.org
> >>> >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin
> >>> >>
> >>> >> Softpin allows userspace to take greater control of GPU virtual
> address
> >>> >> space and eliminates the need of relocations. It can also be used to
> >>> >> mirror addresses between GPU and CPU (shared virtual memory).
> >>> >> Calls to drm_intel_bo_emit_reloc are still required to build the list 
> >>> >> of
> >>> >> drm_i915_gem_exec_objects at exec time, but no entries in relocs
> are
> >>> >> created. Self-relocs don't make any sense for softpinned objects and
> can
> >>> >> indicate a programming errors, thus are forbidden. Softpinned
> objects
> >>> >> are marked by asterisk in debug dumps.
> >>> >>
> >>> >> Cc: Thomas Daniel 
> >>> >> Cc: Kristian Høgsberg 
> >>> >> Cc: Zou Nanhai 
> >>> >> Cc: Michel Thierry 
> >>> >> Cc: Ben Widawsky 
> >>> >> Cc: Chris Wilson 
> >>> >> Signed-off-by: Michał Winiarski 
> >>> >> ---
> >>> >>  include/drm/i915_drm.h|   4 +-
> >>> >>  intel/intel_bufmgr.c  |   9 +++
> >>> >>  intel/intel_bufmgr.h  |   1 +
> >>> >>  intel/intel_bufmgr_gem.c  | 176
> >>> >> --
> >>> >>  intel/intel_bufmgr_priv.h |   7 ++
> >>> >>  5 files changed, 173 insertions(+), 24 deletions(-)
> >>> >
> >>> > Will anybody help to push the patch to libdrm? Beignet highly depend
> on
> >>> this to implement ocl2.0 svm.
> >>>
> >>> Is the kernel patch upstream?
> >>
> >> Yes, the kernel patch already merged, see:
> >> http://cgit.freedesktop.org/drm-
> intel/commit/?id=506a8e87d8d2746b9e9d2433503fe237c54e4750
> >>
> >> I find below line of code in libdrm does not match the kernel version. The
> kernel patch defined as:
> >> "#define EXEC_OBJECT_PINNED (1<<4)", but this patch defined it as
> (1<<3).
> >
> > I have the two 48 bit patches merge here. I'll pull in Michał's patch,
> > update the kernel header and  then push it all.
> 
> All pushed now.

Thanks. We have tried some basic OpenCL tests. Both patches work!
I have another question, does KMD allow soft-pin a bo at zero address?
I have tried to pin a bo with the size of 64KB at zero address in Beignet. It 
can succeed.
But I met some random failure with bo_exec() returning -EINVAL.
I am trying to figure out why. So I want to confirm is it allowed by KMD?

Thanks!
Ruiling

[PATCH v11 03/19] drm: bridge: analogix/dp: remove duplicate configuration of link rate and link count

[Yakir Yang]

link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.

Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7Gbps, 5.4Gbps}.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Update commit message more readable. (Jingoo)
- Adjust the order from 05 to 04

Changes in v3:
- The link_rate and lane_count shouldn't config to the DT property value
  directly, but we can take those as hardware limite. For example, RK3288
  only support 4 physical lanes of 2.7/1.62 Gbps/lane, so DT property would
  like "link-rate = 0x0a" "lane-count = 4". (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 8 
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 5 +++--
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 4a05c2b..6f899cd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -624,6 +624,8 @@ static void analogix_dp_get_max_rx_bandwidth(struct 
analogix_dp_device *dp,
/*
 * For DP rev.1.1, Maximum link rate of Main Link lanes
 * 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps
+* For DP rev.1.2, Maximum link rate of Main Link lanes
+* 0x06 = 1.62 Gbps, 0x0a = 2.7 Gbps, 0x14 = 5.4Gbps
 */
analogix_dp_read_byte_from_dpcd(dp, DP_MAX_LINK_RATE, &data);
*bandwidth = data;
@@ -657,7 +659,8 @@ static void analogix_dp_init_training(struct 
analogix_dp_device *dp,
analogix_dp_get_max_rx_lane_count(dp, &dp->link_train.lane_count);

if ((dp->link_train.link_rate != LINK_RATE_1_62GBPS) &&
-   (dp->link_train.link_rate != LINK_RATE_2_70GBPS)) {
+   (dp->link_train.link_rate != LINK_RATE_2_70GBPS) &&
+   (dp->link_train.link_rate != LINK_RATE_5_40GBPS)) {
dev_err(dp->dev, "Rx Max Link Rate is abnormal :%x !\n",
dp->link_train.link_rate);
dp->link_train.link_rate = LINK_RATE_1_62GBPS;
@@ -898,9 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
analogix_dp_enable_rx_to_enhanced_mode(dp, 1);
analogix_dp_enable_enhanced_mode(dp, 1);

-   analogix_dp_set_lane_count(dp, dp->video_info->lane_count);
-   analogix_dp_set_link_bandwidth(dp, dp->video_info->link_rate);
-
analogix_dp_init_video(dp);
ret = analogix_dp_config_video(dp);
if (ret)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 8e84208..57aa4b0d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -21,8 +21,9 @@
 #define MAX_EQ_LOOP5

 enum link_rate_type {
-   LINK_RATE_1_62GBPS = 0x06,
-   LINK_RATE_2_70GBPS = 0x0a
+   LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
+   LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
+   LINK_RATE_5_40GBPS = DP_LINK_BW_5_4,
 };

 enum link_lane_count_type {
-- 
1.9.1

[PATCH v11 04/19] drm: bridge: analogix/dp: dynamic parse sync_pol & interlace & dynamic_range

[Yakir Yang]

Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.

But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.

Signed-off-by: Yakir Yang 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7:
- Back to use the of_property_read_bool() interfacs to provoid backward
  compatibility of "hsync-active-high" "vsync-active-high" "interlaced"
  to avoid -EOVERFLOW error (Krzysztof)

Changes in v6: None
Changes in v5:
- Switch video timing type to "u32", so driver could use "of_property_read_u32"
  to get the backword timing values. Krzysztof suggest me that driver could use
  the "of_property_read_bool" to get backword timing values, but that interfacs
  would modify the original drm_display_mode timing directly (whether those
  properties exists or not).

Changes in v4:
- Provide backword compatibility with samsung. (Krzysztof)

Changes in v3:
- Dynamic parse video timing info from struct drm_display_mode and
  struct drm_display_info. (Thierry)

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 148 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   2 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  14 +-
 3 files changed, 103 insertions(+), 61 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 6f899cd..a0d97cb 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}

-   ret = analogix_dp_set_link_train(dp, dp->video_info->lane_count,
-dp->video_info->link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
+dp->video_info.link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1032,6 +1032,85 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
dp->dpms_mode = DRM_MODE_DPMS_OFF;
 }

+static void analogix_dp_bridge_mode_set(struct drm_bridge *bridge,
+   struct drm_display_mode *orig_mode,
+   struct drm_display_mode *mode)
+{
+   struct analogix_dp_device *dp = bridge->driver_private;
+   struct drm_display_info *display_info = &dp->connector->display_info;
+   struct video_info *video = &dp->video_info;
+   struct device_node *dp_node = dp->dev->of_node;
+   int vic;
+
+   /* Input video interlaces & hsync pol & vsync pol */
+   video->interlaced = !!(mode->flags & DRM_MODE_FLAG_INTERLACE);
+   video->v_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NVSYNC);
+   video->h_sync_polarity = !!(mode->flags & DRM_MODE_FLAG_NHSYNC);
+
+   /* Input video dynamic_range & colorimetry */
+   vic = drm_match_cea_mode(mode);
+   if ((vic == 6) || (vic == 7) || (vic == 21) || (vic == 22) ||
+   (vic == 2) || (vic == 3) || (vic == 17) || (vic == 18)) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR601;
+   } else if (vic) {
+   video->dynamic_range = CEA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   } else {
+   video->dynamic_range = VESA;
+   video->ycbcr_coeff = COLOR_YCBCR709;
+   }
+
+   /* Input vide bpc and color_formats */
+   switch (display_info->bpc) {
+   case 12:
+   video->color_depth = COLOR_12;
+   break;
+   case 10:
+   video->color_depth = COLOR_10;
+   break;
+   case 8:
+   video->color_depth = COLOR_8;
+   break;
+   case 6:
+   video->color_depth = COLOR_6;
+   break;
+   default:
+   video->color_depth = COLOR_8;
+   break;
+   }
+   if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB444)
+   video->color_space = COLOR_YCBCR444;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_YCRCB422)
+   video->color_space = COLOR_YCBCR422;
+   else if (display_info->color_formats & DRM_COLOR_FORMAT_RGB444)
+   video->color_space = COLOR_RGB;
+   else
+   video->color_space = COLOR_RGB;
+
+   /*
+* NOTE: those property parsing code is used for providing backward
+* compatibility for samsung platform.
+* Due to we used the "of_property_read_u32" interfaces, when this
+* property isn't present, the "video_info" can keep the 

[PATCH v11 05/19] dt-bindings: add document for analogix display port driver

[Yakir Yang]

Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt

Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring

Changes in v9: None
Changes in v8:
- Correct the right document path of display-timing.txt (Heiko)
- Correct the misspell of 'from' to 'frm'. (Heiko)

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Split all DTS changes, and provide backward compatibility. Mark old
  properties as deprecated but still support them. (Krzysztof)
- Update "analogix,hpd-gpio" to "hpd-gpios" prop name. (Rob)
- Deprecated some properties which could parsed from Edid/Mode/DPCD. (Thierry)
"analogix,color-space" & "analogix,color-depth"   &
"analogix,link-rate"   & "analogix,lane-count"&
"analogix,ycbcr-coeff" & "analogix,dynamic-range" &
"vsync-active-high"& "hsync-active-high"  & "interlaces"

Changes in v3:
- Add devicetree binding documents. (Heiko)
- Remove sync pol & colorimetry properies from the new analogix dp driver
  devicetree binding. (Thierry)
- Update the exist exynos dtsi file with the latest DP DT properies.

Changes in v2: None

 .../bindings/display/bridge/analogix_dp.txt| 50 +
 .../bindings/display/exynos/exynos_dp.txt  | 65 --
 2 files changed, 72 insertions(+), 43 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/analogix_dp.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
new file mode 100644
index 000..7659a7a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -0,0 +1,50 @@
+Analogix Display Port bridge bindings
+
+Required properties for dp-controller:
+   -compatible:
+   platform specific such as:
+* "samsung,exynos5-dp"
+* "rockchip,rk3288-dp"
+   -reg:
+   physical base address of the controller and length
+   of memory mapped region.
+   -interrupts:
+   interrupt combiner values.
+   -clocks:
+   from common clock binding: handle to dp clock.
+   -clock-names:
+   from common clock binding: Shall be "dp".
+   -interrupt-parent:
+   phandle to Interrupt combiner node.
+   -phys:
+   from general PHY binding: the phandle for the PHY device.
+   -phy-names:
+   from general PHY binding: Should be "dp".
+
+Optional properties for dp-controller:
+   -hpd-gpios:
+   Hotplug detect GPIO.
+   Indicates which GPIO should be used for hotplug detection
+   -port@[X]: SoC specific port nodes with endpoint definitions as defined
+   in Documentation/devicetree/bindings/media/video-interfaces.txt,
+   please refer to the SoC specific binding document:
+   * Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+   * 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt
+
+
+[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
+---
+
+Example:
+
+   dp-controller {
+   compatible = "samsung,exynos5-dp";
+   reg = <0x145b 0x1>;
+   interrupts = <10 3>;
+   interrupt-parent = <&combiner>;
+   clocks = <&clock 342>;
+   clock-names = "dp";
+
+   phys = <&dp_phy>;
+   phy-names = "dp";
+   };
diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 64693f2..9905081 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -31,45 +31,31 @@ Required properties for dp-controller:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
-   -samsung,color-space:
-   input video data format.
-   COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
-   -samsung,dynamic-range:
-   dynamic range for input video data.
-   VESA = 0, CEA = 1
-   -samsung,ycbcr-coeff:
-   YCbCr co-efficients for input video.
-   COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
-   -samsung,color-depth:
-   number of bits per colour component.
-   COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
-   -samsung

[PATCH v11 06/19] ARM: dts: exynos/dp: remove some properties that deprecated by analogix_dp driver

[Yakir Yang]

After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.

Beside the backward compatibility is fully preserved, so there are no
bisectability break that make this change in a separate patch.

Signed-off-by: Yakir Yang 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6:
- Fix Peach Pit hpd property name error:
-   hpd-gpio = <&gpx2 6 0>;
+   hpd-gpios = <&gpx2 6 0>;

Changes in v5:
- Correct the misspell in commit message. (Krzysztof)

Changes in v4:
- Separate all DTS changes to a separate patch. (Krzysztof)

Changes in v3: None
Changes in v2: None

 arch/arm/boot/dts/exynos5250-arndale.dts  | 2 --
 arch/arm/boot/dts/exynos5250-smdk5250.dts | 2 --
 arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +---
 arch/arm/boot/dts/exynos5250-spring.dts   | 4 +---
 arch/arm/boot/dts/exynos5420-peach-pit.dts| 4 +---
 arch/arm/boot/dts/exynos5420-smdk5420.dts | 2 --
 arch/arm/boot/dts/exynos5800-peach-pi.dts | 4 +---
 7 files changed, 4 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index c000532..b1790cf 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -124,8 +124,6 @@
 &dp {
status = "okay";
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 0f5dcd4..f30c2db 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -80,8 +80,6 @@

 &dp {
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
index 5cb33ba..b96624b 100644
--- a/arch/arm/boot/dts/exynos5250-snow-common.dtsi
+++ b/arch/arm/boot/dts/exynos5250-snow-common.dtsi
@@ -236,12 +236,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = <&gpx0 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpx0 7 GPIO_ACTIVE_HIGH>;

ports {
port at 0 {
diff --git a/arch/arm/boot/dts/exynos5250-spring.dts 
b/arch/arm/boot/dts/exynos5250-spring.dts
index c1edd6d..91881d7 100644
--- a/arch/arm/boot/dts/exynos5250-spring.dts
+++ b/arch/arm/boot/dts/exynos5250-spring.dts
@@ -74,12 +74,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <1>;
-   samsung,hpd-gpio = <&gpc3 0 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpc3 0 GPIO_ACTIVE_HIGH>;
 };

 &ehci {
diff --git a/arch/arm/boot/dts/exynos5420-peach-pit.dts 
b/arch/arm/boot/dts/exynos5420-peach-pit.dts
index 35cfb07..2f37c87 100644
--- a/arch/arm/boot/dts/exynos5420-peach-pit.dts
+++ b/arch/arm/boot/dts/exynos5420-peach-pit.dts
@@ -148,12 +148,10 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd_gpio>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x06>;
samsung,lane-count = <2>;
-   samsung,hpd-gpio = <&gpx2 6 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpx2 6 GPIO_ACTIVE_HIGH>;

ports {
port at 0 {
diff --git a/arch/arm/boot/dts/exynos5420-smdk5420.dts 
b/arch/arm/boot/dts/exynos5420-smdk5420.dts
index ac35aef..f67344f 100644
--- a/arch/arm/boot/dts/exynos5420-smdk5420.dts
+++ b/arch/arm/boot/dts/exynos5420-smdk5420.dts
@@ -93,8 +93,6 @@
pinctrl-names = "default";
pinctrl-0 = <&dp_hpd>;
samsung,color-space = <0>;
-   samsung,dynamic-range = <0>;
-   samsung,ycbcr-coeff = <0>;
samsung,color-depth = <1>;
samsung,link-rate = <0x0a>;
samsung,lane-count = <4>;
diff --git a/arch/arm/boot/dts/exynos5800-peach-pi.dts 
b/arch/arm/boot/dts/exynos5800-peach-pi.dts
index 7b018e4..363c95f 100644
--- a/arch/arm/boot/dts/exyno

[PATCH v11 07/19] drm: rockchip: dp: add rockchip platform dp driver

[Yakir Yang]

Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10:
- Correct the ROCKCHIP_ANALOGIX_DP indentation in Kconfig to tabs here (Heiko)

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Remove the empty line at the end of document, and correct the endpoint
  numbers in the example DT node, and remove the regulator iomux setting
  in driver code while using the pinctl in devicetree instead. (Heiko)
- Add device type declared, cause the previous "platform device type
  support (v4 11/16)" already merge into (v5 02/14).
- Implement connector registration code. (Thierry)

Changes in v4:
- Remove some deprecated DT properties in rockchip dp document.

Changes in v3:
- Leave "sclk_edp_24m" to rockchip dp phy driver which name to "24m",
  and leave "sclk_edp" to analogix dp core driver which name to "dp",
  and leave "pclk_edp" to rockchip dp platform driver which name to
  "pclk". (Thierry & Heiko)
- Add devicetree binding document. (Heiko)
- Remove "rockchip,panel" DT property, take use of remote point to get panel
  node. (Heiko)
- Add the new function point dp_platdata->get_modes() init.

Changes in v2:
- Get panel node with remote-endpoint method, and create devicetree binding
  for driver. (Heiko)
- Remove the clock enable/disbale with "sclk_edp" & "sclk_edp_24m",
  leave those clock to rockchip dp phy driver.

 drivers/gpu/drm/rockchip/Kconfig|   9 +
 drivers/gpu/drm/rockchip/Makefile   |   1 +
 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 442 
 include/drm/bridge/analogix_dp.h|   1 +
 4 files changed, 453 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 35215f6..686cb49 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -25,3 +25,12 @@ config ROCKCHIP_DW_HDMI
  for the Synopsys DesignWare HDMI driver. If you want to
  enable HDMI on RK3288 based SoC, you should selet this
  option.
+
+config ROCKCHIP_ANALOGIX_DP
+   tristate "Rockchip specific extensions for Analogix DP driver"
+   depends on DRM_ROCKCHIP
+   select DRM_ANALOGIX_DP
+   help
+ This selects support for Rockchip SoC specific extensions
+ for the Analogix Core DP driver. If you want to enable DP
+ on RK3288 based SoC, you should selet this option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index f3d8a19..8ad01fb 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -6,5 +6,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \
rockchip_drm_gem.o

 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
+obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o

 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
new file mode 100644
index 000..2c82a9a
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -0,0 +1,442 @@
+/*
+ * Rockchip SoC DP (Display Port) interface driver.
+ *
+ * Copyright (C) Fuzhou Rockchip Electronics Co., Ltd.
+ * Author: Andy Yan 
+ * Yakir Yang 
+ * Jeff Chen 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define to_dp(nm)  container_of(nm, struct rockchip_dp_device, nm)
+
+/* dp grf register offset */
+#define GRF_SOC_CON60x025c
+#define GRF_EDP_LCD_SEL_MASKBIT(5)
+#define GRF_EDP_SEL_VOP_LIT BIT(5)
+#define GRF_EDP_SEL_VOP_BIG 0
+
+struct rockchip_dp_device {
+   struct drm_device*drm_dev;
+   struct device*dev;
+   struct drm_encoder   encoder;
+   struct drm_connector connector;
+   struct drm_display_mode  mode;
+
+   struct clk   *pclk;
+   struct regmap*grf;
+   struct reset_control *rst;
+
+   struct analogix_dp_plat_data plat_data;
+};
+
+static int rockchip_dp_pre_init(struct rockchip_dp_device *dp)
+{
+   reset_control_assert(dp->rst);
+   usleep_range(10, 20);
+

[PATCH v11 08/19] dt-bindings: add document for rockchip variant of analogix_dp

[Yakir Yang]

Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Reviewed-by: Heiko Stuebner 
---
Changes in v11: None
Changes in v10:
- Add the ack from Rob Herring

Changes in v9:
- Document more details for 'ports' property.

Changes in v8:
- Modify the commit subject name. (Heiko)

Changes in v7: None
Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Add eDP hotplug pinctrl property. (Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../display/rockchip/analogix_dp-rockchip.txt  | 91 ++
 1 file changed, 91 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt

diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
new file mode 100644
index 000..04d99e3
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -0,0 +1,91 @@
+Rockchip RK3288 specific extensions to the Analogix Display Port
+
+
+Required properties:
+- compatible: "rockchip,rk3288-edp";
+
+- reg: physical base address of the controller and length
+
+- clocks: from common clock binding: handle to dp clock.
+ of memory mapped region.
+
+- clock-names: from common clock binding:
+  Required elements: "dp" "pclk"
+
+- resets: Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+
+- pinctrl-names: Names corresponding to the chip hotplug pinctrl states.
+- pinctrl-0: pin-control mode. should be <&edp_hpd>
+
+- reset-names: Must include the name "dp"
+
+- rockchip,grf: this soc should set GRF regs, so need get grf here.
+
+- ports: there are 2 port nodes with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+Port 0: contained 2 endpoints, connecting to the output of vop.
+Port 1: contained 1 endpoint, connecting to the input of panel.
+
+For the below properties, please refer to Analogix DP binding document:
+ * Documentation/devicetree/bindings/drm/bridge/analogix_dp.txt
+- phys (required)
+- phy-names (required)
+- hpd-gpios (optional)
+---
+
+Example:
+   dp-controller: dp at ff97 {
+   compatible = "rockchip,rk3288-dp";
+   reg = <0xff97 0x4000>;
+   interrupts = ;
+   clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
+   clock-names = "dp", "pclk";
+   phys = <&dp_phy>;
+   phy-names = "dp";
+
+   rockchip,grf = <&grf>;
+   resets = <&cru 111>;
+   reset-names = "dp";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&edp_hpd>;
+
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in: port at 0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_in_vopb: endpoint at 0 {
+   reg = <0>;
+   remote-endpoint = <&vopb_out_edp>;
+   };
+   edp_in_vopl: endpoint at 1 {
+   reg = <1>;
+   remote-endpoint = <&vopl_out_edp>;
+   };
+   };
+
+   edp_out: port at 1 {
+   reg = <1>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   edp_out_panel: endpoint {
+   reg = <0>;
+   remote-endpoint = <&panel_in_edp>
+   };
+   };
+   };
+   };
+
+   pinctrl {
+   edp {
+   edp_hpd: edp-hpd {
+   rockchip,pins = <7 11 RK_FUNC_2 
&pcfg_pull_none>;
+   };
+   };
+   };
-- 
1.9.1

[PATCH v11 09/19] phy: Add driver for rockchip Display Port PHY

[Yakir Yang]

Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.

Signed-off-by: Yakir Yang 
Reviewed-by: Heiko Stuebner 
---
Changes in v11: None
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK
BIT(4) -> BIT(20)

Changes in v9:
- Removed the unused the variable "res" in probe function. (Heiko)
- Removed the unused head file.

Changes in v8:
- Fix the mixed spacers on macro definitions. (Heiko)
- Remove the unnecessary empty line after clk_prepare_enable. (Heiko)

Changes in v7:
- Simply the commit message. (Kishon)
- Symmetrical enable/disbale the phy clock and power. (Kishon)

Changes in v6: None
Changes in v5:
- Remove "reg" DT property, cause driver could poweron/poweroff phy via
  the exist "grf" syscon already. And rename the example DT node from
  "edp_phy: phy at ff770274" to "edp_phy: edp-phy" directly. (Heiko)
- Add deivce_node at the front of driver, update phy_ops type from "static
  struct" to "static const struct". And correct the input paramters of
  devm_phy_create() interfaces. (Heiko)

Changes in v4:
- Add commit message, and remove the redundant rockchip_dp_phy_init()
  function, move those code to probe() method. And remove driver .owner
  number. (Kishon)

Changes in v3:
- Suggest, add rockchip dp phy driver, collect the phy clocks and
  power control. (Heiko)

Changes in v2: None

 drivers/phy/Kconfig   |   7 ++
 drivers/phy/Makefile  |   1 +
 drivers/phy/phy-rockchip-dp.c | 151 ++
 3 files changed, 159 insertions(+)
 create mode 100644 drivers/phy/phy-rockchip-dp.c

diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 7eb5859d..7355819 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -319,6 +319,13 @@ config PHY_ROCKCHIP_USB
help
  Enable this to support the Rockchip USB 2.0 PHY.

+config PHY_ROCKCHIP_DP
+   tristate "Rockchip Display Port PHY Driver"
+   depends on ARCH_ROCKCHIP && OF
+   select GENERIC_PHY
+   help
+ Enable this to support the Rockchip Display Port PHY.
+
 config PHY_ST_SPEAR1310_MIPHY
tristate "ST SPEAR1310-MIPHY driver"
select GENERIC_PHY
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 075db1a..b1700cd 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -35,6 +35,7 @@ phy-exynos-usb2-$(CONFIG_PHY_S5PV210_USB2)+= 
phy-s5pv210-usb2.o
 obj-$(CONFIG_PHY_EXYNOS5_USBDRD)   += phy-exynos5-usbdrd.o
 obj-$(CONFIG_PHY_QCOM_APQ8064_SATA)+= phy-qcom-apq8064-sata.o
 obj-$(CONFIG_PHY_ROCKCHIP_USB) += phy-rockchip-usb.o
+obj-$(CONFIG_PHY_ROCKCHIP_DP)  += phy-rockchip-dp.o
 obj-$(CONFIG_PHY_QCOM_IPQ806X_SATA)+= phy-qcom-ipq806x-sata.o
 obj-$(CONFIG_PHY_ST_SPEAR1310_MIPHY)   += phy-spear1310-miphy.o
 obj-$(CONFIG_PHY_ST_SPEAR1340_MIPHY)   += phy-spear1340-miphy.o
diff --git a/drivers/phy/phy-rockchip-dp.c b/drivers/phy/phy-rockchip-dp.c
new file mode 100644
index 000..3cb3bf8
--- /dev/null
+++ b/drivers/phy/phy-rockchip-dp.c
@@ -0,0 +1,151 @@
+/*
+ * Rockchip DP PHY driver
+ *
+ * Copyright (C) 2015 FuZhou Rockchip Co., Ltd.
+ * Author: Yakir Yang 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define GRF_SOC_CON12   0x0274
+
+#define GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK   BIT(20)
+#define GRF_EDP_REF_CLK_SEL_INTER   BIT(4)
+
+#define GRF_EDP_PHY_SIDDQ_HIWORD_MASK   BIT(21)
+#define GRF_EDP_PHY_SIDDQ_ON0
+#define GRF_EDP_PHY_SIDDQ_OFF   BIT(5)
+
+struct rockchip_dp_phy {
+   struct device  *dev;
+   struct regmap  *grf;
+   struct clk *phy_24m;
+};
+
+static int rockchip_set_phy_state(struct phy *phy, bool enable)
+{
+   struct rockchip_dp_phy *dp = phy_get_drvdata(phy);
+   int ret;
+
+   if (enable) {
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_ON);
+   if (ret < 0) {
+   dev_err(dp->dev, "Can't enable PHY power %d\n", ret);
+   return ret;
+   }
+
+   ret = clk_prepare_enable(dp->phy_24m);
+   } else {
+   clk_disable_unprepare(dp->phy_24m);
+
+   ret = regmap_write(dp->grf, GRF_SOC_CON12,
+  GRF_EDP_PHY_SIDDQ_HIWORD_MASK |
+  GRF_EDP_PHY_SIDDQ_OFF);
+   }
+
+   return ret;
+}
+
+static int rockchip_dp_phy_power_on(struct phy *phy)
+{
+   return rockchip_set_phy_state(phy, true);
+}
+
+static int rockchip_dp_phy_power_off(struct ph

[PATCH v11 10/19] dt-bindings: add document for rockchip dp phy

[Yakir Yang]

Add dt binding documentation for rockchip display port PHY.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Reviewed-by: Heiko Stuebner 
---
Changes in v11:
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring

Changes in v10: None
Changes in v9: None
Changes in v8:
- Remove the specific address in the example node name. (Heiko)

Changes in v7:
- Simplify the commit message. (Kishon)

Changes in v6: None
Changes in v5:
- Split binding doc's from driver changes. (Rob)
- Update the rockchip,grf explain in document, and correct the clock required
  elemets in document. (Rob & Heiko)

Changes in v4: None
Changes in v3: None
Changes in v2: None

 .../devicetree/bindings/phy/rockchip-dp-phy.txt| 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt 
b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
new file mode 100644
index 000..50c4f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/rockchip-dp-phy.txt
@@ -0,0 +1,22 @@
+Rockchip specific extensions to the Analogix Display Port PHY
+
+
+Required properties:
+- compatible : should be one of the following supported values:
+- "rockchip.rk3288-dp-phy"
+- clocks: from common clock binding: handle to dp clock.
+   of memory mapped region.
+- clock-names: from common clock binding:
+   Required elements: "24m"
+- rockchip,grf: phandle to the syscon managing the "general register files"
+- #phy-cells : from the generic PHY bindings, must be 0;
+
+Example:
+
+edp_phy: edp-phy {
+   compatible = "rockchip,rk3288-dp-phy";
+   rockchip,grf = <&grf>;
+   clocks = <&cru SCLK_EDP_24M>;
+   clock-names = "24m";
+   #phy-cells = <0>;
+};
-- 
1.9.1

[PATCH v11 11/19] drm: rockchip: vop: add bpc and color mode setting

[Yakir Yang]

From: Mark Yao 

Add bpc and color mode setting in rockchip_drm_vop driver, so
connector could try to use the edid drm_display_info to config
vop output mode.

Signed-off-by: Mark Yao 
Signed-off-by: Yakir Yang 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5:
- Fix compiled error (Heiko)
- Using the connector display info message to configure eDP driver input
  video mode, but hard code CRTC video output mode to RGBaaa.

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 25 +++
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 32 ++---
 4 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c 
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index 2c82a9a..3990951 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -180,14 +180,29 @@ static void rockchip_dp_drm_encoder_mode_set(struct 
drm_encoder *encoder,
 static void rockchip_dp_drm_encoder_prepare(struct drm_encoder *encoder)
 {
struct rockchip_dp_device *dp = to_dp(encoder);
+   struct drm_connector *cn = &dp->connector;
+   int ret = -1;
u32 val;
-   int ret;

-   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
-   DRM_MODE_CONNECTOR_eDP,
-   ROCKCHIP_OUT_MODE_);
+   /*
+* FIXME(Yakir): driver should configure the CRTC output video
+* mode with the display information which indicated the monitor
+* support colorimetry.
+*
+* But don't know why the CRTC driver seems could only output the
+* RGBaaa rightly. For example, if connect the "innolux,n116bge"
+* eDP screen, EDID would indicated that screen only accepted the
+* 6bpc mode. But if I configure CRTC to RGB666 output, then eDP
+* screen would show a blue picture (RGB888 show a green picture).
+* But if I configure CTRC to RGBaaa, and eDP driver still keep
+* RGB666 input video mode, then screen would works prefect.
+*/
+   if (cn->display_info.color_formats & DRM_COLOR_FORMAT_RGB444)
+   ret = rockchip_drm_crtc_mode_config(encoder->crtc,
+   DRM_MODE_CONNECTOR_eDP,
+   10, DRM_COLOR_FORMAT_RGB444);
if (ret < 0) {
-   dev_err(dp->dev, "Could not set crtc mode config: %d.\n", ret);
+   dev_err(dp->dev, "Could not set crtc mode config (%d)\n", ret);
return;
}

diff --git a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c 
b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
index 80d6fc8..428a3c1 100644
--- a/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
+++ b/drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
@@ -215,7 +215,7 @@ static void dw_hdmi_rockchip_encoder_commit(struct 
drm_encoder *encoder)
 static void dw_hdmi_rockchip_encoder_prepare(struct drm_encoder *encoder)
 {
rockchip_drm_crtc_mode_config(encoder->crtc, DRM_MODE_CONNECTOR_HDMIA,
- ROCKCHIP_OUT_MODE_);
+ 10, DRM_COLOR_FORMAT_RGB444);
 }

 static struct drm_encoder_helper_funcs dw_hdmi_rockchip_encoder_helper_funcs = 
{
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index dc4e5f0..ef1d7fb 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -59,7 +59,7 @@ void rockchip_unregister_crtc_funcs(struct drm_device *dev, 
int pipe);
 int rockchip_drm_encoder_get_mux_id(struct device_node *node,
struct drm_encoder *encoder);
 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc, int connector_type,
- int out_mode);
+ int bpc, int color);
 int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
   struct device *dev);
 void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 5d8ae5e..9ef4a1f 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1062,14 +1062,40 @@ static const struct drm_plane_funcs vop_plane_funcs = {

 int rockchip_drm_crtc_mode_config(struct drm_crtc *crtc,
  int connector_type,
- int out_mode)
+ int bpc, int color)
 {
struct vop *vop = to_vop(crtc);

+   /*

[PATCH v11 12/19] drm: bridge: analogix/dp: add some rk3288 special registers setting

[Yakir Yang]

RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- Fix compile failed dut to phy_pd_addr variable misspell error

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 76 ++-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h | 12 
 2 files changed, 60 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index 861097a..21a3287 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -15,6 +15,8 @@
 #include 
 #include 

+#include 
+
 #include "analogix_dp_core.h"
 #include "analogix_dp_reg.h"

@@ -72,6 +74,14 @@ void analogix_dp_init_analog_param(struct analogix_dp_device 
*dp)
reg = SEL_24M | TX_DVDD_BIT_1_0625V;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_2);

+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP)) {
+   writel(REF_CLK_24M, dp->reg_base + ANALOGIX_DP_PLL_REG_1);
+   writel(0x95, dp->reg_base + ANALOGIX_DP_PLL_REG_2);
+   writel(0x40, dp->reg_base + ANALOGIX_DP_PLL_REG_3);
+   writel(0x58, dp->reg_base + ANALOGIX_DP_PLL_REG_4);
+   writel(0x22, dp->reg_base + ANALOGIX_DP_PLL_REG_5);
+   }
+
reg = DRIVE_DVDD_BIT_1_0625V | VCO_BIT_600_MICRO;
writel(reg, dp->reg_base + ANALOGIX_DP_ANALOG_CTL_3);

@@ -206,81 +216,85 @@ void analogix_dp_set_analog_power_down(struct 
analogix_dp_device *dp,
   bool enable)
 {
u32 reg;
+   u32 phy_pd_addr = ANALOGIX_DP_PHY_PD;
+
+   if (dp->plat_data && (dp->plat_data->dev_type == RK3288_DP))
+   phy_pd_addr = ANALOGIX_DP_PD;

switch (block) {
case AUX_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~AUX_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH0_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH0_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH1_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH1_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
}
break;
case CH2_BLOCK:
if (enable) {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg |= CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   writel(reg, dp->reg_base + phy_pd_addr);
} else {
-   reg = readl(dp->reg_base + ANALOGIX_DP_PHY_PD);
+   reg = readl(dp->reg_base + phy_pd_addr);
reg &= ~CH2_PD;
-   writel(reg, dp->reg_base + ANALOGIX_DP_PHY_PD);
+   

[PATCH v11 13/19] drm: bridge: analogix/dp: add max link rate and lane count limit for RK3288

[Yakir Yang]

There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10:
- Remove the surplus "plat_data" check. (Heiko)
-   switch (dp->plat_data && dp->plat_data->dev_type) {
+   switch (dp->plat_data->dev_type) {

Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Seprate the link-rate and lane-count limit out with the device_type
  flag. (Thierry)

Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 33 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  4 +--
 2 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index a0d97cb..f624810 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -890,8 +890,8 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
return;
}

-   ret = analogix_dp_set_link_train(dp, dp->video_info.lane_count,
-dp->video_info.link_rate);
+   ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
+dp->video_info.max_link_rate);
if (ret) {
dev_err(dp->dev, "unable to do link train\n");
return;
@@ -1158,16 +1158,25 @@ static int analogix_dp_dt_parse_pdata(struct 
analogix_dp_device *dp)
struct device_node *dp_node = dp->dev->of_node;
struct video_info *video_info = &dp->video_info;

-   if (of_property_read_u32(dp_node, "samsung,link-rate",
-&video_info->link_rate)) {
-   dev_err(dp->dev, "failed to get link-rate\n");
-   return -EINVAL;
-   }
-
-   if (of_property_read_u32(dp_node, "samsung,lane-count",
-&video_info->lane_count)) {
-   dev_err(dp->dev, "failed to get lane-count\n");
-   return -EINVAL;
+   switch (dp->plat_data->dev_type) {
+   case RK3288_DP:
+   /*
+* Like Rk3288 DisplayPort TRM indicate that "Main link
+* containing 4 physical lanes of 2.7/1.62 Gbps/lane".
+*/
+   video_info->max_link_rate = 0x0A;
+   video_info->max_lane_count = 0x04;
+   break;
+   case EXYNOS_DP:
+   /*
+* NOTE: those property parseing code is used for
+* providing backward compatibility for samsung platform.
+*/
+   of_property_read_u32(dp_node, "samsung,link-rate",
+&video_info->max_link_rate);
+   of_property_read_u32(dp_node, "samsung,lane-count",
+&video_info->max_lane_count);
+   break;
}

return 0;
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 0416d23..4ec 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -129,8 +129,8 @@ struct video_info {
enum color_coefficient ycbcr_coeff;
enum color_depth color_depth;

-   enum link_rate_type link_rate;
-   enum link_lane_count_type lane_count;
+   enum link_rate_type max_link_rate;
+   enum link_lane_count_type max_lane_count;
 };

 struct link_train {
-- 
1.9.1

[PATCH v11 14/19] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

[Yakir Yang]

Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.

This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.

Signed-off-by: Yakir Yang 
Acked-by: Rob Herring 
Tested-by: Javier Martinez Canillas 
---
Changes in v11:
- Rename the "analogix,need-force-hpd" to common 'force-hpd' (Rob)
- Add the ack from Rob Herring

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Add "analogix,need-force-hpd" to indicate whether driver need foce
  hpd when hpd detect failed.

Changes in v2: None

 .../bindings/display/bridge/analogix_dp.txt|  4 ++-
 .../bindings/display/exynos/exynos_dp.txt  |  1 +
 .../display/rockchip/analogix_dp-rockchip.txt  |  1 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 35 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  2 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  9 ++
 6 files changed, 46 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt 
b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
index 7659a7a..4f2ba8c 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
@@ -22,6 +22,9 @@ Required properties for dp-controller:
from general PHY binding: Should be "dp".

 Optional properties for dp-controller:
+   -force-hpd:
+   Indicate driver need force hpd when hpd detect failed, this
+   is used for some eDP screen which don't have hpd signal.
-hpd-gpios:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug detection
@@ -31,7 +34,6 @@ Optional properties for dp-controller:
* Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
* 
Documentation/devicetree/bindings/video/analogix_dp-rockchip.txt

-
 [1]: Documentation/devicetree/bindings/media/video-interfaces.txt
 ---

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
index 9905081..8800164 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
@@ -41,6 +41,7 @@ For the below properties, please refer to Analogix DP binding 
document:
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
+   -analogix,need-force-hpd (optional)
-video interfaces (optional)

 Deprecated properties for DisplayPort:
diff --git 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
index 04d99e3..e832ff9 100644
--- 
a/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
+++ 
b/Documentation/devicetree/bindings/display/rockchip/analogix_dp-rockchip.txt
@@ -32,6 +32,7 @@ For the below properties, please refer to Analogix DP binding 
document:
 - phys (required)
 - phy-names (required)
 - hpd-gpios (optional)
+- force-hpd (optional)
 ---

 Example:
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index f624810..9eb17ce 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -59,15 +59,38 @@ static int analogix_dp_detect_hpd(struct analogix_dp_device 
*dp)
 {
int timeout_loop = 0;

-   while (analogix_dp_get_plug_in_status(dp) != 0) {
+   while (timeout_loop < DP_TIMEOUT_LOOP_COUNT) {
+   if (analogix_dp_get_plug_in_status(dp) == 0)
+   return 0;
+
timeout_loop++;
-   if (timeout_loop > DP_TIMEOUT_LOOP_COUNT) {
-   dev_err(dp->dev, "failed to get hpd plug status\n");
-   return -ETIMEDOUT;
-   }
usleep_range(10, 11);
}

+   /*
+* Some edp screen do not have hpd signal, so we can't just
+* return failed when hpd plug in detect failed, DT property
+* "need-force-hpd" would indicate whether driver need this.
+*/
+   if (!dp->force_hpd)
+   return -ETIMEDOUT;
+
+   /*
+* The eDP TRM indicate that if HPD_STATUS(RO) is 0, AUX CH
+* will not work, so we need to give a force hpd action to
+* set HPD_STATUS manually.
+*/
+   dev_dbg(dp->dev, "failed to get hpd plug status, try to force hpd\n");
+
+   analogix_dp_

[PATCH v11 15/19] drm: bridge: analogix/dp: move hpd detect to connector detect function

[Yakir Yang]

This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase

But for now the connector status don't hardcode to connected,
need to operate dp phy in .detect function, so we need to revert
parts if Gustavo Padovan's changes, add phy poweron
function in bind time.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11:
- Revert parts of Gustavo Padovan's changes in commit:
drm/exynos: do not start enabling DP at bind() phase
  Add dp phy poweron function in bind time.
- Move the panel prepare from get_modes time to bind time, and move
  the panel unprepare from bridge->disable to unbind time. (Heiko)

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Take Jingoo suggest, add commit messages.

Changes in v3:
- move dp hpd detect to connector detect function.

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 38 --
 1 file changed, 20 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 9eb17ce..952c2c3 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}

-   ret = analogix_dp_detect_hpd(dp);
-   if (ret) {
-   /* Cable has been disconnected, we're done */
-   return;
-   }
-
ret = analogix_dp_handle_edid(dp);
if (ret) {
dev_err(dp->dev, "unable to handle edid\n");
@@ -941,6 +935,11 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)

 enum drm_connector_status analogix_dp_detect(struct device *dev, bool force)
 {
+   struct analogix_dp_device *dp = dev_get_drvdata(dev);
+
+   if (analogix_dp_detect_hpd(dp))
+   return connector_status_disconnected;
+
return connector_status_connected;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_detect);
@@ -1006,13 +1005,6 @@ static void analogix_dp_bridge_enable(struct drm_bridge 
*bridge)

pm_runtime_get_sync(dp->dev);

-   if (dp->plat_data->panel) {
-   if (drm_panel_prepare(dp->plat_data->panel)) {
-   DRM_ERROR("failed to setup the panel\n");
-   return;
-   }
-   }
-
if (dp->plat_data->power_on)
dp->plat_data->power_on(dp->plat_data);

@@ -1045,11 +1037,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
if (dp->plat_data->power_off)
dp->plat_data->power_off(dp->plat_data);

-   if (dp->plat_data->panel) {
-   if (drm_panel_unprepare(dp->plat_data->panel))
-   DRM_ERROR("failed to turnoff the panel\n");
-   }
-
pm_runtime_put_sync(dp->dev);

dp->dpms_mode = DRM_MODE_DPMS_OFF;
@@ -1307,6 +1294,15 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,

pm_runtime_enable(dev);

+   phy_power_on(dp->phy);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EBUSY;
+   }
+   }
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
   irq_flags, "analogix-dp", dp);
if (ret) {
@@ -1340,6 +1336,12 @@ void analogix_dp_unbind(struct device *dev, struct 
device *master,
struct analogix_dp_device *dp = dev_get_drvdata(dev);

analogix_dp_bridge_disable(dp->bridge);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_unprepare(dp->plat_data->panel))
+   DRM_ERROR("failed to turnoff the panel\n");
+   }
+
pm_runtime_disable(dev);
 }
 EXPORT_SYMBOL_GPL(analogix_dp_unbind);
-- 
1.9.1

[PATCH v11 16/19] drm: bridge: analogix/dp: add edid modes parse in get_modes method

[Yakir Yang]

Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.

Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not start enabling DP at bind() phase

But for now driver need to read edid message in .get_modes()
function, so controller must be inited in bind time, so we
need to add controller init back.

Signed-off-by: Yakir Yang 
Tested-by: Javier Martinez Canillas 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4:
- Call drm_panel_prepare() in .get_modes function, ensure panel should
  power on before driver try to read edid message.

Changes in v3:
- Add edid modes parse support

Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 19 +
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h | 46 +++---
 2 files changed, 35 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 952c2c3..d18054d 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -107,7 +107,7 @@ static unsigned char 
analogix_dp_calc_edid_check_sum(unsigned char *edid_data)

 static int analogix_dp_read_edid(struct analogix_dp_device *dp)
 {
-   unsigned char edid[EDID_BLOCK_LENGTH * 2];
+   unsigned char *edid = dp->edid;
unsigned int extend_block = 0;
unsigned char sum;
unsigned char test_vector;
@@ -901,12 +901,6 @@ static void analogix_dp_commit(struct analogix_dp_device 
*dp)
DRM_ERROR("failed to disable the panel\n");
}

-   ret = analogix_dp_handle_edid(dp);
-   if (ret) {
-   dev_err(dp->dev, "unable to handle edid\n");
-   return;
-   }
-
ret = analogix_dp_set_link_train(dp, dp->video_info.max_lane_count,
 dp->video_info.max_link_rate);
if (ret) {
@@ -947,8 +941,17 @@ EXPORT_SYMBOL_GPL(analogix_dp_detect);
 int analogix_dp_get_modes(struct device *dev)
 {
struct analogix_dp_device *dp = dev_get_drvdata(dev);
+   struct edid *edid = (struct edid *)dp->edid;
int num_modes = 0;

+   if (analogix_dp_handle_edid(dp)) {
+   dev_err(dp->dev, "unable to handle edid\n");
+   return -EINVAL;
+   }
+
+   drm_mode_connector_update_edid_property(dp->connector, edid);
+   num_modes += drm_add_edid_modes(dp->connector, edid);
+
if (dp->plat_data->panel)
num_modes += drm_panel_get_modes(dp->plat_data->panel);

@@ -1303,6 +1306,8 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
}
}

+   analogix_dp_init_dp(dp);
+
ret = devm_request_irq(&pdev->dev, dp->irq, analogix_dp_irq_handler,
   irq_flags, "analogix-dp", dp);
if (ret) {
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index baa06e2..73b780e 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -20,6 +20,28 @@
 #define MAX_CR_LOOP5
 #define MAX_EQ_LOOP5

+/* I2C EDID Chip ID, Slave Address */
+#define I2C_EDID_DEVICE_ADDR   0x50
+#define I2C_E_EDID_DEVICE_ADDR 0x30
+
+#define EDID_BLOCK_LENGTH  0x80
+#define EDID_HEADER_PATTERN0x00
+#define EDID_EXTENSION_FLAG0x7e
+#define EDID_CHECKSUM  0x7f
+
+/* DP_MAX_LANE_COUNT */
+#define DPCD_ENHANCED_FRAME_CAP(x) (((x) >> 7) & 0x1)
+#define DPCD_MAX_LANE_COUNT(x) ((x) & 0x1f)
+
+/* DP_LANE_COUNT_SET */
+#define DPCD_LANE_COUNT_SET(x) ((x) & 0x1f)
+
+/* DP_TRAINING_LANE0_SET */
+#define DPCD_PRE_EMPHASIS_SET(x)   (((x) & 0x3) << 3)
+#define DPCD_PRE_EMPHASIS_GET(x)   (((x) >> 3) & 0x3)
+#define DPCD_VOLTAGE_SWING_SET(x)  (((x) & 0x3) << 0)
+#define DPCD_VOLTAGE_SWING_GET(x)  (((x) >> 0) & 0x3)
+
 enum link_rate_type {
LINK_RATE_1_62GBPS = DP_LINK_BW_1_62,
LINK_RATE_2_70GBPS = DP_LINK_BW_2_7,
@@ -161,6 +183,7 @@ struct analogix_dp_device {
int dpms_mode;
int hpd_gpio;
boolforce_hpd;
+   unsigned char   edid[EDID_BLOCK_LENGTH * 2];

struct analogix_dp_plat_data *plat_data;
 };
@@ -260,27 +283,4 @@ int analogix_dp_is_video_stream_on(struct 
analogix_dp_device *dp);
 void analogix_dp_config_video_slave_mode(st

[PATCH v11 17/19] drm: bridge: analogix/dp: expand the look time for waiting AUX CH reply

[Yakir Yang]

After test on rockchiop platform, i found sometims driver would failed
at reading EDID message. After debugging more, i found that it's okay
to read_a byte from i2c, but it would failed at AUX transcation if we
try to ready multi-bytes from i2c.

Driver just can't received the AUX CH reply command, even no AUX error
code. I may guess that the AUX wait time is not enough, so I try to
expand the AUX wait time, and i do see this could fix the EDID read
failed at rockchip platform.

And I thought that expand the wait time won't hurt Exynos platform too
much, cause Exynos didn't have this problem, then driver would received
the reply command very soon, so no more additional wait time would bring
to Exynos platform.

Signed-off-by: Yakir Yang 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index c7e2959..dc376bd 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -482,7 +482,7 @@ int analogix_dp_start_aux_transaction(struct 
analogix_dp_device *dp)
reg = readl(dp->reg_base + ANALOGIX_DP_INT_STA);
while (!(reg & RPLY_RECEIV)) {
timeout_loop++;
-   if (DP_TIMEOUT_LOOP_COUNT < timeout_loop) {
+   if (DP_TIMEOUT_LOOP_COUNT * 10 < timeout_loop) {
dev_err(dp->dev, "AUX CH command reply failed!\n");
return -ETIMEDOUT;
}
-- 
1.9.1

[PATCH v11 18/19] drm: bridge: analogix/dp: add panel prepare/unprepare in suspend/resume time

[Yakir Yang]

Turn off the panel power in suspend time would help to reduce
power waste.

Signed-off-by: Yakir Yang 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index d18054d..bc4a9e0 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1357,6 +1357,12 @@ int analogix_dp_suspend(struct device *dev)
struct analogix_dp_device *dp = dev_get_drvdata(dev);

clk_disable_unprepare(dp->clock);
+
+   if (dp->plat_data->panel) {
+   if (drm_panel_unprepare(dp->plat_data->panel))
+   DRM_ERROR("failed to turnoff the panel\n");
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_suspend);
@@ -1372,6 +1378,13 @@ int analogix_dp_resume(struct device *dev)
return ret;
}

+   if (dp->plat_data->panel) {
+   if (drm_panel_prepare(dp->plat_data->panel)) {
+   DRM_ERROR("failed to setup the panel\n");
+   return -EBUSY;
+   }
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(analogix_dp_resume);
-- 
1.9.1

[PATCH v11 19/19] drm: bridge: analogix/dp: Fix the possible dead lock in bridge disable time

[Yakir Yang]

It may caused a dead lock if we flush the hpd work in bridge disable time.

The normal flow would like:
  IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to run the work function.
  OUT <-- analogix_dp_bridge
  OUT <-- DRM IOCTL

The dead lock flow would like:
  IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
  IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
  IN --> analogix_dp_hotplug
  IN --> drm_helper_hpd_irq_event
3. Acquire mode_config lock (This lock already have been acquired in 
previous step 1)
** Dead Lock Now **

It's wrong to flush the hpd work in bridge->disable time, I guess the
original code just want to ensure the delay work must be finish before
encoder disabled.

The flush work in bridge disable time is try to ensure the HPD event
won't be missed before display card disabled, actually we can take a
fast respond way(interrupt thread) to update DRM HPD event to fix the
delay update and possible dead lock.

Signed-off-by: Yakir Yang 
---
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 62 ++
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |  3 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  | 26 +
 3 files changed, 55 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index bc4a9e0..c66c522 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -848,47 +848,40 @@ static void analogix_dp_enable_scramble(struct 
analogix_dp_device *dp,
}
 }

-static irqreturn_t analogix_dp_irq_handler(int irq, void *arg)
+static irqreturn_t analogix_dp_hardirq(int irq, void *arg)
 {
struct analogix_dp_device *dp = arg;
-
+   irqreturn_t ret = IRQ_NONE;
enum dp_irq_type irq_type;

irq_type = analogix_dp_get_irq_type(dp);
-   switch (irq_type) {
-   case DP_IRQ_TYPE_HP_CABLE_IN:
-   dev_dbg(dp->dev, "Received irq - cable in\n");
-   schedule_work(&dp->hotplug_work);
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   case DP_IRQ_TYPE_HP_CABLE_OUT:
-   dev_dbg(dp->dev, "Received irq - cable out\n");
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   case DP_IRQ_TYPE_HP_CHANGE:
-   /*
-* We get these change notifications once in a while, but there
-* is nothing we can do with them. Just ignore it for now and
-* only handle cable changes.
-*/
-   dev_dbg(dp->dev, "Received irq - hotplug change; ignoring.\n");
-   analogix_dp_clear_hotplug_interrupts(dp);
-   break;
-   default:
-   dev_err(dp->dev, "Received irq - unknown type!\n");
-   break;
+   if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+   analogix_dp_mute_hpd_interrupt(dp);
+   ret = IRQ_WAKE_THREAD;
}
-   return IRQ_HANDLED;
+
+   return ret;
 }

-static void analogix_dp_hotplug(struct work_struct *work)
+static irqreturn_t analogix_dp_irq_thread(int irq, void *arg)
 {
-   struct analogix_dp_device *dp;
+   struct analogix_dp_device *dp = arg;
+   enum dp_irq_type irq_type;
+
+   irq_type = analogix_dp_get_irq_type(dp);
+   if (irq_type & DP_IRQ_TYPE_HP_CABLE_IN ||
+   irq_type & DP_IRQ_TYPE_HP_CABLE_OUT) {
+   dev_dbg(dp->dev, "Detected cable status changed!\n");
+   if (dp->drm_dev)
+   drm_helper_hpd_irq_event(dp->drm_dev);
+   }

-   dp = container_of(work, struct analogix_dp_device, hotplug_work);
+   if (irq_type != DP_IRQ_TYPE_UNKNOWN) {
+   analogix_dp_clear_hotplug_interrupts(dp);
+   analogix_dp_unmute_hpd_interrupt(dp);
+   }

-   if (dp->drm_dev)
-   drm_helper_hpd_irq_event(dp->drm_dev);
+   return IRQ_HANDLED;
 }

 static void analogix_dp_commit(struct analogix_dp_device *dp)
@@ -1034,7 +1027,6 @@ static void analogix_dp_bridge_disable(struct drm_bridge 
*bridge)
}

disable_irq(dp->irq);
-   flush_work(&dp->hotplug_work);
phy_power_off(dp->phy);

if (dp->plat_data->power_off)
@@ -1293,8 +1285,6 @@ int analogix_dp_bind(struct device *dev, struct 
drm_device *drm_dev,
return -ENODEV;
}

-   INIT_WORK(&dp->hotplug_work, analogix_dp_hotplug);
-
pm_runtime_enable(dev);

phy_power_on(dp->phy);
@@ -1308,8 +1298,

[PATCH 00/12] drm/tilcdc: fixes and added features from TI tree

[Tomi Valkeinen]

Hi,

On 15/12/15 21:03, Jyri Sarha wrote:
> Most of these patches are quite old and they have been used in TI
> linux for some time already. I forward ported the applicaple patches
> from TI tree on top of the latest drm-next, fixed checkpatch issues
> and tested the driver.

I think patches 6-10 can be dropped, as the other not-yet-posted series
will fix those issues properly.

Patch 1 is unclear. We have similar one for omapdrm in the TI kernel,
but I haven't pushed it to mainline as I'm not sure if it's valid. No
other driver seems to need it.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151216/41ae34c9/attachment.sig>

[PATCH v2] drm/i915: Send a hotplug event on resume instead of an IRQ event

[Daniel Vetter]

On Tue, Dec 15, 2015 at 05:25:56PM -0500, Lyude wrote:
> We currently call drm_helper_hpd_irq_event() to handle reprobing
> displays on resume, however drm_helper_hpd_irq_event() only checks the
> status of hpd. HPD doesn't update if the displays connected changed
> before resuming the system, and as such causes us not to detect any
> connection changes after resume.
> 
> This originally wasn't the case since drm would reset all of the
> connectors to unknown during resume and cause a reprobe (since the
> connector statuses would change), however this behavior changed in
> 5677d67ae394 ('drm: Stop resetting connector state to unknown').
> 
> Signed-off-by: Lyude 
> ---
> I did some research into why setting the connector state to unknown was
> causing a reprobe and discovered that the fact that this reprobing ever
> worked at all was just a coincidence (i915's IRQ handler gets called by the
> irq event, notices the state of all the connectors changed since they were
> set to unknown, causes a reprobe). This seems to fix everything (including
> monitor detection in normal VTs), and I can't figure out any real use now
> for us to set everything to unknown so I'm going to go the route of just
> sending the hotplug event instead.
> 
>  drivers/gpu/drm/i915/i915_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 760e0ce..27a6c1b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -792,7 +792,7 @@ static int i915_drm_resume(struct drm_device *dev)
>* */
>   intel_hpd_init(dev_priv);
>   /* Config may have changed between suspend and resume */
> - drm_helper_hpd_irq_event(dev);
> + drm_kms_helper_hotplug_event(dev);

So there's a bunch of things broken in this area, but just from your
description it's unclear what exactly. Problems I'm aware of:

- hpd_irq_event() only reprobes connectors for which hpd is enabled, which
  are not all of them. We broke this in

  commit 816da85a0990c2b52cfffa77637d1c770d6790e9
  Author: Daniel Vetter 
  Date:   Tue Oct 23 18:23:33 2012 +

  drm: handle HPD and polled connectors separately

  which is positively ages ago. Also note that any other driver not using
  vt switching also suffers from this (atm radeon, nouveau, rockchip,
  amdgpu). otoh at least from a quick those drivers also don't really
  bother with reprobing on resume really.

- DP MST reprobing is busted in i915 since

  commit e7d6f7d708290da1b7c92f533444b042c79412e0
  Author: Dave Airlie 
  Date:   Mon Dec 8 13:23:37 2014 +1000

  drm/i915: resume MST after reading back hw state

  There's some bug reports iirc from Takashi and Ted Tso about this. Your
  patch won't help for DP MST since we never reprobe MST state from
  userspace, it only ever happens through interrupt handling. Well mostly,
  if you completely unplug something then we detect that and throw all the
  MST stuff over board, but if you e.g. just change a connection in your
  dock or go from one dock to another we won't detect this.

Which one of the above is it? And to what extend do you care about this
working everywhere?

Sorry that I'm opening a can of worms here.

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

[PATCH] android: fix warning when releasing active sync point

[Maarten Lankhorst]

Op 15-12-15 om 18:19 schreef Dmitry Torokhov:
> On Tue, Dec 15, 2015 at 2:01 AM, Maarten Lankhorst
>  wrote:
>> Op 15-12-15 om 02:29 schreef Dmitry Torokhov:
>>> Userspace can close the sync device while there are still active fence
>>> points, in which case kernel produces the following warning:
>>>
>>> [   43.853176] [ cut here ]
>>> [   43.857834] WARNING: CPU: 0 PID: 892 at 
>>> /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439
>>>  android_fence_release+0x88/0x104()
>>> [   43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 
>>> 3.18.0-07661-g0550ce9 #1
>>> [   43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
>>> [   43.885834] Call trace:
>>> [   43.888294] [] dump_backtrace+0x0/0x10c
>>> [   43.893697] [] show_stack+0x10/0x1c
>>> [   43.898756] [] dump_stack+0x74/0xb8
>>> [   43.903814] [] warn_slowpath_common+0x84/0xb0
>>> [   43.909736] [] warn_slowpath_null+0x14/0x20
>>> [   43.915482] [] android_fence_release+0x84/0x104
>>> [   43.921582] [] fence_release+0x104/0x134
>>> [   43.927066] [] sync_fence_free+0x74/0x9c
>>> [   43.932552] [] sync_fence_release+0x34/0x48
>>> [   43.938304] [] __fput+0x100/0x1b8
>>> [   43.943185] [] fput+0x8/0x14
>>> [   43.947982] [] task_work_run+0xb0/0xe4
>>> [   43.953297] [] do_notify_resume+0x44/0x5c
>>> [   43.958867] ---[ end trace 5a2aa4027cc5d171 ]---
>>>
>>> Let's fix it by introducing a new optional callback (disable_signaling)
>>> to fence operations so that drivers can do proper clean ups when we
>>> remove last callback for given fence.
>>>
>>> Reviewed-by: Andrew Bresticker 
>>> Signed-off-by: Dmitry Torokhov 
>>>
>> NACK! There's no way to do this race free.
> Can you please explain the race because as far as I can see there is not one.\
The entire code in fence.c assumes that a fence can only go from not 
enable_signaling to .enable_signaling. .enable_signaling is not refcounted so 2 
calls to .enable_disabling and 1 to .disable_signaling would mess up.
Furthermore we try to make sure that fence_signal doesn't take locks if its 
unneeded. With a disable_signaling callback you would always need locks.

To get rid of these warnings make sure that there's a refcount on the fence 
until it's signaled.
>> The driver should hold a refcount until fence is signaled.
> If we are no longer interested in fence why do we need to wait for the
> fence to be signaled?
It's the part of the design. A driver tracks its outstanding requests and 
submissions, and every submission has its own fence. Before the driver releases 
its final ref the request should be completed or aborted. In either case it 
must call fence_signal.

[PATCH 03/12] drm/tilcdc: verify fb pitch

[Daniel Vetter]

On Tue, Dec 15, 2015 at 09:03:14PM +0200, Jyri Sarha wrote:
> From: Tomi Valkeinen 
> 
> LCDC hardware does not support fb pitch that is different (i.e. larger)
> than the screen size. The driver currently does no checks for this, and
> the results of too big pitch are are flickering and lower fps.
> 
> This issue easily happens when using libdrm's modetest tool with non-32
> bpp modes. As modetest always allocated 4 bytes per pixel, it implies a
> bigger pitch for 16 or 24 bpp modes.
> 
> This patch adds a check to reject pitches the hardware cannot support.
> 
> Signed-off-by: Tomi Valkeinen 
> Signed-off-by: Darren Etheridge 
> Signed-off-by: Jyri Sarha 
> ---
>  drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c 
> b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> index 7b687ae..105f286 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_crtc.c
> @@ -151,6 +151,22 @@ static void tilcdc_crtc_destroy(struct drm_crtc *crtc)
>   kfree(tilcdc_crtc);
>  }
>  
> +static int tilcdc_verify_fb(struct drm_crtc *crtc, struct drm_framebuffer 
> *fb)
> +{
> + struct drm_device *dev = crtc->dev;
> + unsigned int depth, bpp;
> +
> + drm_fb_get_bpp_depth(fb->pixel_format, &depth, &bpp);
> +
> + if (fb->pitches[0] != crtc->mode.hdisplay * bpp / 8) {
> + dev_err(dev->dev,
> + "Invalid pitch: fb and crtc widths must be the same");
> + return -EINVAL;
> + }
> +
> + return 0;

This should be done in framebuffer_create instead if tilcdc has this
requirement everywhere. No point in allowing userspace to create an fb you
can't use. Only if you have planes with different limits should this be
checked after fb creation.

Also with atomic you'd only need to place this in one function, even if
you have different per-plane limitations ... hint, hint ;-)

Cheers, Daniel


> +}
> +
>  static int tilcdc_crtc_page_flip(struct drm_crtc *crtc,
>   struct drm_framebuffer *fb,
>   struct drm_pending_vblank_event *event,
> @@ -158,6 +174,11 @@ static int tilcdc_crtc_page_flip(struct drm_crtc *crtc,
>  {
>   struct tilcdc_crtc *tilcdc_crtc = to_tilcdc_crtc(crtc);
>   struct drm_device *dev = crtc->dev;
> + int r;
> +
> + r = tilcdc_verify_fb(crtc, fb);
> + if (r)
> + return r;
>  
>   if (tilcdc_crtc->event) {
>   dev_err(dev->dev, "already pending page flip!\n");
> @@ -272,6 +293,10 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
>   if (WARN_ON(!info))
>   return -EINVAL;
>  
> + ret = tilcdc_verify_fb(crtc, crtc->primary->fb);
> + if (ret)
> + return ret;
> +
>   pm_runtime_get_sync(dev->dev);
>  
>   /* Configure the Burst Size and fifo threshold of DMA: */
> @@ -431,6 +456,12 @@ static int tilcdc_crtc_mode_set(struct drm_crtc *crtc,
>  static int tilcdc_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
>   struct drm_framebuffer *old_fb)
>  {
> + int r;
> +
> + r = tilcdc_verify_fb(crtc, crtc->primary->fb);
> + if (r)
> + return r;
> +
>   update_scanout(crtc);
>   return 0;
>  }
> -- 
> 1.9.1
> 

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

[PATCH v7 02/14] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.

[Philipp Zabel]

Hi Daniel,

Am Dienstag, den 15.12.2015, 02:57 +0800 schrieb Daniel Kurtz:
> HI Philipp,
> 
> This driver is looking really good.
> 
> But, still some things to think about (mostly small) inline below...

Most of my answers below seem to be "ok" or some form thereof, but I
have one or two questions regarding the layer_config and crtc_reset
suggestions.

[...]
> > diff --git a/drivers/gpu/drm/mediatek/Kconfig 
> > b/drivers/gpu/drm/mediatek/Kconfig
> > new file mode 100644
> > index 000..5343cf1
> > --- /dev/null
> > +++ b/drivers/gpu/drm/mediatek/Kconfig
> > @@ -0,0 +1,16 @@
> > +config DRM_MEDIATEK
> > +   tristate "DRM Support for Mediatek SoCs"
> > +   depends on DRM
> > +   depends on ARCH_MEDIATEK || (ARM && COMPILE_TEST)
> > +   select MTK_SMI
> > +   select DRM_PANEL
> > +   select DRM_MIPI_DSI
> > +   select DRM_PANEL_SIMPLE
> > +   select DRM_KMS_HELPER
> > +   select IOMMU_DMA
> 
> nit: alphabetize these selects ?

Ok.

[...]
> > +#define DISP_REG_OVL_CON(n)(0x0030 + 0x20 * n)
> 
> nit: it is recommended to always enclose macro arguments in ():
> 
>  (0x0030 + 0x20 * (n))
>
> > +#define DISP_REG_OVL_SRC_SIZE(n)   (0x0038 + 0x20 * n)
> > +#define DISP_REG_OVL_OFFSET(n) (0x003c + 0x20 * n)
> > +#define DISP_REG_OVL_PITCH(n)  (0x0044 + 0x20 * n)
> > +#define DISP_REG_OVL_RDMA_CTRL(n)  (0x00c0 + 0x20 * n)
> > +#define DISP_REG_OVL_RDMA_GMC(n)   (0x00c8 + 0x20 * n)
> > +#define DISP_REG_OVL_ADDR(n)   (0x0f40 + 0x20 * n)

Thanks for the pointer, I'll change those.

[...]
> > +static void mtk_ovl_enable_vblank(void __iomem *disp_base)
> 
> It would be more consistent to pass struct mtk_ddp_comp *comp to all of these
> functions.

Yes.

> > +{
> > +   writel(OVL_FME_CPL_INT, disp_base + DISP_REG_OVL_INTEN);
> 
> I think most of these can be writel_relaxed() instead of writel().
> 
> > +}
> > +
> > +static void mtk_ovl_disable_vblank(void __iomem *disp_base)
> > +{
> > +   writel(0x0, disp_base + DISP_REG_OVL_INTEN);
> > +}
> > +
> > +static void mtk_ovl_start(struct mtk_ddp_comp *comp)
> > +{
> > +   writel(0x1, comp->regs + DISP_REG_OVL_EN);
> > +}
> > +
> > +static void mtk_ovl_stop(struct mtk_ddp_comp *comp)
> > +{
> > +   writel(0x0, comp->regs + DISP_REG_OVL_EN);
> > +}
> > +
> > +static void mtk_ovl_config(void __iomem *ovl_base,
> > +   unsigned int w, unsigned int h, unsigned int vrefresh)
> > +{
> > +   if (w != 0 && h != 0)
> > +   writel(h << 16 | w, ovl_base + DISP_REG_OVL_ROI_SIZE);
> > +   writel(0x0, ovl_base + DISP_REG_OVL_ROI_BGCLR);
> > +
> > +   writel(0x1, ovl_base + DISP_REG_OVL_RST);
> > +   writel(0x0, ovl_base + DISP_REG_OVL_RST);
> 
> These two probably do have to be writel().

Ack.

[...]
> > +static void mtk_ovl_layer_on(void __iomem *ovl_base, unsigned int idx)
> > +{
> > +   unsigned int reg;
> > +
> > +   writel(0x1, ovl_base + DISP_REG_OVL_RDMA_CTRL(idx));
> > +   writel(OVL_RDMA_MEM_GMC, ovl_base + DISP_REG_OVL_RDMA_GMC(idx));
> > +
> > +   reg = readl(ovl_base + DISP_REG_OVL_SRC_CON);
> > +   reg = reg | (1 << idx);
> 
> nit(?):
>  reg |= BIT(idx);
>
> > +   writel(reg, ovl_base + DISP_REG_OVL_SRC_CON);
> > +}
> > +
> > +static void mtk_ovl_layer_off(void __iomem *ovl_base, unsigned int idx)
> > +{
> > +   unsigned int reg;
> > +
> > +   reg = readl(ovl_base + DISP_REG_OVL_SRC_CON);
> > +   reg = reg & ~(1 << idx);
> 
> nit(?):
>  reg &= ~BIT(idx);

Ok.

[...]
> > +static void mtk_ovl_layer_config(void __iomem *ovl_base, unsigned int idx,
> > +   struct mtk_plane_state *state)
> > +{
> > +   struct mtk_plane_pending_state *pending = &state->pending;
> > +   unsigned int addr = pending->addr;
> > +   unsigned int pitch = pending->pitch & 0x;
> > +   unsigned int fmt = pending->format;
> > +   unsigned int offset = (pending->y << 16) | pending->x;
> > +   unsigned int src_size = (pending->height << 16) | pending->width;
> > +   unsigned int con;
> > +
> > +   con = has_rb_swapped(fmt) << 24 | ovl_fmt_convert(fmt) << 12;
> 
> Call these conversion routines earlier (during atomic_check) and just add the
> resulting "con" value to pending.

You mean to add a .layer_atomic_check callback to the mtk_ddp_comp ops?

[...]
> > +/**
> > + * struct mtk_drm_crtc - MediaTek specific crtc structure.
> > + * @base: crtc object.
> > + * @pipe: a crtc index created at load() with a new crtc object creation
> > + * and the crtc object would be set to private->crtc array
> > + * to get a crtc object corresponding to this pipe from private->crtc
> > + * array when irq interrupt occurred. the reason of using this pipe is 
> > that
> > + * drm framework doesn't support multiple irq yet.
> > + * we can refer to the crtc to current hardware interrupt occurred 
> > through
> > + * this pipe valu

[PATCH v6 0/6] Add mipi dsi support for rk3288

[Chris Zhong]

The rk3288 MIPI DSI is a Synopsys DesignWare MIPI DSI host controller
IP. This series adds support for a Synopsys DesignWare MIPI DSI host
controller DRM driver.

The MIPI DSI feature is tested on rk3288 evb board, backport them to
chrome os kernel chrome_v3.14, and it can display normally.

This patchset is base on the patchset from Ying.liu at freescale.com.


According to the suggestion from Thierry, I have get rid of the bridge,
and register the encoder & connecter in drm/rockchip/dw-mipi-dsi.c.


Changes in v6:
- update the document, since the bridge device has been deleted.
- Do not use bridge driver (Thierry Reding)
- Optimization the phy init sequence

Changes in v5:
- modify the clk name to SCLK_MIPIDSI_24M
- add a blank line befor lcd_en

Changes in v4:
- use clk_round_rate to check the clock rate in vop_crtc_mode_fixup

Changes in v3:
- move dw_mipi_dsi_rockchip.txt to bindings/display/rockchip/

Chris Zhong (5):
  drm/rockchip: return a true clock rate to adjusted_mode
  Documentation: dt-bindings: Add bindings for rk3288 DW MIPI DSI driver
  drm: rockchip: Support Synopsys DW MIPI DSI
  ARM: dts: rockchip: add rk3288 mipi_dsi nodes
  ARM: dts: rockchip: add support mipi panel tv080wum-nl0

Liu Ying (1):
  drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

 .../display/rockchip/dw_mipi_dsi_rockchip.txt  |   60 +
 arch/arm/boot/dts/rk3288-evb.dtsi  |   20 +-
 arch/arm/boot/dts/rk3288.dtsi  |   39 +
 drivers/gpu/drm/rockchip/Kconfig   |   10 +
 drivers/gpu/drm/rockchip/Makefile  |1 +
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 1200 
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c|8 +
 include/drm/drm_mipi_dsi.h |   14 +
 8 files changed, 1351 insertions(+), 1 deletion(-)
 create mode 100644 
Documentation/devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt
 create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c

-- 
2.6.3

[PATCH v6 1/6] drm/rockchip: return a true clock rate to adjusted_mode

[Chris Zhong]

Since the mipi dsi driver need to use the clock of vop to make the
calculation of Blanking. But sometimes the clock driver can not set a
accurate clock_rate for vop, get it by clk_round_rate before mode_set,
so we can get the true value.

Signed-off-by: Chris Zhong 
Acked-by: Mark Yao 

---

Changes in v6: None
Changes in v5: None
Changes in v4:
- use clk_round_rate to check the clock rate in vop_crtc_mode_fixup

Changes in v3: None

 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 696e977..d9ec780 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1146,9 +1146,14 @@ static bool vop_crtc_mode_fixup(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode)
 {
+   struct vop *vop = to_vop(crtc);
+
if (adjusted_mode->htotal == 0 || adjusted_mode->vtotal == 0)
return false;

+   adjusted_mode->clock =
+   clk_round_rate(vop->dclk, mode->clock * 1000) / 1000;
+
return true;
 }

-- 
2.6.3

[PATCH v6 2/6] drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

[Chris Zhong]

From: Liu Ying 

Signed-off-by: Liu Ying 
Acked-by: Thierry Reding 
Signed-off-by: Chris Zhong 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 include/drm/drm_mipi_dsi.h | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index f1d8d0d..3662021 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -163,6 +163,20 @@ static inline struct mipi_dsi_device 
*to_mipi_dsi_device(struct device *dev)
return container_of(dev, struct mipi_dsi_device, dev);
 }

+static inline int mipi_dsi_pixel_format_to_bpp(enum mipi_dsi_pixel_format fmt)
+{
+   switch (fmt) {
+   case MIPI_DSI_FMT_RGB888:
+   case MIPI_DSI_FMT_RGB666:
+   return 24;
+   case MIPI_DSI_FMT_RGB666_PACKED:
+   return 18;
+   case MIPI_DSI_FMT_RGB565:
+   return 16;
+   }
+   return -EINVAL;
+}
+
 struct mipi_dsi_device *of_find_mipi_dsi_device_by_node(struct device_node 
*np);
 int mipi_dsi_attach(struct mipi_dsi_device *dsi);
 int mipi_dsi_detach(struct mipi_dsi_device *dsi);
-- 
2.6.3

[PATCH v6 4/6] drm: rockchip: Support Synopsys DW MIPI DSI

[Chris Zhong]

Add support for Synopsys DesignWare MIPI DSI controller which is
embedded in the rk3288 SoCs.

Signed-off-by: Chris Zhong 
---

Changes in v6:
- Do not use bridge driver (Thierry Reding)
- Optimization the phy init sequence

Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/gpu/drm/rockchip/Kconfig|   10 +
 drivers/gpu/drm/rockchip/Makefile   |1 +
 drivers/gpu/drm/rockchip/dw-mipi-dsi.c  | 1200 +++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |3 +
 4 files changed, 1214 insertions(+)
 create mode 100644 drivers/gpu/drm/rockchip/dw-mipi-dsi.c

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index 686cb49..1db1b86 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -34,3 +34,13 @@ config ROCKCHIP_ANALOGIX_DP
  This selects support for Rockchip SoC specific extensions
  for the Analogix Core DP driver. If you want to enable DP
  on RK3288 based SoC, you should selet this option.
+
+config ROCKCHIP_DW_MIPI_DSI
+   bool "Rockchip specific extensions for Synopsys DW MIPI DSI"
+   depends on DRM_ROCKCHIP
+   select DRM_MIPI_DSI
+   help
+This selects support for Rockchip SoC specific extensions
+for the Synopsys DesignWare HDMI driver. If you want to
+enable MIPI DSI on RK3288 based SoC, you should selet this
+option.
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index 8ad01fb..c5c2d61 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -7,5 +7,6 @@ rockchipdrm-y := rockchip_drm_drv.o rockchip_drm_fb.o 
rockchip_drm_fbdev.o \

 obj-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
 obj-$(CONFIG_ROCKCHIP_ANALOGIX_DP) += analogix_dp-rockchip.o
+obj-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o

 obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o rockchip_drm_vop.o
diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
new file mode 100644
index 000..e38ae3f
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -0,0 +1,1200 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+
+#define DRIVER_NAME"dw-mipi-dsi"
+
+#define GRF_SOC_CON60x025c
+#define DSI0_SEL_VOP_LIT(1 << 6)
+#define DSI1_SEL_VOP_LIT(1 << 9)
+
+#define DSI_VERSION0x00
+#define DSI_PWR_UP 0x04
+#define RESET  0
+#define POWERUPBIT(0)
+
+#define DSI_CLKMGR_CFG 0x08
+#define TO_CLK_DIVIDSION(div)  (((div) & 0xff) << 8)
+#define TX_ESC_CLK_DIVIDSION(div)  (((div) & 0xff) << 0)
+
+#define DSI_DPI_VCID   0x0c
+#define DPI_VID(vid)   (((vid) & 0x3) << 0)
+
+#define DSI_DPI_COLOR_CODING   0x10
+#define EN18_LOOSELY   BIT(8)
+#define DPI_COLOR_CODING_16BIT_1   0x0
+#define DPI_COLOR_CODING_16BIT_2   0x1
+#define DPI_COLOR_CODING_16BIT_3   0x2
+#define DPI_COLOR_CODING_18BIT_1   0x3
+#define DPI_COLOR_CODING_18BIT_2   0x4
+#define DPI_COLOR_CODING_24BIT 0x5
+
+#define DSI_DPI_CFG_POL0x14
+#define COLORM_ACTIVE_LOW  BIT(4)
+#define SHUTD_ACTIVE_LOW   BIT(3)
+#define HSYNC_ACTIVE_LOW   BIT(2)
+#define VSYNC_ACTIVE_LOW   BIT(1)
+#define DATAEN_ACTIVE_LOW  BIT(0)
+
+#define DSI_DPI_LP_CMD_TIM 0x18
+#define OUTVACT_LPCMD_TIME(p)  (((p) & 0xff) << 16)
+#define INVACT_LPCMD_TIME(p)   ((p) & 0xff)
+
+#define DSI_DBI_CFG0x20
+#define DSI_DBI_CMDSIZE0x28
+
+#define DSI_PCKHDL_CFG 0x2c
+#define EN_CRC_RX  BIT(4)
+#define EN_ECC_RX  BIT(3)
+#define EN_BTA BIT(2)
+#define EN_EOTP_RX BIT(1)
+#define EN_EOTP_TX BIT(0)
+
+#define DSI_MODE_CFG   0x34
+#define ENABLE_VIDEO_MODE  0
+#define ENABLE_CMD_MODEBIT(0)
+
+#define DSI_VID_MODE_CFG   0x38
+#define FRAME_BTA_ACK  BIT(14)
+#define ENABLE_LOW_POWER   (0x3f << 8)
+#define ENABLE_LOW_POWER_MASK  (0x3f << 8)
+#define VID_MODE_TYPE_BURST_SYNC_PULSES0x2
+

[Nouveau] nouveau sync DMA memory not allocated

[poma]

On 12.11.2015 14:48, Thierry Reding wrote:
> On Wed, Nov 11, 2015 at 09:12:33PM +0100, poma wrote:
>> On 10.11.2015 17:25, Mario Kleiner wrote:
>>> On 11/10/2015 05:00 PM, Thierry Reding wrote:
 On Tue, Nov 10, 2015 at 03:54:52PM +0100, Mario Kleiner wrote:
> From: Daniel Vetter 
>
> Apparently pre-nv50 pageflip events happen before the actual vblank
> period. Therefore that functionality got semi-disabled in
>
> commit af4870e406126b7ac0ae7c7ce5751f25ebe60f28
> Author: Mario Kleiner 
> Date:   Tue May 13 00:42:08 2014 +0200
>
>  drm/nouveau/kms/nv04-nv40: fix pageflip events via special case.
>
> Unfortunately that hack got uprooted in
>
> commit cc1ef118fc099295ae6aabbacc8af94d8d8885eb
> Author: Thierry Reding 
> Date:   Wed Aug 12 17:00:31 2015 +0200
>
>  drm/irq: Make pipe unsigned and name consistent
>
> Trigering a warning when trying to sample the vblank timestamp for a
> non-existing pipe. There's a few ways to fix this:
>
> - Open-code the old behaviour, which just enshrines this slight
>breakage of the userspace ABI.
>
> - Revert Mario's commit and again inflict broken timestamps, again not
>pretty.
>
> - Fix this for real by delaying the pageflip TS until the next vblank
>interrupt, thereby making it accurate.
>
> This patch implements the third option. Since having a page flip
> interrupt that happens when the pageflip gets armed and not when it
> completes in the next vblank seems to be fairly common (older i915 hw
> works very similarly) create a new helper to arm vblank events for
> such drivers.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=106431
> Cc: Thierry Reding 
> Cc: Mario Kleiner 
> Cc: Ben Skeggs 
> Cc: Ilia Mirkin 
>
> v2 (mario): Integrate my own review comments into Daniels patch.
> - Fix function prototypes in drmP.h
> - Add missing vblank_put() for pageflip completion without
>   pageflip event.
> - Initialize sequence number for queued pageflip event to avoidng
>   trouble in drm_handle_vblank_events().
> - Remove dead code and spelling fix.
>
> v3 (mario): Add a signed-off-by and cc stable tag per Ilja's advice.
>
> Signed-off-by: Daniel Vetter 
> (v1) Reviewed-by: Mario Kleiner 
> (v2/v3) Signed-off-by: Mario Kleiner 
>
> Cc: stable at vger.kernel.org # v4.3
> ---
>   drivers/gpu/drm/drm_irq.c | 54 
> ++-
>   drivers/gpu/drm/nouveau/nouveau_display.c | 19 ++-
>   include/drm/drmP.h|  4 +++
>   3 files changed, 68 insertions(+), 9 deletions(-)

 This looks good to me. Let me clean this up a little and submit it to
 Dave.

 Thierry

>>>
>>> Btw., if somebody has a functional old card for testing this, it should 
>>> be easy to verify if it works on pre-nv50. If it would not work it would 
>>> deliver the pageflip event 1 frame delayed, so at least on standard 
>>> nouveau + default DRI2 + default double-buffering the rate for a tight 
>>> loop of page-flipped swaps should go down to 30 fps on a 60 Hz display, 
>>> quite noticeable. Afaik we also have Piglit tests for OML_sync_control 
>>> which would likely fail if this would be broken.
>>>
>>> Oh and if someone has tips on how to resurrect an old nv-40 PC (booted 
>>> with BIOS only) graphics card in a MacPro (EFI boot), i wouldn't mind 
>>> hearing them. It would be nice to still be able to use that card for 
>>> testing.
>>>
>>> thanks,
>>> -mario
>>
>>
>> [ cut here ]
>> WARNING: CPU: 0 PID: 313 at lib/dma-debug.c:1205 check_sync+0x169/0x6e0()
>> nouveau :01:00.0: DMA-API: device driver tries to sync DMA memory it has 
>> not allocated [device address=0xc0bf6468] [size=4096 bytes]
>> Modules linked in: nouveau(+) ...
>> CPU: 0 PID: 313 Comm: systemd-udevd Not tainted 4.3.0-3.fc22.i686+debug #1
>> ...
>> Call Trace:
>>  [] dump_stack+0x48/0x69
>>  [] warn_slowpath_common+0x87/0xc0
>>  [] ? check_sync+0x169/0x6e0
>>  [] ? check_sync+0x169/0x6e0
>>  [] warn_slowpath_fmt+0x3e/0x60
>>  [] check_sync+0x169/0x6e0
>>  [] debug_dma_sync_single_for_device+0x7d/0x90
>>  [] ? ttm_bo_del_sub_from_lru+0x18/0x50 [ttm]
>>  [] ? text_poke_bp+0xd0/0xd0
>>  [] nouveau_bo_sync_for_device+0x8b/0xa0 [nouveau]
>>  [] nouveau_bo_validate+0x34/0x40 [nouveau]
>>  [] nouveau_bo_pin+0x188/0x290 [nouveau]
>>  [] ? nv10_bo_put_tile_region+0x80/0x80 [nouveau]
>>  [] nouveau_channel_prep+0xfd/0x2c0 [nouveau]
>>  [] nouveau_channel_new+0x57/0x7a0 [nouveau]
>>  [] ? kfree+0xdc/0x280
>>  [] ? nvif_object_sclass_put+0x12/0x20 [nouveau]
>>  [] nouveau_drm_load+0x596/0x8d0 [nouveau]
>>  [] ? trace_hardirqs_on_caller+0x12c/0x1d0
>>  [] ? drm_minor_register+0x89/0x120 [drm]
>>  [] drm_dev_register+0x96/0xa0 [drm]
>> 

[PATCH v3 0/7] drm/exynos: rework layer blending

[Marek Szyprowski]

Hello all,

This is a continuation of the work started by Tobias Jakobi. The goal of
this patch set is to remove hardcoded blending setup from Exynos Mixer
driver. This patch also enables other Exynos DRM CRTC drivers to use the
configurable plane zpos feature, however patches for FIMD or Decon are
not yet ready.

The initial patches prepared by Tobias are available here:
http://lists.freedesktop.org/archives/dri-devel/2015-November/095080.html

Main changes in v3:
- added patches for changing zpos property and layer priority
  configuration
- simplified blending setup, removed special configuration for the bottom
  layer, removed layer cache
- significantly simplified the code
- rebased on top of exynos-drm-next branch

Best regards
Marek Szyprowski
Samsung R&D Institute Poland


Patch summary:

Marek Szyprowski (5):
  drm/exynos: rename zpos to index
  drm/exynos: make zpos property configurable
  drm/exynos: mixer: set window priority based on zpos
  drm/exynos: mixer: refactor layer setup
  drm/exynos: mixer: unify a check for video-processor window

Tobias Jakobi (2):
  drm/exynos: mixer: remove all static blending setup
  drm/exynos: mixer: also allow ARGB1555 and ARGB

 drivers/gpu/drm/exynos/exynos5433_drm_decon.c |  10 +--
 drivers/gpu/drm/exynos/exynos7_drm_decon.c|  10 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |   8 +-
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  10 +--
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  55 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.h |   2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |   2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c | 123 --
 drivers/gpu/drm/exynos/regs-mixer.h   |   4 +
 9 files changed, 150 insertions(+), 74 deletions(-)

-- 
1.9.2

[PATCH v3 3/7] drm/exynos: mixer: set window priority based on zpos

[Marek Szyprowski]

'zpos' plane property is configurable, so adjust hardware layers
priority based on the zpos value. 'zpos' value shifted by one can be
used directly as hw priority value and stored to the registers, because
mixer accepts priority values from 1 to 15 (0 means that layer is
disabled).

This patch also changes the default layer priority to match already
exposed initial zpos values. The initial configuration is now:
[top] video > gfx layer1 > gfx layer0 [bottom].

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 39 +++
 drivers/gpu/drm/exynos/regs-mixer.h   |  3 +++
 2 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 0dceeb2b532c..c0d128bc084b 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -117,19 +117,22 @@ static const struct exynos_drm_plane_config 
plane_configs[MIXER_WIN_NR] = {
.type = DRM_PLANE_TYPE_PRIMARY,
.pixel_formats = mixer_formats,
.num_pixel_formats = ARRAY_SIZE(mixer_formats),
-   .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE,
+   .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE |
+   EXYNOS_DRM_PLANE_CAP_ZPOS,
}, {
.zpos = 1,
.type = DRM_PLANE_TYPE_CURSOR,
.pixel_formats = mixer_formats,
.num_pixel_formats = ARRAY_SIZE(mixer_formats),
-   .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE,
+   .capabilities = EXYNOS_DRM_PLANE_CAP_DOUBLE |
+   EXYNOS_DRM_PLANE_CAP_ZPOS,
}, {
.zpos = 2,
.type = DRM_PLANE_TYPE_OVERLAY,
.pixel_formats = vp_formats,
.num_pixel_formats = ARRAY_SIZE(vp_formats),
-   .capabilities = EXYNOS_DRM_PLANE_CAP_SCALE,
+   .capabilities = EXYNOS_DRM_PLANE_CAP_SCALE |
+   EXYNOS_DRM_PLANE_CAP_ZPOS,
},
 };

@@ -372,7 +375,7 @@ static void mixer_cfg_rgb_fmt(struct mixer_context *ctx, 
unsigned int height)
 }

 static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int win,
-   bool enable)
+   unsigned int priority, bool enable)
 {
struct mixer_resources *res = &ctx->mixer_res;
u32 val = enable ? ~0 : 0;
@@ -380,15 +383,24 @@ static void mixer_cfg_layer(struct mixer_context *ctx, 
unsigned int win,
switch (win) {
case 0:
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP0_ENABLE);
+   mixer_reg_writemask(res, MXR_LAYER_CFG,
+   MXR_LAYER_CFG_GRP0_VAL(priority),
+   MXR_LAYER_CFG_GRP0_MASK);
break;
case 1:
mixer_reg_writemask(res, MXR_CFG, val, MXR_CFG_GRP1_ENABLE);
+   mixer_reg_writemask(res, MXR_LAYER_CFG,
+   MXR_LAYER_CFG_GRP1_VAL(priority),
+   MXR_LAYER_CFG_GRP1_MASK);
break;
case 2:
if (ctx->vp_enabled) {
vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
mixer_reg_writemask(res, MXR_CFG, val,
MXR_CFG_VP_ENABLE);
+   mixer_reg_writemask(res, MXR_LAYER_CFG,
+   MXR_LAYER_CFG_VP_VAL(priority),
+   MXR_LAYER_CFG_VP_MASK);

/* control blending of graphic layer 0 */
mixer_reg_writemask(res, MXR_GRAPHIC_CFG(0), val,
@@ -511,7 +523,7 @@ static void vp_video_buffer(struct mixer_context *ctx,

mixer_cfg_scan(ctx, mode->vdisplay);
mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
-   mixer_cfg_layer(ctx, plane->index, true);
+   mixer_cfg_layer(ctx, plane->index, state->zpos + 1, true);
mixer_run(ctx);

mixer_vsync_set_update(ctx, true);
@@ -626,7 +638,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,

mixer_cfg_scan(ctx, mode->vdisplay);
mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
-   mixer_cfg_layer(ctx, win, true);
+   mixer_cfg_layer(ctx, win, state->zpos + 1, true);

/* layer update mandatory for mixer 16.0.33.0 */
if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
@@ -674,17 +686,8 @@ static void mixer_win_reset(struct mixer_context *ctx)
mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST,
MXR_STATUS_BURST_MASK);

-   /* setting default layer priority: layer1 > layer0 > video
-* because typical usage scenario would be
-* layer1 - OSD
-* layer0 - framebuffer
-* video - video overlay
-*/
-   val = MXR_LAYER_CFG_GRP1_VAL(3);
-   

[PATCH v3 1/7] drm/exynos: rename zpos to index

[Marek Szyprowski]

This patch renames zpos entry to index, because in most places it is
used as index for selecting hardware layer/window instead of
configurable layer position. This will later enable to make the zpos
property configurable.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
 drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  | 10 +-
 drivers/gpu/drm/exynos/exynos_drm_plane.c |  4 ++--
 drivers/gpu/drm/exynos/exynos_drm_plane.h |  2 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c  |  2 +-
 drivers/gpu/drm/exynos/exynos_mixer.c | 14 +++---
 8 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index c7362b99ce28..88d022ad5280 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -256,7 +256,7 @@ static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
if (test_bit(BIT_SUSPENDED, &ctx->flags))
return;

-   decon_shadow_protect_win(ctx, plane->zpos, true);
+   decon_shadow_protect_win(ctx, plane->index, true);
 }

 #define BIT_VAL(x, e, s) (((x) & ((1 << ((e) - (s) + 1)) - 1)) << (s))
@@ -270,7 +270,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
to_exynos_plane_state(plane->base.state);
struct decon_context *ctx = crtc->ctx;
struct drm_framebuffer *fb = state->base.fb;
-   unsigned int win = plane->zpos;
+   unsigned int win = plane->index;
unsigned int bpp = fb->bits_per_pixel >> 3;
unsigned int pitch = fb->pitches[0];
dma_addr_t dma_addr = exynos_drm_fb_dma_addr(fb, 0);
@@ -320,7 +320,7 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
struct exynos_drm_plane *plane)
 {
struct decon_context *ctx = crtc->ctx;
-   unsigned int win = plane->zpos;
+   unsigned int win = plane->index;

if (test_bit(BIT_SUSPENDED, &ctx->flags))
return;
@@ -344,7 +344,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
if (test_bit(BIT_SUSPENDED, &ctx->flags))
return;

-   decon_shadow_protect_win(ctx, plane->zpos, false);
+   decon_shadow_protect_win(ctx, plane->index, false);

if (ctx->out_type == IFTYPE_I80)
set_bit(BIT_WIN_UPDATED, &ctx->flags);
@@ -502,7 +502,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[win].zpos = win;
ctx->configs[win].type = decon_win_types[tmp];

-   ret = exynos_plane_init(drm_dev, &ctx->planes[win],
+   ret = exynos_plane_init(drm_dev, &ctx->planes[win], i,
1 << ctx->pipe, &ctx->configs[win]);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index c47f9af8170b..8911f965b06c 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -393,7 +393,7 @@ static void decon_atomic_begin(struct exynos_drm_crtc *crtc,
if (ctx->suspended)
return;

-   decon_shadow_protect_win(ctx, plane->zpos, true);
+   decon_shadow_protect_win(ctx, plane->index, true);
 }

 static void decon_update_plane(struct exynos_drm_crtc *crtc,
@@ -407,7 +407,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
-   unsigned int win = plane->zpos;
+   unsigned int win = plane->index;
unsigned int bpp = fb->bits_per_pixel >> 3;
unsigned int pitch = fb->pitches[0];

@@ -498,7 +498,7 @@ static void decon_disable_plane(struct exynos_drm_crtc 
*crtc,
struct exynos_drm_plane *plane)
 {
struct decon_context *ctx = crtc->ctx;
-   unsigned int win = plane->zpos;
+   unsigned int win = plane->index;
u32 val;

if (ctx->suspended)
@@ -525,7 +525,7 @@ static void decon_atomic_flush(struct exynos_drm_crtc *crtc,
if (ctx->suspended)
return;

-   decon_shadow_protect_win(ctx, plane->zpos, false);
+   decon_shadow_protect_win(ctx, plane->index, false);
 }

 static void decon_init(struct decon_context *ctx)
@@ -657,7 +657,7 @@ static int decon_bind(struct device *dev, struct device 
*master, void *data)
ctx->configs[i].zpos = i;
ctx->configs[i].type = decon_win_types[i];

-   ret = exynos_plane_init(drm_dev, &ctx->planes[i],
+   ret = exynos_plane_init(drm_dev, &ctx->planes[i], i,
 

[PATCH v3 2/7] drm/exynos: make zpos property configurable

[Marek Szyprowski]

This patch adds all infrastructure to make zpos plane property
configurable from userspace.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 ++-
 drivers/gpu/drm/exynos/exynos_drm_plane.c | 51 ---
 2 files changed, 49 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 588b6763f9c7..f0827dbebb7d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -64,6 +64,7 @@ struct exynos_drm_plane_state {
struct exynos_drm_rect src;
unsigned int h_ratio;
unsigned int v_ratio;
+   unsigned int zpos;
 };

 static inline struct exynos_drm_plane_state *
@@ -91,11 +92,12 @@ struct exynos_drm_plane {

 #define EXYNOS_DRM_PLANE_CAP_DOUBLE(1 << 0)
 #define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
+#define EXYNOS_DRM_PLANE_CAP_ZPOS  (1 << 2)

 /*
  * Exynos DRM plane configuration structure.
  *
- * @zpos: z-position of the plane.
+ * @zpos: initial z-position of the plane.
  * @type: type of the plane (primary, cursor or overlay).
  * @pixel_formats: supported pixel formats.
  * @num_pixel_formats: number of elements in 'pixel_formats'.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
b/drivers/gpu/drm/exynos/exynos_drm_plane.c
index fd6cb4cee01a..a2bdab836b50 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
@@ -124,6 +124,7 @@ static void exynos_plane_mode_set(struct 
exynos_drm_plane_state *exynos_state)

 static void exynos_drm_plane_reset(struct drm_plane *plane)
 {
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
struct exynos_drm_plane_state *exynos_state;

if (plane->state) {
@@ -136,6 +137,7 @@ static void exynos_drm_plane_reset(struct drm_plane *plane)

exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
if (exynos_state) {
+   exynos_state->zpos = exynos_plane->config->zpos;
plane->state = &exynos_state->base;
plane->state->plane = plane;
}
@@ -153,6 +155,7 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
return NULL;

__drm_atomic_helper_plane_duplicate_state(plane, ©->base);
+   copy->zpos = exynos_state->zpos;
return ©->base;
 }

@@ -165,13 +168,53 @@ static void exynos_drm_plane_destroy_state(struct 
drm_plane *plane,
kfree(old_exynos_state);
 }

+static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
+   struct drm_plane_state *state,
+   struct drm_property *property,
+   uint64_t val)
+{
+   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
+   struct exynos_drm_plane_state *exynos_state =
+   to_exynos_plane_state(state);
+   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
+   const struct exynos_drm_plane_config *config = exynos_plane->config;
+
+   if (property == dev_priv->plane_zpos_property &&
+   (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
+   exynos_state->zpos = val;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
+static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
+ const struct drm_plane_state *state,
+ struct drm_property *property,
+ uint64_t *val)
+{
+   const struct exynos_drm_plane_state *exynos_state =
+   container_of(state, const struct exynos_drm_plane_state, base);
+   struct exynos_drm_private *dev_priv = plane->dev->dev_private;
+
+   if (property == dev_priv->plane_zpos_property)
+   *val = exynos_state->zpos;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
 static struct drm_plane_funcs exynos_plane_funcs = {
.update_plane   = drm_atomic_helper_update_plane,
.disable_plane  = drm_atomic_helper_disable_plane,
.destroy= drm_plane_cleanup,
+   .set_property   = drm_atomic_helper_plane_set_property,
.reset  = exynos_drm_plane_reset,
.atomic_duplicate_state = exynos_drm_plane_duplicate_state,
.atomic_destroy_state = exynos_drm_plane_destroy_state,
+   .atomic_set_property = exynos_drm_plane_atomic_set_property,
+   .atomic_get_property = exynos_drm_plane_atomic_get_property,
 };

 static int
@@ -267,8 +310,8 @@ static void exynos_plane_attach_zpos_property(struct 
drm_plane *plane,

prop = dev_priv->plane_zpos_property;
if (!prop) {
-   prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
-"zpos", 0, MA

[PATCH v3 6/7] drm/exynos: mixer: also allow ARGB1555 and ARGB4444

[Marek Szyprowski]

From: Tobias Jakobi 

Allow the remaining alpha formats now that blending
is properly setup.

Signed-off-by: Tobias Jakobi 
Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index ae7b122274ac..31a9a228744e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -76,7 +76,9 @@ enum mixer_flag_bits {

 static const uint32_t mixer_formats[] = {
DRM_FORMAT_XRGB,
+   DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB1555,
+   DRM_FORMAT_ARGB1555,
DRM_FORMAT_RGB565,
DRM_FORMAT_XRGB,
DRM_FORMAT_ARGB,
@@ -169,6 +171,8 @@ static inline bool is_alpha_format(unsigned int 
pixel_format)
 {
switch (pixel_format) {
case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ARGB1555:
+   case DRM_FORMAT_ARGB:
return true;
default:
return false;
@@ -595,10 +599,12 @@ static void mixer_graph_buffer(struct mixer_context *ctx,

switch (fb->pixel_format) {
case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_ARGB:
fmt = MXR_FORMAT_ARGB;
break;

case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_ARGB1555:
fmt = MXR_FORMAT_ARGB1555;
break;

-- 
1.9.2

[PATCH v3 4/7] drm/exynos: mixer: remove all static blending setup

[Marek Szyprowski]

From: Tobias Jakobi 

Previously blending setup was static and most of it was
done in mixer_win_reset().

Signed-off-by: Tobias Jakobi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 23 ---
 1 file changed, 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c0d128bc084b..c572e271579e 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -401,11 +401,6 @@ static void mixer_cfg_layer(struct mixer_context *ctx, 
unsigned int win,
mixer_reg_writemask(res, MXR_LAYER_CFG,
MXR_LAYER_CFG_VP_VAL(priority),
MXR_LAYER_CFG_VP_MASK);
-
-   /* control blending of graphic layer 0 */
-   mixer_reg_writemask(res, MXR_GRAPHIC_CFG(0), val,
-   MXR_GRP_CFG_BLEND_PRE_MUL |
-   MXR_GRP_CFG_PIXEL_BLEND_EN);
}
break;
}
@@ -672,7 +667,6 @@ static void mixer_win_reset(struct mixer_context *ctx)
 {
struct mixer_resources *res = &ctx->mixer_res;
unsigned long flags;
-   u32 val; /* value stored to register */

spin_lock_irqsave(&res->reg_slock, flags);
mixer_vsync_set_update(ctx, false);
@@ -694,23 +688,6 @@ static void mixer_win_reset(struct mixer_context *ctx)
mixer_reg_write(res, MXR_BG_COLOR1, 0x008080);
mixer_reg_write(res, MXR_BG_COLOR2, 0x008080);

-   /* setting graphical layers */
-   val  = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
-   val |= MXR_GRP_CFG_WIN_BLEND_EN;
-   val |= MXR_GRP_CFG_ALPHA_VAL(0xff); /* non-transparent alpha */
-
-   /* Don't blend layer 0 onto the mixer background */
-   mixer_reg_write(res, MXR_GRAPHIC_CFG(0), val);
-
-   /* Blend layer 1 into layer 0 */
-   val |= MXR_GRP_CFG_BLEND_PRE_MUL;
-   val |= MXR_GRP_CFG_PIXEL_BLEND_EN;
-   mixer_reg_write(res, MXR_GRAPHIC_CFG(1), val);
-
-   /* setting video layers */
-   val = MXR_GRP_CFG_ALPHA_VAL(0);
-   mixer_reg_write(res, MXR_VIDEO_CFG, val);
-
if (ctx->vp_enabled) {
/* configuration of Video Processor Registers */
vp_win_reset(ctx);
-- 
1.9.2

[PATCH v3 5/7] drm/exynos: mixer: refactor layer setup

[Marek Szyprowski]

Properly configure blending properties of given hardware layer based on
the selected pixel format. Currently only per-pixel-based alpha is possible
when respective pixel format has been selected. Configuration of global,
per-plane alpha value, color key and background color will be added later.

This patch is heavily inspired by earlier work done by Tobias Jakobi
.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 43 +++
 drivers/gpu/drm/exynos/regs-mixer.h   |  1 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index c572e271579e..ae7b122274ac 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -165,6 +165,16 @@ static const u8 filter_cr_horiz_tap4[] = {
70, 59, 48, 37, 27, 19, 11, 5,
 };

+static inline bool is_alpha_format(unsigned int pixel_format)
+{
+   switch (pixel_format) {
+   case DRM_FORMAT_ARGB:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static inline u32 vp_reg_read(struct mixer_resources *res, u32 reg_id)
 {
return readl(res->vp_regs + reg_id);
@@ -294,6 +304,37 @@ static void vp_default_filter(struct mixer_resources *res)
filter_cr_horiz_tap4, sizeof(filter_cr_horiz_tap4));
 }

+static void mixer_cfg_gfx_blend(struct mixer_context *ctx, unsigned int win,
+   bool alpha)
+{
+   struct mixer_resources *res = &ctx->mixer_res;
+   u32 val;
+
+   val  = MXR_GRP_CFG_COLOR_KEY_DISABLE; /* no blank key */
+   if (alpha) {
+   /* blending based on pixel alpha */
+   val |= MXR_GRP_CFG_BLEND_PRE_MUL;
+   val |= MXR_GRP_CFG_PIXEL_BLEND_EN;
+   }
+   mixer_reg_writemask(res, MXR_GRAPHIC_CFG(win),
+   val, MXR_GRP_CFG_MISC_MASK);
+}
+
+static void mixer_cfg_vp_blend(struct mixer_context *ctx)
+{
+   struct mixer_resources *res = &ctx->mixer_res;
+   u32 val;
+
+   /*
+* No blending at the moment since the NV12/NV21 pixelformats don't
+* have an alpha channel. However the mixer supports a global alpha
+* value for a layer. Once this functionality is exposed, we can
+* support blending of the video layer through this.
+*/
+   val = 0;
+   mixer_reg_write(res, MXR_VIDEO_CFG, val);
+}
+
 static void mixer_vsync_set_update(struct mixer_context *ctx, bool enable)
 {
struct mixer_resources *res = &ctx->mixer_res;
@@ -519,6 +560,7 @@ static void vp_video_buffer(struct mixer_context *ctx,
mixer_cfg_scan(ctx, mode->vdisplay);
mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
mixer_cfg_layer(ctx, plane->index, state->zpos + 1, true);
+   mixer_cfg_vp_blend(ctx);
mixer_run(ctx);

mixer_vsync_set_update(ctx, true);
@@ -634,6 +676,7 @@ static void mixer_graph_buffer(struct mixer_context *ctx,
mixer_cfg_scan(ctx, mode->vdisplay);
mixer_cfg_rgb_fmt(ctx, mode->vdisplay);
mixer_cfg_layer(ctx, win, state->zpos + 1, true);
+   mixer_cfg_gfx_blend(ctx, win, is_alpha_format(fb->pixel_format));

/* layer update mandatory for mixer 16.0.33.0 */
if (ctx->mxr_ver == MXR_VER_16_0_33_0 ||
diff --git a/drivers/gpu/drm/exynos/regs-mixer.h 
b/drivers/gpu/drm/exynos/regs-mixer.h
index dbdbc0af3358..7f22df5bf707 100644
--- a/drivers/gpu/drm/exynos/regs-mixer.h
+++ b/drivers/gpu/drm/exynos/regs-mixer.h
@@ -113,6 +113,7 @@
 #define MXR_GRP_CFG_BLEND_PRE_MUL  (1 << 20)
 #define MXR_GRP_CFG_WIN_BLEND_EN   (1 << 17)
 #define MXR_GRP_CFG_PIXEL_BLEND_EN (1 << 16)
+#define MXR_GRP_CFG_MISC_MASK  ((3 << 16) | (3 << 20))
 #define MXR_GRP_CFG_FORMAT_VAL(x)  MXR_MASK_VAL(x, 11, 8)
 #define MXR_GRP_CFG_FORMAT_MASKMXR_GRP_CFG_FORMAT_VAL(~0)
 #define MXR_GRP_CFG_ALPHA_VAL(x)   MXR_MASK_VAL(x, 7, 0)
-- 
1.9.2

[PATCH v3 7/7] drm/exynos: mixer: unify a check for video-processor window

[Marek Szyprowski]

Always use macro instead of hard-coded '2' value in conditions related
to video processor window. Additional checks are not needed, because
video layer is registered only when video processor is available.

Signed-off-by: Marek Szyprowski 
---
 drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 31a9a228744e..bf148dc3623c 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -438,7 +438,7 @@ static void mixer_cfg_layer(struct mixer_context *ctx, 
unsigned int win,
MXR_LAYER_CFG_GRP1_VAL(priority),
MXR_LAYER_CFG_GRP1_MASK);
break;
-   case 2:
+   case VP_DEFAULT_WIN:
if (ctx->vp_enabled) {
vp_reg_writemask(res, VP_ENABLE, val, VP_ENABLE_ON);
mixer_reg_writemask(res, MXR_CFG, val,
@@ -990,7 +990,7 @@ static void mixer_update_plane(struct exynos_drm_crtc *crtc,
if (!test_bit(MXR_BIT_POWERED, &mixer_ctx->flags))
return;

-   if (plane->index > 1 && mixer_ctx->vp_enabled)
+   if (plane->index == VP_DEFAULT_WIN)
vp_video_buffer(mixer_ctx, plane);
else
mixer_graph_buffer(mixer_ctx, plane);
-- 
1.9.2

[PATCH v3 2/7] drm/exynos: make zpos property configurable

[Daniel Vetter]

On Wed, Dec 16, 2015 at 01:21:43PM +0100, Marek Szyprowski wrote:
> This patch adds all infrastructure to make zpos plane property
> configurable from userspace.
> 
> Signed-off-by: Marek Szyprowski 

Imo zpos should be a generic atomic property with well-defined semantics
shared across drivers. So
- storead (in decoded form) in drm_plane_state
- common functions to register/attach zpos prop to a plane, with
  full-blown kerneldoc explaining how it should work
- generic kms igt to validate that interface

One of the big things that always comes up when we talk about zpos is how
equal zpos should be handled, and how exactly they should be sorted. I
think for that we should have a drm function which computes a normalized
zpos. Or the core check code should reject such nonsense.
-Daniel

> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 ++-
>  drivers/gpu/drm/exynos/exynos_drm_plane.c | 51 
> ---
>  2 files changed, 49 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 588b6763f9c7..f0827dbebb7d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -64,6 +64,7 @@ struct exynos_drm_plane_state {
>   struct exynos_drm_rect src;
>   unsigned int h_ratio;
>   unsigned int v_ratio;
> + unsigned int zpos;
>  };
>  
>  static inline struct exynos_drm_plane_state *
> @@ -91,11 +92,12 @@ struct exynos_drm_plane {
>  
>  #define EXYNOS_DRM_PLANE_CAP_DOUBLE  (1 << 0)
>  #define EXYNOS_DRM_PLANE_CAP_SCALE   (1 << 1)
> +#define EXYNOS_DRM_PLANE_CAP_ZPOS(1 << 2)
>  
>  /*
>   * Exynos DRM plane configuration structure.
>   *
> - * @zpos: z-position of the plane.
> + * @zpos: initial z-position of the plane.
>   * @type: type of the plane (primary, cursor or overlay).
>   * @pixel_formats: supported pixel formats.
>   * @num_pixel_formats: number of elements in 'pixel_formats'.
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> index fd6cb4cee01a..a2bdab836b50 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> @@ -124,6 +124,7 @@ static void exynos_plane_mode_set(struct 
> exynos_drm_plane_state *exynos_state)
>  
>  static void exynos_drm_plane_reset(struct drm_plane *plane)
>  {
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
>   struct exynos_drm_plane_state *exynos_state;
>  
>   if (plane->state) {
> @@ -136,6 +137,7 @@ static void exynos_drm_plane_reset(struct drm_plane 
> *plane)
>  
>   exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
>   if (exynos_state) {
> + exynos_state->zpos = exynos_plane->config->zpos;
>   plane->state = &exynos_state->base;
>   plane->state->plane = plane;
>   }
> @@ -153,6 +155,7 @@ exynos_drm_plane_duplicate_state(struct drm_plane *plane)
>   return NULL;
>  
>   __drm_atomic_helper_plane_duplicate_state(plane, ©->base);
> + copy->zpos = exynos_state->zpos;
>   return ©->base;
>  }
>  
> @@ -165,13 +168,53 @@ static void exynos_drm_plane_destroy_state(struct 
> drm_plane *plane,
>   kfree(old_exynos_state);
>  }
>  
> +static int exynos_drm_plane_atomic_set_property(struct drm_plane *plane,
> + struct drm_plane_state *state,
> + struct drm_property *property,
> + uint64_t val)
> +{
> + struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> + struct exynos_drm_plane_state *exynos_state =
> + to_exynos_plane_state(state);
> + struct exynos_drm_private *dev_priv = plane->dev->dev_private;
> + const struct exynos_drm_plane_config *config = exynos_plane->config;
> +
> + if (property == dev_priv->plane_zpos_property &&
> + (config->capabilities & EXYNOS_DRM_PLANE_CAP_ZPOS))
> + exynos_state->zpos = val;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int exynos_drm_plane_atomic_get_property(struct drm_plane *plane,
> +   const struct drm_plane_state *state,
> +   struct drm_property *property,
> +   uint64_t *val)
> +{
> + const struct exynos_drm_plane_state *exynos_state =
> + container_of(state, const struct exynos_drm_plane_state, base);
> + struct exynos_drm_private *dev_priv = plane->dev->dev_private;
> +
> + if (property == dev_priv->plane_zpos_property)
> + *val = exynos_state->zpos;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +
>  static struct drm_plane_funcs exynos_plane_funcs = {
>   .update_plane   = drm_atomic_helper_update_plane,
>  

[Bug 93404] radeon fail when creating a new session with the same user

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

0x60
Dec 15 21:03:44 metal kernel:  [] radeon_drm_ioctl+0x37/0x80
[radeon]
Dec 15 21:03:44 metal kernel:  [] do_vfs_ioctl+0x295/0x480
Dec 15 21:03:44 metal kernel:  [] ? __fget+0x77/0xb0
Dec 15 21:03:44 metal kernel:  [] SyS_ioctl+0x79/0x90
Dec 15 21:03:44 metal kernel:  []
entry_SYSCALL_64_fastpath+0x12/0x71
Dec 15 21:03:44 metal kernel: ---[ end trace 33afaf6a1bc49613 ]---
Dec 15 21:03:44 metal kernel: [drm:radeon_pm_late_init [radeon]] *ERROR* failed
to create device file for power profile
Dec 15 21:03:44 metal kernel: [ cut here ]
Dec 15 21:03:44 metal kernel: WARNING: CPU: 3 PID: 468 at fs/sysfs/dir.c:31
sysfs_warn_dup+0x66/0x80()
Dec 15 21:03:44 metal kernel: sysfs: cannot create duplicate filename
'/devices/pci:00/:00:01.0/:01:00.0/power_method'
Dec 15 21:03:44 metal kernel: Modules linked in: cmac ecb rfcomm fuse bnep
joydev mousedev mmc_block arc4 nls_iso8859_1 nls_cp437 vfat fat intel_rapl
iwlmvm iosf_mbi x86_pkg_temp_thermal intel_powerclamp mac80211 kvm_intel
snd_hda_codec_realtek
Dec 15 21:03:44 metal kernel:  toshiba_bluetooth mei_me intel_gtt soundcore
i2c_algo_bit mei edac_core shpchp toshiba_haps wmi thermal rfkill button
battery video ac processor sch_fq_codel nfs lockd grace sunrpc fscache
ip_tables x_tables ext4 
Dec 15 21:03:44 metal kernel: CPU: 3 PID: 468 Comm: Xorg Tainted: GW   
   4.2.5-1-ARCH #1
Dec 15 21:03:44 metal kernel: Hardware name: TOSHIBA SATELLITE
P50-B-115/VG20SQ, BIOS 1.50 12/09/2014
Dec 15 21:03:44 metal kernel:   afbaeab0
880317c67ac8 81570d0a
Dec 15 21:03:44 metal kernel:   880317c67b20
880317c67b08 810748a6
Dec 15 21:03:44 metal kernel:  623b17c67b08 88025af5a000
a09ec5b8 880320822bb8
Dec 15 21:03:44 metal kernel: Call Trace:
Dec 15 21:03:44 metal kernel:  [] dump_stack+0x4c/0x6e
Dec 15 21:03:44 metal kernel:  []
warn_slowpath_common+0x86/0xc0
Dec 15 21:03:44 metal kernel:  [] warn_slowpath_fmt+0x55/0x70
Dec 15 21:03:44 metal kernel:  [] ? kernfs_path+0x48/0x60
Dec 15 21:03:44 metal kernel:  [] sysfs_warn_dup+0x66/0x80
Dec 15 21:03:44 metal kernel:  []
sysfs_add_file_mode_ns+0x127/0x180
Dec 15 21:03:44 metal kernel:  []
sysfs_create_file_ns+0x2a/0x30
Dec 15 21:03:44 metal kernel:  []
device_create_file+0x42/0x90
Dec 15 21:03:44 metal kernel:  []
radeon_pm_late_init+0xbb/0x1a0 [radeon]
Dec 15 21:03:44 metal kernel:  []
radeon_resume_kms+0x255/0x3b0 [radeon]
Dec 15 21:03:44 metal kernel:  []
radeon_pmops_runtime_resume+0x73/0xb0 [radeon]
Dec 15 21:03:44 metal kernel:  []
pci_pm_runtime_resume+0x7f/0xb0
Dec 15 21:03:44 metal kernel:  [] ?
vga_switcheroo_runtime_suspend+0x60/0x60
Dec 15 21:03:44 metal kernel:  []
vga_switcheroo_runtime_resume+0x39/0x40
Dec 15 21:03:44 metal kernel:  [] __rpm_callback+0x36/0x80
Dec 15 21:03:44 metal kernel:  [] ?
vga_switcheroo_runtime_suspend+0x60/0x60
Dec 15 21:03:44 metal kernel:  [] rpm_callback+0x28/0x90
Dec 15 21:03:44 metal kernel:  [] ?
vga_switcheroo_runtime_suspend+0x60/0x60
Dec 15 21:03:44 metal kernel:  [] rpm_resume+0x490/0x690
Dec 15 21:03:44 metal kernel:  []
__pm_runtime_resume+0x3f/0x60
Dec 15 21:03:44 metal kernel:  [] radeon_drm_ioctl+0x37/0x80
[radeon]
Dec 15 21:03:44 metal kernel:  [] do_vfs_ioctl+0x295/0x480
Dec 15 21:03:44 metal kernel:  [] ? __fget+0x77/0xb0
Dec 15 21:03:44 metal kernel:  [] SyS_ioctl+0x79/0x90
Dec 15 21:03:44 metal kernel:  []
entry_SYSCALL_64_fastpath+0x12/0x71
Dec 15 21:03:44 metal kernel: ---[ end trace 33afaf6a1bc49614 ]---

-- 
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/20151216/02016a81/attachment-0001.html>

[PATCH v3 2/7] drm/exynos: make zpos property configurable

[Ville Syrjälä]

On Wed, Dec 16, 2015 at 02:28:36PM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 01:21:43PM +0100, Marek Szyprowski wrote:
> > This patch adds all infrastructure to make zpos plane property
> > configurable from userspace.
> > 
> > Signed-off-by: Marek Szyprowski 
> 
> Imo zpos should be a generic atomic property with well-defined semantics
> shared across drivers. So
> - storead (in decoded form) in drm_plane_state
> - common functions to register/attach zpos prop to a plane, with
>   full-blown kerneldoc explaining how it should work
> - generic kms igt to validate that interface
> 
> One of the big things that always comes up when we talk about zpos is how
> equal zpos should be handled, and how exactly they should be sorted. I
> think for that we should have a drm function which computes a normalized
> zpos. Or the core check code should reject such nonsense.

Yeah I think just having some core check reject the operation if two
planes end up with the same zpos. And zpos should probably just be 
in the [0-number_of_planes_on_the_crtc_currently] range? Or maybe
[0-max_number_of_planes_possible_on_the_crtc], or just
[0-total_max_number_of_planes] ? One of the latter two might be sensible
because you could then enable/disable some planes on the crtc without
necessarily touching the zpos for the other planes.

Another complication is how you think about color keying. Eg. if you use
dst keying between the primary plane and some other plane, then it may
make sense to think of the primary being above the other plane and the
colorkey just punches a hole into the primary. But if the planes
otherwise are always ordered with the primary at the botton, then I'm
not sure if exposing zpos and requiring it to be reconfigured for
colorkeying to work would just make things more confusing. But this
decisions might also depend on what happens to pixels on the other plane
that fall outside of the primary plane (assuming the primary can be
non-fullscreen). I don't remember off the top of my head how this works
on Intel hw. The other option I suppose is to define color keying as
just being slightly magic that it can effectively reorder the planes
even though zpos says something else. Not quite sure which is best.

Dst color keying is rather confusing in any case since it may work
only between certain planes (and exactly which planes may depend which
planes are active on the same crtc).

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/exynos/exynos_drm_drv.h   |  4 ++-
> >  drivers/gpu/drm/exynos/exynos_drm_plane.c | 51 
> > ---
> >  2 files changed, 49 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > index 588b6763f9c7..f0827dbebb7d 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > @@ -64,6 +64,7 @@ struct exynos_drm_plane_state {
> > struct exynos_drm_rect src;
> > unsigned int h_ratio;
> > unsigned int v_ratio;
> > +   unsigned int zpos;
> >  };
> >  
> >  static inline struct exynos_drm_plane_state *
> > @@ -91,11 +92,12 @@ struct exynos_drm_plane {
> >  
> >  #define EXYNOS_DRM_PLANE_CAP_DOUBLE(1 << 0)
> >  #define EXYNOS_DRM_PLANE_CAP_SCALE (1 << 1)
> > +#define EXYNOS_DRM_PLANE_CAP_ZPOS  (1 << 2)
> >  
> >  /*
> >   * Exynos DRM plane configuration structure.
> >   *
> > - * @zpos: z-position of the plane.
> > + * @zpos: initial z-position of the plane.
> >   * @type: type of the plane (primary, cursor or overlay).
> >   * @pixel_formats: supported pixel formats.
> >   * @num_pixel_formats: number of elements in 'pixel_formats'.
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c 
> > b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> > index fd6cb4cee01a..a2bdab836b50 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
> > @@ -124,6 +124,7 @@ static void exynos_plane_mode_set(struct 
> > exynos_drm_plane_state *exynos_state)
> >  
> >  static void exynos_drm_plane_reset(struct drm_plane *plane)
> >  {
> > +   struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
> > struct exynos_drm_plane_state *exynos_state;
> >  
> > if (plane->state) {
> > @@ -136,6 +137,7 @@ static void exynos_drm_plane_reset(struct drm_plane 
> > *plane)
> >  
> > exynos_state = kzalloc(sizeof(*exynos_state), GFP_KERNEL);
> > if (exynos_state) {
> > +   exynos_state->zpos = exynos_plane->config->zpos;
> > plane->state = &exynos_state->base;
> > plane->state->plane = plane;
> > }
> > @@ -153,6 +155,7 @@ exynos_drm_plane_duplicate_state(struct drm_plane 
> > *plane)
> > return NULL;
> >  
> > __drm_atomic_helper_plane_duplicate_state(plane, ©->base);
> > +   copy->zpos = exynos_state->zpos;
> > return ©->base;
> >  }
> >  
> > @@ -165,13 +168,53 @@ static void exynos_drm_plane_destroy_state(struct 
> > drm

[PATCH v3 2/7] drm/exynos: make zpos property configurable

[Marek Szyprowski]

Hello,

On 2015-12-16 14:28, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 01:21:43PM +0100, Marek Szyprowski wrote:
>> This patch adds all infrastructure to make zpos plane property
>> configurable from userspace.
>>
>> Signed-off-by: Marek Szyprowski 
> Imo zpos should be a generic atomic property with well-defined semantics
> shared across drivers. So
> - storead (in decoded form) in drm_plane_state
> - common functions to register/attach zpos prop to a plane, with
>full-blown kerneldoc explaining how it should work
> - generic kms igt to validate that interface
>
> One of the big things that always comes up when we talk about zpos is how
> equal zpos should be handled, and how exactly they should be sorted. I
> think for that we should have a drm function which computes a normalized
> zpos. Or the core check code should reject such nonsense.

IMHO it will be enough to state that the case of equal zpos is HW specific.
This might simplify some driver logic. For example, in case of Exynos Mixer,
equal priority (zpos) means that HW predefined order will be used, so there
is no need to normalize zpos values.

If you want I can move zpos to drm core and add a function to normalize 
zpos,
although for this particular driver normalization is not needed.

It should be quite easy to convert other drivers to use the generic zpos
property. The only problem I see is how to handle omap driver, which use
'zorder' property.

What about some other typical properties related to blending:
- global plane alpha,
- colorkey,
- alpha mode (standard or pre-multiplied) for alpha-enabled modes,
- crtc background color.

Do you also want to handle them as generic or driver-specific properties?

I plan to add support for them to Exynos Mixer and I would like to avoid
doing this twice.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH v3 2/7] drm/exynos: make zpos property configurable

[Daniel Vetter]

On Wed, Dec 16, 2015 at 02:54:04PM +0100, Marek Szyprowski wrote:
> Hello,
> 
> On 2015-12-16 14:28, Daniel Vetter wrote:
> >On Wed, Dec 16, 2015 at 01:21:43PM +0100, Marek Szyprowski wrote:
> >>This patch adds all infrastructure to make zpos plane property
> >>configurable from userspace.
> >>
> >>Signed-off-by: Marek Szyprowski 
> >Imo zpos should be a generic atomic property with well-defined semantics
> >shared across drivers. So
> >- storead (in decoded form) in drm_plane_state
> >- common functions to register/attach zpos prop to a plane, with
> >   full-blown kerneldoc explaining how it should work
> >- generic kms igt to validate that interface
> >
> >One of the big things that always comes up when we talk about zpos is how
> >equal zpos should be handled, and how exactly they should be sorted. I
> >think for that we should have a drm function which computes a normalized
> >zpos. Or the core check code should reject such nonsense.
> 
> IMHO it will be enough to state that the case of equal zpos is HW specific.
> This might simplify some driver logic. For example, in case of Exynos Mixer,
> equal priority (zpos) means that HW predefined order will be used, so there
> is no need to normalize zpos values.
> 
> If you want I can move zpos to drm core and add a function to normalize
> zpos,
> although for this particular driver normalization is not needed.
> 
> It should be quite easy to convert other drivers to use the generic zpos
> property. The only problem I see is how to handle omap driver, which use
> 'zorder' property.
> 
> What about some other typical properties related to blending:
> - global plane alpha,
> - colorkey,
> - alpha mode (standard or pre-multiplied) for alpha-enabled modes,
> - crtc background color.
> 
> Do you also want to handle them as generic or driver-specific properties?

Should all be generic really. And it's also kinda ABI, so userspace
needed, and preferrably a proper/automated testcase. i915 has
infrastructure to use display pipeline CRCs to really measure it's all
correct even, and that's the standard I'd like to see for all KMS API
extensions like this.

Since if we don't do this we'll end up in a giant mess, and it will be
impossible to write a kms compositor that's generic and uses all this.

And since this stuff is supposed to be generic, fluffy/unspecified
semantics aren't good. Especially if your hw can just somehow deal with it
all.

> I plan to add support for them to Exynos Mixer and I would like to avoid
> doing this twice.

It's a lot more work than just adding a few members to drm_plane_state.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v3 2/7] drm/exynos: make zpos property configurable

[Marek Szyprowski]

Hello,

On 2015-12-16 15:21, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 02:54:04PM +0100, Marek Szyprowski wrote:
>> On 2015-12-16 14:28, Daniel Vetter wrote:
>>> On Wed, Dec 16, 2015 at 01:21:43PM +0100, Marek Szyprowski wrote:
 This patch adds all infrastructure to make zpos plane property
 configurable from userspace.

 Signed-off-by: Marek Szyprowski 
>>> Imo zpos should be a generic atomic property with well-defined semantics
>>> shared across drivers. So
>>> - storead (in decoded form) in drm_plane_state
>>> - common functions to register/attach zpos prop to a plane, with
>>>full-blown kerneldoc explaining how it should work
>>> - generic kms igt to validate that interface
>>>
>>> One of the big things that always comes up when we talk about zpos is how
>>> equal zpos should be handled, and how exactly they should be sorted. I
>>> think for that we should have a drm function which computes a normalized
>>> zpos. Or the core check code should reject such nonsense.
>> IMHO it will be enough to state that the case of equal zpos is HW specific.
>> This might simplify some driver logic. For example, in case of Exynos Mixer,
>> equal priority (zpos) means that HW predefined order will be used, so there
>> is no need to normalize zpos values.
>>
>> If you want I can move zpos to drm core and add a function to normalize
>> zpos,
>> although for this particular driver normalization is not needed.
>>
>> It should be quite easy to convert other drivers to use the generic zpos
>> property. The only problem I see is how to handle omap driver, which use
>> 'zorder' property.
>>
>> What about some other typical properties related to blending:
>> - global plane alpha,
>> - colorkey,
>> - alpha mode (standard or pre-multiplied) for alpha-enabled modes,
>> - crtc background color.
>>
>> Do you also want to handle them as generic or driver-specific properties?
> Should all be generic really. And it's also kinda ABI, so userspace
> needed, and preferrably a proper/automated testcase. i915 has
> infrastructure to use display pipeline CRCs to really measure it's all
> correct even, and that's the standard I'd like to see for all KMS API
> extensions like this.

Could you tell a bit more about this pipeline CRCs? What is it?

> Since if we don't do this we'll end up in a giant mess, and it will be
> impossible to write a kms compositor that's generic and uses all this.
>
> And since this stuff is supposed to be generic, fluffy/unspecified
> semantics aren't good. Especially if your hw can just somehow deal with it
> all.
>
>> I plan to add support for them to Exynos Mixer and I would like to avoid
>> doing this twice.
> It's a lot more work than just adding a few members to drm_plane_state.

I see. Could you elaborate a bit more on what you want to have in drm 
core for
handling all the mentioned features?

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

[PATCH] drm/radeon: Update radeon_get_vblank_counter_kms()

[Thierry Reding]

From: Thierry Reding 

Commit 88e72717c2de ("drm/irq: Use unsigned int pipe in public API")
updated the prototype of this function but not the implementation. This
wasn't noticed even through compile tests because the prototype is part
of the source file that uses it and hence the compiler won't know the
prototype when it compiles the implementation.

The right thing would've been to move the prototype to a header that's
included in radeon_kms.c so that the implementation signature could be
checked against it, but the closest thing would've been radeon_drv.h
and including that results in a lot of build errors, so we'll leave it
as is for now.

Cc: Christian König 
Cc: Alex Deucher 
Signed-off-by: Thierry Reding 
---
Note that this doesn't really need to go into stable because the
generated code should be the same.

 drivers/gpu/drm/radeon/radeon_kms.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
b/drivers/gpu/drm/radeon/radeon_kms.c
index d290a8a09036..4fab44e0f36b 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -748,19 +748,19 @@ void radeon_driver_preclose_kms(struct drm_device *dev,
  * radeon_get_vblank_counter_kms - get frame count
  *
  * @dev: drm dev pointer
- * @crtc: crtc to get the frame count from
+ * @pipe: crtc to get the frame count from
  *
  * Gets the frame count on the requested crtc (all asics).
  * Returns frame count on success, -EINVAL on failure.
  */
-u32 radeon_get_vblank_counter_kms(struct drm_device *dev, int crtc)
+u32 radeon_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe)
 {
int vpos, hpos, stat;
u32 count;
struct radeon_device *rdev = dev->dev_private;

-   if (crtc < 0 || crtc >= rdev->num_crtc) {
-   DRM_ERROR("Invalid crtc %d\n", crtc);
+   if (pipe < 0 || pipe >= rdev->num_crtc) {
+   DRM_ERROR("Invalid crtc %u\n", pipe);
return -EINVAL;
}

@@ -772,29 +772,29 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev, 
int crtc)
 * and start of vsync, so vpos >= 0 means to bump the hw frame counter
 * result by 1 to give the proper appearance to caller.
 */
-   if (rdev->mode_info.crtcs[crtc]) {
+   if (rdev->mode_info.crtcs[pipe]) {
/* Repeat readout if needed to provide stable result if
 * we cross start of vsync during the queries.
 */
do {
-   count = radeon_get_vblank_counter(rdev, crtc);
+   count = radeon_get_vblank_counter(rdev, pipe);
/* Ask radeon_get_crtc_scanoutpos to return vpos as
 * distance to start of vblank, instead of regular
 * vertical scanout pos.
 */
stat = radeon_get_crtc_scanoutpos(
-   dev, crtc, GET_DISTANCE_TO_VBLANKSTART,
+   dev, pipe, GET_DISTANCE_TO_VBLANKSTART,
&vpos, &hpos, NULL, NULL,
-   &rdev->mode_info.crtcs[crtc]->base.hwmode);
-   } while (count != radeon_get_vblank_counter(rdev, crtc));
+   &rdev->mode_info.crtcs[pipe]->base.hwmode);
+   } while (count != radeon_get_vblank_counter(rdev, pipe));

if (((stat & (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE)) 
!=
(DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE))) {
DRM_DEBUG_VBL("Query failed! stat %d\n", stat);
}
else {
-   DRM_DEBUG_VBL("crtc %d: dist from vblank start %d\n",
- crtc, vpos);
+   DRM_DEBUG_VBL("crtc %u: dist from vblank start %d\n",
+ pipe, vpos);

/* Bump counter if we are at >= leading edge of vblank,
 * but before vsync where vpos would turn negative and
@@ -806,7 +806,7 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev, 
int crtc)
}
else {
/* Fallback to use value as is. */
-   count = radeon_get_vblank_counter(rdev, crtc);
+   count = radeon_get_vblank_counter(rdev, pipe);
DRM_DEBUG_VBL("NULL mode info! Returned count may be wrong.\n");
}

-- 
2.5.0

[PATCH] drm/radeon: Update radeon_get_vblank_counter_kms()

[Christian König]

On 16.12.2015 15:31, Thierry Reding wrote:
> From: Thierry Reding 
>
> Commit 88e72717c2de ("drm/irq: Use unsigned int pipe in public API")
> updated the prototype of this function but not the implementation. This
> wasn't noticed even through compile tests because the prototype is part
> of the source file that uses it and hence the compiler won't know the
> prototype when it compiles the implementation.
>
> The right thing would've been to move the prototype to a header that's
> included in radeon_kms.c so that the implementation signature could be
> checked against it, but the closest thing would've been radeon_drv.h
> and including that results in a lot of build errors, so we'll leave it
> as is for now.

Yeah, that's because of the old UMS mess. We could probably clean that 
up now.

>
> Cc: Christian König 
> Cc: Alex Deucher 
> Signed-off-by: Thierry Reding 

Anyway patch is Reviewed-by: Christian König 

Regards,
Christian.

> ---
> Note that this doesn't really need to go into stable because the
> generated code should be the same.
>
>   drivers/gpu/drm/radeon/radeon_kms.c | 24 
>   1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_kms.c 
> b/drivers/gpu/drm/radeon/radeon_kms.c
> index d290a8a09036..4fab44e0f36b 100644
> --- a/drivers/gpu/drm/radeon/radeon_kms.c
> +++ b/drivers/gpu/drm/radeon/radeon_kms.c
> @@ -748,19 +748,19 @@ void radeon_driver_preclose_kms(struct drm_device *dev,
>* radeon_get_vblank_counter_kms - get frame count
>*
>* @dev: drm dev pointer
> - * @crtc: crtc to get the frame count from
> + * @pipe: crtc to get the frame count from
>*
>* Gets the frame count on the requested crtc (all asics).
>* Returns frame count on success, -EINVAL on failure.
>*/
> -u32 radeon_get_vblank_counter_kms(struct drm_device *dev, int crtc)
> +u32 radeon_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe)
>   {
>   int vpos, hpos, stat;
>   u32 count;
>   struct radeon_device *rdev = dev->dev_private;
>   
> - if (crtc < 0 || crtc >= rdev->num_crtc) {
> - DRM_ERROR("Invalid crtc %d\n", crtc);
> + if (pipe < 0 || pipe >= rdev->num_crtc) {
> + DRM_ERROR("Invalid crtc %u\n", pipe);
>   return -EINVAL;
>   }
>   
> @@ -772,29 +772,29 @@ u32 radeon_get_vblank_counter_kms(struct drm_device 
> *dev, int crtc)
>* and start of vsync, so vpos >= 0 means to bump the hw frame counter
>* result by 1 to give the proper appearance to caller.
>*/
> - if (rdev->mode_info.crtcs[crtc]) {
> + if (rdev->mode_info.crtcs[pipe]) {
>   /* Repeat readout if needed to provide stable result if
>* we cross start of vsync during the queries.
>*/
>   do {
> - count = radeon_get_vblank_counter(rdev, crtc);
> + count = radeon_get_vblank_counter(rdev, pipe);
>   /* Ask radeon_get_crtc_scanoutpos to return vpos as
>* distance to start of vblank, instead of regular
>* vertical scanout pos.
>*/
>   stat = radeon_get_crtc_scanoutpos(
> - dev, crtc, GET_DISTANCE_TO_VBLANKSTART,
> + dev, pipe, GET_DISTANCE_TO_VBLANKSTART,
>   &vpos, &hpos, NULL, NULL,
> - &rdev->mode_info.crtcs[crtc]->base.hwmode);
> - } while (count != radeon_get_vblank_counter(rdev, crtc));
> + &rdev->mode_info.crtcs[pipe]->base.hwmode);
> + } while (count != radeon_get_vblank_counter(rdev, pipe));
>   
>   if (((stat & (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE)) 
> !=
>   (DRM_SCANOUTPOS_VALID | DRM_SCANOUTPOS_ACCURATE))) {
>   DRM_DEBUG_VBL("Query failed! stat %d\n", stat);
>   }
>   else {
> - DRM_DEBUG_VBL("crtc %d: dist from vblank start %d\n",
> -   crtc, vpos);
> + DRM_DEBUG_VBL("crtc %u: dist from vblank start %d\n",
> +   pipe, vpos);
>   
>   /* Bump counter if we are at >= leading edge of vblank,
>* but before vsync where vpos would turn negative and
> @@ -806,7 +806,7 @@ u32 radeon_get_vblank_counter_kms(struct drm_device *dev, 
> int crtc)
>   }
>   else {
>   /* Fallback to use value as is. */
> - count = radeon_get_vblank_counter(rdev, crtc);
> + count = radeon_get_vblank_counter(rdev, pipe);
>   DRM_DEBUG_VBL("NULL mode info! Returned count may be wrong.\n");
>   }
>   

[PATCH 1/2] devicetree: add vendor prefix for Kyocera Corporation

[Thierry Reding]

On Wed, Dec 02, 2015 at 07:41:10PM +0100, Lucas Stach wrote:
> KYO is the stock ticker symbol of Kyocera Corporation.
> 
> Signed-off-by: Lucas Stach 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Both patches applied, thanks.

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

i915 + DRM: *ERROR* too many voltage retries, give up + *ERROR* failed to train DP, aborting

[Toralf Förster]

There's a regression in the stable 4.2.x series.

With 4.2.7 I get the following within kern.log:

Dec 16 14:58:41 t44 kernel: [111050.930350] dvb-usb: found a 'Terratec Cinergy 
T USB XXS (HD)/ T3' in cold state, will try to load a firmware
Dec 16 14:58:41 t44 kernel: [111050.930436] dvb-usb: downloading firmware from 
file 'dvb-usb-dib0700-1.20.fw'
Dec 16 14:58:41 t44 kernel: [111051.012685] dib0700: firmware started 
successfully.
Dec 16 14:58:41 t44 kernel: [111051.436108] [drm:c049a8c8] *ERROR* too 
many voltage retries, give up
Dec 16 14:58:41 t44 kernel: [111051.436113] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:41 t44 kernel: [111051.436122] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:41 t44 kernel: [111051.454952] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:41 t44 kernel: [111051.454962] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:41 t44 kernel: [111051.456517] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:41 t44 kernel: [111051.456527] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:41 t44 kernel: [111051.513835] dvb-usb: found a 'Terratec Cinergy 
T USB XXS (HD)/ T3' in warm state.
Dec 16 14:58:41 t44 kernel: [111051.513900] dvb-usb: will pass the complete 
MPEG2 transport stream to the software demuxer.
Dec 16 14:58:41 t44 kernel: [111051.513927] DVB: registering new adapter 
(Terratec Cinergy T USB XXS (HD)/ T3)
Dec 16 14:58:42 t44 kernel: [111051.820661] usb 1-3.3: DVB: registering adapter 
0 frontend 0 (DiBcom 7000PC)...
Dec 16 14:58:42 t44 kernel: [111052.005764] DiB0070: successfully identified
Dec 16 14:58:42 t44 kernel: [111052.005772] Registered IR keymap rc-dib0700-rc5
Dec 16 14:58:42 t44 kernel: [111052.005908] input: IR-receiver inside an USB 
DVB receiver as /devices/pci:00/:00:14.0/usb1/1-3/1-3.3/rc/rc0/input41
Dec 16 14:58:42 t44 kernel: [111052.006046] rc0: IR-receiver inside an USB DVB 
receiver as /devices/pci:00/:00:14.0/usb1/1-3/1-3.3/rc/rc0
Dec 16 14:58:42 t44 kernel: [111052.006121] dvb-usb: schedule remote query 
interval to 50 msecs.
Dec 16 14:58:42 t44 kernel: [111052.006123] dvb-usb: Terratec Cinergy T USB XXS 
(HD)/ T3 successfully initialized and connected.
Dec 16 14:58:42 t44 kernel: [111052.081381] usb 1-3.4: new high-speed USB 
device number 43 using xhci_hcd
Dec 16 14:58:42 t44 kernel: [111052.133231] [drm:c049a8c8] *ERROR* too 
many voltage retries, give up
Dec 16 14:58:42 t44 kernel: [111052.133235] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:42 t44 kernel: [111052.133244] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:42 t44 kernel: [111052.152078] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:42 t44 kernel: [111052.152088] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:42 t44 kernel: [111052.153692] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:42 t44 kernel: [111052.153702] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:42 t44 kernel: [111052.166747] usb 1-3.4: New USB device found, 
idVendor=17ef, idProduct=100f
Dec 16 14:58:42 t44 kernel: [111052.166750] usb 1-3.4: New USB device strings: 
Mfr=1, Product=2, SerialNumber=3
Dec 16 14:58:42 t44 kernel: [111052.166752] usb 1-3.4: Product: Lenovo ThinkPad 
Dock
Dec 16 14:58:42 t44 kernel: [111052.166754] usb 1-3.4: Manufacturer: Lenovo
Dec 16 14:58:42 t44 kernel: [111052.166756] usb 1-3.4: SerialNumber: Rev1.2
Dec 16 14:58:42 t44 kernel: [111052.167201] hub 1-3.4:1.0: USB hub found
Dec 16 14:58:42 t44 kernel: [111052.167264] hub 1-3.4:1.0: 3 ports detected
Dec 16 14:58:42 t44 kernel: [111052.440782] usb 1-3.4.3: new low-speed USB 
device number 44 using xhci_hcd
Dec 16 14:58:42 t44 kernel: [111052.546988] usb 1-3.4.3: New USB device found, 
idVendor=046d, idProduct=c062
Dec 16 14:58:42 t44 kernel: [111052.546991] usb 1-3.4.3: New USB device 
strings: Mfr=1, Product=2, SerialNumber=0
Dec 16 14:58:42 t44 kernel: [111052.546993] usb 1-3.4.3: Product: USB Laser 
Mouse
Dec 16 14:58:42 t44 kernel: [111052.546995] usb 1-3.4.3: Manufacturer: Logitech
...
Dec 16 14:58:48 t44 kernel: [111057.722954] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:48 t44 kernel: [111057.722964] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:48 t44 kernel: [111058.399772] [drm:c049a8c8] *ERROR* too 
many voltage retries, give up
Dec 16 14:58:48 t44 kernel: [111058.399776] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:48 t44 kernel: [111058.399785] [drm:c0457004] *ERROR* 
Unclaimed register before interrupt
Dec 16 14:58:48 t44 kernel: [111058.418626] [drm:c0457004] *ER

[PATCH] drm/panel: add kernel doc for size attributes in panel_desc

[Thierry Reding]

On Fri, Dec 04, 2015 at 12:31:28PM +0100, Ulrich Ölmann wrote:
> Document that 'width' and 'height' are measured in millimeters.
> 
> Signed-off-by: Ulrich Ölmann 
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 4 
>  1 file changed, 4 insertions(+)

I've applied this, with a slightly reworded comment, to clarify that it
is the size of the active display area:

/**
 * @width: width (in millimeters) of the panel's active display area
 * @height: height (in millimeters) of the panel's active display area
 */

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

[PATCH] android: fix warning when releasing active sync point

[Daniel Vetter]

On Tue, Dec 15, 2015 at 11:08:01AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 15, 2015 at 11:00 AM, Gustavo Padovan  
> wrote:
> > 2015-12-15 Daniel Vetter :
> >
> >> On Mon, Dec 14, 2015 at 05:29:55PM -0800, Dmitry Torokhov wrote:
> >> > Userspace can close the sync device while there are still active fence
> >> > points, in which case kernel produces the following warning:
> >> >
> >> > [   43.853176] [ cut here ]
> >> > [   43.857834] WARNING: CPU: 0 PID: 892 at 
> >> > /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439
> >> >  android_fence_release+0x88/0x104()
> >> > [   43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 
> >> > 3.18.0-07661-g0550ce9 #1
> >> > [   43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
> >> > [   43.885834] Call trace:
> >> > [   43.888294] [] dump_backtrace+0x0/0x10c
> >> > [   43.893697] [] show_stack+0x10/0x1c
> >> > [   43.898756] [] dump_stack+0x74/0xb8
> >> > [   43.903814] [] warn_slowpath_common+0x84/0xb0
> >> > [   43.909736] [] warn_slowpath_null+0x14/0x20
> >> > [   43.915482] [] android_fence_release+0x84/0x104
> >> > [   43.921582] [] fence_release+0x104/0x134
> >> > [   43.927066] [] sync_fence_free+0x74/0x9c
> >> > [   43.932552] [] sync_fence_release+0x34/0x48
> >> > [   43.938304] [] __fput+0x100/0x1b8
> >> > [   43.943185] [] fput+0x8/0x14
> >> > [   43.947982] [] task_work_run+0xb0/0xe4
> >> > [   43.953297] [] do_notify_resume+0x44/0x5c
> >> > [   43.958867] ---[ end trace 5a2aa4027cc5d171 ]---
> >> >
> >> > Let's fix it by introducing a new optional callback (disable_signaling)
> >> > to fence operations so that drivers can do proper clean ups when we
> >> > remove last callback for given fence.
> >> >
> >> > Reviewed-by: Andrew Bresticker 
> >> > Signed-off-by: Dmitry Torokhov 
> >> > ---
> >> >  drivers/dma-buf/fence.c| 6 +-
> >> >  drivers/staging/android/sync.c | 8 
> >> >  include/linux/fence.h  | 2 ++
> >> >  3 files changed, 15 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c
> >> > index 7b05dbe..0ed73ad 100644
> >> > --- a/drivers/dma-buf/fence.c
> >> > +++ b/drivers/dma-buf/fence.c
> >> > @@ -304,8 +304,12 @@ fence_remove_callback(struct fence *fence, struct 
> >> > fence_cb *cb)
> >> > spin_lock_irqsave(fence->lock, flags);
> >> >
> >> > ret = !list_empty(&cb->node);
> >> > -   if (ret)
> >> > +   if (ret) {
> >> > list_del_init(&cb->node);
> >> > +   if (list_empty(&fence->cb_list))
> >> > +   if (fence->ops->disable_signaling)
> >> > +   fence->ops->disable_signaling(fence);
> >>
> >> What exactly is the bug here? A fence with no callbacks registered any
> >> more shouldn't have any problem. Why exactly does this blow up?
> >
> > The WARN_ON is probably this one:
> > https://android.googlesource.com/kernel/common/+/android-3.18/drivers/staging/android/sync.c#433
> >
> > I've been wondering in the last few days if this warning is really
> > necessary. If the user is closing a sync_timeline that has unsignalled
> > fences it should probably be aware of that already. Then I think it is
> > okay to remove the the sync_pt from the active_list at the release-time.
> > In fact I've already prepared a patch doing that. Thoughts?
> >
> 
> Maybe, but you need to make sure that you only affecting your fences.
> 
> My main objection is that still leaves fence_remove_callback() being
> not mirror image of fence_add_callback().

That's 100% intentional. I looked at the sync.c code a bit more and it
duplicates a bunch of the fence stuff still. We need to either merge that
code into the mainline struct fence logic, or remove it. There shouldn't
really be any need for the userspace ABI layer to keep track of active
fences at all. Worse, it means that you must use the sync_pt struct to be
able to export it to userspace, and can't just export any normal struct
fence object. That breaks the abstraction we're aiming for.

Imo just remove that WARN_ON for now.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH] android: fix warning when releasing active sync point

[Daniel Vetter]

On Tue, Dec 15, 2015 at 09:22:56AM -0800, Dmitry Torokhov wrote:
> On Tue, Dec 15, 2015 at 5:30 AM, Gustavo Padovan  
> wrote:
> > 2015-12-14 Dmitry Torokhov :
> >
> >> Userspace can close the sync device while there are still active fence
> >> points, in which case kernel produces the following warning:
> >>
> >> [   43.853176] [ cut here ]
> >> [   43.857834] WARNING: CPU: 0 PID: 892 at 
> >> /mnt/host/source/src/third_party/kernel/v3.18/drivers/staging/android/sync.c:439
> >>  android_fence_release+0x88/0x104()
> >> [   43.871741] CPU: 0 PID: 892 Comm: Binder_5 Tainted: G U 
> >> 3.18.0-07661-g0550ce9 #1
> >> [   43.880176] Hardware name: Google Tegra210 Smaug Rev 1+ (DT)
> >> [   43.885834] Call trace:
> >> [   43.888294] [] dump_backtrace+0x0/0x10c
> >> [   43.893697] [] show_stack+0x10/0x1c
> >> [   43.898756] [] dump_stack+0x74/0xb8
> >> [   43.903814] [] warn_slowpath_common+0x84/0xb0
> >> [   43.909736] [] warn_slowpath_null+0x14/0x20
> >> [   43.915482] [] android_fence_release+0x84/0x104
> >> [   43.921582] [] fence_release+0x104/0x134
> >> [   43.927066] [] sync_fence_free+0x74/0x9c
> >> [   43.932552] [] sync_fence_release+0x34/0x48
> >> [   43.938304] [] __fput+0x100/0x1b8
> >> [   43.943185] [] fput+0x8/0x14
> >> [   43.947982] [] task_work_run+0xb0/0xe4
> >> [   43.953297] [] do_notify_resume+0x44/0x5c
> >> [   43.958867] ---[ end trace 5a2aa4027cc5d171 ]---
> >
> > This crash report seems to be for a 3.18 kernel. Can you reproduce it
> > on upstream kernel as well?
> 
> Unfortunately this board does not run upsrteam just yet, but looking
> at the sync driver and fence code we are pretty much in sync with
> upstream.

Just to check: Is that with a proper hw driver, or using SW_SYNC? The
later will get removed in upstream since it's a debug/validation only
interface. Well, removed for drivers and production systems, the
kselftests will use it.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 1/7] drm/omap: ensure all displays have been probed

[Tomi Valkeinen]

On 13/12/15 22:30, Laurent Pinchart wrote:
> Hi Tomi,
> 
> Thank you for the patch.
> 
> On Wednesday 09 December 2015 17:38:05 Tomi Valkeinen wrote:
>> DRM offers no ways to add new displays after the DRM driver has been
>> loaded. This causes issues on boards that have multiple displays, and
>> omapdrm is loaded when some of them are loaded but not all. The result
>> is that omapdrm starts with the displays that were loaded at that time,
>> ignoring the displays loaded later.
>>
>> This patch changes the behavior so that omapdrm ensures all display are
>> loaded which have an alias in the .dts file.
>>
>> The downside is that this prevents omapdrm from loading if, say, the
>> user has not compiled a kernel module for one of the displays, or
>> there's some kind of failure in one of the displays. Thus, after this
>> patch, all the displays have to work, or none does.
>>
>> Signed-off-by: Tomi Valkeinen 
>> ---
>>  drivers/gpu/drm/omapdrm/omap_drv.c | 27 +++
>>  1 file changed, 27 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
>> b/drivers/gpu/drm/omapdrm/omap_drv.c index 5c6609cbb6a2..c93c13e2c22d
>> 100644
>> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>> @@ -242,11 +242,38 @@ static void omap_disconnect_dssdevs(void)
>>  dssdev->driver->disconnect(dssdev);
>>  }
>>
>> +static bool dssdev_with_alias_exists(const char *alias)
>> +{
>> +struct omap_dss_device *dssdev = NULL;
>> +
>> +for_each_dss_dev(dssdev) {
>> +if (strcmp(alias, dssdev->alias) == 0) {
>> +omap_dss_put_device(dssdev);
>> +return true;
>> +}
>> +}
>> +
>> +return false;
>> +}
>> +
>>  static int omap_connect_dssdevs(void)
>>  {
>>  int r;
>>  struct omap_dss_device *dssdev = NULL;
>>  bool no_displays = true;
>> +struct device_node *aliases;
>> +struct property *pp;
>> +
>> +aliases = of_find_node_by_path("/aliases");
>> +if (aliases) {
>> +for_each_property_of_node(aliases, pp) {
>> +if (strncmp(pp->name, "display", 7) != 0)
>> +continue;
>> +
>> +if (dssdev_with_alias_exists(pp->name) == false)
>> +return -EPROBE_DEFER;
>> +}
>> +}
> 
> The DSS bindings document the aliases as optional, so this won't work in the 
> general case. The best solution would be to travel the display graph through 
> the ports and use the components framework, but that would be more complex to 
> implement.

Well, even with this patch aliases are optional. The difference is that
if you don't have any aliases, and omapdrm starts, and one of the
multiple displays has not been probed yet, that display will be
unavailable. If you do have aliases, omapdrm ensures that the displays
with an alias are probed.

But... You are probably right, travelling the graph is better.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151216/45c91328/attachment.sig>

[PATCH RFC 0/9] omapdrm/omapfb/omapdss split

[Tomi Valkeinen]

mapfb/dss/display.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dpi.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dsi.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss-of.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss.h
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss_features.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/dss_features.h
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi.h
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi4_core.h
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi5_core.h
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_common.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_pll.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/hdmi_wp.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/manager-sysfs.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/manager.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/omapdss-boot-init.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/output.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/overlay-sysfs.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/overlay.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/pll.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/rfbi.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/sdi.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/venc.c
>  create mode 100644 drivers/video/fbdev/omap2/omapfb/dss/video-pll.c
>  rename drivers/video/fbdev/omap2/{ => omapfb}/vrfb.c (100%)
> 

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151216/dfde8bd4/attachment-0001.sig>

[PATCH v2 00/16] omapdrm: Implement dma_buf import

[Tomi Valkeinen]

Hi Laurent,

On 14/12/15 22:39, Laurent Pinchart wrote:
> Hello,
> 
> This patch series implements support for dma_buf import in the omapdrm driver.
> The patches are based on top of the latest drm-next branch and can be found in
> my git tree at
> 
> git://linuxtv.org/pinchartl/fbdev.git omapdrm/dmabuf-import
> 
> The first two patches are unrelated fixes and enhancements, but I've included
> them in the series to avoid merge conflicts.
> 
> The next 13 patches are miscellaneous fixes, cleanups and refactoring to
> prepare for patch 16/16 that implements dma_buf import.
> 
> The code has been successfully tested with the vivid driver as an exporter,
> using a hacked version that uses uncached CPU mappings in vivid when filling
> the buffers. vivid is a test driver that generates a test pattern using the
> CPU with cached mappings by default, resulting in corruption on the screen due
> to missing cache handling. As the problem doesn't occur when sharing buffers
> not touched by the CPU or touched through uncached mappings only, it will be
> addressed separately.

I've picked up these patches to my omapdrm-4.5 branch:

drm: omapdrm: move omap_plane_reset()
drm: omapdrm: Fix plane state free in plane reset handler
drm: omapdrm: Make fbdev emulation optional
drm: omapdrm: gem: Remove unused function prototypes
drm: omapdrm: gem: Remove forward declarations
drm: omapdrm: gem: Group functions by purpose
drm: omapdrm: gem: Move global usergart variable to omap_drm_private
drm: omapdrm: gem: Mask out private flags passed from userspace
drm: omapdrm: gem: Free the correct memory object
drm: omapdrm: gem: Fix GEM object destroy in error path
drm: omapdrm: gem: Don't free mmap offset twice
drm: omapdrm: gem: Simplify error handling when creating GEM object
drm: omapdrm: gem: Remove check for impossible condition

I did split the "Fix plane state free in plane reset handler" into two,
moving the function first. And as I dropped few patches from between the
others, they're not exactly as they were in your series.

The remaining patches are:

drm: omapdrm: gem: Remove omap_drm_private has_dmm field
drm: omapdrm: gem: Clean up GEM objects memory flags
drm: omapdrm: gem: Refactor GEM object allocation
drm: omapdrm: gem: Implement dma_buf import

Those are more complex, and I haven't fully reviewed them yet. I wanted
to get the bulk of the patches already, so that I can ensure we get at
least those to 4.5.

 Tomi

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151216/47e45066/attachment.sig>

[Bug 109481] New: Radeon Module crashing/freezing on ATI/AMD Evergreen (Radeon HD6250, Wrestler)

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

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

Bug ID: 109481
   Summary: Radeon Module crashing/freezing on ATI/AMD Evergreen
(Radeon HD6250, Wrestler)
   Product: Drivers
   Version: 2.5
Kernel Version: 4.3.3
  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: elbuffo166 at gmail.com
Regression: No

We have some hundred ThinClients (Fujitsu Futro S900) based on AMD G-T44R with
AMD Radeon HD 6250.

I have tested with some Kernel-Versions, e.g. the newest of 4.1, 4.2, 4.3 and
4.4-RC5.
On all these Kernels, System is freezing with a black screen, when radeon
module with enabled modeset is loaded.
With kernel parameter nomodeset system is not freezing, but the xorg ati driver
will need kms.

I've tried booting an Ubuntu Live System to verify, that it is not the problem
of my ThinClient distribution. Ubuntu 15.10 as well  fails with a black screen.

I've the following trace:

radeon: Unknown symbol i2c_bit_add_bus (err 0)
radeon: Unknown symbol i2c_bit_add_bus (err 0)
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (PALM 0x1002:0x9805 0x1734:0x11BD).
[drm] register mmio base: 0xFEB0
[drm] register mmio size: 262144
ATOM BIOS: AMD
radeon :00:01.0: VRAM: 384M 0x - 0x17FF (384M
used)
radeon :00:01.0: GTT: 1024M 0x1800 - 0x57FF
[drm] Detected VRAM RAM=384M, BAR=256M
[drm] RAM width 32bits DDR
[TTM] Zone  kernel: Available graphics memory: 443856 kiB
[TTM] Zone highmem: Available graphics memory: 824158 kiB
[TTM] Initializing pool allocator
[drm] radeon: 384M of VRAM memory ready
[drm] radeon: 1024M of GTT memory ready.
[drm] Loading PALM Microcode
[drm] Internal thermal controller without fan control
[drm] Found smc ucode version: 0x00010601
[drm] radeon: dpm initialized
[drm] GART: num cpu pages 262144, num gpu pages 262144
[drm] PCIE GART of 1024M enabled (table at 0x00274000).
radeon :00:01.0: WB enabled
radeon :00:01.0: fence driver on ring 0 use gpu addr 0x18000c00 and
cpu addr 0xf1788c00
radeon :00:01.0: fence driver on ring 3 use gpu addr 0x18000c0c and
cpu addr 0xf1788c0c
radeon :00:01.0: fence driver on ring 5 use gpu addr 0x00072118 and
cpu addr 0xf9432118
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
radeon :00:01.0: radeon: MSI limited to 32-bit
[drm] radeon: irq initialized.
[drm] ring test on 0 succeeded in 1 usecs
[drm] ring test on 3 succeeded in 3 usecs
[drm] ring test on 5 succeeded in 1 usecs
[drm] UVD initialized successfully.
[drm] ib test on ring 0 succeeded in 0 usecs
[drm] ib test on ring 3 succeeded in 0 usecs
[drm] ib test on ring 5 succeeded
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm]   DP-1
[drm]   HPD1
[drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] Connector 1:
[drm]   DVI-D-1
[drm]   HPD2
[drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY
BUG: unable to handle kernel NULL pointer dereference at 0024
IP: [] atombios_get_encoder_mode+0x87/0x178 [radeon]
*pde =  
Oops:  [#1] SMP 
Modules linked in: radeon(+) i2c_algo_bit ipv6 ati_agp snd_hda_intel k10temp
hwmon drm_kms_helper snd_hda_codec_realtek snd_hda_codec_generic
snd_hda_codec_hdmi ttm snd_hda_codec snd_hda_core fujitsu_laptop video drm
snd_hwdep snd_pcm snd_timer snd agpgart soundcore syscopyarea sysfillrect
sysimgblt fb_sys_fops button acpi_cpufreq squashfs [last unloaded:
snd_hda_intel]
CPU: 0 PID: 2457 Comm: modprobe Not tainted 4.3.0-slitaz #2
Hardware name: FUJITSU FUTRO S900/D3003-A1, BIOS V4.6.4.1 R1.14.0 for D3003-A1x
01/27/2012
task: f284a080 ti: d343 task.ti: d343
EIP: 0060:[] EFLAGS: 00010246 CPU: 0
EIP is at atombios_get_encoder_mode+0x87/0x178 [radeon]
EAX:  EBX:  ECX: f167c9ec EDX: f167c9e0
ESI: f6699600 EDI: d341 EBP: 0020 ESP: d3431d2c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
CR0: 8005003b CR2: 0024 CR3: 3418d000 CR4: 06d0
Stack:
 f6699600 0003 d341 f90b9524 f6699600 f911ed18 f167c9f8 0020
 f8302270 f6699600 f167c800 f83022ac f167c800 d341  f8302320
 f6699200 f90797f8 d341 0002 0002 f167c800 f9075554 
Call Trace:
 [] ? radeon_atom_encoder_dpms+0x14/0xeb [radeon]
 [] ? drm_encoder_disable+0x25/0x2f [drm_kms_helper]
 [] ? __drm_helper_disable_unused_functions+0x32/0x97
[drm_kms_helper]
 [] ? drm_helper_disable_unused_functions+0xf/0x17 [drm_kms_helper]
 [] ? radeon_fbdev_init+0xa2/0xc8 [radeon]
 [] ? radeon_modeset_init+0x6b4/0x820 [radeon]
 [] ? radeon

[PATCH v4 2/2] drm: panel: simple: add QiaoDian qd43003c0-40

[Thierry Reding]

On Tue, Dec 15, 2015 at 02:43:47PM +0100, Nicolas Ferre wrote:
> Le 02/12/2015 23:03, Alexandre Belloni a écrit :
> > From: Josh Wu 
> > 
> > The QiaoDian Xianshi QD43003C0-40 is a 4"3 TFT LCD panel.
> > 
> > Timings from the OTA5180A document, ver 0.9, section
> > 10.1.1:
> >   http://www.orientdisplay.com/pdf/OTA5180A.pdf
> > 
> > Signed-off-by: Josh Wu 
> > Signed-off-by: Alexandre Belloni 
> > Acked-by: Rob Herring 
> 
> If it can speed-up things:
> Acked-by: Nicolas Ferre 
> 
> Thierry, it seems that this patch keeps on sitting aside for quite some
> time, and Alexandre only rebased it lately so it can be easier to take
> (so this v4).
> 
> Can we see this trivial patch move forward so that we can at least see
> it appearing in linux-next and use our screen with Mainline?

Please make sure to Cc: dri-devel at lists.freedesktop.org on patches that
apply under drivers/gpu/drm to make sure that patchwork picks them up. I
recommend also sending the corresponding vendor prefix patches to that
list, which makes it a whole lot easier to track.

Also, please use "drm/panel: " as the prefix (instead of "drm: panel: ")
to make it easier for me to pick up things. I was about to send out a
pull request for drm/panel when I noticed that there was this patch. The
v4 wasn't Cc: dri-devel, so I ended up applying v3 from patchwork. From
the changelog it seems like that's okay, though.

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

[PATCH] drm/docs: more leftovers from the big vtable documentation pile

[Daniel Vetter]

Another pile of vfuncs from the old gpu.tmpl xml documentation that
I've forgotten to delete. I spotted a few more things to
clarify/extend in the new kerneldoc while going through this once
more.

Cc: Laurent Pinchart 
Cc: Thierry Reding 
Signed-off-by: Daniel Vetter 
---
 Documentation/DocBook/gpu.tmpl   | 188 ---
 include/drm/drm_modeset_helper_vtables.h |  28 -
 2 files changed, 25 insertions(+), 191 deletions(-)

diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index a3764291c826..c0fa21c797fe 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1579,194 +1579,6 @@ void intel_crt_init(struct drm_device *dev)
   entities.
 
 
-  Legacy CRTC Helper Operations
-  
-
-  bool (*mode_fixup)(struct drm_crtc *crtc,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
-  
-Let CRTCs adjust the requested mode or reject it completely. This
-operation returns true if the mode is accepted (possibly after 
being
-adjusted) or false if it is rejected.
-  
-  
-The mode_fixup operation should reject the
-mode if it can't reasonably use it. The definition of "reasonable"
-is currently fuzzy in this context. One possible behaviour would be
-to set the adjusted mode to the panel timings when a fixed-mode
-panel is used with hardware capable of scaling. Another behaviour
-would be to accept any input mode and adjust it to the closest mode
-supported by the hardware (FIXME: This needs to be clarified).
-  
-
-
-  int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
-  
-Move the CRTC on the current frame buffer (stored in
-crtc->fb) to position (x,y). Any of the frame
-buffer, x position or y position may have been modified.
-  
-  
-This helper operation is optional. If not provided, the
-drm_crtc_helper_set_config function will fall
-back to the mode_set helper operation.
-  
-  
-FIXME: Why are x and y passed as arguments, as they can be accessed
-through crtc->x and
-crtc->y?
-  
-
-
-  void (*prepare)(struct drm_crtc *crtc);
-  
-Prepare the CRTC for mode setting. This operation is called after
-validating the requested mode. Drivers use it to perform
-device-specific operations required before setting the new mode.
-  
-
-
-  int (*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);
-  
-Set a new mode, position and frame buffer. Depending on the device
-requirements, the mode can be stored internally by the driver and
-applied in the commit operation, or
-programmed to the hardware immediately.
-  
-  
-The mode_set operation returns 0 on 
success
-   or a negative error code if an error occurs.
-  
-
-
-  void (*commit)(struct drm_crtc *crtc);
-  
-Commit a mode. This operation is called after setting the new mode.
-Upon return the device must use the new mode and be fully
-operational.
-  
-
-  
-
-
-  Encoder Helper Operations
-  
-
-  bool (*mode_fixup)(struct drm_encoder *encoder,
-   const struct drm_display_mode *mode,
-   struct drm_display_mode *adjusted_mode);
-  
-Let encoders adjust the requested mode or reject it completely. 
This
-operation returns true if the mode is accepted (possibly after 
being
-adjusted) or false if it is rejected. See the
-mode_fixup CRTC helper
-operation for an explanation of the allowed adjustments.
-  
-
-
-  void (*prepare)(struct drm_encoder *encoder);
-  
-Prepare the encoder for mode setting. This operation is called 
after
-validating the requested mode. Drivers use it to perform
-device-specific operations required before setting the new mode.
-  
-
-
-  void (*mode_set)(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode);
-  
-Set a new mode. Depending on the device requirements, the mode can
-be stored inte

[GIT PULL] drm/panel: Changes for v4.5-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:

  Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.5-rc1

for you to fetch changes up to d2a6f0f5597696ebf5bb34089be3b88ba2455b7a:

  drm/panel: simple: Add QiaoDian qd43003c0-40 (2015-12-16 18:15:26 +0100)

Thanks,
Thierry


drm/panel: Changes for v4.5-rc1

This set of changes brings in a few more helpers for DSI support as well
as a couple of new drivers and support for some more simple panels.


Akshay Bhat (1):
  drm/panel: simple: Add support for Innolux G121X1-L03

Alexandre Belloni (1):
  of: Add vendor prefix for QiaoDian Xianshi

Chris Zhong (3):
  of: Add vendor prefix for BOE Technology Group
  dt-bindings: Add BOE TV080WUM-NL0 panel binding
  drm/panel: simple: Add support for BOE TV080WUM-NL0

Josh Wu (1):
  drm/panel: simple: Add QiaoDian qd43003c0-40

Liu Ying (1):
  drm/dsi: Add a helper to get bits per pixel of MIPI DSI pixel format

Lucas Stach (2):
  devicetree: add vendor prefix for Kyocera Corporation
  drm/panel: simple: Add support for Kyocera TCG121XGLP panel

Thierry Reding (2):
  drm/bridge: dw-hdmi: Use dashes in filenames
  drm/bridge: Remove gratuitous blank line

Ulrich Ölmann (1):
  drm/panel: add kernel doc for size attributes in panel_desc

Werner Johansson (5):
  dt-bindings: Add Panasonic VVX10F034N00 panel binding
  drm/panel: Add Panasonic VVX10F034N00 MIPI DSI panel
  drm/dsi: Add Turn On/Shutdown Peripheral command helpers
  dt-bindings: Add Sharp LS043T1LE01 panel binding
  drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

 .../bindings/display/panel/boe,tv080wum-nl0.txt|   7 +
 .../bindings/display/panel/innolux,g121x1-l03.txt  |   7 +
 .../bindings/display/panel/kyo,tcg121xglp.txt  |   7 +
 .../bindings/display/panel/sharp,ls043t1le01.txt   |  22 ++
 .../bindings/panel/panasonic,vvx10f034n00.txt  |  20 ++
 .../bindings/panel/qiaodian,qd43003c0-40.txt   |   7 +
 .../devicetree/bindings/vendor-prefixes.txt|   3 +
 drivers/gpu/drm/bridge/Kconfig |   1 -
 drivers/gpu/drm/bridge/Makefile|   4 +-
 .../{dw_hdmi-ahb-audio.c => dw-hdmi-ahb-audio.c}   |   2 +-
 .../bridge/{dw_hdmi-audio.h => dw-hdmi-audio.h}|   0
 drivers/gpu/drm/bridge/{dw_hdmi.c => dw-hdmi.c}|   4 +-
 drivers/gpu/drm/bridge/{dw_hdmi.h => dw-hdmi.h}|   0
 drivers/gpu/drm/drm_mipi_dsi.c |  38 ++
 drivers/gpu/drm/panel/Kconfig  |  19 +
 drivers/gpu/drm/panel/Makefile |   2 +
 .../gpu/drm/panel/panel-panasonic-vvx10f034n00.c   | 334 ++
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c| 387 +
 drivers/gpu/drm/panel/panel-simple.c   | 123 +++
 include/drm/drm_mipi_dsi.h |  27 ++
 20 files changed, 1008 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/boe,tv080wum-nl0.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/innolux,g121x1-l03.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/kyo,tcg121xglp.txt
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
 create mode 100644 
Documentation/devicetree/bindings/panel/panasonic,vvx10f034n00.txt
 create mode 100644 
Documentation/devicetree/bindings/panel/qiaodian,qd43003c0-40.txt
 rename drivers/gpu/drm/bridge/{dw_hdmi-ahb-audio.c => dw-hdmi-ahb-audio.c} 
(99%)
 rename drivers/gpu/drm/bridge/{dw_hdmi-audio.h => dw-hdmi-audio.h} (100%)
 rename drivers/gpu/drm/bridge/{dw_hdmi.c => dw-hdmi.c} (99%)
 rename drivers/gpu/drm/bridge/{dw_hdmi.h => dw-hdmi.h} (100%)
 create mode 100644 drivers/gpu/drm/panel/panel-panasonic-vvx10f034n00.c
 create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c

[GIT PULL] drm/tegra: Changes for v4.5-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 663a233eef643b38f36c05535cb5c9a4972edcc1:

  Merge branch 'drm-header-fixes' of https://github.com/GabrielL/linux into 
drm-next (2015-12-11 13:46:05 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.5-rc1

for you to fetch changes up to ad906599c1919eda6f365ecec8d50198c9232131:

  drm/tegra: Advertise DRIVER_ATOMIC (2015-12-14 15:47:36 +0100)

Thanks,
Thierry


drm/tegra: Changes for v4.5-rc1

This adds support for the version of host1x found on Tegra210 SoCs. It
also makes use of the new atomic suspend/resume functionality to bring
this feature to Tegra.

Other than that it's mostly small fixes and cleanups, with some prep-
work for things that will hopefully get merged for the next release.


Dan Carpenter (1):
  drm/tegra: checking for IS_ERR() instead of NULL

Daniel Vetter (3):
  drm/tegra: Use unlocked gem unreferencing
  drm/tegra: Don't take dev->struct_mutex in mmap offset ioctl
  drm/tegra: Use drm_gem_object_unreference_unlocked()

Julia Lawall (1):
  drm/tegra: dc: Add missing of_node_put()

Thierry Reding (9):
  gpu: host1x: Use platform_register/unregister_drivers()
  gpu: host1x: Remove core driver on unregister
  gpu: host1x: Add Tegra210 support
  drm/tegra: Use new multi-driver module helpers
  drm/tegra: sor: Operate on struct drm_dp_aux *
  drm/tegra: sor: Remove unnecessary conditional
  drm/tegra: Implement subsystem-level suspend/resume
  drm/tegra: Use DRIVER level for IOMMU aperture message
  drm/tegra: Advertise DRIVER_ATOMIC

 drivers/gpu/drm/tegra/dc.c  |   4 +-
 drivers/gpu/drm/tegra/dpaux.c   |  41 ++---
 drivers/gpu/drm/tegra/drm.c |  89 --
 drivers/gpu/drm/tegra/drm.h |  27 ++--
 drivers/gpu/drm/tegra/fb.c  |  24 +++
 drivers/gpu/drm/tegra/gem.c |  15 +-
 drivers/gpu/drm/tegra/sor.c | 145 -
 drivers/gpu/host1x/Makefile |   3 +-
 drivers/gpu/host1x/bus.c|   2 +
 drivers/gpu/host1x/dev.c|  33 ++--
 drivers/gpu/host1x/hw/host1x05.c|  42 +
 drivers/gpu/host1x/hw/host1x05.h|  26 +++
 drivers/gpu/host1x/hw/host1x05_hardware.h   | 142 
 drivers/gpu/host1x/hw/hw_host1x05_channel.h | 121 ++
 drivers/gpu/host1x/hw/hw_host1x05_sync.h| 243 
 drivers/gpu/host1x/hw/hw_host1x05_uclass.h  | 181 +
 16 files changed, 944 insertions(+), 194 deletions(-)
 create mode 100644 drivers/gpu/host1x/hw/host1x05.c
 create mode 100644 drivers/gpu/host1x/hw/host1x05.h
 create mode 100644 drivers/gpu/host1x/hw/host1x05_hardware.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x05_channel.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x05_sync.h
 create mode 100644 drivers/gpu/host1x/hw/hw_host1x05_uclass.h

[PATCH 08/15] drm: omapdrm: gem: Mask out private flags passed from userspace

[Emil Velikov]

Hi Laurent,

On 14 December 2015 at 20:33, Laurent Pinchart
 wrote:
> Hi Emil,
>
> On Monday 07 December 2015 14:13:43 Emil Velikov wrote:
>> On 4 December 2015 at 22:27, Laurent Pinchart wrote:
>> > The 8 high order bits of the buffer flags are reserved for internal use.
>> > Mask them out from the flags passed by userspace.
>>
>> Ouch... I know that the Intel guys are pretty rigorous about input
>> validation, although I wonder how many drivers are (partially or not)
>> missing these.
>>
>> > Signed-off-by: Laurent Pinchart 
>> > ---
>> >
>> >  drivers/gpu/drm/omapdrm/omap_drv.c | 9 ++---
>> >  include/uapi/drm/omap_drm.h| 1 +
>> >  2 files changed, 7 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
>> > b/drivers/gpu/drm/omapdrm/omap_drv.c index 83d63d71062c..e405ab23d7a6
>> > 100644
>> > --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>> > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>> > @@ -551,10 +551,13 @@ static int ioctl_gem_new(struct drm_device *dev,
>> > void *data,
>> > struct drm_file *file_priv)
>> >  {
>> > struct drm_omap_gem_new *args = data;
>> > +   u32 flags = args->flags & OMAP_BO_USER_MASK;
>> > +
>> > VERB("%p:%p: size=0x%08x, flags=%08x", dev, file_priv,
>> > -   args->size.bytes, args->flags);
>> > -   return omap_gem_new_handle(dev, file_priv, args->size,
>> > -   args->flags, &args->handle);
>> > +args->size.bytes, flags);
>> > +
>> > +   return omap_gem_new_handle(dev, file_priv, args->size, flags,
>> > +  &args->handle);
>> >  }
>> >
>> >  static int ioctl_gem_cpu_prep(struct drm_device *dev, void *data,
>> > diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
>> > index 1d0b1172664e..6852c26e8f78 100644
>> > --- a/include/uapi/drm/omap_drm.h
>> > +++ b/include/uapi/drm/omap_drm.h
>> > @@ -36,6 +36,7 @@ struct drm_omap_param {
>> >
>> >  #define OMAP_BO_SCANOUT0x0001  /* scanout capable (phys
>> >  contiguous) */
>> >  #define OMAP_BO_CACHE_MASK 0x0006  /* cache type mask, see
>> >  cache modes */
>> >  #define OMAP_BO_TILED_MASK 0x0f00  /* tiled mapping mask, see
>> >  tiled modes */
>> > +#define OMAP_BO_USER_MASK  0x00ff  /* flags settable by
>> > userspace */
>>
>> Fwiw I'm not too sure that adding the mask here  (UAPI) is a good
>> idea.
>
> Good point, I'll make it private.
>
Thanks for the update (hiding the extra define from UAPI). Shame we
cannot do that for OMAP_BO_TILED_MASK :'-(

>> If you like to keep it, I'd suggest that it encapsulates only what's
>> currently available. Might even want to move the individual masks in the
>> respective sections/hunks. Speaking of which - OMAP_BO_TILED_MASK should be
>> 0x0300, shouldn't it ?
>
> I suppose 0x0f00 was chosen to reserve a couple of bits for additional
> tiled modes.
>
Perhaps a silly question - what is the reason to have larger mask than
the actual supported flags ? Looking from other drm modules (and vague
memories of other subsystems), drivers do not try to be forward
compatible and reject (should reject that is) unsupported flags.

Am I missing something ?

Thanks
Emil

[Bug 109481] Radeon Module crashing/freezing on ATI/AMD Evergreen (Radeon HD6250, Wrestler)

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||alexdeucher at gmail.com

--- Comment #1 from Alex Deucher  ---
Is this a regression?  If so, when was it working last?

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

[Bug 93412] hang in xcb_wait_for_reply / vl_dri2_get_flush_reply

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

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

Bug ID: 93412
   Summary: hang in xcb_wait_for_reply / vl_dri2_get_flush_reply
   Product: Mesa
   Version: 11.0
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel at lists.freedesktop.org
  Reporter: vliaskov at gmail.com
QA Contact: dri-devel at lists.freedesktop.org

Application that renders using libva/vdpau/opengl hangs after a few minutes of
operation (always reproducible within 1-15 minutes usually).

I see a hang in xcb_wait_for_reply() for request #31161:

Possibly relevant part of xtrace:
000:>:4d8a:32: Reply to SwapBuffers: swap_hi=0 swap_lo=31161
000:>:4d8b:32: Reply to GetInputFocus: revert-to=Parent(0x02) focus=0x02e000e0
000:<:24d8c: 20: DRI2-Request(155,7): GetBuffersWithFormat drawable=0x0446
attachments={attachment=BackLeft(0x0001) format=0x0020};
000:>:24d8c: Event DRI2-BufferSwapComplete(102) drawable=0x0002
ust_hi=71303174 ust_lo=0 msc_hi=1858207713 msc_lo=0 sbc_hi=109393 sbc_lo=31161

And:
000:<:31161:  4: Request(43): GetInputFocus  
000:>:31161: Event DRI2-InvalidateBuffers(103) drawable=0x0446

Backtrace of thread waiting in xcb_wait_for_reply():

Thread 8 (Thread 0x7fca1f778700 (LWP 3580)):
#0  0x7fca55a3e12d in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x7fca5316b262 in poll (__timeout=-1, __nfds=1, __fds=0x7fca1f776a20)
at
/usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  _xcb_conn_wait (c=c at entry=0x2885500, cond=cond at entry=0x7fca1f776b40,
vector=vector at entry=0x0, count=count at entry=0x0) at xcb_conn.c:459
#3  0x7fca5316cadf in wait_for_reply (c=c at entry=0x2885500, request=31161,
e=e at entry=0x0) at xcb_in.c:491
#4  0x7fca5316cbf2 in xcb_wait_for_reply (c=0x2885500, request=31161,
e=0x0)
at xcb_in.c:521
#5  0x7fca419b8004 in vl_dri2_get_flush_reply (scrn=0x2653600) at
../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:110
#6  0x7fca419b8101 in vl_dri2_destroy_drawable (scrn=0x2653600) at
../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:153
#7  0x7fca419b8185 in vl_dri2_set_drawable (scrn=0x2653600,
drawable=71303307) at
../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:176
#8  0x7fca419b82c8 in vl_dri2_screen_texture_from_drawable
(vscreen=0x2653600, drawable=0x440008b) at
../../../../../src/gallium/auxiliary/vl/vl_winsys_dri.c:193
#9  0x7fca419b61ab in vlVdpPresentationQueueDisplay
(presentation_queue=, surface=5, clip_width=1280,
 clip_height=720, earliest_presentation_time=0)
at
../../../../../../src/gallium/state_trackers/vdpau/presentation.c:234
#10 0x7fca423ca6a3 in flip_surface_unlocked
(driver_data=driver_data at entry=0x2650c90,
 obj_output=obj_output at entry=0x291a2b0) at vdpau_video_x11.c:583
#11 0x7fca423cb2e1 in queue_surface_unlocked (obj_surface=,
obj_output=0x291a2b0, driver_data=0x2650c90) at vdpau_video_x11.c:610
#12 put_surface_unlocked (flags=32, target_rect=0x7fca1f776f90,
source_rect=0x7fca1f776f80, obj_output=0x291a2b0,
obj_surface=0x2919bf0,
driver_data=0x2650c90) at vdpau_video_x11.c:689
#13 put_surface (driver_data=driver_data at entry=0x2650c90,
surface=surface at entry=50331655, drawable=drawable at entry=71303307,
drawable_width=, drawable_height=720,
source_rect=source_rect at entry=0x7fca1f776f80,
target_rect=target_rect at entry=0x7fca1f776f90, flags=flags at 
entry=32)
at vdpau_video_x11.c:755
#14 0x7fca423cb59c in vdpau_PutSurface (ctx=,
surface=50331655, draw=0x440008b, srcx=, srcy=, srcw=, srch=720, destx=0, desty=0,
destw=1280, desth=720, cliprects=0x0, number_cliprects=0, flags=32)
at vdpau_video_x11.c:808
#15 0x0040eed2 in on_client_draw (glsink=,
buf=, data=0x626d40 ) at video.c:619


Full backtrace at: http://pastebin.com/rQCJm64C

Using:

libX11 1.6.2
libxcb 1.10 or 1.11
mesa 11.0 (11.0~git1508070730.42d283~gd~t from oibaf/graphics-drivers ppa)
xserver-xorg-video-radeon 1:7.5.99+git1508070731.3791fc~gd~t (same ppa)

-- 
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/20151216/2141623f/attachment.html>

[Bug 93412] hang in xcb_wait_for_reply / vl_dri2_get_flush_reply

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

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

--- Comment #1 from Vasilis LIaskovitis  ---
I also made same bug  under xcb/protocol
https://bugs.freedesktop.org/show_bug.cgi?id=93414 , apologies for this, I am
not sure where to file this problem. I will close one of the two bugs when I am
pointed to the most appropriate component of the two.

-- 
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/20151216/7362735d/attachment.html>

[PATCH RFC 0/9] omapdrm/omapfb/omapdss split

[Rob Clark]

On Wed, Dec 16, 2015 at 10:52 AM, Tomi Valkeinen  
wrote:
> Hi Dave,
>
> On 10/12/15 16:25, Tomi Valkeinen wrote:
>> Hi,
>>
>> Here's an RFC series to fix the mess we have at the moment with
>> omapdrm/omapfb/omapdss.
>
> There hasn't been any NACKs for this series, so I'd like to get this in
> for 4.5.

I might suggest a short TODO/README type file explaining the current
state of flux and the plans going forward.. probably just copy/paste
the text from the cover letter.

other than that, if it's worth anything, you've got my a-b ;-)

BR,
-R

> As it's mostly on the fbdev side, I can merge this via fbdev tree. Only
> the two last patches are under drivers/gpu/ and it's unlikely they cause
> any conflicts, as they mainly just move files from drivers/fbdev/ to
> drivers/gpu/ (and they don't cause conflicts at the moment with my other
> omapdrm patches, nor with current drm-next).
>
> Can I get your ack on the two last patches?
>
>  Tomi
>
>> First, a short background on the current status. We have the following
>> entities:
>>
>> * omapdss, located in drivers/video/fbdev/omap2/dss/. This is a driver for 
>> the
>>   display subsystem IPs used on OMAP (and related) SoCs. It offers only a
>>   kernel internal API, and does not implement anything for fbdev or drm.
>>
>> * omapdss panels and encoders, located in
>>   drivers/video/fbdev/omap2/displays-new/. These are panel and external 
>> encoder
>>   drivers, which use APIs offered by omapdss driver. These also don't 
>> implement
>>   anything for fbdev or drm.
>>
>> * omapdrm, located in drivers/gpu/drm/omapdrm/. This is a drm driver, which
>>   uses omapdss and the panel/encoder drivers to operate the hardware.
>>
>> * omapfb, located in drivers/video/fbdev/omap2/omapfb/. This is an fbdev
>>   driver, which uses omapdss and the panel/encoder drivers to operate the
>>   hardware.
>>
>> * omap_vout, located in drivers/media/platform/omap/. This is a v4l2 driver,
>>   which uses omapdss and omapfb to implement a v4l2 API for the video 
>> overlays.
>>
>> So, on the top level, we have either omapdrm, or omapfb+omap_vout. Both of
>> those use the same low level drivers. Without going to the historical details
>> why the architecture is like that, I think it's finally time to change that.
>>
>> The situation with omapfb+omap_vout is that it still works, but no new 
>> features
>> have been added for a long time, and I want to keep it working as it's still
>> being used.  At some point in the future I'd like to remove omapfb and
>> omap_vout altogether.
>>
>> Omapdrm, on the other hand, is being actively developed. Sharing the low 
>> level
>> parts with omapfb makes that development more difficult than it should be. It
>> also "hides" half of the development, as everything happening in the low 
>> level
>> parts resides under fbdev directory, not in the drm directory.
>>
>> I've been wanting to clean this up for a long time, but I haven't figured 
>> out a
>> very good way to do it. I still haven't, but here's the best way I have come 
>> up
>> with.
>>
>> This series makes a full copy of the low level parts, omapdss and 
>> panel/encoder
>> drivers. Both omapfb+omap_vout and omapdrm will have their own versions. The
>> copy omapfb+omap_vout get is a new copy, and the copy that omapdrm gets is 
>> just
>> the current files moved. This way git will associate the omapdrm version with
>> the old files.
>>
>> The omapfb+omap_vout versions won't be touched unless there are some big 
>> issues
>> there.
>>
>> The omapdrm versions can be refactored and cleaned up, as the omapfb support
>> code is no longer needed. We can perhaps also merge omapdss and omapdrm into
>> the same kernel module.
>>
>> This series only does the copy, and the absolutely necessary parts. No 
>> further
>> cleanups are done yet.
>>
>>  Tomi
>>
>> Tomi Valkeinen (9):
>>   omapfb: allow compilation only if DRM_OMAP is disabled
>>   omapfb: copy omapdss & displays for omapfb
>>   omapdss: remove CONFIG_OMAP2_DSS_VENC from omapdss.h
>>   omapfb/dss: change CONFIG_OMAP* to CONFIG_FB_OMAP*
>>   omapfb/displays: change CONFIG_DISPLAY_* to CONFIG_FB_OMAP2_*
>>   omapfb: take omapfb's prive omapdss into use
>>   omapfb: move vrfb into omapfb
>>   drm/omap: move omapdss & displays under omapdrm
>>   drm/omap: make omapdrm select OMAP2_DSS
>>
>>  drivers/gpu/drm/Makefile   |2 +-
>>  drivers/gpu/drm/omapdrm/Kconfig|   10 +-
>>  drivers/gpu/drm/omapdrm/Makefile   |3 +
>>  .../drm/omapdrm/displays}/Kconfig  |3 +-
>>  .../drm/omapdrm/displays}/Makefile |0
>>  .../drm/omapdrm/displays}/connector-analog-tv.c|0
>>  .../drm/omapdrm/displays}/connector-dvi.c  |0
>>  .../drm/omapdrm/displays}/connector-hdmi.c |0
>>  .../drm/omapdrm/displays}/encoder-opa362.c |0
>>  .../drm/omapdrm/displays}/encoder-tfp410.c |0
>>  .../drm/omapdrm/displays}/encoder-tpd12s0

Direct userspace dma-buf mmap (v6)

[Tiago Vignatti]

Hi all,

The last version of this work was sent a while ago here:

http://lists.freedesktop.org/archives/dri-devel/2015-August/089263.html

So let's recap this series:

1. it adds a vendor-independent client interface for mapping gem objects
   through prime, IOW it implements userspace mmap() on dma-buf fd.
   This could be used for texturing from CPU rendered buffer, passing
   buffers among processes without performing copies in the userspace.
2. the series lets the client write on the mmap'ed memory, and
3. it deals with GPU and CPU caches synchronization.

Based on previous discussions seems that people are fine with 1. and 2. but 
not really with 3., given that caches coherency is a bit more boring to deal 
with.

It's easier to use this new infra on "coherent hardware" (systems with the
memory cache that is shared by the GPU and CPU) because they rarely need to
use that kind of synchronization. But would be much more convenient to have 
the very same interface exposed for clients no matter whether the underlying 
hardware is cache coherent or not.

One idea that came up was to force clients to call the sync ioctls after the
dma-buf was mmaped. But apparently there's no easy, and performant, way to do
so cause seems too costly to go over the page table entry and check the dirty
bits. Also, depending on the instructions order sent for the devices, it
might be needed a sync call after the mapped region gets accessed as well, to
flush all cachelines and make sure for example the GPU domain won't read stale 
data. So that would make the things even more complicated, if we ever decide
to go to this direction of forcing sync ioctls. The alternative therefore is to
simply document it very well, strong wording the clients to use the sync ioctl 
regardless otherwise they will mis-behave. Do we have objections or maybe 
other wiser ways to circumvent this? I've made similar comments in August and
no one has came up with better ideas.

Lastly, the diff of v6 series is that I've basically addressed concerns
pointed in the igt tests, organized those changes better a bit (in smaller
patches), documented the usage of sync ioctls and I have extensively tested 
this in different types of hardware.

https://github.com/tiagovignatti/drm-intel/commits/drm-intel-nightly_dma-buf-mmap-v6
https://github.com/tiagovignatti/intel-gpu-tools/commits/dma-buf-mmap-v6

Tiago


Daniel Thompson (1):
  drm: prime: Honour O_RDWR during prime-handle-to-fd

Daniel Vetter (1):
  dma-buf: Add ioctls to allow userspace to flush

Tiago Vignatti (3):
  dma-buf: Remove range-based flush
  drm/i915: Implement end_cpu_access
  drm/i915: Use CPU mapping for userspace dma-buf mmap()

 Documentation/dma-buf-sharing.txt | 41 +++---
 drivers/dma-buf/dma-buf.c | 56 ++-
 drivers/gpu/drm/drm_prime.c   | 10 ++
 drivers/gpu/drm/i915/i915_gem_dmabuf.c| 42 +--
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  4 +--
 drivers/gpu/drm/udl/udl_fb.c  |  2 --
 drivers/staging/android/ion/ion.c |  6 ++--
 drivers/staging/android/ion/ion_test.c|  4 +--
 include/linux/dma-buf.h   | 12 +++
 include/uapi/drm/drm.h|  1 +
 include/uapi/linux/dma-buf.h  | 38 +
 11 files changed, 169 insertions(+), 47 deletions(-)
 create mode 100644 include/uapi/linux/dma-buf.h


And the igt changes:
Rob Bradford (1):
  prime_mmap: Add new test for calling mmap() on dma-buf fds

Tiago Vignatti (5):
  lib: Add gem_userptr and __gem_userptr helpers
  prime_mmap: Add basic tests to write in a bo using CPU
  lib: Add prime_sync_start and prime_sync_end helpers
  tests: Add kms_mmap_write_crc for cache coherency tests
  tests: Add prime_mmap_coherency for cache coherency tests

 benchmarks/gem_userptr_benchmark.c |  55 +
 lib/ioctl_wrappers.c   |  92 +++
 lib/ioctl_wrappers.h   |  32 +++
 tests/Makefile.sources |   3 +
 tests/gem_userptr_blits.c  | 104 ++--
 tests/kms_mmap_write_crc.c | 281 +
 tests/prime_mmap.c | 494 +
 tests/prime_mmap_coherency.c   | 246 ++
 8 files changed, 1180 insertions(+), 127 deletions(-)
 create mode 100644 tests/kms_mmap_write_crc.c
 create mode 100644 tests/prime_mmap.c
 create mode 100644 tests/prime_mmap_coherency.c

-- 
2.1.4

[PATCH v6 1/5] drm: prime: Honour O_RDWR during prime-handle-to-fd

[Tiago Vignatti]

From: Daniel Thompson 

Currently DRM_IOCTL_PRIME_HANDLE_TO_FD rejects all flags except
(DRM|O)_CLOEXEC making it difficult (maybe impossible) for userspace
to mmap() the resulting dma-buf even when this is supported by the
DRM driver.

It is trivial to relax the restriction and permit read/write access.
This is safe because the flags are seldom touched by drm; mostly they
are passed verbatim to dma_buf calls.

v3 (Tiago): removed unused flags variable from drm_prime_handle_to_fd_ioctl.

Reviewed-by: Chris Wilson 
Signed-off-by: Daniel Thompson 
Signed-off-by: Tiago Vignatti 
---
 drivers/gpu/drm/drm_prime.c | 10 +++---
 include/uapi/drm/drm.h  |  1 +
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 27aa718..df6cdc7 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -329,7 +329,7 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops =  
{
  * drm_gem_prime_export - helper library implementation of the export callback
  * @dev: drm_device to export from
  * @obj: GEM object to export
- * @flags: flags like DRM_CLOEXEC
+ * @flags: flags like DRM_CLOEXEC and DRM_RDWR
  *
  * This is the implementation of the gem_prime_export functions for GEM drivers
  * using the PRIME helpers.
@@ -628,7 +628,6 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
 struct drm_file *file_priv)
 {
struct drm_prime_handle *args = data;
-   uint32_t flags;

if (!drm_core_check_feature(dev, DRIVER_PRIME))
return -EINVAL;
@@ -637,14 +636,11 @@ int drm_prime_handle_to_fd_ioctl(struct drm_device *dev, 
void *data,
return -ENOSYS;

/* check flags are valid */
-   if (args->flags & ~DRM_CLOEXEC)
+   if (args->flags & ~(DRM_CLOEXEC | DRM_RDWR))
return -EINVAL;

-   /* we only want to pass DRM_CLOEXEC which is == O_CLOEXEC */
-   flags = args->flags & DRM_CLOEXEC;
-
return dev->driver->prime_handle_to_fd(dev, file_priv,
-   args->handle, flags, &args->fd);
+   args->handle, args->flags, &args->fd);
 }

 int drm_prime_fd_to_handle_ioctl(struct drm_device *dev, void *data,
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index b4e92eb..a0ebfe7 100644
--- a/include/uapi/drm/drm.h
+++ b/include/uapi/drm/drm.h
@@ -669,6 +669,7 @@ struct drm_set_client_cap {
__u64 value;
 };

+#define DRM_RDWR O_RDWR
 #define DRM_CLOEXEC O_CLOEXEC
 struct drm_prime_handle {
__u32 handle;
-- 
2.1.4

[PATCH v6 2/5] dma-buf: Remove range-based flush

[Tiago Vignatti]

This patch removes range-based information used for optimizations in
begin_cpu_access and end_cpu_access.

We don't have any user nor implementation using range-based flush. It seems a
consensus that if we ever want something like that again (or even more robust
using 2D, 3D sub-range regions) we can use the upcoming dma-buf sync ioctl for
such.

Cc: Sumit Semwal 
Cc: Daniel Vetter 
Signed-off-by: Tiago Vignatti 
---
 Documentation/dma-buf-sharing.txt | 19 ---
 drivers/dma-buf/dma-buf.c | 13 -
 drivers/gpu/drm/i915/i915_gem_dmabuf.c|  2 +-
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c |  4 ++--
 drivers/gpu/drm/udl/udl_fb.c  |  2 --
 drivers/staging/android/ion/ion.c |  6 ++
 drivers/staging/android/ion/ion_test.c|  4 ++--
 include/linux/dma-buf.h   | 12 +---
 8 files changed, 24 insertions(+), 38 deletions(-)

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 480c8de..4f4a84b 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -257,17 +257,15 @@ Access to a dma_buf from the kernel context involves 
three steps:

Interface:
   int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
-  size_t start, size_t len,
   enum dma_data_direction direction)

This allows the exporter to ensure that the memory is actually available for
cpu access - the exporter might need to allocate or swap-in and pin the
backing storage. The exporter also needs to ensure that cpu access is
-   coherent for the given range and access direction. The range and access
-   direction can be used by the exporter to optimize the cache flushing, i.e.
-   access outside of the range or with a different direction (read instead of
-   write) might return stale or even bogus data (e.g. when the exporter needs 
to
-   copy the data to temporary storage).
+   coherent for the access direction. The direction can be used by the exporter
+   to optimize the cache flushing, i.e. access with a different direction (read
+   instead of write) might return stale or even bogus data (e.g. when the
+   exporter needs to copy the data to temporary storage).

This step might fail, e.g. in oom conditions.

@@ -322,14 +320,13 @@ Access to a dma_buf from the kernel context involves 
three steps:

 3. Finish access

-   When the importer is done accessing the range specified in begin_cpu_access,
-   it needs to announce this to the exporter (to facilitate cache flushing and
-   unpinning of any pinned resources). The result of any dma_buf kmap calls
-   after end_cpu_access is undefined.
+   When the importer is done accessing the CPU, it needs to announce this to
+   the exporter (to facilitate cache flushing and unpinning of any pinned
+   resources). The result of any dma_buf kmap calls after end_cpu_access is
+   undefined.

Interface:
   void dma_buf_end_cpu_access(struct dma_buf *dma_buf,
- size_t start, size_t len,
  enum dma_data_direction dir);


diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 155c146..b2ac13b 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -539,13 +539,11 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
  * preparations. Coherency is only guaranteed in the specified range for the
  * specified access direction.
  * @dmabuf:[in]buffer to prepare cpu access for.
- * @start: [in]start of range for cpu access.
- * @len:   [in]length of range for cpu access.
  * @direction: [in]length of range for cpu access.
  *
  * Can return negative error values, returns 0 on success.
  */
-int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
+int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
 enum dma_data_direction direction)
 {
int ret = 0;
@@ -554,8 +552,7 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, size_t 
start, size_t len,
return -EINVAL;

if (dmabuf->ops->begin_cpu_access)
-   ret = dmabuf->ops->begin_cpu_access(dmabuf, start,
-   len, direction);
+   ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);

return ret;
 }
@@ -567,19 +564,17 @@ EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
  * actions. Coherency is only guaranteed in the specified range for the
  * specified access direction.
  * @dmabuf:[in]buffer to complete cpu access for.
- * @start: [in]start of range for cpu access.
- * @len:   [in]length of range for cpu access.
  * @direction: [in]length of range for cpu access.
  *
  * This call must always succeed.
  */
-void dma_buf_end_cpu_access(struct dma_buf *dmabuf, size_t start, size_t len,
+void dma_buf_end_cpu_a

[PATCH v6 3/5] dma-buf: Add ioctls to allow userspace to flush

[Tiago Vignatti]

From: Daniel Vetter 

The userspace might need some sort of cache coherency management e.g. when CPU
and GPU domains are being accessed through dma-buf at the same time. To
circumvent this problem there are begin/end coherency markers, that forward
directly to existing dma-buf device drivers vfunc hooks. Userspace can make use
of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence would be
used like following:
 - mmap dma-buf fd
 - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
   to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
   want (with the new data being consumed by the GPU or say scanout device)
 - munmap once you don't need the buffer any more

v2 (Tiago): Fix header file type names (u64 -> __u64)
v3 (Tiago): Add documentation. Use enum dma_buf_sync_flags to the begin/end
dma-buf functions. Check for overflows in start/length.
v4 (Tiago): use 2d regions for sync.
v5 (Tiago): forget about 2d regions (v4); use _IOW in DMA_BUF_IOCTL_SYNC and
remove range information from struct dma_buf_sync.
v6 (Tiago): use __u64 structured padded flags instead enum. Adjust
documentation about the recommendation on using sync ioctls.

Cc: Sumit Semwal 
Signed-off-by: Daniel Vetter 
Signed-off-by: Tiago Vignatti 
---
 Documentation/dma-buf-sharing.txt | 22 +++-
 drivers/dma-buf/dma-buf.c | 43 +++
 include/uapi/linux/dma-buf.h  | 38 ++
 3 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 include/uapi/linux/dma-buf.h

diff --git a/Documentation/dma-buf-sharing.txt 
b/Documentation/dma-buf-sharing.txt
index 4f4a84b..2ddd4b2 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -350,7 +350,27 @@ Being able to mmap an export dma-buf buffer object has 2 
main use-cases:
handles, too). So it's beneficial to support this in a similar fashion on
dma-buf to have a good transition path for existing Android userspace.

-   No special interfaces, userspace simply calls mmap on the dma-buf fd.
+   No special interfaces, userspace simply calls mmap on the dma-buf fd. Very
+   important to note though is that, even if it is not mandatory, the userspace
+   is strongly recommended to always use the cache synchronization ioctl
+   (DMA_BUF_IOCTL_SYNC) discussed next.
+
+   Some systems might need some sort of cache coherency management e.g. when
+   CPU and GPU domains are being accessed through dma-buf at the same time. To
+   circumvent this problem there are begin/end coherency markers, that forward
+   directly to existing dma-buf device drivers vfunc hooks. Userspace can make
+   use of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence
+   would be used like following:
+ - mmap dma-buf fd
+ - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write
+   to mmap area 3. SYNC_END ioctl. This can be repeated as often as you
+   want (with the new data being consumed by the GPU or say scanout device)
+ - munmap once you don't need the buffer any more
+
+In principle systems with the memory cache shared by the GPU and CPU may
+not need SYNC_START and SYNC_END but still, userspace is always encouraged
+to use these ioctls before and after, respectively, when accessing the
+mapped address.

 2. Supporting existing mmap interfaces in importers

diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index b2ac13b..9a298bd 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -34,6 +34,8 @@
 #include 
 #include 

+#include 
+
 static inline int is_dma_buf_file(struct file *);

 struct dma_buf_list {
@@ -251,11 +253,52 @@ out:
return events;
 }

+static long dma_buf_ioctl(struct file *file,
+ unsigned int cmd, unsigned long arg)
+{
+   struct dma_buf *dmabuf;
+   struct dma_buf_sync sync;
+   enum dma_data_direction direction;
+
+   dmabuf = file->private_data;
+
+   if (!is_dma_buf_file(file))
+   return -EINVAL;
+
+   switch (cmd) {
+   case DMA_BUF_IOCTL_SYNC:
+   if (copy_from_user(&sync, (void __user *) arg, sizeof(sync)))
+   return -EFAULT;
+
+   if (sync.flags & DMA_BUF_SYNC_RW)
+   direction = DMA_BIDIRECTIONAL;
+   else if (sync.flags & DMA_BUF_SYNC_READ)
+   direction = DMA_FROM_DEVICE;
+   else if (sync.flags & DMA_BUF_SYNC_WRITE)
+   direction = DMA_TO_DEVICE;
+   else
+   return -EINVAL;
+
+   if (sync.flags & ~DMA_BUF_SYNC_VALID_FLAGS_MASK)
+   return -EINVAL;
+
+   if (sync.flags & DMA_BUF_SYNC_END)
+   dma_buf_end_cpu_access(dmabuf, direction);
+   else
+   dma_buf_begin_cpu_a

[PATCH v6 4/5] drm/i915: Implement end_cpu_access

[Tiago Vignatti]

This function is meant to be used with dma-buf mmap, when finishing the CPU
access of the mapped pointer.

The error case should be rare to happen though, requiring the buffer become
active during the sync period and for the end_cpu_access to be interrupted. So
we use a uninterruptible mutex_lock to spit out when it ever happens.

v2: disable interruption to make sure errors are reported.
v3: update to the new end_cpu_access API.

Reviewed-by: Chris Wilson 
Signed-off-by: Tiago Vignatti 
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 65ab2bd..9dba876 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -212,6 +212,27 @@ static int i915_gem_begin_cpu_access(struct dma_buf 
*dma_buf, enum dma_data_dire
return ret;
 }

+static void i915_gem_end_cpu_access(struct dma_buf *dma_buf, enum 
dma_data_direction direction)
+{
+   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
+   struct drm_device *dev = obj->base.dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
+   bool was_interruptible, write = (direction == DMA_BIDIRECTIONAL || 
direction == DMA_TO_DEVICE);
+   int ret;
+
+   mutex_lock(&dev->struct_mutex);
+   was_interruptible = dev_priv->mm.interruptible;
+   dev_priv->mm.interruptible = false;
+
+   ret = i915_gem_object_set_to_gtt_domain(obj, write);
+
+   dev_priv->mm.interruptible = was_interruptible;
+   mutex_unlock(&dev->struct_mutex);
+
+   if (unlikely(ret))
+   DRM_ERROR("unable to flush buffer following CPU access; 
rendering may be corrupt\n");
+}
+
 static const struct dma_buf_ops i915_dmabuf_ops =  {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
@@ -224,6 +245,7 @@ static const struct dma_buf_ops i915_dmabuf_ops =  {
.vmap = i915_gem_dmabuf_vmap,
.vunmap = i915_gem_dmabuf_vunmap,
.begin_cpu_access = i915_gem_begin_cpu_access,
+   .end_cpu_access = i915_gem_end_cpu_access,
 };

 struct dma_buf *i915_gem_prime_export(struct drm_device *dev,
-- 
2.1.4

[PATCH v6 5/5] drm/i915: Use CPU mapping for userspace dma-buf mmap()

[Tiago Vignatti]

Userspace is the one in charge of flush CPU by wrapping mmap with
begin{,end}_cpu_access.

v2: Remove LLC check cause we have dma-buf sync providers now. Also, fix return
before transferring ownership when mmap fails.
v3: Fix return values.
v4: !obj->base.filp is user triggerable, so removed the WARN_ON.

Reviewed-by: Chris Wilson 
Signed-off-by: Tiago Vignatti 
---
 drivers/gpu/drm/i915/i915_gem_dmabuf.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_dmabuf.c 
b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
index 9dba876..b7e7a90 100644
--- a/drivers/gpu/drm/i915/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/i915_gem_dmabuf.c
@@ -193,7 +193,23 @@ static void i915_gem_dmabuf_kunmap(struct dma_buf 
*dma_buf, unsigned long page_n

 static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct 
*vma)
 {
-   return -EINVAL;
+   struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
+   int ret;
+
+   if (obj->base.size < vma->vm_end - vma->vm_start)
+   return -EINVAL;
+
+   if (!obj->base.filp)
+   return -ENODEV;
+
+   ret = obj->base.filp->f_op->mmap(obj->base.filp, vma);
+   if (ret)
+   return ret;
+
+   fput(vma->vm_file);
+   vma->vm_file = get_file(obj->base.filp);
+
+   return 0;
 }

 static int i915_gem_begin_cpu_access(struct dma_buf *dma_buf, enum 
dma_data_direction direction)
-- 
2.1.4

[PATCH igt v6 1/6] lib: Add gem_userptr and __gem_userptr helpers

[Tiago Vignatti]

This patch moves userptr definitions and helpers implementation that were
locally in gem_userptr_benchmark and gem_userptr_blits to the library, so other
tests can make use of them as well. There's no functional changes.

v2: added __ function to differentiate when errors want to be handled back in
the caller; bring gem_userptr_sync back to gem_userptr_blits; added gtkdoc.

Signed-off-by: Tiago Vignatti 
---
 benchmarks/gem_userptr_benchmark.c |  55 +++-
 lib/ioctl_wrappers.c   |  41 +++
 lib/ioctl_wrappers.h   |  13 +
 tests/gem_userptr_blits.c  | 104 ++---
 4 files changed, 86 insertions(+), 127 deletions(-)

diff --git a/benchmarks/gem_userptr_benchmark.c 
b/benchmarks/gem_userptr_benchmark.c
index 1eae7ff..f7716df 100644
--- a/benchmarks/gem_userptr_benchmark.c
+++ b/benchmarks/gem_userptr_benchmark.c
@@ -58,17 +58,6 @@
   #define PAGE_SIZE 4096
 #endif

-#define LOCAL_I915_GEM_USERPTR   0x33
-#define LOCAL_IOCTL_I915_GEM_USERPTR DRM_IOWR (DRM_COMMAND_BASE + 
LOCAL_I915_GEM_USERPTR, struct local_i915_gem_userptr)
-struct local_i915_gem_userptr {
-   uint64_t user_ptr;
-   uint64_t user_size;
-   uint32_t flags;
-#define LOCAL_I915_USERPTR_READ_ONLY (1<<0)
-#define LOCAL_I915_USERPTR_UNSYNCHRONIZED (1<<31)
-   uint32_t handle;
-};
-
 static uint32_t userptr_flags = LOCAL_I915_USERPTR_UNSYNCHRONIZED;

 #define BO_SIZE (65536)
@@ -83,30 +72,6 @@ static void gem_userptr_test_synchronized(void)
userptr_flags = 0;
 }

-static int gem_userptr(int fd, void *ptr, int size, int read_only, uint32_t 
*handle)
-{
-   struct local_i915_gem_userptr userptr;
-   int ret;
-
-   userptr.user_ptr = (uintptr_t)ptr;
-   userptr.user_size = size;
-   userptr.flags = userptr_flags;
-   if (read_only)
-   userptr.flags |= LOCAL_I915_USERPTR_READ_ONLY;
-
-   ret = drmIoctl(fd, LOCAL_IOCTL_I915_GEM_USERPTR, &userptr);
-   if (ret)
-   ret = errno;
-   igt_skip_on_f(ret == ENODEV &&
- (userptr_flags & LOCAL_I915_USERPTR_UNSYNCHRONIZED) == 0 
&&
- !read_only,
- "Skipping, synchronized mappings with no kernel 
CONFIG_MMU_NOTIFIER?");
-   if (ret == 0)
-   *handle = userptr.handle;
-
-   return ret;
-}
-
 static void **handle_ptr_map;
 static unsigned int num_handle_ptr_map;

@@ -144,8 +109,7 @@ static uint32_t create_userptr_bo(int fd, int size)
ret = posix_memalign(&ptr, PAGE_SIZE, size);
igt_assert(ret == 0);

-   ret = gem_userptr(fd, (uint32_t *)ptr, size, 0, &handle);
-   igt_assert(ret == 0);
+   gem_userptr(fd, (uint32_t *)ptr, size, 0, userptr_flags, &handle);
add_handle_ptr(handle, ptr);

return handle;
@@ -167,7 +131,7 @@ static int has_userptr(int fd)
assert(posix_memalign(&ptr, PAGE_SIZE, PAGE_SIZE) == 0);
oldflags = userptr_flags;
gem_userptr_test_unsynchronized();
-   ret = gem_userptr(fd, ptr, PAGE_SIZE, 0, &handle);
+   ret = __gem_userptr(fd, ptr, PAGE_SIZE, 0, userptr_flags, &handle);
userptr_flags = oldflags;
if (ret != 0) {
free(ptr);
@@ -379,9 +343,7 @@ static void test_impact_overlap(int fd, const char *prefix)

for (i = 0, p = block; i < nr_bos[subtest];
 i++, p += PAGE_SIZE)
-   ret = gem_userptr(fd, (uint32_t *)p, BO_SIZE, 0,
- &handles[i]);
-   igt_assert(ret == 0);
+   gem_userptr(fd, (uint32_t *)p, BO_SIZE, 0, 
userptr_flags, &handles[i]);
}

if (nr_bos[subtest] > 0)
@@ -427,7 +389,6 @@ static void test_single(int fd)
char *ptr, *bo_ptr;
uint32_t handle = 0;
unsigned long iter = 0;
-   int ret;
unsigned long map_size = BO_SIZE + PAGE_SIZE - 1;

ptr = mmap(NULL, map_size, PROT_READ | PROT_WRITE,
@@ -439,8 +400,7 @@ static void test_single(int fd)
start_test(test_duration_sec);

while (run_test) {
-   ret = gem_userptr(fd, bo_ptr, BO_SIZE, 0, &handle);
-   assert(ret == 0);
+   gem_userptr(fd, bo_ptr, BO_SIZE, 0, userptr_flags, &handle);
gem_close(fd, handle);
iter++;
}
@@ -456,7 +416,6 @@ static void test_multiple(int fd, unsigned int batch, int 
random)
uint32_t handles[1];
int map[1];
unsigned long iter = 0;
-   int ret;
int i;
unsigned long map_size = batch * BO_SIZE + PAGE_SIZE - 1;

@@ -478,10 +437,8 @@ static void test_multiple(int fd, unsigned int batch, int 
random)
if (random)
igt_permute_array(map, batch, igt_exchange_int);
for (i = 0; i < batch; i++) {
-   r

[PATCH igt v6 2/6] prime_mmap: Add new test for calling mmap() on dma-buf fds

[Tiago Vignatti]

From: Rob Bradford 

This test has the following subtests:
 - test_correct for correctness of the data
 - test_map_unmap checks for mapping idempotency
 - test_reprime checks for dma-buf creation idempotency
 - test_forked checks for multiprocess access
 - test_refcounting checks for buffer reference counting
 - test_dup checks that dup()ing the fd works
 - test_userptr make sure it fails when mmaping due the lack of obj->base.filp
   in a userptr.
 - test_errors checks the error return values for failures
 - test_aperture_limit tests multiple buffer creation at the gtt aperture
   limit

v2 (Tiago): Removed pattern_check(), which was walking through a useless
iterator. Removed superfluous PROT_WRITE from gem_mmap, in test_correct().
Added binary file to .gitignore
v3 (Tiago): squash patch "prime_mmap: Test for userptr mmap" into this one.
v4 (Tiago): use synchronized userptr for testing. Add test for buffer
overlapping.

Signed-off-by: Rob Bradford 
Signed-off-by: Tiago Vignatti 
---
 tests/Makefile.sources |   1 +
 tests/prime_mmap.c | 417 +
 2 files changed, 418 insertions(+)
 create mode 100644 tests/prime_mmap.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index d594038..75f3cb0 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -96,6 +96,7 @@ TESTS_progs_M = \
pm_rps \
pm_rc6_residency \
pm_sseu \
+   prime_mmap \
prime_self_import \
template \
$(NULL)
diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
new file mode 100644
index 000..95304a9
--- /dev/null
+++ b/tests/prime_mmap.c
@@ -0,0 +1,417 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Rob Bradford 
+ *
+ */
+
+/*
+ * Testcase: Check whether mmap()ing dma-buf works
+ */
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drm.h"
+#include "i915_drm.h"
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "ioctl_wrappers.h"
+
+#define BO_SIZE (16*1024)
+
+static int fd;
+
+char pattern[] = {0xff, 0x00, 0x00, 0x00,
+   0x00, 0xff, 0x00, 0x00,
+   0x00, 0x00, 0xff, 0x00,
+   0x00, 0x00, 0x00, 0xff};
+
+static void
+fill_bo(uint32_t handle, size_t size)
+{
+   off_t i;
+   for (i = 0; i < size; i+=sizeof(pattern))
+   {
+   gem_write(fd, handle, i, pattern, sizeof(pattern));
+   }
+}
+
+static void
+test_correct(void)
+{
+   int dma_buf_fd;
+   char *ptr1, *ptr2;
+   uint32_t handle;
+
+   handle = gem_create(fd, BO_SIZE);
+   fill_bo(handle, BO_SIZE);
+
+   dma_buf_fd = prime_handle_to_fd(fd, handle);
+   igt_assert(errno == 0);
+
+   /* Check correctness vs GEM_MMAP_GTT */
+   ptr1 = gem_mmap__gtt(fd, handle, BO_SIZE, PROT_READ);
+   ptr2 = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+   igt_assert(ptr1 != MAP_FAILED);
+   igt_assert(ptr2 != MAP_FAILED);
+   igt_assert(memcmp(ptr1, ptr2, BO_SIZE) == 0);
+
+   /* Check pattern correctness */
+   igt_assert(memcmp(ptr2, pattern, sizeof(pattern)) == 0);
+
+   munmap(ptr1, BO_SIZE);
+   munmap(ptr2, BO_SIZE);
+   close(dma_buf_fd);
+   gem_close(fd, handle);
+}
+
+static void
+test_map_unmap(void)
+{
+   int dma_buf_fd;
+   char *ptr;
+   uint32_t handle;
+
+   handle = gem_create(fd, BO_SIZE);
+   fill_bo(handle, BO_SIZE);
+
+   dma_buf_fd = prime_handle_to_fd(fd, handle);
+   igt_assert(errno == 0);
+
+   ptr = mmap(NULL, BO_SIZE, PROT_READ, MAP_SHARED, dma_buf_fd, 0);
+   igt_assert(ptr != MAP_FAILED);
+   igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+
+   /* Unmap and remap */
+   munmap(ptr, BO_SIZE);
+   ptr = mmap(NULL, BO_SIZE, PROT_READ,

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

[Tiago Vignatti]

This patch adds test_correct_cpu_write, which maps the texture buffer through a
prime fd and then writes directly to it using the CPU. It stresses the driver
to guarantee cache synchronization among the different domains.

This test also adds test_forked_cpu_write, which creates the GEM bo in one
process and pass the prime handle of the it to another process, which in turn
uses the handle only to map and write. Roughly speaking this test simulates
Chrome OS  architecture, where the Web content ("unpriviledged process") maps
and CPU-draws a buffer, which was previously allocated in the GPU process
("priviledged process").

This requires kernel modifications (Daniel Thompson's "drm: prime: Honour
O_RDWR during prime-handle-to-fd") and therefore prime_handle_to_fd_for_mmap is
added to fail in case these lack. Also, upcoming tests (e.g. next patch) are
going to use it as well, so make it public and available in the lib.

v2: adds prime_handle_to_fd_with_mmap for skipping test in older kernels and
test for invalid flags.

Signed-off-by: Tiago Vignatti 
---
 lib/ioctl_wrappers.c | 25 +++
 lib/ioctl_wrappers.h |  4 +++
 tests/prime_mmap.c   | 89 
 3 files changed, 112 insertions(+), 6 deletions(-)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 6cad8a2..86a61ba 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1329,6 +1329,31 @@ int prime_handle_to_fd(int fd, uint32_t handle)
 }

 /**
+ * prime_handle_to_fd_for_mmap:
+ * @fd: open i915 drm file descriptor
+ * @handle: file-private gem buffer object handle
+ *
+ * Same as prime_handle_to_fd above but with DRM_RDWR capabilities, which can
+ * be useful for writing into the mmap'ed dma-buf file-descriptor.
+ *
+ * Returns: The created dma-buf fd handle or -1 if the ioctl fails.
+ */
+int prime_handle_to_fd_for_mmap(int fd, uint32_t handle)
+{
+   struct drm_prime_handle args;
+
+   memset(&args, 0, sizeof(args));
+   args.handle = handle;
+   args.flags = DRM_CLOEXEC | DRM_RDWR;
+   args.fd = -1;
+
+   if (drmIoctl(fd, DRM_IOCTL_PRIME_HANDLE_TO_FD, &args) != 0)
+   return -1;
+
+   return args.fd;
+}
+
+/**
  * prime_fd_to_handle:
  * @fd: open i915 drm file descriptor
  * @dma_buf_fd: dma-buf fd handle
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index bb8a858..d3ffba2 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -149,6 +149,10 @@ void gem_require_ring(int fd, int ring_id);

 /* prime */
 int prime_handle_to_fd(int fd, uint32_t handle);
+#ifndef DRM_RDWR
+#define DRM_RDWR O_RDWR
+#endif
+int prime_handle_to_fd_for_mmap(int fd, uint32_t handle);
 uint32_t prime_fd_to_handle(int fd, int dma_buf_fd);
 off_t prime_get_size(int dma_buf_fd);

diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
index 95304a9..269ada6 100644
--- a/tests/prime_mmap.c
+++ b/tests/prime_mmap.c
@@ -22,6 +22,7 @@
  *
  * Authors:
  *Rob Bradford 
+ *Tiago Vignatti 
  *
  */

@@ -66,6 +67,12 @@ fill_bo(uint32_t handle, size_t size)
 }

 static void
+fill_bo_cpu(char *ptr)
+{
+   memcpy(ptr, pattern, sizeof(pattern));
+}
+
+static void
 test_correct(void)
 {
int dma_buf_fd;
@@ -180,6 +187,65 @@ test_forked(void)
gem_close(fd, handle);
 }

+/* test simple CPU write */
+static void
+test_correct_cpu_write(void)
+{
+   int dma_buf_fd;
+   char *ptr;
+   uint32_t handle;
+
+   handle = gem_create(fd, BO_SIZE);
+
+   dma_buf_fd = prime_handle_to_fd_for_mmap(fd, handle);
+
+   /* Skip if DRM_RDWR is not supported */
+   igt_skip_on(errno == EINVAL);
+
+   /* Check correctness of map using write protection (PROT_WRITE) */
+   ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, 
dma_buf_fd, 0);
+   igt_assert(ptr != MAP_FAILED);
+
+   /* Fill bo using CPU */
+   fill_bo_cpu(ptr);
+
+   /* Check pattern correctness */
+   igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+
+   munmap(ptr, BO_SIZE);
+   close(dma_buf_fd);
+   gem_close(fd, handle);
+}
+
+/* map from another process and then write using CPU */
+static void
+test_forked_cpu_write(void)
+{
+   int dma_buf_fd;
+   char *ptr;
+   uint32_t handle;
+
+   handle = gem_create(fd, BO_SIZE);
+
+   dma_buf_fd = prime_handle_to_fd_for_mmap(fd, handle);
+
+   /* Skip if DRM_RDWR is not supported */
+   igt_skip_on(errno == EINVAL);
+
+   igt_fork(childno, 1) {
+   ptr = mmap(NULL, BO_SIZE, PROT_READ | PROT_WRITE , MAP_SHARED, 
dma_buf_fd, 0);
+   igt_assert(ptr != MAP_FAILED);
+   fill_bo_cpu(ptr);
+
+   igt_assert(memcmp(ptr, pattern, sizeof(pattern)) == 0);
+   munmap(ptr, BO_SIZE);
+   close(dma_buf_fd);
+   }
+   close(dma_buf_fd);
+   igt_waitchildren();
+   gem_close(fd, handle);
+}
+
 static void
 test_refcounting(void)
 {
@@ -224,15 +290,14 @@ test_dup(v

[PATCH igt v6 4/6] lib: Add prime_sync_start and prime_sync_end helpers

[Tiago Vignatti]

This patch adds dma-buf mmap synchronization ioctls that can be used by tests
for cache coherency management e.g. when CPU and GPU domains are being accessed
through dma-buf at the same time.

Signed-off-by: Tiago Vignatti 
---
 lib/ioctl_wrappers.c | 26 ++
 lib/ioctl_wrappers.h | 15 +++
 2 files changed, 41 insertions(+)

diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 86a61ba..0d84d00 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1400,6 +1400,32 @@ off_t prime_get_size(int dma_buf_fd)
 }

 /**
+ * prime_sync_start
+ * @dma_buf_fd: dma-buf fd handle
+ */
+void prime_sync_start(int dma_buf_fd)
+{
+   struct local_dma_buf_sync sync_start;
+
+   memset(&sync_start, 0, sizeof(sync_start));
+   sync_start.flags = LOCAL_DMA_BUF_SYNC_START | LOCAL_DMA_BUF_SYNC_RW;
+   do_ioctl(dma_buf_fd, LOCAL_DMA_BUF_IOCTL_SYNC, &sync_start);
+}
+
+/**
+ * prime_sync_end
+ * @dma_buf_fd: dma-buf fd handle
+ */
+void prime_sync_end(int dma_buf_fd)
+{
+   struct local_dma_buf_sync sync_end;
+
+   memset(&sync_end, 0, sizeof(sync_end));
+   sync_end.flags = LOCAL_DMA_BUF_SYNC_END | LOCAL_DMA_BUF_SYNC_RW;
+   do_ioctl(dma_buf_fd, LOCAL_DMA_BUF_IOCTL_SYNC, &sync_end);
+}
+
+/**
  * igt_require_fb_modifiers:
  * @fd: Open DRM file descriptor.
  *
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index d3ffba2..cbd7a73 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -148,6 +148,19 @@ void gem_require_caching(int fd);
 void gem_require_ring(int fd, int ring_id);

 /* prime */
+struct local_dma_buf_sync {
+   uint64_t flags;
+};
+
+#define LOCAL_DMA_BUF_SYNC_RW(3 << 0)
+#define LOCAL_DMA_BUF_SYNC_START (0 << 2)
+#define LOCAL_DMA_BUF_SYNC_END   (1 << 2)
+#define DMA_BUF_SYNC_VALID_FLAGS_MASK \
+   (DMA_BUF_SYNC_RW | DMA_BUF_SYNC_END)
+
+#define LOCAL_DMA_BUF_BASE 'b'
+#define LOCAL_DMA_BUF_IOCTL_SYNC _IOW(LOCAL_DMA_BUF_BASE, 0, struct 
local_dma_buf_sync)
+
 int prime_handle_to_fd(int fd, uint32_t handle);
 #ifndef DRM_RDWR
 #define DRM_RDWR O_RDWR
@@ -155,6 +168,8 @@ int prime_handle_to_fd(int fd, uint32_t handle);
 int prime_handle_to_fd_for_mmap(int fd, uint32_t handle);
 uint32_t prime_fd_to_handle(int fd, int dma_buf_fd);
 off_t prime_get_size(int dma_buf_fd);
+void prime_sync_start(int dma_buf_fd);
+void prime_sync_end(int dma_buf_fd);

 /* addfb2 fb modifiers */
 struct local_drm_mode_fb_cmd2 {
-- 
2.1.4

[PATCH igt v6 5/6] tests: Add kms_mmap_write_crc for cache coherency tests

[Tiago Vignatti]

This program can be used to detect when CPU writes in the dma-buf mapped object
don't land in scanout due cache incoherency.

Although this seems a problem inherently of non-LCC machines ("Atom"), this
particular test catches a cache dirt on scanout on LLC machines as well. It's
inspired in Ville's kms_pwrite_crc.c and can be used also to test the
correctness of the driver's begin_cpu_access and end_cpu_access (which requires
i915 implementation.

To see the need for flush, one has to run this same binary a few times cause
it's not 100% reproducible -- what I usually do is the following, using '-n'
option to not call the sync ioctls:

$ while ((1)) ; do ./kms_mmap_write_crc -n; done  # in terminal A
$ find /  # in terminal B

That will most likely trashes the memory while the test will catch the
coherency issue. If you now suppress '-n', then things should just work like
expected.

I tested this with !llc and llc platforms, BTY and IVY respectively.

v2: use prime_handle_to_fd_for_mmap instead.
v3: merge end_cpu_access() patch with this and provide options to disable sync.
v4: use library's prime_sync_{start,end} instead.

Signed-off-by: Tiago Vignatti 
---
 tests/Makefile.sources |   1 +
 tests/kms_mmap_write_crc.c | 281 +
 2 files changed, 282 insertions(+)
 create mode 100644 tests/kms_mmap_write_crc.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 75f3cb0..ad2dd6a 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -168,6 +168,7 @@ TESTS_progs = \
kms_3d \
kms_fence_pin_leak \
kms_force_connector_basic \
+   kms_mmap_write_crc \
kms_pwrite_crc \
kms_sink_crc_basic \
prime_udl \
diff --git a/tests/kms_mmap_write_crc.c b/tests/kms_mmap_write_crc.c
new file mode 100644
index 000..6a12539
--- /dev/null
+++ b/tests/kms_mmap_write_crc.c
@@ -0,0 +1,281 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Tiago Vignatti 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "drmtest.h"
+#include "igt_debugfs.h"
+#include "igt_kms.h"
+#include "intel_chipset.h"
+#include "ioctl_wrappers.h"
+#include "igt_aux.h"
+
+IGT_TEST_DESCRIPTION(
+   "Use the display CRC support to validate mmap write to an already uncached 
future scanout buffer.");
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   struct igt_fb fb[2];
+   igt_output_t *output;
+   igt_plane_t *primary;
+   enum pipe pipe;
+   igt_crc_t ref_crc;
+   igt_pipe_crc_t *pipe_crc;
+   uint32_t devid;
+} data_t;
+
+static int ioctl_sync = true;
+int dma_buf_fd;
+
+static char *dmabuf_mmap_framebuffer(int drm_fd, struct igt_fb *fb)
+{
+   char *ptr = NULL;
+
+   dma_buf_fd = prime_handle_to_fd_for_mmap(drm_fd, fb->gem_handle);
+   igt_skip_on(dma_buf_fd == -1 && errno == EINVAL);
+
+   ptr = mmap(NULL, fb->size, PROT_READ | PROT_WRITE, MAP_SHARED, 
dma_buf_fd, 0);
+   igt_assert(ptr != MAP_FAILED);
+
+   return ptr;
+}
+
+static void test(data_t *data)
+{
+   igt_display_t *display = &data->display;
+   igt_output_t *output = data->output;
+   struct igt_fb *fb = &data->fb[1];
+   drmModeModeInfo *mode;
+   cairo_t *cr;
+   char *ptr;
+   uint32_t caching;
+   void *buf;
+   igt_crc_t crc;
+
+   mode = igt_output_get_mode(output);
+
+   /* create a non-white fb where we can write later */
+   igt_create_fb(data->drm_fd, mode->hdisplay, mode->vdisplay,
+ DRM_FORMAT_XRGB, LOCAL_DRM_FORMAT_MOD_NONE, fb);
+
+   ptr = dmabuf_mmap_framebuffer(data->drm_fd, fb);
+
+   cr = igt_get_cairo_ctx(data->drm_fd, fb);
+   igt_paint_test_pattern(cr, fb->width, fb->height);
+   cairo_dest

[PATCH igt v6 6/6] tests: Add prime_mmap_coherency for cache coherency tests

[Tiago Vignatti]

Different than kms_mmap_write_crc that captures the coherency issues within the
scanout mapped buffer, this one is meant for test dma-buf mmap on !llc
platforms mostly and provoke coherency bugs so we know where we need the sync
ioctls.

I tested this with !llc and llc platforms, BTY and IVY respectively.

Signed-off-by: Tiago Vignatti 
---
 tests/Makefile.sources   |   1 +
 tests/prime_mmap_coherency.c | 246 +++
 2 files changed, 247 insertions(+)
 create mode 100644 tests/prime_mmap_coherency.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index ad2dd6a..78605c6 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -97,6 +97,7 @@ TESTS_progs_M = \
pm_rc6_residency \
pm_sseu \
prime_mmap \
+   prime_mmap_coherency \
prime_self_import \
template \
$(NULL)
diff --git a/tests/prime_mmap_coherency.c b/tests/prime_mmap_coherency.c
new file mode 100644
index 000..a9a2664
--- /dev/null
+++ b/tests/prime_mmap_coherency.c
@@ -0,0 +1,246 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *Tiago Vignatti
+ */
+
+/** @file prime_mmap_coherency.c
+ *
+ * TODO: need to show the need for prime_sync_end().
+ */
+
+#include "igt.h"
+
+IGT_TEST_DESCRIPTION("Test dma-buf mmap on !llc platforms mostly and provoke"
+   " coherency bugs so we know for sure where we need the sync 
ioctls.");
+
+#define ROUNDS 20
+
+int fd;
+int stale = 0;
+static drm_intel_bufmgr *bufmgr;
+struct intel_batchbuffer *batch;
+static int width = 1024, height = 1024;
+
+/*
+ * Exercises the need for read flush:
+ *   1. create a BO and write '0's, in GTT domain.
+ *   2. read BO using the dma-buf CPU mmap.
+ *   3. write '1's, in GTT domain.
+ *   4. read again through the mapped dma-buf.
+ */
+static void test_read_flush(bool expect_stale_cache)
+{
+   drm_intel_bo *bo_1;
+   drm_intel_bo *bo_2;
+   uint32_t *ptr_cpu;
+   uint32_t *ptr_gtt;
+   int dma_buf_fd, i;
+
+   if (expect_stale_cache)
+   igt_require(!gem_has_llc(fd));
+
+   bo_1 = drm_intel_bo_alloc(bufmgr, "BO 1", width * height * 4, 4096);
+
+   /* STEP #1: put the BO 1 in GTT domain. We use the blitter to copy and 
fill
+* zeros to BO 1, so commands will be submitted and likely to place BO 
1 in
+* the GTT domain. */
+   bo_2 = drm_intel_bo_alloc(bufmgr, "BO 2", width * height * 4, 4096);
+   intel_copy_bo(batch, bo_1, bo_2, width * height);
+   gem_sync(fd, bo_1->handle);
+   drm_intel_bo_unreference(bo_2);
+
+   /* STEP #2: read BO 1 using the dma-buf CPU mmap. This dirties the CPU 
caches. */
+   dma_buf_fd = prime_handle_to_fd_for_mmap(fd, bo_1->handle);
+   igt_skip_on(errno == EINVAL);
+
+   ptr_cpu = mmap(NULL, width * height, PROT_READ | PROT_WRITE,
+  MAP_SHARED, dma_buf_fd, 0);
+   igt_assert(ptr_cpu != MAP_FAILED);
+
+   for (i = 0; i < (width * height) / 4; i++)
+   igt_assert_eq(ptr_cpu[i], 0);
+
+   /* STEP #3: write 0x11 into BO 1. */
+   bo_2 = drm_intel_bo_alloc(bufmgr, "BO 2", width * height * 4, 4096);
+   ptr_gtt = gem_mmap__gtt(fd, bo_2->handle, width * height, PROT_READ | 
PROT_WRITE);
+   memset(ptr_gtt, 0x11, width * height);
+   munmap(ptr_gtt, width * height);
+
+   intel_copy_bo(batch, bo_1, bo_2, width * height);
+   gem_sync(fd, bo_1->handle);
+   drm_intel_bo_unreference(bo_2);
+
+   /* STEP #4: read again using the CPU mmap. Doing #1 before #3 makes 
sure we
+* don't do a full CPU cache flush in step #3 again. That makes sure 
all the
+* stale cachelines from step #2 survive (mostly, a few will be evicted)
+* until we try to read them again in step #4. This behavior could be 
fixed
+* by flush C

[GIT PULL] drm/panel: Changes for v4.5-rc1

[Rob Herring]

On Wed, Dec 16, 2015 at 11:19 AM, Thierry Reding
 wrote:
> Hi Dave,
>
> The following changes since commit 8005c49d9aea74d382f474ce11afbbc7d7130bec:
>
>   Linux 4.4-rc1 (2015-11-15 17:00:27 -0800)
>
> are available in the git repository at:
>
>   git://anongit.freedesktop.org/tegra/linux tags/drm/panel/for-4.5-rc1
>
> for you to fetch changes up to d2a6f0f5597696ebf5bb34089be3b88ba2455b7a:
>
>   drm/panel: simple: Add QiaoDian qd43003c0-40 (2015-12-16 18:15:26 +0100)

[...]

> Josh Wu (1):
>   drm/panel: simple: Add QiaoDian qd43003c0-40

[...]

> Werner Johansson (5):
>   dt-bindings: Add Panasonic VVX10F034N00 panel binding
>   drm/panel: Add Panasonic VVX10F034N00 MIPI DSI panel
>   drm/dsi: Add Turn On/Shutdown Peripheral command helpers
>   dt-bindings: Add Sharp LS043T1LE01 panel binding
>   drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

>  .../bindings/panel/panasonic,vvx10f034n00.txt  |  20 ++
>  .../bindings/panel/qiaodian,qd43003c0-40.txt   |   7 +

Alexandre already pointed out one of these, but these 2 should be
moved to bindings/display/panel/.

Rob

[PATCH 08/15] drm: omapdrm: gem: Mask out private flags passed from userspace

[Rob Clark]

On Wed, Dec 16, 2015 at 12:33 PM, Emil Velikov  
wrote:
> Hi Laurent,
>
> On 14 December 2015 at 20:33, Laurent Pinchart
>  wrote:
>> Hi Emil,
>>
>> On Monday 07 December 2015 14:13:43 Emil Velikov wrote:
>>> On 4 December 2015 at 22:27, Laurent Pinchart wrote:
>>> > The 8 high order bits of the buffer flags are reserved for internal use.
>>> > Mask them out from the flags passed by userspace.
>>>
>>> Ouch... I know that the Intel guys are pretty rigorous about input
>>> validation, although I wonder how many drivers are (partially or not)
>>> missing these.
>>>
>>> > Signed-off-by: Laurent Pinchart 
>>> > ---
>>> >
>>> >  drivers/gpu/drm/omapdrm/omap_drv.c | 9 ++---
>>> >  include/uapi/drm/omap_drm.h| 1 +
>>> >  2 files changed, 7 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
>>> > b/drivers/gpu/drm/omapdrm/omap_drv.c index 83d63d71062c..e405ab23d7a6
>>> > 100644
>>> > --- a/drivers/gpu/drm/omapdrm/omap_drv.c
>>> > +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
>>> > @@ -551,10 +551,13 @@ static int ioctl_gem_new(struct drm_device *dev,
>>> > void *data,
>>> > struct drm_file *file_priv)
>>> >  {
>>> > struct drm_omap_gem_new *args = data;
>>> > +   u32 flags = args->flags & OMAP_BO_USER_MASK;
>>> > +
>>> > VERB("%p:%p: size=0x%08x, flags=%08x", dev, file_priv,
>>> > -   args->size.bytes, args->flags);
>>> > -   return omap_gem_new_handle(dev, file_priv, args->size,
>>> > -   args->flags, &args->handle);
>>> > +args->size.bytes, flags);
>>> > +
>>> > +   return omap_gem_new_handle(dev, file_priv, args->size, flags,
>>> > +  &args->handle);
>>> >  }
>>> >
>>> >  static int ioctl_gem_cpu_prep(struct drm_device *dev, void *data,
>>> > diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
>>> > index 1d0b1172664e..6852c26e8f78 100644
>>> > --- a/include/uapi/drm/omap_drm.h
>>> > +++ b/include/uapi/drm/omap_drm.h
>>> > @@ -36,6 +36,7 @@ struct drm_omap_param {
>>> >
>>> >  #define OMAP_BO_SCANOUT0x0001  /* scanout capable (phys
>>> >  contiguous) */
>>> >  #define OMAP_BO_CACHE_MASK 0x0006  /* cache type mask, see
>>> >  cache modes */
>>> >  #define OMAP_BO_TILED_MASK 0x0f00  /* tiled mapping mask, see
>>> >  tiled modes */
>>> > +#define OMAP_BO_USER_MASK  0x00ff  /* flags settable by
>>> > userspace */
>>>
>>> Fwiw I'm not too sure that adding the mask here  (UAPI) is a good
>>> idea.
>>
>> Good point, I'll make it private.
>>
> Thanks for the update (hiding the extra define from UAPI). Shame we
> cannot do that for OMAP_BO_TILED_MASK :'-(
>
>>> If you like to keep it, I'd suggest that it encapsulates only what's
>>> currently available. Might even want to move the individual masks in the
>>> respective sections/hunks. Speaking of which - OMAP_BO_TILED_MASK should be
>>> 0x0300, shouldn't it ?
>>
>> I suppose 0x0f00 was chosen to reserve a couple of bits for additional
>> tiled modes.
>>
> Perhaps a silly question - what is the reason to have larger mask than
> the actual supported flags ? Looking from other drm modules (and vague
> memories of other subsystems), drivers do not try to be forward
> compatible and reject (should reject that is) unsupported flags.

yeah, it was chosen to reserve some extra bits if needed in the future..

but yeah, current kernel should probably reject unknown tile modes..
which I think should be easy since iirc there are only 3 (which is a
nice maskable number)

BR,
-R

> Am I missing something ?
>
> Thanks
> Emil
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

linux-next: Tree for Dec 16 (gpu/drm/vc4)

[Eric Anholt]

Randy Dunlap  writes:

> On 12/15/15 21:43, Stephen Rothwell wrote:
>> Hi all,
>> 
>> Changes since 20151215:
>> 
>
> on i386, when CONFIG_PM_SLEEP is not enabled:
>
> ../drivers/gpu/drm/vc4/vc4_v3d.c: In function 'vc4_v3d_set_power':
> ../drivers/gpu/drm/vc4/vc4_v3d.c:157:29: error: called object is not a 
> function or function pointer
>return pm_generic_poweroff(&vc4->v3d->pdev->dev);
>  ^
> ../drivers/gpu/drm/vc4/vc4_v3d.c:159:27: error: called object is not a 
> function or function pointer
>return pm_generic_resume(&vc4->v3d->pdev->dev);

A patch got sent to the PM maintainers producing static inlines in the
config-disabled case.  We'll see if they like it, or if I just add a
dependency on the config option instead.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151216/73148cb6/attachment.sig>

linux-next: Tree for Dec 16 (gpu/drm/vc4)

[Randy Dunlap]

On 12/15/15 21:43, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20151215:
> 

on i386, when CONFIG_PM_SLEEP is not enabled:

../drivers/gpu/drm/vc4/vc4_v3d.c: In function 'vc4_v3d_set_power':
../drivers/gpu/drm/vc4/vc4_v3d.c:157:29: error: called object is not a function 
or function pointer
   return pm_generic_poweroff(&vc4->v3d->pdev->dev);
 ^
../drivers/gpu/drm/vc4/vc4_v3d.c:159:27: error: called object is not a function 
or function pointer
   return pm_generic_resume(&vc4->v3d->pdev->dev);
   ^



-- 
~Randy

[PATCH v4 2/2] drm: panel: simple: add QiaoDian qd43003c0-40

[Alexandre Belloni]

Hi,

On 16/12/2015 at 18:14:06 +0100, Thierry Reding wrote :
> Also, please use "drm/panel: " as the prefix (instead of "drm: panel: ")
> to make it easier for me to pick up things. I was about to send out a
> pull request for drm/panel when I noticed that there was this patch. The
> v4 wasn't Cc: dri-devel, so I ended up applying v3 from patchwork. From
> the changelog it seems like that's okay, though.
> 

I think v3 didn't have the documentation at the correct place, this
should be:
Documentation/devicetree/bindings/display/panel/qiaodian,qd43003c0-40.txt



-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com