[GIT PULL v2] exynos-drm-next

[Inki Dae]

Hi Dave,

   This pull request includes MIPI-DSI driver, two panel drivers,
   and relevant dt bindings.

   And I has excepted one patch series, super device support from
   exynos-drm-next because the patch series hadn't been reviewed by
   right maintainers and mailing list. The patch series is reasonable
   to me but we should have followed open source rule. Sorry for this.

Summaries:
- Add MIPI-DSI Driver, and dt bindigs
- Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings
- Add LD9040 parallel panel driver
 . this driver is placed in drivers/gpu/drm/panel, and it seems
   to be used for exynos drm as of now,
- Some fixups

Changelog v2:
- Remove super device support, and relevant dt bindings for more reviews.
- Fix module build errors you pointed out.
- Re-based it to drm-next again.

If there is any problem, please kindly let me know.

Thanks,
Inki Dae


The following changes since commit 66e514c14a1cb9c2540c685c40d94dc6ef6b6bb5:

  Merge tag 'drm-intel-next-2014-03-21' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2014-04-03 07:51:54 
+1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to 96e112c44477edea1c01fbb976205e751f4229b9:

  drm/bridge: export ptn3460_init function (2014-04-04 21:24:50 +0900)


Andrzej Hajda (15):
  drm/mipi_dsi: add flags to DSI messages
  drm/mipi_dsi: create dsi devices only for nodes with reg property
  drm/exynos: disallow fbdev initialization if no device is connected
  exynos/dsim: add DT bindings
  drm/exynos: add DSIM driver
  panel/s6e8aa0: add DT bindings
  panel/ld9040: add DT bindings
  drm/panel: add ld9040 driver
  ARM: dts: exynos4210-universal_c210: add proper panel node
  drm/panel: add S6E8AA0 driver
  ARM: dts: exynos4: add MIPI DSI Master node
  ARM: dts: exynos4210-trats: add panel node
  ARM: dts: exynos4412-trats2: add panel node
  ARM: dts: exynos4210-trats: enable exynos/fimd node
  ARM: dts: exynos4412-trats2: enable exynos/fimd node

Inki Dae (2):
  drm/exynos: remove MODULE_DEVICE_TABLE definitions
  drm/bridge: export ptn3460_init function

 .../devicetree/bindings/panel/samsung,ld9040.txt   |   66 +
 .../devicetree/bindings/panel/samsung,s6e8aa0.txt  |   56 +
 .../devicetree/bindings/video/exynos_dsim.txt  |   80 +
 arch/arm/boot/dts/exynos4.dtsi |   14 +
 arch/arm/boot/dts/exynos4210-trats.dts |   61 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts|   71 +-
 arch/arm/boot/dts/exynos4412-trats2.dts|   70 +
 drivers/gpu/drm/bridge/ptn3460.c   |1 +
 drivers/gpu/drm/drm_mipi_dsi.c |6 +-
 drivers/gpu/drm/exynos/Kconfig |9 +
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|1 -
 drivers/gpu/drm/exynos/exynos_drm_drv.c|   15 +
 drivers/gpu/drm/exynos/exynos_drm_drv.h|1 +
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1524 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   21 +
 drivers/gpu/drm/panel/Kconfig  |   14 +
 drivers/gpu/drm/panel/Makefile |2 +
 drivers/gpu/drm/panel/panel-ld9040.c   |  376 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1069 ++
 include/drm/drm_mipi_dsi.h |6 +
 21 files changed, 3445 insertions(+), 19 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,ld9040.txt
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
 create mode 100644 drivers/gpu/drm/panel/panel-ld9040.c
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

[PATCH 3/4] drm/dp/i2c: Update comments about common i2c over dp assumptions

[Ville Syrjälä]

On Fri, Apr 04, 2014 at 01:52:05PM -0400, Alex Deucher wrote:
> If you are using the common dp over i2c functionality, it is
> asumed that the aux transfer function does not modify the any
> of the msg structure other than the reply field.  Doing so
> breaks the logic in the common code.
> 
> Signed-off-by: Alex Deucher 
> Cc: Ville Syrj?l? 
> Cc: Jani Nikula 
> Cc: Thierry Reding 

Reviewed-by: Ville Syrj?l? 

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 125f84d..7a8c091 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -577,7 +577,9 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
> *adapter)
>  
>  /*
>   * Transfer a single I2C-over-AUX message and handle various error 
> conditions,
> - * retrying the transaction as appropriate.
> + * retrying the transaction as appropriate.  It is assumed that the
> + * aux->transfer function does not modify anything in the msg other than the
> + * reply field.
>   */
>  static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
> *msg)
>  {
> -- 
> 1.8.3.1

-- 
Ville Syrj?l?
Intel OTC

[PATCH 2/4] drm/dp/i2c: send bare addresses to properly reset i2c connections (v2)

[Ville Syrjälä]

On Fri, Apr 04, 2014 at 01:52:04PM -0400, Alex Deucher wrote:
> We need bare address packets at the start and end of
> each i2c over aux transaction to properly reset the connection
> between transactions.  This mirrors what the existing dp i2c
> over aux algo currently does.
> 
> This fixes EDID fetches on certain monitors especially with
> dp bridges.
> 
> v2: update as per Ville's comments
> - Set buffer to NULL for zero sized packets
> - abort the entre transaction if one of the messages fails
> 
> Signed-off-by: Alex Deucher 
> Cc: Ville Syrj?l? 
> Cc: Jani Nikula 
> Cc: Thierry Reding 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 54 
> +++--
>  1 file changed, 31 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 74724aa..125f84d 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -664,12 +664,25 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>  int num)
>  {
>   struct drm_dp_aux *aux = adapter->algo_data;
> - unsigned int i, j;
> + unsigned int m, b;
> + struct drm_dp_aux_msg msg;
> + int err = 0;
>  
> - for (i = 0; i < num; i++) {
> - struct drm_dp_aux_msg msg;
> - int err;
> + memset(, 0, sizeof(msg));
>  
> + for (m = 0; m < num; m++) {
> + msg.address = msgs[m].addr;
> + msg.request = (msgs[m].flags & I2C_M_RD) ?
> + DP_AUX_I2C_READ :
> + DP_AUX_I2C_WRITE;
> + msg.request |= DP_AUX_I2C_MOT;
> + msg.buffer = NULL;
> + msg.size = 0;
> + err = drm_dp_i2c_do_msg(aux, );
> + if (err < 0) {
> + printk("error %d in bare address write\n", err);

I guess this printk was some leftover debug thing? Either should be
dropped or converted to some more appropriate DRM_ thing I suppose.

But otherwise the patch looks good:
Reviewed-by: Ville Syrj?l? 

> + break;
> + }
>   /*
>* Many hardware implementations support FIFOs larger than a
>* single byte, but it has been empirically determined that
> @@ -677,31 +690,26 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>* decreased performance. Therefore each message is simply
>* transferred byte-by-byte.
>*/
> - for (j = 0; j < msgs[i].len; j++) {
> - memset(, 0, sizeof(msg));
> - msg.address = msgs[i].addr;
> -
> - msg.request = (msgs[i].flags & I2C_M_RD) ?
> - DP_AUX_I2C_READ :
> - DP_AUX_I2C_WRITE;
> -
> - /*
> -  * All messages except the last one are middle-of-
> -  * transfer messages.
> -  */
> - if ((i < num - 1) || (j < msgs[i].len - 1))
> - msg.request |= DP_AUX_I2C_MOT;
> -
> - msg.buffer = msgs[i].buf + j;
> + for (b = 0; b < msgs[m].len; b++) {
> + msg.buffer = msgs[m].buf + b;
>   msg.size = 1;
>  
>   err = drm_dp_i2c_do_msg(aux, );
>   if (err < 0)
> - return err;
> + break;
>   }
> + if (err < 0)
> + break;
>   }
> -
> - return num;
> + if (err >= 0)
> + err = num;
> + /* send a bare address packet to close out the connection */
> + msg.request &= ~DP_AUX_I2C_MOT;
> + msg.buffer = NULL;
> + msg.size = 0;
> + (void)drm_dp_i2c_do_msg(aux, );
> +
> + return err;
>  }
>  
>  static const struct i2c_algorithm drm_dp_i2c_algo = {
> -- 
> 1.8.3.1

-- 
Ville Syrj?l?
Intel OTC

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

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

--- Comment #13 from benjamin.menant+debian at gmail.com ---
Unfortunately, deactivating ColorTiling and/or ColorTiling2D has no effect. I
also tried to set "SwapbuffersWait" to "False". 

Actually, as far as I remember, I tried to test most of the options available
(http://manpages.debian.org/cgi-bin/man.cgi?sektion=4=radeon) two years
ago, when I installed the board. Then, I switched to fglrx-driver.

I think it?s not related, but? often, X failed to restart from the virtual
console (weird pixelized screen or black screen, or nothing at all).
I had to reboot the computer to double check the result (and then, I did not
see any error in the Xorg log). 

Thanks again,
Benjamin.

-- 
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/20140404/8c10a2d5/attachment.html>

[Bug 77069] New: Use semantic naming for microcode files

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

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

  Priority: medium
Bug ID: 77069
  Assignee: dri-devel at lists.freedesktop.org
   Summary: Use semantic naming for microcode files
  Severity: minor
Classification: Unclassified
OS: Linux (All)
  Reporter: nmschulte at gmail.com
  Hardware: Other
Status: NEW
   Version: unspecified
 Component: DRM/Radeon
   Product: DRI

This is a rather trivial request, but it would help the uninitiated and long
term maintenance.

It would be nice if the microcode was more semantically named, rather than how
it exists now.

For example, I currently have an issue with UVD on a Radeon HD 8970M, which is
"Neptune XT" based (which is "Pitcairn" based), and I receive the following
logging:

[   15.942210] [drm] Loading PITCAIRN Microcode
[   15.966837] radeon :01:00.0: firmware: direct-loading firmware
radeon/PITCAIRN_pfp.bin
[   15.976695] radeon :01:00.0: firmware: direct-loading firmware
radeon/PITCAIRN_me.bin
[   15.996448] radeon :01:00.0: firmware: direct-loading firmware
radeon/PITCAIRN_ce.bin
[   16.015403] radeon :01:00.0: firmware: direct-loading firmware
radeon/PITCAIRN_rlc.bin
[   16.016529] radeon :01:00.0: firmware: direct-loading firmware
radeon/PITCAIRN_mc.bin
[   16.026910] radeon :01:00.0: firmware: direct-loading firmware
radeon/PITCAIRN_smc.bin
[   16.045744] radeon :01:00.0: firmware: direct-loading firmware
radeon/TAHITI_uvd.bin



[   65.525470] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   66.537637] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   67.549797] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   68.561967] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   69.574142] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   70.586334] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   71.598533] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   72.610705] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   73.622877] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   74.635068] [drm:uvd_v1_0_start] *ERROR* UVD not responding, trying to reset
the VCPU!!!
[   74.654938] [drm:uvd_v1_0_start] *ERROR* UVD not responding, giving up!!!
[   74.654955] [drm:si_startup] *ERROR* radeon: failed initializing UVD (-1).

At first glance, I'm thinking: well clearly TAHITI_uvd.bin is incorrect for
PITCAIRN Microcode, but that's not quite how things work.  It would be nice to
name the UVD microcode after the actual version of the platform the code is
targeting.  Perhaps this is simply a naming collision issue and the UVD
microcode naming is semantic within the context (that is: my Radeon HD 8970M
card really does run the TAHITI version of UVD), but that's doubtful and I
would suggest the names change to be more meaningful, :).

Another proposition is to skip the "fully semantic naming" idea above and just
use symlinks to bridge the two namespaces.

-- 
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/20140404/288407dd/attachment.html>

[PATCH] drm/dp_helper: don't return EPROTO for defers (v2)

[Dave Airlie]

From: Dave Airlie 

If we get a msg.reply of REPLY_DEFER, we also get an err of 0
so we fail reads with 0 < size and return -EPROTO instead of trying
again.

v2: same fix in i2c code.

Found writing MST support.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_helper.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f4babed..2767148 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -386,11 +386,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
return err;
}

-   if (err < size)
-   return -EPROTO;

switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
case DP_AUX_NATIVE_REPLY_ACK:
+   if (err < size)
+   return -EPROTO;
return err;

case DP_AUX_NATIVE_REPLY_NACK:
@@ -599,8 +599,6 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
return err;
}

-   if (err < msg->size)
-   return -EPROTO;

switch (msg->reply & DP_AUX_NATIVE_REPLY_MASK) {
case DP_AUX_NATIVE_REPLY_ACK:
@@ -639,6 +637,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
 * Both native ACK and I2C ACK replies received. We
 * can assume the transfer was successful.
 */
+   if (err < msg->size)
+   return -EPROTO;
return 0;

case DP_AUX_I2C_REPLY_NACK:
-- 
1.8.5.3

[Bug 76840] HybridGraphics: Kernel driver in use: radeon but adapter not listed

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

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

--- Comment #8 from Michael Eagle  ---
Hello,

I upgraded my kernel with latest ubuntu mainline
Linux mike-g337 3.14.0-999-generic #201404040227 SMP Fri Apr 4 06:28:24 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux

and also webstack from oibaf-ppa:

Upgrade: libg3dvl-mesa:amd64 (10.2~git1404021931.0f641b~gd~s,
10.2~git1404040730.4fa58a~gd~s), xserver-xorg-video-intel:amd64
(2.99.911+git1404021930.baef22~gd~s, 2.99.911+git1404031930.f05658~gd~s),
xserver-xorg-video-ati:amd64 (7.3.99+git1404021930.ed0cfb~gd~s,
7.3.99+git1404022026.ed0cfb~gd~s), xserver-xorg-video-radeon:amd64
(7.3.99+git1404021930.ed0cfb~gd~s, 7.3.99+git1404022026.ed0cfb~gd~s),
mesa-common-dev:amd64 (10.2~git1404021931.0f641b~gd~s,
10.2~git1404040730.4fa58a~gd~s)

and now, xrandr --listproviders shows the desired output:

Providers: number : 3
Provider 0: id: 0x68 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs:
4 outputs: 5 associated providers: 2 name:Intel
Provider 1: id: 0x3f cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon
Provider 2: id: 0x3f cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 0 outputs: 0 associated providers: 2 name:radeon

DRI_PRIME, also works

mike-g337 mike # DRI_PRIME=0 glxinfo  | grep 'OpenGL'
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile 
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 10.2.0-devel
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
mike-g337 mike # DRI_PRIME=1 glxinfo  | grep 'OpenGL'
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD HAINAN
OpenGL core profile version string: 3.1 (Core Profile) Mesa 10.2.0-devel
OpenGL core profile shading language version string: 1.40
OpenGL core profile context flags: (none)
OpenGL core profile extensions:
OpenGL version  string: 3.0 Mesa 10.2.0-devel
OpenGL shading languagew, version string: 1.30
OpenGL context flags: (none)
OpenGL extensions

Now because radeon is active, I can not remove the module from within X
anymore: 
rmmod radeon
Error: Module radeon is in use

DRI_PRIME=1 glxgears also works, I don't have any game to test now, But,
everything is fine in your opinion ?


And also, perhaps I shouldn't do this, but if I run:
 DRI_PRIME=2 glxinfo  | grep 'OpenGL'
X server crashes with the following backtrace (it wasn't crashing before): 

[   913.503] (EE) 
[   913.503] (EE) Backtrace:
[   913.503] (EE) 0: /usr/bin/X (xorg_backtrace+0x3d) [0x7fae2101cfdd]
[   913.503] (EE) 1: /usr/bin/X (0x7fae20e7a000+0x1a6d49) [0x7fae21020d49]
[   913.503] (EE) 2: /lib/x86_64-linux-gnu/libpthread.so.0
(0x7fae1ff7a000+0xfbb0) [0x7fae1ff89bb0]
[   913.503] (EE) 3: /usr/bin/X (DRI2Connect+0x5f) [0x7fae20ff0a7f]
[   913.503] (EE) 4: /usr/bin/X (0x7fae20e7a000+0x1776dc) [0x7fae20ff16dc]
[   913.503] (EE) 5: /usr/bin/X (0x7fae20e7a000+0x5525e) [0x7fae20ecf25e]
[   913.503] (EE) 6: /usr/bin/X (0x7fae20e7a000+0x447ba) [0x7fae20ebe7ba]
[   913.503] (EE) 7: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xf5)
[0x7fae1ebb5de5]
[   913.503] (EE) 8: /usr/bin/X (0x7fae20e7a000+0x44aff) [0x7fae20ebeaff]
[   913.503] (EE) 
[   913.503] (EE) Segmentation fault at address 0x0
[   913.503] (EE) 
Fatal server error:
[   913.503] (EE) Caught signal 11 (Segmentation fault). Server aborting
[   913.503] (EE) 
[   913.503] (EE) 
Please consult the The X.Org Foundation support 
 at http://wiki.x.org
 for help. 
[   913.503] (EE) Please also check the log file at "/var/log/Xorg.0.log" for
additional information.
[   913.503] (EE) 
[   913.503] (II) AIGLX: Suspending AIGLX clients for VT switch
[   913.521] (EE) Server terminated with error (1). Closing log file.

Thank you,
Cheers Mike.

-- 
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/20140404/6aeb52c8/attachment.html>

[PATCH] radeon: sync with radeon_drm.h from kernel headers

[Marek Olšák]

From: Marek Ol??k 

Signed-off-by: Marek Ol??k 
---

I will make a new release and clean up Mesa definitions after this is committed.

 include/drm/radeon_drm.h | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/include/drm/radeon_drm.h b/include/drm/radeon_drm.h
index 55e85bf..cd31794 100644
--- a/include/drm/radeon_drm.h
+++ b/include/drm/radeon_drm.h
@@ -510,6 +510,7 @@ typedef struct {
 #define DRM_RADEON_GEM_GET_TILING  0x29
 #define DRM_RADEON_GEM_BUSY0x2a
 #define DRM_RADEON_GEM_VA  0x2b
+#define DRM_RADEON_GEM_OP  0x2c

 #define DRM_IOCTL_RADEON_CP_INITDRM_IOW( DRM_COMMAND_BASE + 
DRM_RADEON_CP_INIT, drm_radeon_init_t)
 #define DRM_IOCTL_RADEON_CP_START   DRM_IO(  DRM_COMMAND_BASE + 
DRM_RADEON_CP_START)
@@ -548,10 +549,11 @@ typedef struct {
 #define DRM_IOCTL_RADEON_GEM_WAIT_IDLE DRM_IOW(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_WAIT_IDLE, struct drm_radeon_gem_wait_idle)
 #define DRM_IOCTL_RADEON_CSDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_CS, struct drm_radeon_cs)
 #define DRM_IOCTL_RADEON_INFO  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_INFO, struct drm_radeon_info)
-#define DRM_IOCTL_RADEON_SET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_SET_TILING, struct drm_radeon_gem_set_tiling)
-#define DRM_IOCTL_RADEON_GET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_GET_TILING, struct drm_radeon_gem_get_tiling)
+#define DRM_IOCTL_RADEON_GEM_SET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_SET_TILING, struct drm_radeon_gem_set_tiling)
+#define DRM_IOCTL_RADEON_GEM_GET_TILINGDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_GET_TILING, struct drm_radeon_gem_get_tiling)
 #define DRM_IOCTL_RADEON_GEM_BUSY  DRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_BUSY, struct drm_radeon_gem_busy)
 #define DRM_IOCTL_RADEON_GEM_VADRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_VA, struct drm_radeon_gem_va)
+#define DRM_IOCTL_RADEON_GEM_OPDRM_IOWR(DRM_COMMAND_BASE + 
DRM_RADEON_GEM_OP, struct drm_radeon_gem_op)

 typedef struct drm_radeon_init {
enum {
@@ -643,7 +645,7 @@ typedef struct drm_radeon_vertex2 {
 } drm_radeon_vertex2_t;

 /* v1.3 - obsoletes drm_radeon_vertex2
- *  - allows arbitarily large cliprect list
+ *  - allows arbitrarily large cliprect list
  *  - allows updating of tcl packet, vector and scalar state
  *  - allows memory-efficient description of state updates
  *  - allows state to be emitted without a primitive
@@ -885,6 +887,16 @@ struct drm_radeon_gem_pwrite {
uint64_t data_ptr;
 };

+/* Sets or returns a value associated with a buffer. */
+struct drm_radeon_gem_op {
+   uint32_thandle; /* buffer */
+   uint32_top; /* RADEON_GEM_OP_* */
+   uint64_tvalue;  /* input or return value */
+};
+
+#define RADEON_GEM_OP_GET_INITIAL_DOMAIN   0
+#define RADEON_GEM_OP_SET_INITIAL_DOMAIN   1
+
 #define RADEON_VA_MAP  1
 #define RADEON_VA_UNMAP2

@@ -920,6 +932,7 @@ struct drm_radeon_gem_va {
 #define RADEON_CS_RING_COMPUTE  1
 #define RADEON_CS_RING_DMA  2
 #define RADEON_CS_RING_UVD  3
+#define RADEON_CS_RING_VCE  4
 /* The third dword of RADEON_CHUNK_ID_FLAGS is a sint32 that sets the priority 
*/
 /* 0 = normal, + = higher priority, - = lower priority */

@@ -984,6 +997,18 @@ struct drm_radeon_cs {
 #define RADEON_INFO_SI_CP_DMA_COMPUTE  0x17
 /* CIK macrotile mode array */
 #define RADEON_INFO_CIK_MACROTILE_MODE_ARRAY   0x18
+/* query the number of render backends */
+#define RADEON_INFO_SI_BACKEND_ENABLED_MASK0x19
+/* max engine clock - needed for OpenCL */
+#define RADEON_INFO_MAX_SCLK   0x1a
+/* version of VCE firmware */
+#define RADEON_INFO_VCE_FW_VERSION 0x1b
+/* version of VCE feedback */
+#define RADEON_INFO_VCE_FB_VERSION 0x1c
+#define RADEON_INFO_NUM_BYTES_MOVED0x1d
+#define RADEON_INFO_VRAM_USAGE 0x1e
+#define RADEON_INFO_GTT_USAGE  0x1f
+

 struct drm_radeon_info {
uint32_trequest;
-- 
1.8.3.2

[PATCH 2/3] drm/dp/i2c: send bare addresses to properly reset i2c connections

[Ville Syrjälä]

On Fri, Apr 04, 2014 at 10:40:57AM -0400, Alex Deucher wrote:
> We need bare address packets at the start and end of
> each i2c over aux transaction to properly reset the connection
> between transactions.  This mirrors what the existing dp i2c
> over aux algo currently does.
> 
> This fixes EDID fetches on certain monitors especially with
> dp bridges.
> 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 53 
> +++--
>  1 file changed, 30 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f4babed..f0c2850 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -664,12 +664,26 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>  int num)
>  {
>   struct drm_dp_aux *aux = adapter->algo_data;
> - unsigned int i, j;
> + unsigned int m, b;
> + struct drm_dp_aux_msg msg;
> + int err = 0;
> + u8 buf = 0;
>  
> - for (i = 0; i < num; i++) {
> - struct drm_dp_aux_msg msg;
> - int err;
> + memset(, 0, sizeof(msg));
>  
> + for (m = 0; m < num; m++) {
> + msg.address = msgs[m].addr;
> + msg.request = (msgs[m].flags & I2C_M_RD) ?
> + DP_AUX_I2C_READ :
> + DP_AUX_I2C_WRITE;
> + msg.request |= DP_AUX_I2C_MOT;
> + msg.buffer = 

Maybe just pass NULL and let buggy implementations explode?

> + msg.size = 0;
> + err = drm_dp_i2c_do_msg(aux, );
> + if (err < 0) {
> + printk("error %d in bare address write\n", err);
> + break;
> + }
>   /*
>* Many hardware implementations support FIFOs larger than a
>* single byte, but it has been empirically determined that
> @@ -677,31 +691,24 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>* decreased performance. Therefore each message is simply
>* transferred byte-by-byte.
>*/
> - for (j = 0; j < msgs[i].len; j++) {
> - memset(, 0, sizeof(msg));
> - msg.address = msgs[i].addr;
> -
> - msg.request = (msgs[i].flags & I2C_M_RD) ?
> - DP_AUX_I2C_READ :
> - DP_AUX_I2C_WRITE;
> -
> - /*
> -  * All messages except the last one are middle-of-
> -  * transfer messages.
> -  */
> - if ((i < num - 1) || (j < msgs[i].len - 1))
> - msg.request |= DP_AUX_I2C_MOT;
> -
> - msg.buffer = msgs[i].buf + j;
> + for (b = 0; b < msgs[m].len; b++) {
> + msg.buffer = msgs[m].buf + b;
>   msg.size = 1;
>  
>   err = drm_dp_i2c_do_msg(aux, );
>   if (err < 0)
> - return err;
> + break;

This will abort the current message, but it'll keep going and try to
tranfer the next message. We need to abort the entire thing and proceed
to generate the i2c STOP.

Also you're now reusing the msg and expecting .transfer() to not clobber
any of the fields (apart from msg.reply). Hmm, actually the retry loop
in drm_dp_i2c_do_msg() already requires such a contract between the
caller and the callee. As we can't make the msg const due to msg.reply,
it would be nice if the documentation mentioned this somewhat important
detail.

>   }
>   }
> -
> - return num;
> + if (err >= 0)
> + err = num;
> + /* send a bare address packet to close out the connection */
> + msg.request &= ~DP_AUX_I2C_MOT;
> + msg.buffer = 

Another chance to make buggy drivers explode ;)

> + msg.size = 0;
> + (void)drm_dp_i2c_do_msg(aux, );
> +
> + return err;
>  }
>  
>  static const struct i2c_algorithm drm_dp_i2c_algo = {
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrj?l?
Intel OTC

[Bug 76190] [r600g-evergreen] GPU lockup in Stunt Rally (bisected)

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

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

--- Comment #1 from Benjamin Bellec  ---
These gfx settings are just to easily catch the crash. I originaly detected
this crash with the preset settings:

High preset with soft particules = no crash
Higher preset without soft particules = no crash
Higher preset with soft particules = CRASH
Ultra preset without soft particules = CRASH

-- 
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/20140404/af824317/attachment.html>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #9 from Christian K?nig  ---
(In reply to comment #7)
> Created attachment 96914 [details]
> dmesg after switching to 25hz and back to 24hz

Those logs doesn't contain a mode switch, are you sure you actually grabed the
right log?

Please also try changing the mode directly from the command line with xrandr.

-- 
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/20140404/d7706cb9/attachment.html>

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #62 from Rackow, Detlev  ---
Thanks for your fast reply, it's done.

Regards,

Detlev

-- 
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/20140404/3ec039cc/attachment-0001.html>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #8 from Rackow, Detlev  ---
Created attachment 96915
  --> https://bugs.freedesktop.org/attachment.cgi?id=96915=edit
Xorg.0.log after switching to 25hz and back to 24hz

-- 
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/20140404/d42ea384/attachment.html>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #7 from Rackow, Detlev  ---
Created attachment 96914
  --> https://bugs.freedesktop.org/attachment.cgi?id=96914=edit
dmesg after switching to 25hz and back to 24hz

-- 
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/20140404/ae8df866/attachment.html>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #6 from Rackow, Detlev  ---
Hi, I also have issues with OE 3.95.x and Radeon 6320 (AMD E-450). On my
device, issues happened with all fractional frequencies (23.9x, 29.9x, 59.9x
hz)

The test-version which Peter Fruehberger posted and which contains your
preliminary patch changed the behaviour.

With that new patch fractionalmodes (23.976, ... , ... ) are now working
fine, but with 25hz I have a problem. (Peter supposes that it's actually 50i
and I believe this too, but I'm just a user and I can only report the frequency
that I select in the XBMC-settings)

When I set the rate to 25Hz, the picture begins to shiver up and down a few
millimeters. When I don't acknowledge the new rate, XBMC switches back to the
old rate, and the picture is immediately stable as ever. 

This effect used to happen with all fractional rates in OE 3.95.x, while 25Hz
worked fine. With the mentioned test-version it is gone on the fractional
rates, but now it happens on 25Hz (or 50i, as Peter says).

As instructed, I booted OE with the kernel-parameter drm.debug=0xe and took
dmesg and Xorg.0.log immediately after switching to 25hz and falling back.

This is my first post on this site, I hope I don't mess it ;)

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

[PATCH 2/3] drm/dp/i2c: send bare addresses to properly reset i2c connections

[Daniel Vetter]

On Fri, Apr 04, 2014 at 10:40:57AM -0400, Alex Deucher wrote:
> We need bare address packets at the start and end of
> each i2c over aux transaction to properly reset the connection
> between transactions.  This mirrors what the existing dp i2c
> over aux algo currently does.
> 
> This fixes EDID fetches on certain monitors especially with
> dp bridges.
> 
> Signed-off-by: Alex Deucher 

Reviewed-by: Daniel Vetter 

The i915 dp aux code will work the same way still, but curiously the hw
spec doesn't mention anything for this really. I didn't check tegra.
-Daniel

> ---
>  drivers/gpu/drm/drm_dp_helper.c | 53 
> +++--
>  1 file changed, 30 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f4babed..f0c2850 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -664,12 +664,26 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>  int num)
>  {
>   struct drm_dp_aux *aux = adapter->algo_data;
> - unsigned int i, j;
> + unsigned int m, b;
> + struct drm_dp_aux_msg msg;
> + int err = 0;
> + u8 buf = 0;
>  
> - for (i = 0; i < num; i++) {
> - struct drm_dp_aux_msg msg;
> - int err;
> + memset(, 0, sizeof(msg));
>  
> + for (m = 0; m < num; m++) {
> + msg.address = msgs[m].addr;
> + msg.request = (msgs[m].flags & I2C_M_RD) ?
> + DP_AUX_I2C_READ :
> + DP_AUX_I2C_WRITE;
> + msg.request |= DP_AUX_I2C_MOT;
> + msg.buffer = 
> + msg.size = 0;
> + err = drm_dp_i2c_do_msg(aux, );
> + if (err < 0) {
> + printk("error %d in bare address write\n", err);
> + break;
> + }
>   /*
>* Many hardware implementations support FIFOs larger than a
>* single byte, but it has been empirically determined that
> @@ -677,31 +691,24 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
> struct i2c_msg *msgs,
>* decreased performance. Therefore each message is simply
>* transferred byte-by-byte.
>*/
> - for (j = 0; j < msgs[i].len; j++) {
> - memset(, 0, sizeof(msg));
> - msg.address = msgs[i].addr;
> -
> - msg.request = (msgs[i].flags & I2C_M_RD) ?
> - DP_AUX_I2C_READ :
> - DP_AUX_I2C_WRITE;
> -
> - /*
> -  * All messages except the last one are middle-of-
> -  * transfer messages.
> -  */
> - if ((i < num - 1) || (j < msgs[i].len - 1))
> - msg.request |= DP_AUX_I2C_MOT;
> -
> - msg.buffer = msgs[i].buf + j;
> + for (b = 0; b < msgs[m].len; b++) {
> + msg.buffer = msgs[m].buf + b;
>   msg.size = 1;
>  
>   err = drm_dp_i2c_do_msg(aux, );
>   if (err < 0)
> - return err;
> + break;
>   }
>   }
> -
> - return num;
> + if (err >= 0)
> + err = num;
> + /* send a bare address packet to close out the connection */
> + msg.request &= ~DP_AUX_I2C_MOT;
> + msg.buffer = 
> + msg.size = 0;
> + (void)drm_dp_i2c_do_msg(aux, );
> +
> + return err;
>  }
>  
>  static const struct i2c_algorithm drm_dp_i2c_algo = {
> -- 
> 1.8.3.1
> 
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[GIT PULL] exynos-drm-next

[Inki Dae]

2014-04-04 17:05 GMT+09:00, Tomasz Figa :
> On 04.04.2014 09:48, Inki Dae wrote:
>>
>>
>>> -Original Message-
>>> From: Tomasz Figa [mailto:t.figa at samsung.com]
>>> Sent: Friday, April 04, 2014 4:29 PM
>>> To: Inki Dae; 'Tomasz Figa'; airlied at linux.ie; dri-
>>> devel at lists.freedesktop.org; 'Marek Szyprowski';
>>> devicetree at vger.kernel.org; Grant Likely; Rob Herring
>>> Subject: Re: [GIT PULL] exynos-drm-next
>>>
>>> On 04.04.2014 07:34, Inki Dae wrote:
 Hi Tomasz,

> -Original Message-
> From: Tomasz Figa [mailto:tomasz.figa at gmail.com]
> Sent: Friday, April 04, 2014 2:00 PM
> To: inki.dae at samsung.com; airlied at linux.ie; dri-
> devel at lists.freedesktop.org
> Subject: Re: [GIT PULL] exynos-drm-next
>
> Hi Inki,
>
> On 03.04.2014 19:34, inki.dae at samsung.com wrote:
>> Hi Dave,
>>   Sorry for late.
>>   This pull request includes MIPI-DSI driver, two panel drivers,
>>   super device support, and relevant dt bindings.
>>
>> Summaries:
>> - Add MIPI-DSI Driver, and dt bindigs
>> - Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings
>> - Add LD9040 parallel panel driver
>>  . this driver is placed in drivers/gpu/drm/panel, and it seems
>>to be used for exynos drm as of now,
>> - Add super device support, and dt bindings
>>  . this patch resolves the probe order issue to sub drivers
>>without specific lists
>
> I don't think the DT bindings have been Acked by DT maintainers,
> which is necessary to merge them.
>
> Also I believe more discussion is needed on this, but I didn't have
> time to comment on this series yet. Please hold off with merging the
> supernode series yet.

 I sent a email about review request to you but I didn't get any answer
 from you.
>>>
>>> It's been just three days ago and I just didn't find time yet to review
>>
>> No, the email was just ping. My original RFC patch series had been posted
>> March 3, about 1 month ago, And for my official patch series, eight days
>> ago.
>> So the email I sent three days ago was just a ping that I requested for
>> you
>> to review the patch series.
>
> As I said, it was not even posted to samsung-soc, the central ML for
> Samsung SoC related patches, as mandated by MAINTAINERS file. I learned
> about its presence just after your ping.
>
>>> them. I would like to be able to review all the patches straight after
>>> them being posted, but unfortunately that's not the only thing I have to
>>> do.
>>>
>>
>> So I think there was no any comments from you for a long time.
>>
>>> Anyway, a common practice in open source world is to let the patches
>>> wait
>>> on the mailing lists for two weeks for people to find some time to
>>> review
>>> them and only then apply. There might be people that don't work full
>>> time
>>> on this area, but still would be interested to do a review in some free
>>> time.
>>>
>>> Also, neither version of this series have been posted to
>>> linux-samsung-soc
>>> mailing list, which is also a key to have a broader review. Note that
>>> this
>>> ML is listed in MAINTAINERS file for all kernel files with "exynos" in
>>> name.
>>>
>>> ARM/S5P EXYNOS ARM ARCHITECTURES
>>> M:  Kukjin Kim 
>>> L:  linux-arm-kernel at lists.infradead.org (moderated for
>> non-subscribers)
>>> L:  linux-samsung-soc at vger.kernel.org (moderated for
>>> non-subscribers)
>>> S:  Maintained
>>> F:  arch/arm/mach-s5p*/
>>> F:  arch/arm/mach-exynos*/
>>> N:  exynos
>>>
>>>
 And I think super node concept was already accepted, and relevant
 codes, component framework, has already been merged to mainline. And
 Linux staging next has already such dt bindings. Please see imx dts
>>> files.
>>>
>>> Yes, they are, but for other platforms not this particular instance.
>>>
>>> Any new DT bindings introduced are needed to have an ACK from one of DT
>>> maintainers to be merged, unless you can't get any reply from any of
>>> them
>>> for a longer time, usually 3 weeks from posting the series to be
>>> applied.
>>
>> So should I wait for more times?
>>
>
> Since this series is not a dependency for any other patches queued for
> this release and it doesn't add any new functionality, I don't think
> there is any need to hurry with it.
>

That was times enough to me, one month! And that is for easy to
maintain this patch sets.

>>>
>>> Of course standard pinging rules apply, so you should ping DT
>>> maintainers
>>> first before applying such series.
>>
>>
>> The email I sent to you three days ago was that.
>
> Unfortunately I'm not a DT maintainer, so I don't qualify here. You can
> see list of DT maintainers in MAINTAINERS file:
>
> OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> M:  Rob Herring 
> M:  Pawel Moll 
> M:  Mark Rutland 
> M:  Ian Campbell 

[PATCH 2/2] drm/exynos/fbdev: don't set mode_config.fb_base

[Daniel Kurtz]

AFAICT, the fb_base of a drm_device's mode_config is never used.  It isn't
accessed by core drm, it isn't used by fbmem, and it isn't exposed to user
space.

Furthermore, it is probably supposed to be a physical address, not the
dma address mapped to the display controller, so this is just wrong.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 2dcc589..3270a36 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -121,7 +121,6 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,
offset = fbi->var.xoffset * (fb->bits_per_pixel >> 3);
offset += fbi->var.yoffset * fb->pitches[0];

-   dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
fbi->screen_base = buffer->kvaddr + offset;
fbi->screen_size = size;

-- 
1.9.1.423.g4596e3a

[PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}

[Daniel Kurtz]

Kernel access to the eyxnos fbdev framebuffer is via its gem object's
kernel mapping (kvaddr, stored in info->screen_base).

User space access is provided by mmap(), read() and write() of /dev/fb/fb0.
These functions also only use screen_base/screen_size().

Therefore, it is not necessary to set fix->smem_{start,len} or
fix->mmio_{start,len} fields.

This avoids leaking kernel, physical and dma mapped addresses to user
space via the ioctls FBIOGET_VSCREENINFO and FBIOGET_FSCREENINFO.

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c 
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index 5fa342e..2dcc589 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -123,14 +123,7 @@ static int exynos_drm_fbdev_update(struct drm_fb_helper 
*helper,

dev->mode_config.fb_base = (resource_size_t)buffer->dma_addr;
fbi->screen_base = buffer->kvaddr + offset;
-   if (is_drm_iommu_supported(dev))
-   fbi->fix.smem_start = (unsigned long)
-   (page_to_phys(sg_page(buffer->sgt->sgl)) + offset);
-   else
-   fbi->fix.smem_start = (unsigned long)buffer->dma_addr;
-
fbi->screen_size = size;
-   fbi->fix.smem_len = size;

return 0;
 }
-- 
1.9.1.423.g4596e3a

[PULL] drm-intel-fixes

[Daniel Vetter]

Hi Dave,

Merge window -fixes pull request as usual. Well, I did sneak in Jani's
drm_i915_private_t typedef removal, need to have fun with a big sed job
too ;-)

Otherwise:
- hdmi interlaced fixes (Jesse)
- pipe error/underrun/crc tracking fixes, regression in late 3.14-rc (but
  not cc: stable since only really relevant for igt runs)
- large cursor wm fixes (Chris)
- fix gpu turbo boost/throttle again, was getting stuck due to vlv rps
  patches (Chris+Imre)
- fix runtime pm fallout (Paulo)
- bios framebuffer inherit fix (Chris)
- a few smaller things

Also a bunch with cc: stable in here.

Note that I have a 3.14 release backmerge in here because of some vt-d
stuff (which I then actually postponed for 3.16 ...). No conflicts really
with current drm-next nor in the merge commit itself. I've frobbed the
shortlog though to exclude anything already merged into Linus' tree.

Jani and I decided that he'll take care of -fixes for 3.15 again and will
take over after this pull request.

For outstanding issues there's a bit of lifetime fun in the reset stats
code still on older platforms. Chris is working on that and I didn't
really want to delay this pull request.

Cheers, Daniel


The following changes since commit 698b3135acb94e838a33a69f1a7a684fe0d90734:

  drm/i915: Include a note about the dangers of I915_READ64/I915_WRITE64 
(2014-03-21 16:13:14 +0100)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2014-04-04

for you to fetch changes up to 10b6ee4a87811a110cb01eaca01eb04da6801baf:

  Skip intel_crt_init for Dell XPS 8700 (2014-04-04 09:30:53 +0200)


Akash Goel (1):
  drm/i915: Remove the enabling of VS_TIMER_DISPATCH bit in MI MODE reg

Chris Wilson (8):
  drm/i915: Compute WM for current cursor size
  drm/i915: Recompute WM when the cursor size changes
  drm/i915: Broadwell expands ACTHD to 64bit
  drm/i915: Split 64bit hexadecimal addresses to make them easier to read
  Revert "drm/i915: Disable/Enable PM Intrrupts based on the current freq."
  drm/i915: Refactor gen6_set_rps
  drm/i915: Mask PM/RPS interrupt generation based on activity
  drm/i915: Fix the computation of required fb size for pipe

Damien Lespiau (1):
  drm/i915/bdw: Implement Wa4x4STCOptimizationDisable:bdw

Daniel Vetter (6):
  drm/i915: add locking to fixed panel edid probing
  drm/i915: fix up semaphore_waits_for
  drm/i915: Fix initial pipe underrun state tracking
  drm/i915: Undo gtt scratch pte unmapping again
  Merge tag 'v3.14' into drm-intel-next-queued
  drm/i915: restrict vt-d stolen memory workaround to pre-gen8

Deepak S (2):
  drm/i915: Track the enabled PM interrupts in dev_priv.
  Revert "drm/i915/vlv: fixup DDR freq detection per Punit spec"

Giacomo Comes (1):
  Skip intel_crt_init for Dell XPS 8700

Imre Deak (3):
  drm/i915: vlv: reserve the GT power context only once during driver init
  drm/i915: move power domain init earlier during system resume
  drm/i915: vlv: fix RPS interrupt mask setting

Jani Nikula (9):
  drm/i915/tv: fix gen4 composite s-video tv-out
  drm/i915/debugfs: prefer struct drm_i915_private to drm_i915_private_t
  drm/i915/dma: prefer struct drm_i915_private to drm_i915_private_t
  drm/i915/gem: prefer struct drm_i915_private to drm_i915_private_t
  drm/i915/irq: prefer struct drm_i915_private to drm_i915_private_t
  drm/i915/display: prefer struct drm_i915_private to drm_i915_private_t
  drm/i915/ringbuffer: prefer struct drm_i915_private to drm_i915_private_t
  drm/i915/overlay: prefer struct drm_i915_private to drm_i915_private_t
  drm/i915: prefer struct drm_i915_private to drm_i915_private_t

Jesse Barnes (1):
  drm/i915/vlv: use W_SYNC_SHIFT for interlaced modes on VLV

Paulo Zanoni (7):
  drm/i915: don't schedule force_wake_timer at gen6_read
  drm/i915: get runtime PM at i915_reg_read_ioctl
  drm/i915: don't read pp_ctrl_reg if we're suspended
  drm/i915: get runtime PM at i915_display_info
  drm/i915: don't read cursor registers on powered down pipes
  drm/i915: fix WARNs when reading DDI state while suspended
  drm/i915: don't get/put runtime PM at the debugfs forcewake file

Ville Syrj?l? (3):
  drm/i915: Program VSYNCSHIFT in a more consistent manner
  drm/i915: Fix the interlace mode selection for gmch platforms
  drm/i915: Make sure vsyncshift is positive

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

[RFC 3/3] drm/ttm: Enable the priority queue for VRAM

[Lauri Kasanen]

Signed-off-by: Lauri Kasanen 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 68 +++-
 1 file changed, 54 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 621151c..80e5856 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -172,7 +172,12 @@ void ttm_bo_add_to_lru(struct ttm_buffer_object *bo)
BUG_ON(!list_empty(>lru));

man = >man[bo->mem.mem_type];
-   list_add_tail(>lru, >lru);
+
+   if (bdev->use_pqueue && bo->mem.mem_type == TTM_PL_VRAM)
+   ttm_prio_add(>pqueue, >pqueue);
+   else
+   list_add_tail(>lru, >lru);
+
kref_get(>list_kref);

if (bo->ttm != NULL) {
@@ -186,6 +191,8 @@ EXPORT_SYMBOL(ttm_bo_add_to_lru);
 int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
 {
int put_count = 0;
+   struct ttm_bo_device *bdev = bo->bdev;
+   struct ttm_mem_type_manager *man = >man[bo->mem.mem_type];

if (!list_empty(>swap)) {
list_del_init(>swap);
@@ -194,6 +201,10 @@ int ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
if (!list_empty(>lru)) {
list_del_init(>lru);
++put_count;
+   } else if (bdev->use_pqueue && bo->mem.mem_type == TTM_PL_VRAM &&
+   ttm_prio_is_queued(>pqueue)) {
+   ttm_prio_remove(>pqueue, >pqueue);
+   ++put_count;
}

/*
@@ -725,10 +736,22 @@ static int ttm_mem_evict_first(struct ttm_bo_device *bdev,
int ret = -EBUSY, put_count;

spin_lock(>lru_lock);
-   list_for_each_entry(bo, >lru, lru) {
-   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
-   if (!ret)
-   break;
+   if (bdev->use_pqueue && mem_type == TTM_PL_VRAM) {
+   struct ttm_pqueue_entry *pe;
+   for (pe = ttm_prio_query_lowest(>pqueue); pe;
+   pe = ttm_prio_query_next(pe)) {
+
+   bo = container_of(pe, struct ttm_buffer_object, pqueue);
+   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
+   if (!ret)
+   break;
+   }
+   } else {
+   list_for_each_entry(bo, >lru, lru) {
+   ret = ttm_bo_reserve_nolru(bo, false, true, false, 0);
+   if (!ret)
+   break;
+   }
}

if (ret) {
@@ -1125,6 +1148,7 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(>ddestroy);
INIT_LIST_HEAD(>swap);
INIT_LIST_HEAD(>io_reserve_lru);
+   ttm_prio_init_entry(>pqueue);
mutex_init(>wu_mutex);
bo->bdev = bdev;
bo->glob = bdev->glob;
@@ -1243,17 +1267,32 @@ static int ttm_bo_force_list_clean(struct ttm_bo_device 
*bdev,
 */

spin_lock(>lru_lock);
-   while (!list_empty(>lru)) {
-   spin_unlock(>lru_lock);
-   ret = ttm_mem_evict_first(bdev, mem_type, false, false);
-   if (ret) {
-   if (allow_errors) {
-   return ret;
-   } else {
-   pr_err("Cleanup eviction failed\n");
+   if (bdev->use_pqueue && mem_type == TTM_PL_VRAM) {
+   while (ttm_prio_query_lowest(>pqueue)) {
+   spin_unlock(>lru_lock);
+   ret = ttm_mem_evict_first(bdev, mem_type, false, false);
+   if (ret) {
+   if (allow_errors) {
+   return ret;
+   } else {
+   pr_err("Cleanup eviction failed\n");
+   }
}
+   spin_lock(>lru_lock);
+   }
+   } else {
+   while (!list_empty(>lru)) {
+   spin_unlock(>lru_lock);
+   ret = ttm_mem_evict_first(bdev, mem_type, false, false);
+   if (ret) {
+   if (allow_errors) {
+   return ret;
+   } else {
+   pr_err("Cleanup eviction failed\n");
+   }
+   }
+   spin_lock(>lru_lock);
}
-   spin_lock(>lru_lock);
}
spin_unlock(>lru_lock);
return 0;
@@ -1338,6 +1377,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned 
type,
man->size = p_size;

INIT_LIST_HEAD(>lru);
+   memset(>pqueue, 0, sizeof(struct ttm_pqueue));

return 0;
 }
-- 
1.8.3.1

[PATCH 4/4] Revert "drm/exynos: add mout_hdmi clock in hdmi driver to change parent"

[Tomasz Stanislawski]

This reverts commit 59956d35a8618235ea715280b49447bb36f2c975.

Signed-off-by: Tomasz Stanislawski 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 9a6d652..8ebb4bf 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -75,7 +75,6 @@ struct hdmi_resources {
struct clk  *sclk_pixel;
struct clk  *sclk_hdmiphy;
struct clk  *hdmiphy;
-   struct clk  *mout_hdmi;
struct regulator_bulk_data  *regul_bulk;
int regul_count;
 };
@@ -1282,7 +1281,7 @@ static void hdmi_v13_mode_apply(struct hdmi_context 
*hdata)
}

clk_disable_unprepare(hdata->res.sclk_hdmi);
-   clk_set_parent(hdata->res.mout_hdmi, hdata->res.sclk_hdmiphy);
+   clk_set_parent(hdata->res.sclk_hdmi, hdata->res.sclk_hdmiphy);
clk_prepare_enable(hdata->res.sclk_hdmi);

/* enable HDMI and timing generator */
@@ -1449,7 +1448,7 @@ static void hdmi_v14_mode_apply(struct hdmi_context 
*hdata)
}

clk_disable_unprepare(hdata->res.sclk_hdmi);
-   clk_set_parent(hdata->res.mout_hdmi, hdata->res.sclk_hdmiphy);
+   clk_set_parent(hdata->res.sclk_hdmi, hdata->res.sclk_hdmiphy);
clk_prepare_enable(hdata->res.sclk_hdmi);

/* enable HDMI and timing generator */
@@ -1475,7 +1474,7 @@ static void hdmiphy_conf_reset(struct hdmi_context *hdata)
u32 reg;

clk_disable_unprepare(hdata->res.sclk_hdmi);
-   clk_set_parent(hdata->res.mout_hdmi, hdata->res.sclk_pixel);
+   clk_set_parent(hdata->res.sclk_hdmi, hdata->res.sclk_pixel);
clk_prepare_enable(hdata->res.sclk_hdmi);

/* operation mode */
@@ -1982,13 +1981,8 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
DRM_ERROR("failed to get clock 'hdmiphy'\n");
goto fail;
}
-   res->mout_hdmi = devm_clk_get(dev, "mout_hdmi");
-   if (IS_ERR(res->mout_hdmi)) {
-   DRM_ERROR("failed to get clock 'mout_hdmi'\n");
-   goto fail;
-   }

-   clk_set_parent(res->mout_hdmi, res->sclk_pixel);
+   clk_set_parent(res->sclk_hdmi, res->sclk_pixel);

res->regul_bulk = devm_kzalloc(dev, ARRAY_SIZE(supply) *
sizeof(res->regul_bulk[0]), GFP_KERNEL);
-- 
1.7.9.5

[PATCH 3/4] clk: exynos4: enable clk_set_parent() propagation for sclk_hdmi and sclk_mixer clocks

[Tomasz Stanislawski]

This patch enables clk_set_parent() propagation for clocks used
by s5p-tv and exynos-drm drivers.

Signed-off-by: Tomasz Stanislawski 
---
 drivers/clk/samsung/clk-exynos4.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index 528f8eb..87b8264 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -680,7 +680,8 @@ static struct samsung_gate_clock exynos4_gate_clks[] 
__initdata = {
 * the device name and clock alias names specified below for some
 * of the clocks can be removed.
 */
-   GATE(CLK_SCLK_HDMI, "sclk_hdmi", "mout_hdmi", SRC_MASK_TV, 0, 0, 0),
+   GATE(CLK_SCLK_HDMI, "sclk_hdmi", "mout_hdmi", SRC_MASK_TV, 0,
+   CLK_SET_PARENT_PARENT, 0),
GATE(CLK_SCLK_SPDIF, "sclk_spdif", "mout_spdif", SRC_MASK_PERIL1, 8, 0,
0),
GATE(CLK_JPEG, "jpeg", "aclk160", GATE_IP_CAM, 6, 0, 0),
@@ -880,7 +881,8 @@ static struct samsung_gate_clock exynos4210_gate_clks[] 
__initdata = {
E4210_SRC_MASK_LCD1, 12, CLK_SET_RATE_PARENT, 0),
GATE(CLK_SCLK_SATA, "sclk_sata", "div_sata",
SRC_MASK_FSYS, 24, CLK_SET_RATE_PARENT, 0),
-   GATE(CLK_SCLK_MIXER, "sclk_mixer", "mout_mixer", SRC_MASK_TV, 4, 0, 0),
+   GATE(CLK_SCLK_MIXER, "sclk_mixer", "mout_mixer", SRC_MASK_TV, 4,
+   CLK_SET_PARENT_PARENT, 0),
GATE(CLK_SCLK_DAC, "sclk_dac", "mout_dac", SRC_MASK_TV, 8, 0, 0),
GATE(CLK_TSADC, "tsadc", "aclk100", GATE_IP_PERIL, 15,
0, 0),
-- 
1.7.9.5

[PATCH 2/4] clk: exynos4: export sclk_hdmiphy clock

[Tomasz Stanislawski]

Export sclk_hdmiphy clock to be usable from DT.

Signed-off-by: Tomasz Stanislawski 
---
 drivers/clk/samsung/clk-exynos4.c   |2 +-
 include/dt-bindings/clock/exynos4.h |1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/samsung/clk-exynos4.c 
b/drivers/clk/samsung/clk-exynos4.c
index b4f9672..528f8eb 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -428,7 +428,7 @@ static struct samsung_fixed_rate_clock 
exynos4_fixed_rate_ext_clks[] __initdata
 /* fixed rate clocks generated inside the soc */
 static struct samsung_fixed_rate_clock exynos4_fixed_rate_clks[] __initdata = {
FRATE(0, "sclk_hdmi24m", NULL, CLK_IS_ROOT, 2400),
-   FRATE(0, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2700),
+   FRATE(CLK_SCLK_HDMIPHY, "sclk_hdmiphy", NULL, CLK_IS_ROOT, 2700),
FRATE(0, "sclk_usbphy0", NULL, CLK_IS_ROOT, 4800),
 };

diff --git a/include/dt-bindings/clock/exynos4.h 
b/include/dt-bindings/clock/exynos4.h
index 75aff33..0e245eb 100644
--- a/include/dt-bindings/clock/exynos4.h
+++ b/include/dt-bindings/clock/exynos4.h
@@ -33,6 +33,7 @@
 #define CLK_MOUT_MPLL_USER_C   18 /* Exynos4x12 only */
 #define CLK_MOUT_CORE  19
 #define CLK_MOUT_APLL  20
+#define CLK_SCLK_HDMIPHY   22

 /* gate for special clocks (sclk) */
 #define CLK_SCLK_FIMC0 128
-- 
1.7.9.5

[PATCH 1/4] clk: propagate parent change up one level

[Tomasz Stanislawski]

This patch adds support for propagation of setup of clock's parent one level
up.

This feature is helpful when a driver changes topology of its clocks using
clk_set_parent().  The problem occurs when on one platform/SoC driver's clock
is located at MUX output but on the other platform/SoC there is a gated proxy
clock between the MUX and driver's clock.  In such a case, driver's code has to
be modified to use one clock for enabling and the other clock for setup of a
parent.

The code updates are avoided by propagating setup of a parent up one level.

Additionally, this patch adds CLK_SET_PARENT_PARENT (sorry for naming) flag to
inform clk-core that clk_set_parent() should be propagated.

Signed-off-by: Tomasz Stanislawski 
---
 drivers/clk/clk.c|6 ++
 include/linux/clk-provider.h |1 +
 2 files changed, 7 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index dff0373..53bbfda 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1737,6 +1737,12 @@ int clk_set_parent(struct clk *clk, struct clk *parent)

/* try finding the new parent index */
if (parent) {
+   if ((clk->flags & CLK_SET_PARENT_PARENT)
+   && clk->num_parents == 1) {
+   ret = clk_set_parent(clk->parent, parent);
+   goto out;
+   }
+
p_index = clk_fetch_parent_index(clk, parent);
p_rate = parent->rate;
if (p_index < 0) {
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5119174..daa0b03 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -30,6 +30,7 @@
 #define CLK_GET_RATE_NOCACHE   BIT(6) /* do not use the cached clk rate */
 #define CLK_SET_RATE_NO_REPARENT BIT(7) /* don't re-parent on rate change */
 #define CLK_GET_ACCURACY_NOCACHE BIT(8) /* do not use the cached clk accuracy 
*/
+#define CLK_SET_PARENT_PARENT  BIT(9) /* propagate parent change up one level 
*/

 struct clk_hw;
 struct dentry;
-- 
1.7.9.5

[RFC 2/3] drm/ttm: Add the priority queue to appropriate structs

[Lauri Kasanen]

Signed-off-by: Lauri Kasanen 
---
 drivers/gpu/drm/ast/ast_ttm.c | 1 +
 drivers/gpu/drm/bochs/bochs_mm.c  | 1 +
 drivers/gpu/drm/cirrus/cirrus_ttm.c   | 1 +
 drivers/gpu/drm/mgag200/mgag200_ttm.c | 1 +
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
 drivers/gpu/drm/qxl/qxl_ttm.c | 2 +-
 drivers/gpu/drm/radeon/radeon_ttm.c   | 1 +
 drivers/gpu/drm/ttm/ttm_bo.c  | 2 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   | 2 +-
 include/drm/ttm/ttm_bo_api.h  | 2 ++
 include/drm/ttm/ttm_bo_driver.h   | 7 +++
 11 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_ttm.c b/drivers/gpu/drm/ast/ast_ttm.c
index 61f9e39..311f37f 100644
--- a/drivers/gpu/drm/ast/ast_ttm.c
+++ b/drivers/gpu/drm/ast/ast_ttm.c
@@ -263,6 +263,7 @@ int ast_mm_init(struct ast_private *ast)
 dev->anon_inode->i_mapping,
 DRM_FILE_PAGE_OFFSET,
 true,
+false,
 0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 9dfd24a..c4aba61 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -229,6 +229,7 @@ int bochs_mm_init(struct bochs_device *bochs)
 bochs->dev->anon_inode->i_mapping,
 DRM_FILE_PAGE_OFFSET,
 true,
+false,
 0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
diff --git a/drivers/gpu/drm/cirrus/cirrus_ttm.c 
b/drivers/gpu/drm/cirrus/cirrus_ttm.c
index 74e8e21..895d20e 100644
--- a/drivers/gpu/drm/cirrus/cirrus_ttm.c
+++ b/drivers/gpu/drm/cirrus/cirrus_ttm.c
@@ -263,6 +263,7 @@ int cirrus_mm_init(struct cirrus_device *cirrus)
 dev->anon_inode->i_mapping,
 DRM_FILE_PAGE_OFFSET,
 true,
+false,
 0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
diff --git a/drivers/gpu/drm/mgag200/mgag200_ttm.c 
b/drivers/gpu/drm/mgag200/mgag200_ttm.c
index 6844b24..591f68e 100644
--- a/drivers/gpu/drm/mgag200/mgag200_ttm.c
+++ b/drivers/gpu/drm/mgag200/mgag200_ttm.c
@@ -263,6 +263,7 @@ int mgag200_mm_init(struct mga_device *mdev)
 dev->anon_inode->i_mapping,
 DRM_FILE_PAGE_OFFSET,
 true,
+false,
 0);
if (ret) {
DRM_ERROR("Error initialising bo driver; %d\n", ret);
diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index 3fef97c..4b032b4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -384,7 +384,7 @@ nouveau_ttm_init(struct nouveau_drm *drm)
  _bo_driver,
  dev->anon_inode->i_mapping,
  DRM_FILE_PAGE_OFFSET,
- bits <= 32 ? true : false, 0);
+ bits <= 32 ? true : false, false, 0);
if (ret) {
NV_ERROR(drm, "error initialising bo driver, %d\n", ret);
return ret;
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index 8401a00..88f12e7 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/gpu/drm/qxl/qxl_ttm.c
@@ -495,7 +495,7 @@ int qxl_ttm_init(struct qxl_device *qdev)
   qdev->mman.bo_global_ref.ref.object,
   _bo_driver,
   qdev->ddev->anon_inode->i_mapping,
-  DRM_FILE_PAGE_OFFSET, 0, 0);
+  DRM_FILE_PAGE_OFFSET, 0, false, 0);
if (r) {
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
return r;
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c 
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 1aef339..dd96ed5 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -711,6 +711,7 @@ int radeon_ttm_init(struct radeon_device *rdev)
   rdev->ddev->anon_inode->i_mapping,
   DRM_FILE_PAGE_OFFSET,
   rdev->need_dma32,
+  false,
   512 * 1024);
if (r) {
DRM_ERROR("failed initializing buffer object driver(%d).\n", r);
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index caf7cd3..621151c 

[PATCH 0/4] Update to Exynos clocks

[Tomasz Stanislawski]

This patchset adds some updates to clocks for Exynos4 platform and to the clock
core.  The patches are rebased on linux/next.

An interesting part might be 'propagation of clk_set_parent()'.  This feature
simplifies configuration of complex topologyof clocks by drivers.  Such a
situation happens for Exynos HDMI driver.

The HDMI device is clocked by sclk_hdmi clock. In older versions of SoC and its
driver, the clock had two parent clocks: sclk_hdmiphy and sclk_pixel.
The sclk_hdmi was a gated clock.

In the recent version of Exynos clock provider this topology was slightly
changed. A new clock named mout_hdmi was introduced.  This new clock represents
the output of multiplexer that selects between sclk_hdmiphy and sclk_pixel.

After the change the sclk_hdmi is still gated but has a single parent -
mout_hdmi.

This change caused interesting situation in Exynos HDMI driver because this
driver used only sclk_hdmi.  Now clk_set_parent(sclk_hdmi, ...) fails because
sclk_hdmi has a single parent now.  Using mout_hdmi instead of sclk_hdmi will
not work because clk_enable(mout_hdmi) is not propagated to sclk_hdmi.

To solve this problem, the setup of mout_hdmi was added to Exynos HDMI in the
patch: "drm/exynos: add mout_hdmi clock in hdmi driver to change parent"

IMO, this change breaks abstraction of clock API reveling too detailed
information about clock topology to the driver.

Moreover, the driver no longer works with old DT bindings because they provide
no mout_hdmi clock.

The clock set_parent propagation can be used to fix this.  The clk_set_parent()
is propagated to a parent as long as the current clock has a single parent and
has the flag CLK_SET_PARENT_PARENT set.

Now Exynos HDMI can use only sclk_hdmi clock. The clk_enable() gates this clock
directly and clk_set_parent() is propagated to mout_hdmi.

This new behaviour does not break DT bindings because mout_hdmi would be simply
ignored.

After this change the 'add mout_hdmi clock' is no longer needed.

Regards,
Tomasz Stanislawski

Tomasz Stanislawski (4):
  clk: propagate parent change up one level
  clk: exynos4: export sclk_hdmiphy clock
  clk: exynos4: enable clk_set_parent() propagation for sclk_hdmi and
sclk_mixer clocks
  Revert "drm/exynos: add mout_hdmi clock in hdmi driver to change
parent"

 drivers/clk/clk.c|6 ++
 drivers/clk/samsung/clk-exynos4.c|8 +---
 drivers/gpu/drm/exynos/exynos_hdmi.c |   14 --
 include/dt-bindings/clock/exynos4.h  |1 +
 include/linux/clk-provider.h |1 +
 5 files changed, 17 insertions(+), 13 deletions(-)

-- 
1.7.9.5

[RFC 1/3] drm/ttm: Add a priority queue

[Lauri Kasanen]

Signed-off-by: Lauri Kasanen 
---
 drivers/gpu/drm/ttm/Makefile   |   2 +-
 drivers/gpu/drm/ttm/ttm_priority.c | 152 +
 include/drm/ttm/ttm_priority.h |  90 ++
 3 files changed, 243 insertions(+), 1 deletion(-)
 create mode 100644 drivers/gpu/drm/ttm/ttm_priority.c
 create mode 100644 include/drm/ttm/ttm_priority.h

diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index b433b9f..4411599 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -5,6 +5,6 @@ ccflags-y := -Iinclude/drm
 ttm-y := ttm_agp_backend.o ttm_memory.o ttm_tt.o ttm_bo.o \
ttm_bo_util.o ttm_bo_vm.o ttm_module.o \
ttm_object.o ttm_lock.o ttm_execbuf_util.o ttm_page_alloc.o \
-   ttm_bo_manager.o ttm_page_alloc_dma.o
+   ttm_bo_manager.o ttm_page_alloc_dma.o ttm_priority.o

 obj-$(CONFIG_DRM_TTM) += ttm.o
diff --git a/drivers/gpu/drm/ttm/ttm_priority.c 
b/drivers/gpu/drm/ttm/ttm_priority.c
new file mode 100644
index 000..a7cf8d1
--- /dev/null
+++ b/drivers/gpu/drm/ttm/ttm_priority.c
@@ -0,0 +1,152 @@
+/**
+ *
+ * Copyright (c) 2014 Lauri Kasanen
+ * All Rights Reserved.
+ *
+ * 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, sub license, 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 NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+
+#include 
+#include 
+
+static void ttm_prio_insert_rb(struct rb_root * const root,
+  struct ttm_pqueue_entry * const data,
+  struct rb_node *parent,
+  struct rb_node **where)
+{
+   BUG_ON(!where || (!parent && root->rb_node));
+
+   rb_link_node(>node, parent, where);
+   rb_insert_color(>node, root);
+}
+
+static struct ttm_pqueue_entry *ttm_prio_search_rb(struct rb_root *root,
+  u64 score,
+  struct rb_node **parent,
+  struct rb_node ***where)
+{
+   struct rb_node **new = >rb_node;
+
+   while (*new) {
+   struct ttm_pqueue_entry *this = container_of(*new,
+struct 
ttm_pqueue_entry,
+node);
+
+   *parent = *new;
+
+   if (score < this->score)
+   new = &((*new)->rb_left);
+   else if (score > this->score)
+   new = &((*new)->rb_right);
+   else
+   return this;
+
+   BUG_ON(*parent == *new);
+   }
+
+   *where = new;
+
+   return NULL;
+}
+
+void ttm_prio_add(struct ttm_pqueue * const queue,
+ struct ttm_pqueue_entry * const entry)
+{
+   struct rb_root * const tree = >tree;
+   struct rb_node **place = NULL, *parent = NULL;
+   struct ttm_pqueue_entry *test;
+
+   if (ttm_prio_is_queued(entry))
+   ttm_prio_remove(queue, entry);
+
+   test = ttm_prio_search_rb(tree, entry->score, , );
+
+   if (!test)
+   ttm_prio_insert_rb(tree, entry, parent, place);
+   else
+   list_add_tail(>list, >list);
+}
+
+struct ttm_pqueue_entry *ttm_prio_query_lowest(const struct ttm_pqueue * const 
queue)
+{
+   const struct rb_root * const root = >tree;
+   struct rb_node *node;
+
+   node = rb_first(root);
+   if (!node)
+   return NULL;
+
+   return container_of(node, struct ttm_pqueue_entry, node);
+}
+
+void ttm_prio_remove(struct ttm_pqueue * const queue,
+struct ttm_pqueue_entry * const entry)
+{
+   struct rb_root * const tree = >tree;
+
+   if (list_empty(>list)) {
+   rb_erase(>node, tree);
+

[RFC 0/3] TTM priority queue logic

[Lauri Kasanen]

Hi list, Thomas,

I'd like to know if this is going in the right direction.

I've implemented a priority queue on top of the kernel rb tree and
linked list. It's been tested well in userspace.

I hardcoded radeon to input the buffer size as the score. Nothing blew
up, games ran fine, and even got ~2% more fps on average*.

The only thing missing from this code is the "if score is too low, and
there is no room without eviction, tell driver so" logic.

- Lauri

* This is a fairly bad strategy, and according to my simulator achieves
16% worse results compared to LRU in heavier situations. The games
tested here all fit in VRAM, which should explain the improvement.

PCI Radeon RV100 detection hang on sparc64

[David Miller]

From: Meelis Roos 
Date: Tue, 1 Oct 2013 11:43:20 +0300 (EEST)

>> > > That looks quite strange. I guess the kernel should map the ROM at the
>> > > address OpenBoot/OF assigned to it. ( 1002 ).
>> > 
>> > The address you see is a raw physical I/O address, which is a concatenation
>> > of the I/O window physical address for that PCI controller and the
>> > PCI bus assigned address.
>> > 
>> > This is what we store in the resource values.
>> > 
>> > The pci_assign_resource() path must have some bug that causes the
>> > resource values to be set incorrectly or similar.
>> > 
>> > Meelis, what is the value of pci_resource_start(pdev, PCI_ROM_RESOURCE)
>> > before the pci_map_rom() call?
>> 
>> [drm] radeon_read_bios: pci_resource_start(ROM)=01FF1002
>> 
>> I am a little confused here. ROM addressis OK but after pci_map_rom it 
>> results in address that corresponds to another device?
> 
> I read more code and tried a couple of more things.
> 
> Using ofpci_debug=1 I get sensible output for scsi:
> 
> PCI: scan_bus[/pci at 1f,0/pci at 1] bus no 2
>   * /pci at 1f,0/pci at 1/scsi at 1
> create device, devfn: 8, type: scsi-2
> class: 0x1 device name: :02:01.0
> parse addresses (40 bytes) @ f8003fedc1c0
>   start: 1ff2000, end: 1ff20ff, i: 14
>   start: 1ff0001, end: 1ff0001, i: 30
> adding to system ...
> 
> adding to system refers to pci_device_add(dev, bus) and that does not 
> modify the PCI bus available windows in any way, at least by my reafing 
> of the PCI code, so the PCI code does not know the resource ranges are 
> now busy?

I finally did some digging into this, and I think the issue is that
sparc needs to do pci_claim_resource() calls over all the PCI device
resources which are valid after we finish adding the PCI devices.

I'll try to follow up with a patch some time next week.

[GIT PULL] exynos-drm-next

[Inki Dae]

> -Original Message-
> From: Tomasz Figa [mailto:t.figa at samsung.com]
> Sent: Friday, April 04, 2014 4:29 PM
> To: Inki Dae; 'Tomasz Figa'; airlied at linux.ie; dri-
> devel at lists.freedesktop.org; 'Marek Szyprowski';
> devicetree at vger.kernel.org; Grant Likely; Rob Herring
> Subject: Re: [GIT PULL] exynos-drm-next
> 
> On 04.04.2014 07:34, Inki Dae wrote:
> > Hi Tomasz,
> >
> >> -Original Message-
> >> From: Tomasz Figa [mailto:tomasz.figa at gmail.com]
> >> Sent: Friday, April 04, 2014 2:00 PM
> >> To: inki.dae at samsung.com; airlied at linux.ie; dri-
> >> devel at lists.freedesktop.org
> >> Subject: Re: [GIT PULL] exynos-drm-next
> >>
> >> Hi Inki,
> >>
> >> On 03.04.2014 19:34, inki.dae at samsung.com wrote:
> >>> Hi Dave,
> >>>  Sorry for late.
> >>>  This pull request includes MIPI-DSI driver, two panel drivers,
> >>>  super device support, and relevant dt bindings.
> >>>
> >>> Summaries:
> >>> - Add MIPI-DSI Driver, and dt bindigs
> >>> - Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings
> >>> - Add LD9040 parallel panel driver
> >>> . this driver is placed in drivers/gpu/drm/panel, and it seems
> >>>   to be used for exynos drm as of now,
> >>> - Add super device support, and dt bindings
> >>> . this patch resolves the probe order issue to sub drivers
> >>>   without specific lists
> >>
> >> I don't think the DT bindings have been Acked by DT maintainers,
> >> which is necessary to merge them.
> >>
> >> Also I believe more discussion is needed on this, but I didn't have
> >> time to comment on this series yet. Please hold off with merging the
> >> supernode series yet.
> >
> > I sent a email about review request to you but I didn't get any answer
> > from you.
> 
> It's been just three days ago and I just didn't find time yet to review

No, the email was just ping. My original RFC patch series had been posted
March 3, about 1 month ago, And for my official patch series, eight days
ago.
So the email I sent three days ago was just a ping that I requested for you
to review the patch series.

> them. I would like to be able to review all the patches straight after
> them being posted, but unfortunately that's not the only thing I have to
> do.
> 

So I think there was no any comments from you for a long time.

> Anyway, a common practice in open source world is to let the patches wait
> on the mailing lists for two weeks for people to find some time to review
> them and only then apply. There might be people that don't work full time
> on this area, but still would be interested to do a review in some free
> time.
> 
> Also, neither version of this series have been posted to linux-samsung-soc
> mailing list, which is also a key to have a broader review. Note that this
> ML is listed in MAINTAINERS file for all kernel files with "exynos" in
> name.
> 
> ARM/S5P EXYNOS ARM ARCHITECTURES
> M:  Kukjin Kim 
> L:  linux-arm-kernel at lists.infradead.org (moderated for
non-subscribers)
> L:  linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
> S:  Maintained
> F:  arch/arm/mach-s5p*/
> F:  arch/arm/mach-exynos*/
> N:  exynos
> 
> 
> > And I think super node concept was already accepted, and relevant
> > codes, component framework, has already been merged to mainline. And
> > Linux staging next has already such dt bindings. Please see imx dts
> files.
> 
> Yes, they are, but for other platforms not this particular instance.
> 
> Any new DT bindings introduced are needed to have an ACK from one of DT
> maintainers to be merged, unless you can't get any reply from any of them
> for a longer time, usually 3 weeks from posting the series to be applied.

So should I wait for more times?

> 
> Of course standard pinging rules apply, so you should ping DT maintainers
> first before applying such series.


The email I sent to you three days ago was that.

Thanks,
Inki Dae


> 
> >
> > I hope this time this series would be merged to mainline so that we
> > could go to next step, integrating drm_panel and drm_bridge framework
> > to one integrated drm_bridge. So Can you hurry up to review it a bit?
> > I'll wait for your ack.
> 
> I don't think there is any need to hurry up with this particular series
> for this release. I'd recommend sending a pull request with remaining
> patches separately, as the supernode is not required to make anything
work,
> rather than being just a refactor.
> 
> Best regards,
> Tomasz

[Bug 76659] Display does not return from DPMS off using ATI drivers

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

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

--- Comment #8 from Alex Deucher  ---
Does manually turning off the display also cause problems?  e.g. run:
xset dpms force off
xset dpms force on
from a terminal

Can you get remote access to the box (e.g., ssh)?  If so can you try manually
turning the displays on/off?  E.g.,

DISPLAY=:0.0 xset dpms force off
DISPLAY=:0.0 xset dpms force on

or

DISPLAY=:0.0 xrandr --output DVI-0 --off
DISPLAY=:0.0 xrandr --output DVI-0 --auto

-- 
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/20140404/ff79694d/attachment.html>

[RFC 0/3] TTM priority queue logic

[Thomas Hellstrom]

On 04/04/2014 03:52 PM, Lauri Kasanen wrote:
> Hi list, Thomas,
>
> I'd like to know if this is going in the right direction.
>
> I've implemented a priority queue on top of the kernel rb tree and
> linked list. It's been tested well in userspace.
>
> I hardcoded radeon to input the buffer size as the score. Nothing blew
> up, games ran fine, and even got ~2% more fps on average*.
>
> The only thing missing from this code is the "if score is too low, and
> there is no room without eviction, tell driver so" logic.
>
> - Lauri
>
> * This is a fairly bad strategy, and according to my simulator achieves
> 16% worse results compared to LRU in heavier situations. The games
> tested here all fit in VRAM, which should explain the improvement

Lauri, I'm out of the office until monday, I'll take a look then.
Thanks,

Thomas

[PATCH V2] gpu: host1x: handle the correct # of syncpt regs

[Stephen Warren]

From: Stephen Warren 

BIT_WORD() truncates rather than rounds, so the loops in
syncpt_thresh_isr() and _host1x_intr_disable_all_syncpt_intrs() use <=
rather than < in an attempt to process the correct number of registers
when rounding of the conversion of count of bits to count of words is
necessary. However, when rounding isn't necessary because the value is
already a multiple of the divisor (as is the case for all values of
nb_pts the code actually sees), this causes one too many registers to
be processed.

Solve this by using and explicit DIV_ROUND_UP() call, rather than
BIT_WORD(), and comparing with < rather than <=.

Signed-off-by: Stephen Warren 
---
v2: Use DIV_ROUND_UP rather than BITS_TO_LONGS to avoid problems on 64-bit.
---
 drivers/gpu/host1x/hw/intr_hw.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/host1x/hw/intr_hw.c b/drivers/gpu/host1x/hw/intr_hw.c
index db9017adfe2b..498b37e39058 100644
--- a/drivers/gpu/host1x/hw/intr_hw.c
+++ b/drivers/gpu/host1x/hw/intr_hw.c
@@ -47,7 +47,7 @@ static irqreturn_t syncpt_thresh_isr(int irq, void *dev_id)
unsigned long reg;
int i, id;

-   for (i = 0; i <= BIT_WORD(host->info->nb_pts); i++) {
+   for (i = 0; i < DIV_ROUND_UP(host->info->nb_pts, 32); i++) {
reg = host1x_sync_readl(host,
HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(i));
for_each_set_bit(id, , BITS_PER_LONG) {
@@ -64,7 +64,7 @@ static void _host1x_intr_disable_all_syncpt_intrs(struct 
host1x *host)
 {
u32 i;

-   for (i = 0; i <= BIT_WORD(host->info->nb_pts); ++i) {
+   for (i = 0; i < DIV_ROUND_UP(host->info->nb_pts, 32); ++i) {
host1x_sync_writel(host, 0xu,
HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(i));
host1x_sync_writel(host, 0xu,
-- 
1.8.1.5

[Bug 42960] Display does not work when resuming from suspend

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

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

--- Comment #27 from Swoorup  ---
(In reply to comment #25)
> (In reply to comment #22)
> > Adding s3_bios to kernel parameters didn't work for me. The suspend just
> > does not work anymore. Laptop wont suspend anymore.
> > 
> > My hardware:
> > Asus -K55N
> > Radeon HD7250G
> 
> You can also try: acpi_sleep=s3_mode or acpi_sleep=s3_bios,s3_mode
> 
> A little info here:https://www.kernel.org/doc/Documentation/power/video.txt

Neither of that work. Also I am booted in UEFI mode, if that helps?

-- 
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/20140404/00dd04f8/attachment.html>

[PATCH v4 14/34] drm/exynos: hdmi: remove the i2c drivers and use devtree

[Tomasz Stanislawski]

Hi Inki,
Sorry for a very late reply.

On 02/19/2014 12:14 PM, Inki Dae wrote:
> Hi Tomasz,
> 
> 
> 2014-02-14 23:13 GMT+09:00 Tomasz Stanislawski :
>> Hi Daniel,
>> I think that it would be better to change the semantic of phy and ddc
>> bindings.
>>
>> Rather than pointing to I2C client it should point to I2C bus instead.
>> The exynos DRM driver can create dummy I2C clients using i2c_new_dummy()
>> function.
> 
> It seems better way. As of now, all we need for HDMI DDC is
> i2c_adapter (including i2c phy), not i2c_client.
> 
>>
>> There is quite strong rationale for this:
>> - DDC is always accessible on fixed addresses described in HDMI 
>> specification.
>> - HDMIPHY (including I2C address) is a part of HDMI IP and it is bound to
>>   specific version of Exynos SoC
>> - no need to add virtual nodes in DTS
> 
> You mean hdmiddc and hdmiphy nodes? If so, I think they are real
> nodes, not virtual nodes. Otherwise, plz give me more comments.
> 
> Thanks,
> Inki Dae
> 

The problem is that those nodes have no dedicated driver.
Moreover, the I2C address for HDMIPHY is always present on
a fixed address dependant on SoC (read HDMI IP) version.
Moreover, both devices share HDMI and HDMIPHY share registers
from HDMI's pool.
Additionally, the hdmiphy I2C client is currently configured using
exynos-hdmi code its DRM driver.
So technically the hdmiphy bus is only a resource used by
exynos-drm-hdmi driver.

Regards,
Tomasz Stanislawski

>> - NVIDIA already use bindings to DDC bus instead of DDC client. Take a look 
>> to
>>   arch/arm/boot/dts/tegra*.dts
>>
>> Regards,
>> Tomasz Stanislawski
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] drm/radeon/dp: switch to the common i2c over aux code

[Alex Deucher]

Provides a nice cleanup in radeon.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c   | 117 +
 drivers/gpu/drm/radeon/radeon_connectors.c |  44 ++-
 drivers/gpu/drm/radeon/radeon_display.c|  11 ++-
 drivers/gpu/drm/radeon/radeon_i2c.c|  60 ---
 drivers/gpu/drm/radeon/radeon_mode.h   |  12 +--
 5 files changed, 44 insertions(+), 200 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index e914008..d545769 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -201,98 +201,15 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)

 void radeon_dp_aux_init(struct radeon_connector *radeon_connector)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
-
-   dig_connector->dp_i2c_bus->aux.dev = radeon_connector->base.kdev;
-   dig_connector->dp_i2c_bus->aux.transfer = radeon_dp_aux_transfer;
-}
-
-int radeon_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
-u8 write_byte, u8 *read_byte)
-{
-   struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
-   struct radeon_i2c_chan *auxch = i2c_get_adapdata(adapter);
-   u16 address = algo_data->address;
-   u8 msg[5];
-   u8 reply[2];
-   unsigned retry;
-   int msg_bytes;
-   int reply_bytes = 1;
int ret;
-   u8 ack;
-
-   /* Set up the address */
-   msg[0] = address;
-   msg[1] = address >> 8;
-
-   /* Set up the command byte */
-   if (mode & MODE_I2C_READ) {
-   msg[2] = DP_AUX_I2C_READ << 4;
-   msg_bytes = 4;
-   msg[3] = msg_bytes << 4;
-   } else {
-   msg[2] = DP_AUX_I2C_WRITE << 4;
-   msg_bytes = 5;
-   msg[3] = msg_bytes << 4;
-   msg[4] = write_byte;
-   }

-   /* special handling for start/stop */
-   if (mode & (MODE_I2C_START | MODE_I2C_STOP))
-   msg[3] = 3 << 4;
-
-   /* Set MOT bit for all but stop */
-   if ((mode & MODE_I2C_STOP) == 0)
-   msg[2] |= DP_AUX_I2C_MOT << 4;
-
-   for (retry = 0; retry < 7; retry++) {
-   ret = radeon_process_aux_ch(auxch,
-   msg, msg_bytes, reply, reply_bytes, 
0, );
-   if (ret == -EBUSY)
-   continue;
-   else if (ret < 0) {
-   DRM_DEBUG_KMS("aux_ch failed %d\n", ret);
-   return ret;
-   }
+   radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
+   radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
+   ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus->aux);
+   if (!ret)
+   radeon_connector->ddc_bus->has_aux = true;

-   switch ((ack >> 4) & DP_AUX_NATIVE_REPLY_MASK) {
-   case DP_AUX_NATIVE_REPLY_ACK:
-   /* I2C-over-AUX Reply field is only valid
-* when paired with AUX ACK.
-*/
-   break;
-   case DP_AUX_NATIVE_REPLY_NACK:
-   DRM_DEBUG_KMS("aux_ch native nack\n");
-   return -EREMOTEIO;
-   case DP_AUX_NATIVE_REPLY_DEFER:
-   DRM_DEBUG_KMS("aux_ch native defer\n");
-   usleep_range(500, 600);
-   continue;
-   default:
-   DRM_ERROR("aux_ch invalid native reply 0x%02x\n", ack);
-   return -EREMOTEIO;
-   }
-
-   switch ((ack >> 4) & DP_AUX_I2C_REPLY_MASK) {
-   case DP_AUX_I2C_REPLY_ACK:
-   if (mode == MODE_I2C_READ)
-   *read_byte = reply[0];
-   return ret;
-   case DP_AUX_I2C_REPLY_NACK:
-   DRM_DEBUG_KMS("aux_i2c nack\n");
-   return -EREMOTEIO;
-   case DP_AUX_I2C_REPLY_DEFER:
-   DRM_DEBUG_KMS("aux_i2c defer\n");
-   usleep_range(400, 500);
-   break;
-   default:
-   DRM_ERROR("aux_i2c invalid reply 0x%02x\n", ack);
-   return -EREMOTEIO;
-   }
-   }
-
-   DRM_DEBUG_KMS("aux i2c too many retries, giving up\n");
-   return -EREMOTEIO;
+   WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n", ret);
 }

 /* general DP utility functions */
@@ -427,12 +344,11 @@ static u8 radeon_dp_encoder_service(struct radeon_device 
*rdev,

 u8 radeon_dp_getsinktype(struct radeon_connector *radeon_connector)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
struct drm_device *dev = 

[PATCH 3/4] drm/dp/i2c: Update comments about common i2c over dp assumptions

[Alex Deucher]

If you are using the common dp over i2c functionality, it is
asumed that the aux transfer function does not modify the any
of the msg structure other than the reply field.  Doing so
breaks the logic in the common code.

Signed-off-by: Alex Deucher 
Cc: Ville Syrj?l? 
Cc: Jani Nikula 
Cc: Thierry Reding 
Reviewed-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_dp_helper.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index dfe4cf4..948de4f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -577,7 +577,9 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
*adapter)

 /*
  * Transfer a single I2C-over-AUX message and handle various error conditions,
- * retrying the transaction as appropriate.
+ * retrying the transaction as appropriate.  It is assumed that the
+ * aux->transfer function does not modify anything in the msg other than the
+ * reply field.
  */
 static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
*msg)
 {
-- 
1.8.3.1

[PATCH 2/4] drm/dp/i2c: send bare addresses to properly reset i2c connections (v3)

[Alex Deucher]

We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions.  This mirrors what the existing dp i2c
over aux algo currently does.

This fixes EDID fetches on certain monitors especially with
dp bridges.

v2: update as per Ville's comments
- Set buffer to NULL for zero sized packets
- abort the entre transaction if one of the messages fails
v3: drop leftover debugging code

Signed-off-by: Alex Deucher 
Cc: Ville Syrj?l? 
Cc: Jani Nikula 
Cc: Thierry Reding 
Reviewed-by: Ville Syrj?l? 
---
 drivers/gpu/drm/drm_dp_helper.c | 52 +++--
 1 file changed, 29 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 74724aa..dfe4cf4 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -664,12 +664,23 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
   int num)
 {
struct drm_dp_aux *aux = adapter->algo_data;
-   unsigned int i, j;
+   unsigned int m, b;
+   struct drm_dp_aux_msg msg;
+   int err = 0;

-   for (i = 0; i < num; i++) {
-   struct drm_dp_aux_msg msg;
-   int err;
+   memset(, 0, sizeof(msg));

+   for (m = 0; m < num; m++) {
+   msg.address = msgs[m].addr;
+   msg.request = (msgs[m].flags & I2C_M_RD) ?
+   DP_AUX_I2C_READ :
+   DP_AUX_I2C_WRITE;
+   msg.request |= DP_AUX_I2C_MOT;
+   msg.buffer = NULL;
+   msg.size = 0;
+   err = drm_dp_i2c_do_msg(aux, );
+   if (err < 0)
+   break;
/*
 * Many hardware implementations support FIFOs larger than a
 * single byte, but it has been empirically determined that
@@ -677,31 +688,26 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
 * decreased performance. Therefore each message is simply
 * transferred byte-by-byte.
 */
-   for (j = 0; j < msgs[i].len; j++) {
-   memset(, 0, sizeof(msg));
-   msg.address = msgs[i].addr;
-
-   msg.request = (msgs[i].flags & I2C_M_RD) ?
-   DP_AUX_I2C_READ :
-   DP_AUX_I2C_WRITE;
-
-   /*
-* All messages except the last one are middle-of-
-* transfer messages.
-*/
-   if ((i < num - 1) || (j < msgs[i].len - 1))
-   msg.request |= DP_AUX_I2C_MOT;
-
-   msg.buffer = msgs[i].buf + j;
+   for (b = 0; b < msgs[m].len; b++) {
+   msg.buffer = msgs[m].buf + b;
msg.size = 1;

err = drm_dp_i2c_do_msg(aux, );
if (err < 0)
-   return err;
+   break;
}
+   if (err < 0)
+   break;
}
-
-   return num;
+   if (err >= 0)
+   err = num;
+   /* send a bare address packet to close out the connection */
+   msg.request &= ~DP_AUX_I2C_MOT;
+   msg.buffer = NULL;
+   msg.size = 0;
+   (void)drm_dp_i2c_do_msg(aux, );
+
+   return err;
 }

 static const struct i2c_algorithm drm_dp_i2c_algo = {
-- 
1.8.3.1

[PATCH 1/4] drm/radeon/dp: handle zero sized i2c over aux transactions

[Alex Deucher]

Needed for proper i2c over aux handling for certain
monitors and configurations (e.g., dp bridges or
adapters).

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8b0ab17..e914008 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -143,6 +143,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
 }

 #define HEADER_SIZE 4
+#define BARE_ADDRESS_SIZE 3

 static ssize_t
 radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
@@ -160,13 +161,16 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
tx_buf[0] = msg->address & 0xff;
tx_buf[1] = msg->address >> 8;
tx_buf[2] = msg->request << 4;
-   tx_buf[3] = msg->size - 1;
+   tx_buf[3] = msg->size ? (msg->size - 1) : 0;

switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
tx_size = HEADER_SIZE + msg->size;
-   tx_buf[3] |= tx_size << 4;
+   if (msg->size == 0)
+   tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
+   else
+   tx_buf[3] |= tx_size << 4;
memcpy(tx_buf + HEADER_SIZE, msg->buffer, msg->size);
ret = radeon_process_aux_ch(chan,
tx_buf, tx_size, NULL, 0, delay, 
);
@@ -177,7 +181,10 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
tx_size = HEADER_SIZE;
-   tx_buf[3] |= tx_size << 4;
+   if (msg->size == 0)
+   tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
+   else
+   tx_buf[3] |= tx_size << 4;
ret = radeon_process_aux_ch(chan,
tx_buf, tx_size, msg->buffer, 
msg->size, delay, );
break;
@@ -186,7 +193,7 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
break;
}

-   if (ret > 0)
+   if (ret >= 0)
msg->reply = ack >> 4;

return ret;
-- 
1.8.3.1

[PATCH 0/4] Reset i2c connection between xfers (v3)

[Alex Deucher]

V3 just drops a left over debug statement.

Alex Deucher (4):
  drm/radeon/dp: handle zero sized i2c over aux transactions
  drm/dp/i2c: send bare addresses to properly reset i2c connections (v3)
  drm/dp/i2c: Update comments about common i2c over dp assumptions
  drm/radeon/dp: switch to the common i2c over aux code

 drivers/gpu/drm/drm_dp_helper.c|  56 ++--
 drivers/gpu/drm/radeon/atombios_dp.c   | 132 ++---
 drivers/gpu/drm/radeon/radeon_connectors.c |  44 ++
 drivers/gpu/drm/radeon/radeon_display.c|  11 ++-
 drivers/gpu/drm/radeon/radeon_i2c.c|  60 +++--
 drivers/gpu/drm/radeon/radeon_mode.h   |  12 +--
 6 files changed, 87 insertions(+), 228 deletions(-)

-- 
1.8.3.1

[PATCH v2 1/7] drm/exynos: add super device support

[Tomasz Figa]

Hi Inki,

On 01.04.2014 14:37, Inki Dae wrote:
> This patch adds super device support to bind sub drivers
> using device tree.
>
> For this, you should add a super device node to each machine dt files
> like belows,
>
> In case of using MIPI-DSI,
>   display-subsystem {
>   compatible = "samsung,exynos-display-subsystem";
>   ports = <>, <>;
>   };
>
> In case of using DisplayPort,
>   display-subsystem {
>   compatible = "samsung,exynos-display-subsystem";
>   ports = <>, <>;
>   };
>
> In case of using Parallel panel,
>   display-subsystem {
>   compatible = "samsung,exynos-display-subsystem";
>   ports = <>;
>   };
>
> And if you don't add connector device node to ports property,
> default parallel panel driver, exynos_drm_dpi module, will be used.
>
> ports property can have the following device nodes,
>   fimd, mixer, Image Enhancer, MIPI-DSI, eDP, LVDS Bridge, or HDMI
>
> With this patch, we can resolve the probing order issue without
> some global lists. So this patch also removes the unnecessary lists and
> stuff related to these lists.

I can see several problems with this approach:

1) It breaks compatibility with existing DT. After this patch it is no 
longer possible to use old device trees and get a working DRM. However, 
in my opinion, this requirement can be relaxed if we make sure that any 
users are properly converted.

2) What happens if in Kconfig you disable a driver for a component that 
is listed in supernode? If I'm reading the code correctly, Exynos DRM 
will not register, which is completely wrong. Users should be able to 
select which drivers should be compiled into their kernels.

3) Such approach leads to complete integration of all Exynos DRM 
drivers, without possibility of loading some sub-drivers as modules. I 
know that current driver design doesn't support it either, but if this 
series is claimed to improve things, it should really do so.

4) Exactly the same can be achieved without changing the DT bindings at 
all. In fact even without adding any new single property or node to DT. 
We discussed this with Andrzej and Marek today and came to a solution in 
which just by adding a little bit of code to Exynos DRM subdrivers, you 
could guarantee correct registration of Exynos DRM platform and also get 
rid of #ifdeffery in exynos_drm_drv.c. Andrzej will send an RFC after 
the weekend.

5) This series seems to break DPI display support with runtime PM 
enabled. Universal C210 just hangs on second FIMD probe, after first one 
fails with probe deferral. This needs more investigation, though.

Best regards,
Tomasz

[Bug 77002] problems with kernel 3.14

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

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

--- Comment #8 from bgunteriv at gmail.com ---
Created attachment 96908
  --> https://bugs.freedesktop.org/attachment.cgi?id=96908=edit
xbmc trying to play video/audio files

Here is the last file of my original post as an attachment. i forgot to upload
this the first time.

Getting a lot of I/O errors in AlSA Sink.

-- 
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/20140404/bf30d214/attachment.html>

[Bug 77002] problems with kernel 3.14

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

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

--- Comment #7 from bgunteriv at gmail.com ---
Created attachment 96906
  --> https://bugs.freedesktop.org/attachment.cgi?id=96906=edit
good_dmesg-kernel 3.13.8

-- 
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/20140404/42f7548d/attachment.html>

[Bug 77002] problems with kernel 3.14

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

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

--- Comment #6 from bgunteriv at gmail.com ---
oh! my apologies, i guess i left that out.

i'm seeing choppy video, no audio at all.
audio files don't play.
using HDMI output. I have not tried S/PDIF
I'm using XBMC as my interface with minimal install of Ubuntu.

I would say regression.
all 3.13.x kernels work for me.
I've noticed this problem with the very first introduction of kernel 3.14.rc1

i'll attach a good dmesg. with my current kernel 3.13.8

-- 
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/20140404/de8af49f/attachment.html>

[Bug 76659] Display does not return from DPMS off using ATI drivers

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

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

--- Comment #7 from Tyler Brock  ---
Any thoughts Alex? I basically need to restart my computer almost every time
the screen turns off. I have no problem providing any help I could give you
guys in figuring this out.

-- 
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/20140404/95e8486c/attachment.html>

[Bug 77002] problems with kernel 3.14

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

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

--- Comment #5 from Alex Deucher  ---
What sort of issues are you having?  Display corruption?  gpu hangs?  system
hangs?  Is this a regression?  If so, when did it last work?

-- 
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/20140404/dd35e68a/attachment-0001.html>

[Bug 77002] problems with kernel 3.14

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

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

--- Comment #4 from bgunteriv at gmail.com ---
please let me know if you require some different information.

-- 
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/20140404/6e1704d7/attachment.html>

[GIT PULL] exynos-drm-next

[Inki Dae]

Hi Tomasz,

> -Original Message-
> From: Tomasz Figa [mailto:tomasz.figa at gmail.com]
> Sent: Friday, April 04, 2014 2:00 PM
> To: inki.dae at samsung.com; airlied at linux.ie; dri-
> devel at lists.freedesktop.org
> Subject: Re: [GIT PULL] exynos-drm-next
> 
> Hi Inki,
> 
> On 03.04.2014 19:34, inki.dae at samsung.com wrote:
> > Hi Dave,
> > Sorry for late.
> > This pull request includes MIPI-DSI driver, two panel drivers,
> > super device support, and relevant dt bindings.
> >
> > Summaries:
> > - Add MIPI-DSI Driver, and dt bindigs
> > - Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings
> > - Add LD9040 parallel panel driver
> >. this driver is placed in drivers/gpu/drm/panel, and it seems
> >  to be used for exynos drm as of now,
> > - Add super device support, and dt bindings
> >. this patch resolves the probe order issue to sub drivers
> >  without specific lists
> 
> I don't think the DT bindings have been Acked by DT maintainers, which is
> necessary to merge them.
> 
> Also I believe more discussion is needed on this, but I didn't have time
> to comment on this series yet. Please hold off with merging the supernode
> series yet.

I sent a email about review request to you but I didn't get any answer from
you. And I think super node concept was already accepted, and relevant
codes, component framework, has already been merged to mainline. And Linux
staging next has already such dt bindings. Please see imx dts files.

I hope this time this series would be merged to mainline so that we could go
to next step, integrating drm_panel and drm_bridge framework to one
integrated drm_bridge. So Can you hurry up to review it a bit? I'll wait for
your ack.

Thanks,
Inki Dae

> 
> Best regards,
> Tomasz

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #5 from Garrett  ---
Thanks for the patch.  As of this am, I now have local Openelec 4.0 code that
builds now and is affected.  Building it took overnight on an i5- full
OS/OE/XMBC/Kernel...  It will take some build time, so over this weekend I will
try to collect all of the data.  +/- patches.

-- 
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/20140404/f1d4d17f/attachment.html>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

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

--- Comment #12 from Alex Deucher  ---
Does disabling tiling help?  Add:
Option "ColorTiling" "False"
Option "ColorTiling2D" "False"
to the device section of your xorg.conf

-- 
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/20140404/0f403fb2/attachment.html>

[PATCH 4/4] drm/radeon/dp: switch to the common i2c over aux code

[Alex Deucher]

Provides a nice cleanup in radeon.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c   | 117 +
 drivers/gpu/drm/radeon/radeon_connectors.c |  44 ++-
 drivers/gpu/drm/radeon/radeon_display.c|  11 ++-
 drivers/gpu/drm/radeon/radeon_i2c.c|  60 ---
 drivers/gpu/drm/radeon/radeon_mode.h   |  12 +--
 5 files changed, 44 insertions(+), 200 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index e914008..d545769 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -201,98 +201,15 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)

 void radeon_dp_aux_init(struct radeon_connector *radeon_connector)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
-
-   dig_connector->dp_i2c_bus->aux.dev = radeon_connector->base.kdev;
-   dig_connector->dp_i2c_bus->aux.transfer = radeon_dp_aux_transfer;
-}
-
-int radeon_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
-u8 write_byte, u8 *read_byte)
-{
-   struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
-   struct radeon_i2c_chan *auxch = i2c_get_adapdata(adapter);
-   u16 address = algo_data->address;
-   u8 msg[5];
-   u8 reply[2];
-   unsigned retry;
-   int msg_bytes;
-   int reply_bytes = 1;
int ret;
-   u8 ack;
-
-   /* Set up the address */
-   msg[0] = address;
-   msg[1] = address >> 8;
-
-   /* Set up the command byte */
-   if (mode & MODE_I2C_READ) {
-   msg[2] = DP_AUX_I2C_READ << 4;
-   msg_bytes = 4;
-   msg[3] = msg_bytes << 4;
-   } else {
-   msg[2] = DP_AUX_I2C_WRITE << 4;
-   msg_bytes = 5;
-   msg[3] = msg_bytes << 4;
-   msg[4] = write_byte;
-   }

-   /* special handling for start/stop */
-   if (mode & (MODE_I2C_START | MODE_I2C_STOP))
-   msg[3] = 3 << 4;
-
-   /* Set MOT bit for all but stop */
-   if ((mode & MODE_I2C_STOP) == 0)
-   msg[2] |= DP_AUX_I2C_MOT << 4;
-
-   for (retry = 0; retry < 7; retry++) {
-   ret = radeon_process_aux_ch(auxch,
-   msg, msg_bytes, reply, reply_bytes, 
0, );
-   if (ret == -EBUSY)
-   continue;
-   else if (ret < 0) {
-   DRM_DEBUG_KMS("aux_ch failed %d\n", ret);
-   return ret;
-   }
+   radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
+   radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
+   ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus->aux);
+   if (!ret)
+   radeon_connector->ddc_bus->has_aux = true;

-   switch ((ack >> 4) & DP_AUX_NATIVE_REPLY_MASK) {
-   case DP_AUX_NATIVE_REPLY_ACK:
-   /* I2C-over-AUX Reply field is only valid
-* when paired with AUX ACK.
-*/
-   break;
-   case DP_AUX_NATIVE_REPLY_NACK:
-   DRM_DEBUG_KMS("aux_ch native nack\n");
-   return -EREMOTEIO;
-   case DP_AUX_NATIVE_REPLY_DEFER:
-   DRM_DEBUG_KMS("aux_ch native defer\n");
-   usleep_range(500, 600);
-   continue;
-   default:
-   DRM_ERROR("aux_ch invalid native reply 0x%02x\n", ack);
-   return -EREMOTEIO;
-   }
-
-   switch ((ack >> 4) & DP_AUX_I2C_REPLY_MASK) {
-   case DP_AUX_I2C_REPLY_ACK:
-   if (mode == MODE_I2C_READ)
-   *read_byte = reply[0];
-   return ret;
-   case DP_AUX_I2C_REPLY_NACK:
-   DRM_DEBUG_KMS("aux_i2c nack\n");
-   return -EREMOTEIO;
-   case DP_AUX_I2C_REPLY_DEFER:
-   DRM_DEBUG_KMS("aux_i2c defer\n");
-   usleep_range(400, 500);
-   break;
-   default:
-   DRM_ERROR("aux_i2c invalid reply 0x%02x\n", ack);
-   return -EREMOTEIO;
-   }
-   }
-
-   DRM_DEBUG_KMS("aux i2c too many retries, giving up\n");
-   return -EREMOTEIO;
+   WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n", ret);
 }

 /* general DP utility functions */
@@ -427,12 +344,11 @@ static u8 radeon_dp_encoder_service(struct radeon_device 
*rdev,

 u8 radeon_dp_getsinktype(struct radeon_connector *radeon_connector)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
struct drm_device *dev = 

[PATCH 3/4] drm/dp/i2c: Update comments about common i2c over dp assumptions

[Alex Deucher]

If you are using the common dp over i2c functionality, it is
asumed that the aux transfer function does not modify the any
of the msg structure other than the reply field.  Doing so
breaks the logic in the common code.

Signed-off-by: Alex Deucher 
Cc: Ville Syrj?l? 
Cc: Jani Nikula 
Cc: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 125f84d..7a8c091 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -577,7 +577,9 @@ static u32 drm_dp_i2c_functionality(struct i2c_adapter 
*adapter)

 /*
  * Transfer a single I2C-over-AUX message and handle various error conditions,
- * retrying the transaction as appropriate.
+ * retrying the transaction as appropriate.  It is assumed that the
+ * aux->transfer function does not modify anything in the msg other than the
+ * reply field.
  */
 static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg 
*msg)
 {
-- 
1.8.3.1

[PATCH 2/4] drm/dp/i2c: send bare addresses to properly reset i2c connections (v2)

[Alex Deucher]

We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions.  This mirrors what the existing dp i2c
over aux algo currently does.

This fixes EDID fetches on certain monitors especially with
dp bridges.

v2: update as per Ville's comments
- Set buffer to NULL for zero sized packets
- abort the entre transaction if one of the messages fails

Signed-off-by: Alex Deucher 
Cc: Ville Syrj?l? 
Cc: Jani Nikula 
Cc: Thierry Reding 
---
 drivers/gpu/drm/drm_dp_helper.c | 54 +++--
 1 file changed, 31 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 74724aa..125f84d 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -664,12 +664,25 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
   int num)
 {
struct drm_dp_aux *aux = adapter->algo_data;
-   unsigned int i, j;
+   unsigned int m, b;
+   struct drm_dp_aux_msg msg;
+   int err = 0;

-   for (i = 0; i < num; i++) {
-   struct drm_dp_aux_msg msg;
-   int err;
+   memset(, 0, sizeof(msg));

+   for (m = 0; m < num; m++) {
+   msg.address = msgs[m].addr;
+   msg.request = (msgs[m].flags & I2C_M_RD) ?
+   DP_AUX_I2C_READ :
+   DP_AUX_I2C_WRITE;
+   msg.request |= DP_AUX_I2C_MOT;
+   msg.buffer = NULL;
+   msg.size = 0;
+   err = drm_dp_i2c_do_msg(aux, );
+   if (err < 0) {
+   printk("error %d in bare address write\n", err);
+   break;
+   }
/*
 * Many hardware implementations support FIFOs larger than a
 * single byte, but it has been empirically determined that
@@ -677,31 +690,26 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
 * decreased performance. Therefore each message is simply
 * transferred byte-by-byte.
 */
-   for (j = 0; j < msgs[i].len; j++) {
-   memset(, 0, sizeof(msg));
-   msg.address = msgs[i].addr;
-
-   msg.request = (msgs[i].flags & I2C_M_RD) ?
-   DP_AUX_I2C_READ :
-   DP_AUX_I2C_WRITE;
-
-   /*
-* All messages except the last one are middle-of-
-* transfer messages.
-*/
-   if ((i < num - 1) || (j < msgs[i].len - 1))
-   msg.request |= DP_AUX_I2C_MOT;
-
-   msg.buffer = msgs[i].buf + j;
+   for (b = 0; b < msgs[m].len; b++) {
+   msg.buffer = msgs[m].buf + b;
msg.size = 1;

err = drm_dp_i2c_do_msg(aux, );
if (err < 0)
-   return err;
+   break;
}
+   if (err < 0)
+   break;
}
-
-   return num;
+   if (err >= 0)
+   err = num;
+   /* send a bare address packet to close out the connection */
+   msg.request &= ~DP_AUX_I2C_MOT;
+   msg.buffer = NULL;
+   msg.size = 0;
+   (void)drm_dp_i2c_do_msg(aux, );
+
+   return err;
 }

 static const struct i2c_algorithm drm_dp_i2c_algo = {
-- 
1.8.3.1

[PATCH 1/4] drm/radeon/dp: handle zero sized i2c over aux transactions

[Alex Deucher]

Needed for proper i2c over aux handling for certain
monitors and configurations (e.g., dp bridges or
adapters).

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8b0ab17..e914008 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -143,6 +143,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
 }

 #define HEADER_SIZE 4
+#define BARE_ADDRESS_SIZE 3

 static ssize_t
 radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
@@ -160,13 +161,16 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
tx_buf[0] = msg->address & 0xff;
tx_buf[1] = msg->address >> 8;
tx_buf[2] = msg->request << 4;
-   tx_buf[3] = msg->size - 1;
+   tx_buf[3] = msg->size ? (msg->size - 1) : 0;

switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
tx_size = HEADER_SIZE + msg->size;
-   tx_buf[3] |= tx_size << 4;
+   if (msg->size == 0)
+   tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
+   else
+   tx_buf[3] |= tx_size << 4;
memcpy(tx_buf + HEADER_SIZE, msg->buffer, msg->size);
ret = radeon_process_aux_ch(chan,
tx_buf, tx_size, NULL, 0, delay, 
);
@@ -177,7 +181,10 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
tx_size = HEADER_SIZE;
-   tx_buf[3] |= tx_size << 4;
+   if (msg->size == 0)
+   tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
+   else
+   tx_buf[3] |= tx_size << 4;
ret = radeon_process_aux_ch(chan,
tx_buf, tx_size, msg->buffer, 
msg->size, delay, );
break;
@@ -186,7 +193,7 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
break;
}

-   if (ret > 0)
+   if (ret >= 0)
msg->reply = ack >> 4;

return ret;
-- 
1.8.3.1

[PATCH 0/4] Reset i2c connection between xfers (v2)

[Alex Deucher]

I think this set should address the remaining concerns
raised by Ville.

Alex Deucher (4):
  drm/radeon/dp: handle zero sized i2c over aux transactions
  drm/dp/i2c: send bare addresses to properly reset i2c connections (v2)
  drm/dp/i2c: Update comments about common i2c over dp assumptions
  drm/radeon/dp: switch to the common i2c over aux code

 drivers/gpu/drm/drm_dp_helper.c|  58 +++--
 drivers/gpu/drm/radeon/atombios_dp.c   | 132 ++---
 drivers/gpu/drm/radeon/radeon_connectors.c |  44 ++
 drivers/gpu/drm/radeon/radeon_display.c|  11 ++-
 drivers/gpu/drm/radeon/radeon_i2c.c|  60 +++--
 drivers/gpu/drm/radeon/radeon_mode.h   |  12 +--
 6 files changed, 89 insertions(+), 228 deletions(-)

-- 
1.8.3.1

[PATCH] drm/dp_helper: don't return EPROTO for defers (v2)

[Jani Nikula]

On Fri, 04 Apr 2014, Dave Airlie  wrote:
> From: Dave Airlie 
>
> If we get a msg.reply of REPLY_DEFER, we also get an err of 0
> so we fail reads with 0 < size and return -EPROTO instead of trying
> again.
>
> v2: same fix in i2c code.
>
> Found writing MST support.
>

Reviewed-by: Jani Nikula 

> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f4babed..2767148 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -386,11 +386,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, 
> u8 request,
>   return err;
>   }
>  
> - if (err < size)
> - return -EPROTO;
>  
>   switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
>   case DP_AUX_NATIVE_REPLY_ACK:
> + if (err < size)
> + return -EPROTO;
>   return err;
>  
>   case DP_AUX_NATIVE_REPLY_NACK:
> @@ -599,8 +599,6 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>   return err;
>   }
>  
> - if (err < msg->size)
> - return -EPROTO;
>  
>   switch (msg->reply & DP_AUX_NATIVE_REPLY_MASK) {
>   case DP_AUX_NATIVE_REPLY_ACK:
> @@ -639,6 +637,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, 
> struct drm_dp_aux_msg *msg)
>* Both native ACK and I2C ACK replies received. We
>* can assume the transfer was successful.
>*/
> + if (err < msg->size)
> + return -EPROTO;
>   return 0;
>  
>   case DP_AUX_I2C_REPLY_NACK:
> -- 
> 1.8.5.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

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

--- Comment #11 from benjamin.menant+debian at gmail.com ---
Oups, sorry? Indeed, you are right Alex, this board has 1 GB
<http://www.club-3d.com/index.php/products/reader.en/product/radeon-hd-6570-coolstream-edition.html>

Thanks again for the clever explainations.

Thus, it was my last guess? Is there anything else I can do to find the origin
of this issue?

Sincerely,
Benjamin.

-- 
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/20140404/c85e88be/attachment.html>

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

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

--- Comment #10 from Alex Deucher  ---
(In reply to comment #9)
> The dmesg output reveals these lines:
> 
> > [5.343548] radeon :05:00.0: VRAM: 1024M 0x - 
> > 0x3FFF (1024M used)
> > [5.343550] radeon :05:00.0: GTT: 1024M 0x4000 - 
> > 0x7FFF
> > [5.343552] [drm] Detected VRAM RAM=1024M, BAR=256M
> 
> 1G VRAM seems to be a wrong value, since my graphic card holds only 256MB,
> which seems to be seeing as BAR (what?s that stuff?). 
> 
> Anyway, could it be the cause of my problem?

Your board has 1 GB of vram.  The max BAR size is 256 MB regardless of how much
video ram is actually on the card.  The BAR is the CPU's aperture to vram.  The
CPU can only access teh first 256 MB of vram, but the GPU can access the entire
amount of vram.

-- 
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/20140404/6efbc992/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

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

Alex Deucher  changed:

   What|Removed |Added

 CC||djtm at gmx.net

--- Comment #26 from Alex Deucher  ---
*** Bug 73882 has been marked as a duplicate of this bug. ***

-- 
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/20140404/3cb7f35c/attachment.html>

Synchronization between a crtc mode_set and page_flip?

[Archit Taneja]

On Friday 04 April 2014 02:54 AM, Daniel Vetter wrote:
> On Thu, Apr 03, 2014 at 02:28:32PM +0530, Archit Taneja wrote:
>> On Wednesday 02 April 2014 06:41 PM, Rob Clark wrote:
>>> On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja  wrote:
 Hi,

 I was trying to figure out how we are supposed to manage synchronization
 between a mode_set and a page_flip called on a crtc.

 Say, if a mode_set is immediately followed by a page_flip. The driver can't
 process the page_flip straight away since the hardware is still completing
 the mode_set.
>>>
>>> I guess setcrtc is expected to be synchronous(ish).. so a lot of
>>> userspace won't expect the first pageflip to fail with -EBUSY.
>>
>> Okay, thanks. I guess having setcrtc synchronous isn't that bad.
>
> Yeah, atm I think the rules are that pageflip can only return -EBUSY if
> there's still a pageflip ongoing. Everything else is presumed to be at
> least implicitly ordered, so if your hw can do async modesets then you
> need to synchronize. Also if there's still a pageflip outstanding you need
> to wait for that to complete in your set_config callback first (usually in
> the set_base or the crtc->disable/prepare hooks when using the crtc
> helpers).

Thanks for the info. I didn't realize that the prepare/commit hooks get 
executed when using drm_crtc_helper_set_mode() for the set_config helper.

Rob,

We disable the crtc in prepare, and enable it in commit.

If setcrtc changes the mode,  I don't see how apply worker can execute 
prepare() -> mode_set() -> commit() hooks in a row for the crtc 
drm_crtc_helper_set_mode(). We can't queue more than one 'apply' of the 
same entity. So the latter queues are bound to get rejected, I see 
omap_crtc_apply() bailing out for crtc's apply in this case.

I guess making prepare() and mode_set() wait for a vsync should fix 
this. Or, combining mode_set and commit as a single queue to apply 
should work too. Any suggestions?

Thanks,
Archit

[RESEND][GIT PULL] exynos-drm-next

[Inki Dae]

Hi Dave,

   I am re-sending git-pull request with fixing module build errors.

For this, I reverted one patch, and added two patches below,
- Revert 'drm/exynos: register platform driver at each kms sub drivers'
  . Exynos drm should be built as single module,
so platform_driver_register of each sub driver should be called
at exynos_drm_drv module.
- Remove MODULE_DEVICE_TABLE definition of DP and MIPI-DSI drivers.
- Export ptn3460_init function so that other modules can call this funtion.


If there is any problem, please kindly let me know,

Thanks,
Inki Dae


The following changes since commit 2844ea3f252331cc0ecf3ae74f6226db2f580f8a:

  Merge branch 'primary-plane' of git://people.freedesktop.org/~robclark/linux 
into drm-next (2014-04-02 12:09:09 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos 
exynos-drm-next

for you to fetch changes up to 0c64ef98ac2c49452d4e269132c0474871a1fd93:

  drm/bridge: export ptn3460_init function (2014-04-04 12:14:51 +0900)


Andrzej Hajda (16):
  drm/mipi_dsi: add flags to DSI messages
  drm/mipi_dsi: create dsi devices only for nodes with reg property
  drm/exynos: disallow fbdev initialization if no device is connected
  exynos/dsim: add DT bindings
  drm/exynos: add DSIM driver
  panel/s6e8aa0: add DT bindings
  panel/ld9040: add DT bindings
  drm/panel: add ld9040 driver
  ARM: dts: exynos4210-universal_c210: add proper panel node
  drm/panel: add S6E8AA0 driver
  ARM: dts: exynos4: add MIPI DSI Master node
  ARM: dts: exynos4210-trats: add panel node
  ARM: dts: exynos4412-trats2: add panel node
  ARM: dts: exynos4210-trats: enable exynos/fimd node
  ARM: dts: exynos4412-trats2: enable exynos/fimd node
  drm/exynos: separate dpi from fimd

Inki Dae (8):
  drm/exynos: add super device support
  drm/exynos: dpi: fix hotplug fail issue
  ARM: dts: exynos4210-universal: add super device node for exynos drm
  ARM: dts: exynos4210-trats: add super device node for exynos drm
  ARM: dts: exynos4412-trats2: add super device node for exynos drm
  exynos/drm: add DT bindings
  drm/exynos: remove MODULE_DEVICE_TABLE definitions
  drm/bridge: export ptn3460_init function

 .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 +
 .../devicetree/bindings/panel/samsung,ld9040.txt   |   66 +
 .../devicetree/bindings/panel/samsung,s6e8aa0.txt  |   56 +
 .../devicetree/bindings/video/exynos_dsim.txt  |   80 +
 arch/arm/boot/dts/exynos4.dtsi |   14 +
 arch/arm/boot/dts/exynos4210-trats.dts |   66 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts|   76 +-
 arch/arm/boot/dts/exynos4412-trats2.dts|   75 +
 drivers/gpu/drm/bridge/ptn3460.c   |1 +
 drivers/gpu/drm/drm_mipi_dsi.c |6 +-
 drivers/gpu/drm/exynos/Kconfig |9 +
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|   46 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c   |  216 +--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   17 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |4 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c|   51 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  217 +--
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   65 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1556 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   21 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   74 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |   61 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   59 +-
 drivers/gpu/drm/exynos/exynos_mixer.c  |   54 +-
 drivers/gpu/drm/panel/Kconfig  |   14 +
 drivers/gpu/drm/panel/Makefile |2 +
 drivers/gpu/drm/panel/panel-ld9040.c   |  376 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1069 ++
 include/drm/drm_mipi_dsi.h |6 +
 30 files changed, 3944 insertions(+), 446 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,ld9040.txt
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
 create mode 100644 drivers/gpu/drm/panel/panel-ld9040.c
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #4 from Christian K?nig  ---
(In reply to comment #2)
> Hi Christian. Thanks for your help.  They are not 100% the same.  I hope
> that I am not misleading you.  My, aplogies in advance, if it works out to
> be so.

No problem at all. It's still quite likely that my patch is the source of the
problem.

> xorg3.15, Kernel 3.13.7 vs. 3.14

We should just make sure that it is indeed the only change in the system and we
don't have an issue like two patches affecting each other or something like
that.

Beeing based on kernel 3.13.7 vs. 3.14 for the two versions sounds like we
should make that sure first.

> Tonight I will make a new build environment to test PURELY the
> patch/un-patch.  I am a bit new to building kernel Dri/Drm modules.  But I
> should be able to figure it out.

Let me know if you need any help.

> It might be that my LCD does not like 23.98?  Thanks.  I will post back with
> the results.
Might be, but I would rather guess that the PLL isn't stable enough any more
with my changes.

When the values get higher you usually get better matching results, but the
electrical signal also gets more unstable. Your LCD is probably just a bit
picky what signal it gets as input.

I've attached a patch that artifically limits the dividers and so might produce
better results. Please try it and report back if that changes anything.

-- 
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/20140404/e7a3ea18/attachment-0001.html>

[Bug 76998] hang on CEDAR right after log on

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

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

--- Comment #4 from tcl_de at gmx.net ---
I did a small "bisection" and installed the 3.9.0-030900-generic,
3.10.0-031000-generic and 3.14.0-031400-generic kernels from the Ubuntu
MainlineBuilds.

3.9 works, 3.10 and 3.14 hang.

The attached logs are for the 3.9 kernel.

I'm sorry, I prefer not to do a git bisect because I can only spend a limited
amount of time on this bug.

-- 
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/20140404/b0017711/attachment.html>

[Bug 77009] 24P playback video signal loss with latest DRI patches

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

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

--- Comment #3 from Christian K?nig  ---
Created attachment 96900
  --> https://bugs.freedesktop.org/attachment.cgi?id=96900=edit
Possible fix.

-- 
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/20140404/618073f5/attachment.html>

[Bug 76998] hang on CEDAR right after log on

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

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

--- Comment #3 from tcl_de at gmx.net ---
Created attachment 96898
  --> https://bugs.freedesktop.org/attachment.cgi?id=96898=edit
dmesg

-- 
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/20140404/51cec1fa/attachment.html>

[Bug 76998] hang on CEDAR right after log on

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

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

--- Comment #2 from tcl_de at gmx.net ---
Created attachment 96897
  --> https://bugs.freedesktop.org/attachment.cgi?id=96897=edit
Xorg log

-- 
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/20140404/d7a3eeb2/attachment.html>

[PATCH] drm/dp_helper: don't return EPROTO for defers

[Dave Airlie]

From: Dave Airlie 

If we get a msg.reply of REPLY_DEFER, we also get an err of 0
so we fail reads with 0 < size and return -EPROTO instead of trying
again.

Found writing MST support.

Signed-off-by: Dave Airlie 
---
 drivers/gpu/drm/drm_dp_helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f4babed..725354f 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -386,11 +386,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 
request,
return err;
}

-   if (err < size)
-   return -EPROTO;

switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
case DP_AUX_NATIVE_REPLY_ACK:
+   if (err < size)
+   return -EPROTO;
return err;

case DP_AUX_NATIVE_REPLY_NACK:
-- 
1.8.5.3

[PATCH] gpu: host1x: handle the correct # of syncpt regs

[Thierry Reding]

On Thu, Apr 03, 2014 at 11:09:22AM +0300, Terje Bergstr?m wrote:
> On 01.04.2014 23:10, Stephen Warren wrote:
> > diff --git a/drivers/gpu/host1x/hw/intr_hw.c 
> > b/drivers/gpu/host1x/hw/intr_hw.c
> > index db9017adfe2b..17407b2de2bf 100644
> > --- a/drivers/gpu/host1x/hw/intr_hw.c
> > +++ b/drivers/gpu/host1x/hw/intr_hw.c
> > @@ -47,7 +47,7 @@ static irqreturn_t syncpt_thresh_isr(int irq, void 
> > *dev_id)
> > unsigned long reg;
> > int i, id;
> >  
> > -   for (i = 0; i <= BIT_WORD(host->info->nb_pts); i++) {
> > +   for (i = 0; i < BITS_TO_LONGS(host->info->nb_pts); i++) {
> > reg = host1x_sync_readl(host,
> > HOST1X_SYNC_SYNCPT_THRESH_CPU0_INT_STATUS(i));
> > for_each_set_bit(id, , BITS_PER_LONG) {
> > @@ -64,7 +64,7 @@ static void _host1x_intr_disable_all_syncpt_intrs(struct 
> > host1x *host)
> >  {
> > u32 i;
> >  
> > -   for (i = 0; i <= BIT_WORD(host->info->nb_pts); ++i) {
> > +   for (i = 0; i < BITS_TO_LONGS(host->info->nb_pts); ++i) {
> > host1x_sync_writel(host, 0xu,
> > HOST1X_SYNC_SYNCPT_THRESH_INT_DISABLE(i));
> > host1x_sync_writel(host, 0xu,
> > 
> 
> Wouldn't this break in architectures with 64-bit longs?

Well, BIT_WORD() relies on BITS_PER_LONG too, so the current code is
broken for 64-bit architectures too.

> Probably the safest way would be to use DIV_ROUND_UP(host->info->nb_pts, 32),
> because we know there are 32 bits in each host1x register.

I agree. I hope there aren't any plans on making the registers 64 bits
wide in the future. Although they'd probably still be accessible as 32
bit values even then.

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

[PATCH 3/3] drm/radeon/dp: switch to the common i2c over aux code

[Alex Deucher]

Provides a nice cleanup in radeon.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c   | 117 +
 drivers/gpu/drm/radeon/radeon_connectors.c |  44 ++-
 drivers/gpu/drm/radeon/radeon_display.c|  11 ++-
 drivers/gpu/drm/radeon/radeon_i2c.c|  60 ---
 drivers/gpu/drm/radeon/radeon_mode.h   |  12 +--
 5 files changed, 44 insertions(+), 200 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index e914008..d545769 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -201,98 +201,15 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)

 void radeon_dp_aux_init(struct radeon_connector *radeon_connector)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
-
-   dig_connector->dp_i2c_bus->aux.dev = radeon_connector->base.kdev;
-   dig_connector->dp_i2c_bus->aux.transfer = radeon_dp_aux_transfer;
-}
-
-int radeon_dp_i2c_aux_ch(struct i2c_adapter *adapter, int mode,
-u8 write_byte, u8 *read_byte)
-{
-   struct i2c_algo_dp_aux_data *algo_data = adapter->algo_data;
-   struct radeon_i2c_chan *auxch = i2c_get_adapdata(adapter);
-   u16 address = algo_data->address;
-   u8 msg[5];
-   u8 reply[2];
-   unsigned retry;
-   int msg_bytes;
-   int reply_bytes = 1;
int ret;
-   u8 ack;
-
-   /* Set up the address */
-   msg[0] = address;
-   msg[1] = address >> 8;
-
-   /* Set up the command byte */
-   if (mode & MODE_I2C_READ) {
-   msg[2] = DP_AUX_I2C_READ << 4;
-   msg_bytes = 4;
-   msg[3] = msg_bytes << 4;
-   } else {
-   msg[2] = DP_AUX_I2C_WRITE << 4;
-   msg_bytes = 5;
-   msg[3] = msg_bytes << 4;
-   msg[4] = write_byte;
-   }

-   /* special handling for start/stop */
-   if (mode & (MODE_I2C_START | MODE_I2C_STOP))
-   msg[3] = 3 << 4;
-
-   /* Set MOT bit for all but stop */
-   if ((mode & MODE_I2C_STOP) == 0)
-   msg[2] |= DP_AUX_I2C_MOT << 4;
-
-   for (retry = 0; retry < 7; retry++) {
-   ret = radeon_process_aux_ch(auxch,
-   msg, msg_bytes, reply, reply_bytes, 
0, );
-   if (ret == -EBUSY)
-   continue;
-   else if (ret < 0) {
-   DRM_DEBUG_KMS("aux_ch failed %d\n", ret);
-   return ret;
-   }
+   radeon_connector->ddc_bus->aux.dev = radeon_connector->base.kdev;
+   radeon_connector->ddc_bus->aux.transfer = radeon_dp_aux_transfer;
+   ret = drm_dp_aux_register_i2c_bus(_connector->ddc_bus->aux);
+   if (!ret)
+   radeon_connector->ddc_bus->has_aux = true;

-   switch ((ack >> 4) & DP_AUX_NATIVE_REPLY_MASK) {
-   case DP_AUX_NATIVE_REPLY_ACK:
-   /* I2C-over-AUX Reply field is only valid
-* when paired with AUX ACK.
-*/
-   break;
-   case DP_AUX_NATIVE_REPLY_NACK:
-   DRM_DEBUG_KMS("aux_ch native nack\n");
-   return -EREMOTEIO;
-   case DP_AUX_NATIVE_REPLY_DEFER:
-   DRM_DEBUG_KMS("aux_ch native defer\n");
-   usleep_range(500, 600);
-   continue;
-   default:
-   DRM_ERROR("aux_ch invalid native reply 0x%02x\n", ack);
-   return -EREMOTEIO;
-   }
-
-   switch ((ack >> 4) & DP_AUX_I2C_REPLY_MASK) {
-   case DP_AUX_I2C_REPLY_ACK:
-   if (mode == MODE_I2C_READ)
-   *read_byte = reply[0];
-   return ret;
-   case DP_AUX_I2C_REPLY_NACK:
-   DRM_DEBUG_KMS("aux_i2c nack\n");
-   return -EREMOTEIO;
-   case DP_AUX_I2C_REPLY_DEFER:
-   DRM_DEBUG_KMS("aux_i2c defer\n");
-   usleep_range(400, 500);
-   break;
-   default:
-   DRM_ERROR("aux_i2c invalid reply 0x%02x\n", ack);
-   return -EREMOTEIO;
-   }
-   }
-
-   DRM_DEBUG_KMS("aux i2c too many retries, giving up\n");
-   return -EREMOTEIO;
+   WARN(ret, "drm_dp_aux_register_i2c_bus() failed with error %d\n", ret);
 }

 /* general DP utility functions */
@@ -427,12 +344,11 @@ static u8 radeon_dp_encoder_service(struct radeon_device 
*rdev,

 u8 radeon_dp_getsinktype(struct radeon_connector *radeon_connector)
 {
-   struct radeon_connector_atom_dig *dig_connector = 
radeon_connector->con_priv;
struct drm_device *dev = 

[PATCH 2/3] drm/dp/i2c: send bare addresses to properly reset i2c connections

[Alex Deucher]

We need bare address packets at the start and end of
each i2c over aux transaction to properly reset the connection
between transactions.  This mirrors what the existing dp i2c
over aux algo currently does.

This fixes EDID fetches on certain monitors especially with
dp bridges.

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/drm_dp_helper.c | 53 +++--
 1 file changed, 30 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index f4babed..f0c2850 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -664,12 +664,26 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
   int num)
 {
struct drm_dp_aux *aux = adapter->algo_data;
-   unsigned int i, j;
+   unsigned int m, b;
+   struct drm_dp_aux_msg msg;
+   int err = 0;
+   u8 buf = 0;

-   for (i = 0; i < num; i++) {
-   struct drm_dp_aux_msg msg;
-   int err;
+   memset(, 0, sizeof(msg));

+   for (m = 0; m < num; m++) {
+   msg.address = msgs[m].addr;
+   msg.request = (msgs[m].flags & I2C_M_RD) ?
+   DP_AUX_I2C_READ :
+   DP_AUX_I2C_WRITE;
+   msg.request |= DP_AUX_I2C_MOT;
+   msg.buffer = 
+   msg.size = 0;
+   err = drm_dp_i2c_do_msg(aux, );
+   if (err < 0) {
+   printk("error %d in bare address write\n", err);
+   break;
+   }
/*
 * Many hardware implementations support FIFOs larger than a
 * single byte, but it has been empirically determined that
@@ -677,31 +691,24 @@ static int drm_dp_i2c_xfer(struct i2c_adapter *adapter, 
struct i2c_msg *msgs,
 * decreased performance. Therefore each message is simply
 * transferred byte-by-byte.
 */
-   for (j = 0; j < msgs[i].len; j++) {
-   memset(, 0, sizeof(msg));
-   msg.address = msgs[i].addr;
-
-   msg.request = (msgs[i].flags & I2C_M_RD) ?
-   DP_AUX_I2C_READ :
-   DP_AUX_I2C_WRITE;
-
-   /*
-* All messages except the last one are middle-of-
-* transfer messages.
-*/
-   if ((i < num - 1) || (j < msgs[i].len - 1))
-   msg.request |= DP_AUX_I2C_MOT;
-
-   msg.buffer = msgs[i].buf + j;
+   for (b = 0; b < msgs[m].len; b++) {
+   msg.buffer = msgs[m].buf + b;
msg.size = 1;

err = drm_dp_i2c_do_msg(aux, );
if (err < 0)
-   return err;
+   break;
}
}
-
-   return num;
+   if (err >= 0)
+   err = num;
+   /* send a bare address packet to close out the connection */
+   msg.request &= ~DP_AUX_I2C_MOT;
+   msg.buffer = 
+   msg.size = 0;
+   (void)drm_dp_i2c_do_msg(aux, );
+
+   return err;
 }

 static const struct i2c_algorithm drm_dp_i2c_algo = {
-- 
1.8.3.1

[PATCH 1/3] drm/radeon/dp: handle zero sized i2c over aux transactions

[Alex Deucher]

Needed for proper i2c over aux handling for certain
monitors and configurations (e.g., dp bridges or
adapters).

Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/radeon/atombios_dp.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 8b0ab17..e914008 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -143,6 +143,7 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan 
*chan,
 }

 #define HEADER_SIZE 4
+#define BARE_ADDRESS_SIZE 3

 static ssize_t
 radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
@@ -160,13 +161,16 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
tx_buf[0] = msg->address & 0xff;
tx_buf[1] = msg->address >> 8;
tx_buf[2] = msg->request << 4;
-   tx_buf[3] = msg->size - 1;
+   tx_buf[3] = msg->size ? (msg->size - 1) : 0;

switch (msg->request & ~DP_AUX_I2C_MOT) {
case DP_AUX_NATIVE_WRITE:
case DP_AUX_I2C_WRITE:
tx_size = HEADER_SIZE + msg->size;
-   tx_buf[3] |= tx_size << 4;
+   if (msg->size == 0)
+   tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
+   else
+   tx_buf[3] |= tx_size << 4;
memcpy(tx_buf + HEADER_SIZE, msg->buffer, msg->size);
ret = radeon_process_aux_ch(chan,
tx_buf, tx_size, NULL, 0, delay, 
);
@@ -177,7 +181,10 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
case DP_AUX_NATIVE_READ:
case DP_AUX_I2C_READ:
tx_size = HEADER_SIZE;
-   tx_buf[3] |= tx_size << 4;
+   if (msg->size == 0)
+   tx_buf[3] |= BARE_ADDRESS_SIZE << 4;
+   else
+   tx_buf[3] |= tx_size << 4;
ret = radeon_process_aux_ch(chan,
tx_buf, tx_size, msg->buffer, 
msg->size, delay, );
break;
@@ -186,7 +193,7 @@ radeon_dp_aux_transfer(struct drm_dp_aux *aux, struct 
drm_dp_aux_msg *msg)
break;
}

-   if (ret > 0)
+   if (ret >= 0)
msg->reply = ack >> 4;

return ret;
-- 
1.8.3.1

[PATCH 0/3] Reset i2c connection between xfers

[Alex Deucher]

When switching to the new common i2c over aux code,
I ran into problems fetching the EDID on certain DP monitors.
I tracked this down to the lack of bare address packets being
sent between i2c transfers.  This patch set adds that functionality
which brings it back inline with the old drm dpm i2c algo.

Originally, I added flags to note a bare address packet, but after
review switched to sending a zero sized packet instead. Note that I'm
not sure the other drivers that use these helpers currently handle
zero sized packets properly.  I had to fix up radeon to do so.

Alex Deucher (3):
  drm/radeon/dp: handle zero sized i2c over aux transactions
  drm/dp/i2c: send bare addresses to properly reset i2c connections
  drm/radeon/dp: switch to the common i2c over aux code

 drivers/gpu/drm/drm_dp_helper.c|  53 +++-
 drivers/gpu/drm/radeon/atombios_dp.c   | 132 ++---
 drivers/gpu/drm/radeon/radeon_connectors.c |  44 ++
 drivers/gpu/drm/radeon/radeon_display.c|  11 ++-
 drivers/gpu/drm/radeon/radeon_i2c.c|  60 +++--
 drivers/gpu/drm/radeon/radeon_mode.h   |  12 +--
 6 files changed, 85 insertions(+), 227 deletions(-)

-- 
1.8.3.1

[Bug 76957] Pixel artifacts and corruption plus system freeze and instabilities with the free radeon driver (AMD HD 6570)

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

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

--- Comment #9 from benjamin.menant+debian at gmail.com ---
The dmesg output reveals these lines:

> [5.343548] radeon :05:00.0: VRAM: 1024M 0x - 
> 0x3FFF (1024M used)
> [5.343550] radeon :05:00.0: GTT: 1024M 0x4000 - 
> 0x7FFF
> [5.343552] [drm] Detected VRAM RAM=1024M, BAR=256M

1G VRAM seems to be a wrong value, since my graphic card holds only 256MB,
which seems to be seeing as BAR (what?s that stuff?). 

Anyway, could it be the cause of my problem?

Thank you,
Benjamin.

-- 
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/20140404/37d2109c/attachment.html>

[PATCH] modetest: consider supported formats before selecting a DRM plane

[Rob Clark]

On Fri, Mar 28, 2014 at 6:15 AM, Fabien DESSENNE  
wrote:
> This fixes an issue where the DRM planes do not support the same pixel
> formats.
> The current implementation selects a DRM plane without checking whether
> the pixel format is supported or not. As a consequence modetest may try
> to set up a plane not supporting the user request-format, which fails.
> Modetest has to check the supported formats accross the plane list before
> selecting a candidate.
>
> Signed-off-by: Fabien Dessenne 

Looks reasonable.  I suppose one drawback is that you could previously
use modetest to test an error condition.  I'm not sure if anyone cares
about that.. having a proper collection of tests for generic KMS APIs
would of course be a better solution to that problem ;-)

It could be a useful thing for linaro to look into intel-gpu-tools and
see if it could be possible to refactor some of that into some
cross-driver tests ;-)

BR,
-R

> ---
>  tests/modetest/modetest.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index 4761c60..866ea82 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -951,7 +951,7 @@ static int set_plane(struct device *dev, struct plane_arg 
> *p)
> int crtc_x, crtc_y, crtc_w, crtc_h;
> struct crtc *crtc = NULL;
> unsigned int pipe;
> -   unsigned int i;
> +   unsigned int i, j;
>
> /* Find an unused plane which can be connected to our CRTC. Find the
>  * CRTC index first, then iterate over available planes.
> @@ -974,8 +974,11 @@ static int set_plane(struct device *dev, struct 
> plane_arg *p)
> if (!ovr)
> continue;
>
> -   if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id)
> -   plane_id = ovr->plane_id;
> +   if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id) {
> +   for (j = 0; j < ovr->count_formats; j++)
> +   if (!strncmp(p->format_str, (char *) 
> >formats[j], 4))
> +   plane_id = ovr->plane_id;
> +   }
> }
>
> if (!plane_id) {
> --
> 1.9.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] drm/dp: add flags field to drm_dp_aux_msg struct

[Alex Deucher]

On Fri, Apr 4, 2014 at 2:09 AM, Jani Nikula  
wrote:
> On Sat, 22 Mar 2014, Alex Deucher  wrote:
>> This adds a flags field and a new flag, BARE_ADDRESS,
>> which drivers can use for special handling when they
>> want to set just the aux address.  This is needed
>> to properly reset the connection between i2c transactions.
>
> Sorry it took me so long to get to this.
>
> The changes in patches 1-3 look sensible in general, but I think I'd
> prefer you dropped the flags field and used size == 0 to mean bare
> address. It feels silly to have to set size = 1 and have a dummy one
> byte buffer that doesn't get transfered. Without the payload I think it
> feels natural only the address is transfered.

Thanks.  I'll resend with size = 0.  Note that it doesn't look like
the current intel dp code handles zero sized transfers so that will
need to be fixed up.

Alex


>
> BR,
> Jani.
>
>
>>
>> Signed-off-by: Alex Deucher 
>> ---
>>  include/drm/drm_dp_helper.h | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
>> index b7488c9..a006e96 100644
>> --- a/include/drm/drm_dp_helper.h
>> +++ b/include/drm/drm_dp_helper.h
>> @@ -403,6 +403,8 @@ drm_dp_enhanced_frame_cap(const u8 
>> dpcd[DP_RECEIVER_CAP_SIZE])
>>   * DisplayPort AUX channel
>>   */
>>
>> +#define DRM_DP_AUX_MSG_FLAGS_BARE_ADDRESS (1 << 0)
>> +
>>  /**
>>   * struct drm_dp_aux_msg - DisplayPort AUX channel transaction
>>   * @address: address of the (first) register to access
>> @@ -417,6 +419,7 @@ struct drm_dp_aux_msg {
>>   u8 reply;
>>   void *buffer;
>>   size_t size;
>> + u32 flags;
>>  };
>>
>>  /**
>> --
>> 1.8.3.1
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Technology Center

[GIT PULL] exynos-drm-next

[Tomasz Figa]

On 04.04.2014 09:48, Inki Dae wrote:
>
>
>> -Original Message-
>> From: Tomasz Figa [mailto:t.figa at samsung.com]
>> Sent: Friday, April 04, 2014 4:29 PM
>> To: Inki Dae; 'Tomasz Figa'; airlied at linux.ie; dri-
>> devel at lists.freedesktop.org; 'Marek Szyprowski';
>> devicetree at vger.kernel.org; Grant Likely; Rob Herring
>> Subject: Re: [GIT PULL] exynos-drm-next
>>
>> On 04.04.2014 07:34, Inki Dae wrote:
>>> Hi Tomasz,
>>>
 -Original Message-
 From: Tomasz Figa [mailto:tomasz.figa at gmail.com]
 Sent: Friday, April 04, 2014 2:00 PM
 To: inki.dae at samsung.com; airlied at linux.ie; dri-
 devel at lists.freedesktop.org
 Subject: Re: [GIT PULL] exynos-drm-next

 Hi Inki,

 On 03.04.2014 19:34, inki.dae at samsung.com wrote:
> Hi Dave,
>   Sorry for late.
>   This pull request includes MIPI-DSI driver, two panel drivers,
>   super device support, and relevant dt bindings.
>
> Summaries:
> - Add MIPI-DSI Driver, and dt bindigs
> - Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings
> - Add LD9040 parallel panel driver
>  . this driver is placed in drivers/gpu/drm/panel, and it seems
>to be used for exynos drm as of now,
> - Add super device support, and dt bindings
>  . this patch resolves the probe order issue to sub drivers
>without specific lists

 I don't think the DT bindings have been Acked by DT maintainers,
 which is necessary to merge them.

 Also I believe more discussion is needed on this, but I didn't have
 time to comment on this series yet. Please hold off with merging the
 supernode series yet.
>>>
>>> I sent a email about review request to you but I didn't get any answer
>>> from you.
>>
>> It's been just three days ago and I just didn't find time yet to review
>
> No, the email was just ping. My original RFC patch series had been posted
> March 3, about 1 month ago, And for my official patch series, eight days
> ago.
> So the email I sent three days ago was just a ping that I requested for you
> to review the patch series.

As I said, it was not even posted to samsung-soc, the central ML for 
Samsung SoC related patches, as mandated by MAINTAINERS file. I learned 
about its presence just after your ping.

>> them. I would like to be able to review all the patches straight after
>> them being posted, but unfortunately that's not the only thing I have to
>> do.
>>
>
> So I think there was no any comments from you for a long time.
>
>> Anyway, a common practice in open source world is to let the patches wait
>> on the mailing lists for two weeks for people to find some time to review
>> them and only then apply. There might be people that don't work full time
>> on this area, but still would be interested to do a review in some free
>> time.
>>
>> Also, neither version of this series have been posted to linux-samsung-soc
>> mailing list, which is also a key to have a broader review. Note that this
>> ML is listed in MAINTAINERS file for all kernel files with "exynos" in
>> name.
>>
>> ARM/S5P EXYNOS ARM ARCHITECTURES
>> M:  Kukjin Kim 
>> L:  linux-arm-kernel at lists.infradead.org (moderated for
> non-subscribers)
>> L:  linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
>> S:  Maintained
>> F:  arch/arm/mach-s5p*/
>> F:  arch/arm/mach-exynos*/
>> N:  exynos
>>
>>
>>> And I think super node concept was already accepted, and relevant
>>> codes, component framework, has already been merged to mainline. And
>>> Linux staging next has already such dt bindings. Please see imx dts
>> files.
>>
>> Yes, they are, but for other platforms not this particular instance.
>>
>> Any new DT bindings introduced are needed to have an ACK from one of DT
>> maintainers to be merged, unless you can't get any reply from any of them
>> for a longer time, usually 3 weeks from posting the series to be applied.
>
> So should I wait for more times?
>

Since this series is not a dependency for any other patches queued for 
this release and it doesn't add any new functionality, I don't think 
there is any need to hurry with it.

>>
>> Of course standard pinging rules apply, so you should ping DT maintainers
>> first before applying such series.
>
>
> The email I sent to you three days ago was that.

Unfortunately I'm not a DT maintainer, so I don't qualify here. You can 
see list of DT maintainers in MAINTAINERS file:

OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
M:  Rob Herring 
M:  Pawel Moll 
M:  Mark Rutland 
M:  Ian Campbell 
M:  Kumar Gala 
L:  devicetree at vger.kernel.org
S:  Maintained
F:  Documentation/devicetree/
F:  arch/*/boot/dts/
F:  include/dt-bindings/

Best regards,
Tomasz

[GIT PULL] exynos-drm-next

[Tomasz Figa]

On 04.04.2014 07:34, Inki Dae wrote:
> Hi Tomasz,
>
>> -Original Message-
>> From: Tomasz Figa [mailto:tomasz.figa at gmail.com]
>> Sent: Friday, April 04, 2014 2:00 PM
>> To: inki.dae at samsung.com; airlied at linux.ie; dri-
>> devel at lists.freedesktop.org
>> Subject: Re: [GIT PULL] exynos-drm-next
>>
>> Hi Inki,
>>
>> On 03.04.2014 19:34, inki.dae at samsung.com wrote:
>>> Hi Dave,
>>>  Sorry for late.
>>>  This pull request includes MIPI-DSI driver, two panel drivers,
>>>  super device support, and relevant dt bindings.
>>>
>>> Summaries:
>>> - Add MIPI-DSI Driver, and dt bindigs
>>> - Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings
>>> - Add LD9040 parallel panel driver
>>> . this driver is placed in drivers/gpu/drm/panel, and it seems
>>>   to be used for exynos drm as of now,
>>> - Add super device support, and dt bindings
>>> . this patch resolves the probe order issue to sub drivers
>>>   without specific lists
>>
>> I don't think the DT bindings have been Acked by DT maintainers, which is
>> necessary to merge them.
>>
>> Also I believe more discussion is needed on this, but I didn't have time
>> to comment on this series yet. Please hold off with merging the supernode
>> series yet.
>
> I sent a email about review request to you but I didn't get any answer from
> you.

It's been just three days ago and I just didn't find time yet to review 
them. I would like to be able to review all the patches straight after 
them being posted, but unfortunately that's not the only thing I have to do.

Anyway, a common practice in open source world is to let the patches 
wait on the mailing lists for two weeks for people to find some time to 
review them and only then apply. There might be people that don't work 
full time on this area, but still would be interested to do a review in 
some free time.

Also, neither version of this series have been posted to 
linux-samsung-soc mailing list, which is also a key to have a broader 
review. Note that this ML is listed in MAINTAINERS file for all kernel 
files with "exynos" in name.

ARM/S5P EXYNOS ARM ARCHITECTURES
M:  Kukjin Kim 
L:  linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
L:  linux-samsung-soc at vger.kernel.org (moderated for non-subscribers)
S:  Maintained
F:  arch/arm/mach-s5p*/
F:  arch/arm/mach-exynos*/
N:  exynos


> And I think super node concept was already accepted, and relevant
> codes, component framework, has already been merged to mainline. And Linux
> staging next has already such dt bindings. Please see imx dts files.

Yes, they are, but for other platforms not this particular instance.

Any new DT bindings introduced are needed to have an ACK from one of DT 
maintainers to be merged, unless you can't get any reply from any of 
them for a longer time, usually 3 weeks from posting the series to be 
applied.

Of course standard pinging rules apply, so you should ping DT 
maintainers first before applying such series.

>
> I hope this time this series would be merged to mainline so that we could go
> to next step, integrating drm_panel and drm_bridge framework to one
> integrated drm_bridge. So Can you hurry up to review it a bit? I'll wait for
> your ack.

I don't think there is any need to hurry up with this particular series 
for this release. I'd recommend sending a pull request with remaining 
patches separately, as the supernode is not required to make anything 
work, rather than being just a refactor.

Best regards,
Tomasz

[GIT PULL] drm/tegra: Changes for v3.15-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 88759686c702f1fbbb8e737e6231b64a9880db73:

  drm/dp: Allow registering AUX channels as I2C busses (2014-02-26 17:21:34 
+0100)

are available in the git repository at:

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

for you to fetch changes up to d105a6c97e43e35fd4f852928bb8a19df235c6e7:

  drm/tegra: Use standard GPL v2 license text (2014-04-04 09:12:51 +0200)

Thanks,
Thierry


drm/tegra: Changes for v3.15-rc1

Implement eDP support for Tegra124 and support the PRIME vmap()/vunmap()
operations.

A symbol that is required for upcoming V4L2 support is now exported by
the host1x driver.

Relicense drivers under the GPL v2 for consistency. One exception is the
public header file, which is relicensed under MIT to abide by the common
rule.


Bryan Wu (1):
  gpu: host1x: export host1x_syncpt_incr_max() function

Thierry Reding (5):
  drm/tegra: prime: Add vmap support
  drm/tegra: Add eDP support
  drm/tegra: Relicense public header under MIT
  drm/tegra: Relicense under GPL v2
  drm/tegra: Use standard GPL v2 license text

 .../bindings/gpu/nvidia,tegra20-host1x.txt |   42 +
 drivers/gpu/drm/tegra/Makefile |2 +
 drivers/gpu/drm/tegra/dc.h |1 +
 drivers/gpu/drm/tegra/dpaux.c  |  544 ++
 drivers/gpu/drm/tegra/dpaux.h  |   73 ++
 drivers/gpu/drm/tegra/drm.c|   19 +-
 drivers/gpu/drm/tegra/drm.h|   20 +
 drivers/gpu/drm/tegra/dsi.c|   20 +-
 drivers/gpu/drm/tegra/dsi.h|   20 +-
 drivers/gpu/drm/tegra/gem.c|   25 +-
 drivers/gpu/drm/tegra/gem.h|   14 +-
 drivers/gpu/drm/tegra/gr2d.c   |   14 +-
 drivers/gpu/drm/tegra/mipi-phy.c   |   20 +-
 drivers/gpu/drm/tegra/mipi-phy.h   |   20 +-
 drivers/gpu/drm/tegra/output.c |8 +
 drivers/gpu/drm/tegra/sor.c| 1092 
 drivers/gpu/drm/tegra/sor.h|  278 +
 drivers/gpu/host1x/syncpt.c|1 +
 include/linux/host1x.h |1 +
 include/uapi/drm/tegra_drm.h   |   24 +-
 20 files changed, 2129 insertions(+), 109 deletions(-)
 create mode 100644 drivers/gpu/drm/tegra/dpaux.c
 create mode 100644 drivers/gpu/drm/tegra/dpaux.h
 create mode 100644 drivers/gpu/drm/tegra/sor.c
 create mode 100644 drivers/gpu/drm/tegra/sor.h
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/e4c7709f/attachment.sig>

[GIT PULL] drm/panel: Changes for v3.15-rc1

[Thierry Reding]

Hi Dave,

The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:

  Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)

are available in the git repository at:

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

for you to fetch changes up to 712ac1ba63448d38e2fc3f2b58e62ca4af9778c2:

  drm/panel: add support for LG LD070WX3-SL01 panel (2014-04-04 09:06:40 +0200)

Thanks,
Thierry


drm/panel: Changes for v3.15-rc1

Add support for a couple more simple panels. A few cleanups to the
simple panel driver are also included (gpiod interface conversion,
removal of redundant call to regulator_disable()).


Alexandre Courbot (4):
  drm/panel: use gpiod interface for enable GPIO
  drm/panel: remove redundant regulator_disable()
  drm/panel: add support for LG LH500WX1-SD03 panel
  drm/panel: add support for LG LD070WX3-SL01 panel

Thierry Reding (4):
  MAINTAINERS: Add entry for DRM panel drivers
  drm/panel: Add LG 12.9" LCD panel
  drm/panel: simple: Allow GPIO accesses to sleep
  drm/panel: simple: Allow DSI panels to provide mode flags

 .../devicetree/bindings/panel/lg,ld070wx3-sl01.txt |   7 +
 .../devicetree/bindings/panel/lg,lh500wx1-sd03.txt |   7 +
 .../devicetree/bindings/panel/lg,lp129qe.txt   |   7 +
 MAINTAINERS|  10 ++
 drivers/gpu/drm/panel/panel-simple.c   | 157 ++---
 5 files changed, 137 insertions(+), 51 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt
 create mode 100644 Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt
 create mode 100644 Documentation/devicetree/bindings/panel/lg,lp129qe.txt
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/2e3c4818/attachment-0001.sig>

[PATCH] modetest: consider supported formats before selecting a DRM plane

[Fabien DESSENNE]

Can anyone review this patch ?
Thanks for your time.
Fabien

> -Original Message-
> From: Fabien DESSENNE [mailto:fabien.dessenne at st.com]
> Sent: vendredi 28 mars 2014 11:16
> To: dri-devel at lists.freedesktop.org
> Cc: Benjamin Gaignard; Vincent Abriou; Fabien DESSENNE
> Subject: [PATCH] modetest: consider supported formats before selecting a
> DRM plane
> 
> This fixes an issue where the DRM planes do not support the same pixel
> formats.
> The current implementation selects a DRM plane without checking whether
> the pixel format is supported or not. As a consequence modetest may try to
> set up a plane not supporting the user request-format, which fails.
> Modetest has to check the supported formats accross the plane list before
> selecting a candidate.
> 
> Signed-off-by: Fabien Dessenne 
> ---
>  tests/modetest/modetest.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c index
> 4761c60..866ea82 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -951,7 +951,7 @@ static int set_plane(struct device *dev, struct
> plane_arg *p)
>   int crtc_x, crtc_y, crtc_w, crtc_h;
>   struct crtc *crtc = NULL;
>   unsigned int pipe;
> - unsigned int i;
> + unsigned int i, j;
> 
>   /* Find an unused plane which can be connected to our CRTC. Find
> the
>* CRTC index first, then iterate over available planes.
> @@ -974,8 +974,11 @@ static int set_plane(struct device *dev, struct
> plane_arg *p)
>   if (!ovr)
>   continue;
> 
> - if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id)
> - plane_id = ovr->plane_id;
> + if ((ovr->possible_crtcs & (1 << pipe)) && !ovr->crtc_id) {
> + for (j = 0; j < ovr->count_formats; j++)
> + if (!strncmp(p->format_str, (char *) 
> >formats[j], 4))
> + plane_id = ovr->plane_id;
> + }
>   }
> 
>   if (!plane_id) {
> --
> 1.9.0

[PATCH 1/4] drm/dp: add flags field to drm_dp_aux_msg struct

[Jani Nikula]

On Sat, 22 Mar 2014, Alex Deucher  wrote:
> This adds a flags field and a new flag, BARE_ADDRESS,
> which drivers can use for special handling when they
> want to set just the aux address.  This is needed
> to properly reset the connection between i2c transactions.

Sorry it took me so long to get to this.

The changes in patches 1-3 look sensible in general, but I think I'd
prefer you dropped the flags field and used size == 0 to mean bare
address. It feels silly to have to set size = 1 and have a dummy one
byte buffer that doesn't get transfered. Without the payload I think it
feels natural only the address is transfered.

BR,
Jani.


>
> Signed-off-by: Alex Deucher 
> ---
>  include/drm/drm_dp_helper.h | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index b7488c9..a006e96 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -403,6 +403,8 @@ drm_dp_enhanced_frame_cap(const u8 
> dpcd[DP_RECEIVER_CAP_SIZE])
>   * DisplayPort AUX channel
>   */
>  
> +#define DRM_DP_AUX_MSG_FLAGS_BARE_ADDRESS (1 << 0)
> +
>  /**
>   * struct drm_dp_aux_msg - DisplayPort AUX channel transaction
>   * @address: address of the (first) register to access
> @@ -417,6 +419,7 @@ struct drm_dp_aux_msg {
>   u8 reply;
>   void *buffer;
>   size_t size;
> + u32 flags;
>  };
>  
>  /**
> -- 
> 1.8.3.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/dp_helper: don't return EPROTO for defers

[Jani Nikula]

On Fri, 04 Apr 2014, Jani Nikula  wrote:
> On Fri, 04 Apr 2014, Dave Airlie  wrote:
>> From: Dave Airlie 
>>
>> If we get a msg.reply of REPLY_DEFER, we also get an err of 0
>> so we fail reads with 0 < size and return -EPROTO instead of trying
>> again.
>>
>> Found writing MST support.
>>
>
> Reviewed-by: Jani Nikula 

On second thought, I think you'll need the same for drm_dp_i2c_do_msg()
as well.

Cheers,
Jani.


>
>
>> Signed-off-by: Dave Airlie 
>> ---
>>  drivers/gpu/drm/drm_dp_helper.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c 
>> b/drivers/gpu/drm/drm_dp_helper.c
>> index f4babed..725354f 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -386,11 +386,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, 
>> u8 request,
>>  return err;
>>  }
>>  
>> -if (err < size)
>> -return -EPROTO;
>>  
>>  switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
>>  case DP_AUX_NATIVE_REPLY_ACK:
>> +if (err < size)
>> +return -EPROTO;
>>  return err;
>>  
>>  case DP_AUX_NATIVE_REPLY_NACK:
>> -- 
>> 1.8.5.3
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> -- 
> Jani Nikula, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/dp_helper: don't return EPROTO for defers

[Jani Nikula]

On Fri, 04 Apr 2014, Dave Airlie  wrote:
> From: Dave Airlie 
>
> If we get a msg.reply of REPLY_DEFER, we also get an err of 0
> so we fail reads with 0 < size and return -EPROTO instead of trying
> again.
>
> Found writing MST support.
>

Reviewed-by: Jani Nikula 


> Signed-off-by: Dave Airlie 
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f4babed..725354f 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -386,11 +386,11 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, 
> u8 request,
>   return err;
>   }
>  
> - if (err < size)
> - return -EPROTO;
>  
>   switch (msg.reply & DP_AUX_NATIVE_REPLY_MASK) {
>   case DP_AUX_NATIVE_REPLY_ACK:
> + if (err < size)
> + return -EPROTO;
>   return err;
>  
>   case DP_AUX_NATIVE_REPLY_NACK:
> -- 
> 1.8.5.3
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH] drm/dp_helper: don't return EPROTO for defers

[Thierry Reding]

On Fri, Apr 04, 2014 at 09:00:31AM +0300, Jani Nikula wrote:
> On Fri, 04 Apr 2014, Jani Nikula  wrote:
> > On Fri, 04 Apr 2014, Dave Airlie  wrote:
> >> From: Dave Airlie 
> >>
> >> If we get a msg.reply of REPLY_DEFER, we also get an err of 0
> >> so we fail reads with 0 < size and return -EPROTO instead of trying
> >> again.
> >>
> >> Found writing MST support.
> >>
> >
> > Reviewed-by: Jani Nikula 
> 
> On second thought, I think you'll need the same for drm_dp_i2c_do_msg()
> as well.

I agree. drm_dp_i2c_do_msg() should have the same change. With that:

Reviewed-by: Thierry Reding 
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140404/97e6f1e6/attachment.sig>

[PULL] vmwgfx-next

[Thomas Hellstrom]

Dave,
The second vmwgfx pull request for the 3.15 merge window.
Contains a fbdev fix by Christopher Friedt, one fix for a locking order
violation introduced in 3.14 (hit when using queries) and finally a
removal of the DRM_AUTH requirement around some vmwgfx IOCTLS where the
caller is already required to have an open handle to the object.

The following changes since commit 2844ea3f252331cc0ecf3ae74f6226db2f580f8a:

  Merge branch 'primary-plane' of git://people.freedesktop.org/~robclark/linux 
into drm-next (2014-04-02 12:09:09 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~thomash/linux tags/vmwgfx-next-2014-04-04

for you to fetch changes up to aa6de142c901cd2d90ef08db30ae87da214bedcc:

  drm/vmwgfx: correct fb_fix_screeninfo.line_length (2014-04-03 09:34:06 +0200)


Pull request of 2014-04-04


Christopher Friedt (1):
  drm/vmwgfx: correct fb_fix_screeninfo.line_length

Thomas Hellstrom (2):
  drm/vmwgfx: Fix query buffer locking order violation
  drm/vmwgfx: Remove authorization requirements around some more ioctls

 drivers/gpu/drm/vmwgfx/vmwgfx_context.c |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |5 -
 3 files changed, 8 insertions(+), 5 deletions(-)

[PULL] ttm-next

[Thomas Hellstrom]

Dave,
Currently only a single patch fixing up mixed use of the ttm_bo_reserve and
ww_mutex APIs.

/Thomas

The following changes since commit 2844ea3f252331cc0ecf3ae74f6226db2f580f8a:

  Merge branch 'primary-plane' of git://people.freedesktop.org/~robclark/linux 
into drm-next (2014-04-02 12:09:09 +1000)

are available in the git repository at:


  git://people.freedesktop.org/~thomash/linux tags/ttm-next-2014-04-04

for you to fetch changes up to c75230833ce4fbbfaa257c07b55f97912fb1dc02:

  drm/ttm: Hide the implementation details of reservation (2014-04-04 08:00:59 
+0200)


Pull request of 2014-04-04


Thomas Hellstrom (1):
  drm/ttm: Hide the implementation details of reservation

 drivers/gpu/drm/qxl/qxl_release.c  |2 +-
 drivers/gpu/drm/ttm/ttm_bo.c   |   26 +-
 drivers/gpu/drm/ttm/ttm_execbuf_util.c |8 +++---
 include/drm/ttm/ttm_bo_driver.h|   47 
 4 files changed, 47 insertions(+), 36 deletions(-)

[Bug 76564] [AMD Fusion E-350] HDMI refresh rates doesn't match expectations

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

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

--- Comment #61 from Christian K?nig  ---
Detlev, please attache your logs to this bug instead:
ttps://bugs.freedesktop.org/show_bug.cgi?id=77009

It's essentially a different problem and I want to keep it separated from the
discussion here.

Thanks,
Christian.

-- 
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/20140404/541a2678/attachment.html>

[PATCH] drm: gem-cma: Fix warnings due to improper printk formats

[Dave Airlie]

On Thu, Apr 3, 2014 at 10:21 AM, Laurent Pinchart
 wrote:
> Hi Dave,
>
> Could you please take this patch in your tree ?
>
> What's the expected process when sending patches to the mailing list by the
> way ? Do you track them somehow, or always expect pull requests ?

I generally pick up things with reviewed tags if I can, other stuff I
pick up in cycles from patchwork, but since patchwork is mostly
unmaintained sometimes things fall through the cracks,

so pull reqs of reviewed patches generally always win, but for fixes
like this I don't mind pull reqs if they've hit the list and haven't
cause much discussion.

Dave.

Synchronization between a crtc mode_set and page_flip?

[Rob Clark]

On Fri, Apr 4, 2014 at 3:21 AM, Archit Taneja  wrote:
> On Friday 04 April 2014 02:54 AM, Daniel Vetter wrote:
>>
>> On Thu, Apr 03, 2014 at 02:28:32PM +0530, Archit Taneja wrote:
>>>
>>> On Wednesday 02 April 2014 06:41 PM, Rob Clark wrote:

 On Wed, Apr 2, 2014 at 5:52 AM, Archit Taneja  wrote:
>
> Hi,
>
> I was trying to figure out how we are supposed to manage
> synchronization
> between a mode_set and a page_flip called on a crtc.
>
> Say, if a mode_set is immediately followed by a page_flip. The driver
> can't
> process the page_flip straight away since the hardware is still
> completing
> the mode_set.


 I guess setcrtc is expected to be synchronous(ish).. so a lot of
 userspace won't expect the first pageflip to fail with -EBUSY.
>>>
>>>
>>> Okay, thanks. I guess having setcrtc synchronous isn't that bad.
>>
>>
>> Yeah, atm I think the rules are that pageflip can only return -EBUSY if
>> there's still a pageflip ongoing. Everything else is presumed to be at
>> least implicitly ordered, so if your hw can do async modesets then you
>> need to synchronize. Also if there's still a pageflip outstanding you need
>> to wait for that to complete in your set_config callback first (usually in
>> the set_base or the crtc->disable/prepare hooks when using the crtc
>> helpers).
>
>
> Thanks for the info. I didn't realize that the prepare/commit hooks get
> executed when using drm_crtc_helper_set_mode() for the set_config helper.
>
> Rob,
>
> We disable the crtc in prepare, and enable it in commit.
>
> If setcrtc changes the mode,  I don't see how apply worker can execute
> prepare() -> mode_set() -> commit() hooks in a row for the crtc
> drm_crtc_helper_set_mode(). We can't queue more than one 'apply' of the same
> entity. So the latter queues are bound to get rejected, I see
> omap_crtc_apply() bailing out for crtc's apply in this case.

What is *supposed* to happen is that whenever apply worker gets a
chance to run, it applies whatever are the most recent settings.   So
even if you somehow managed to do two modesets before the apply worker
had a chance to run, it would simply apply whatever is the most recent
mode..  so modeset is not synchronized, but it is serialized.

So we don't actually need to queue up the same apply multiple times.
Looking at omap_crtc_pre_apply(), I think that should be fine.  Even
if we miss the dpms(OFF) from the prepare step, omap_crtc_pre_apply()
will still disable and reenable power if switching encoder.

That said, we probably do at least need to handle a pending pageflip
during setcrtc.  I think it would be reasonable to make prepare()
block until no pending pageflip or apply.  (Note: a pageflip to a
buffer still being rendered by the GPU won't have triggered an apply
*yet*)

BR,
-R

> I guess making prepare() and mode_set() wait for a vsync should fix this.
> Or, combining mode_set and commit as a single queue to apply should work
> too. Any suggestions?
>
> Thanks,
> Archit
>

[PATCH 2/5] drm/exynos: use regmap interface to set hdmiphy control bit in pmu

[Rahul Sharma]

Thanks Inki,

On 3 April 2014 21:23, Inki Dae  wrote:
> Hi Rahul,
>
> Thanks for contributions.
>
> 2014-04-03 2:13 GMT+09:00 Rahul Sharma :
>> From: Rahul Sharma 
>>
>> Hdmiphy control bit needs to be set before setting the resolution
>> to hdmi hardware. This was handled using dummy hdmiphy clock which
>> is removed now.
>>
>> PMU is already defined as system controller for exynos SoC. Registers
>> of PMU are accessed using regmap interfaces.
>>
>> Devicetree binding document for hdmi is also updated.
>>
>> Signed-off-by: Rahul Sharma 
>> ---
>>  .../devicetree/bindings/video/exynos_hdmi.txt  |2 ++
>>  drivers/gpu/drm/exynos/exynos_hdmi.c   |   17 +
>>  drivers/gpu/drm/exynos/regs-hdmi.h |4 
>>  3 files changed, 23 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt 
>> b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> index f9187a2..243a499 100644
>> --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
>> @@ -27,6 +27,7 @@ Required properties:
>> "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
>>  - ddc: phandle to the hdmi ddc node
>>  - phy: phandle to the hdmi phy node
>> +- samsung,syscon-phandle: phandle for system controller node for PMU.
>>
>>  Example:
>>
>> @@ -37,4 +38,5 @@ Example:
>> hpd-gpio = < 7 1>;
>> ddc = <_ddc_node>;
>> phy = <_phy_node>;
>> +   samsung,syscon-phandle = <_system_controller>;
>
> System regiters could be controlled by phy framework, drivers/phy/*
> with 'phys' property so I think we would need to consider the phy
> framework. Especially, this patch adds a new property,
> samsung,syscon-phandle so I'm careful in merging - I'm not sure that
> we really need this property, and we couldn't really use existing phys
> property. So let's have more times for reviews.
>

I will do that. But still "syscon-phandle" property needs to be added
to hdmi phy bindings. Very similar to USB phys in
Documentation/devicetree/bindings/phy/samsung-phy.txt. I hope
that should be fine.

Please review my other patches also.

Regards,
Rahul Sharma

> Thanks,
> Inki Dae
>
>> };
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index 23abfa0..47b8c06 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -36,6 +36,8 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>
>>  #include 
>>
>> @@ -194,6 +196,7 @@ struct hdmi_context {
>> struct hdmi_resources   res;
>>
>> int hpd_gpio;
>> +   struct regmap   *pmureg;
>>
>> enum hdmi_type  type;
>>  };
>> @@ -1853,6 +1856,9 @@ static void hdmi_poweron(struct exynos_drm_display 
>> *display)
>> if (regulator_bulk_enable(res->regul_count, res->regul_bulk))
>> DRM_DEBUG_KMS("failed to enable regulator bulk\n");
>>
>> +   /* set pmu hdmiphy control bit to enable hdmiphy */
>> +   regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>> +   PMU_HDMI_PHY_ENABLE_BIT, 1);
>> clk_prepare_enable(res->hdmi);
>> clk_prepare_enable(res->sclk_hdmi);
>>
>> @@ -1879,6 +1885,10 @@ static void hdmi_poweroff(struct exynos_drm_display 
>> *display)
>>
>> clk_disable_unprepare(res->sclk_hdmi);
>> clk_disable_unprepare(res->hdmi);
>> +   /* reset pmu hdmiphy control bit to disable hdmiphy */
>> +   regmap_update_bits(hdata->pmureg, PMU_HDMI_PHY_CONTROL,
>> +   PMU_HDMI_PHY_ENABLE_BIT, 0);
>> +
>> regulator_bulk_disable(res->regul_count, res->regul_bulk);
>>
>> pm_runtime_put_sync(hdata->dev);
>> @@ -2128,6 +2138,13 @@ static int hdmi_probe(struct platform_device *pdev)
>> goto err_hdmiphy;
>> }
>>
>> +   hdata->pmureg = syscon_regmap_lookup_by_phandle(dev->of_node,
>> +   "samsung,syscon-phandle");
>> +   if (IS_ERR_OR_NULL(hdata->pmureg)) {
>> +   DRM_ERROR("syscon regmap lookup failed.\n");
>> +   goto err_hdmiphy;
>> +   }
>> +
>> pm_runtime_enable(dev);
>>
>> hdmi_display.ctx = hdata;
>> diff --git a/drivers/gpu/drm/exynos/regs-hdmi.h 
>> b/drivers/gpu/drm/exynos/regs-hdmi.h
>> index ef1b3eb..9811d6f 100644
>> --- a/drivers/gpu/drm/exynos/regs-hdmi.h
>> +++ b/drivers/gpu/drm/exynos/regs-hdmi.h
>> @@ -578,4 +578,8 @@
>>  #define HDMI_TG_VACT_ST4_H HDMI_TG_BASE(0x0074)
>>  #define HDMI_TG_3D HDMI_TG_BASE(0x00F0)
>>
>> +/* PMU Registers for PHY */
>> +#define PMU_HDMI_PHY_CONTROL   0x700
>> +#define PMU_HDMI_PHY_ENABLE_BIT(1<<0)
>> +
>>  #endif /* SAMSUNG_REGS_HDMI_H */
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from 

[GIT PULL] exynos-drm-next

[Tomasz Figa]

Hi Inki,

On 03.04.2014 19:34, inki.dae at samsung.com wrote:
> Hi Dave,
> Sorry for late.
> This pull request includes MIPI-DSI driver, two panel drivers,
> super device support, and relevant dt bindings.
>
> Summaries:
> - Add MIPI-DSI Driver, and dt bindigs
> - Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings
> - Add LD9040 parallel panel driver
>. this driver is placed in drivers/gpu/drm/panel, and it seems
>  to be used for exynos drm as of now,
> - Add super device support, and dt bindings
>. this patch resolves the probe order issue to sub drivers
>  without specific lists

I don't think the DT bindings have been Acked by DT maintainers, which 
is necessary to merge them.

Also I believe more discussion is needed on this, but I didn't have time 
to comment on this series yet. Please hold off with merging the 
supernode series yet.

Best regards,
Tomasz

[Bug 42960] Display does not work when resuming from suspend

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

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

--- Comment #25 from klausenbusk at hotmail.com ---
(In reply to comment #22)
> Adding s3_bios to kernel parameters didn't work for me. The suspend just
> does not work anymore. Laptop wont suspend anymore.
> 
> My hardware:
> Asus -K55N
> Radeon HD7250G

You can also try: acpi_sleep=s3_mode or acpi_sleep=s3_bios,s3_mode

A little info here:https://www.kernel.org/doc/Documentation/power/video.txt

-- 
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/20140404/cbee3ac3/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

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

--- Comment #24 from Swoorup  ---
Hey guys are you able to help me out?
I have got this on kernel parameters

pcie_aspm=force acpi_osi='!Windows 2012' acpi=force acpi_enforce_resources=lax
acpi_backlight=vendor acpi_sleep=s3_bios

However when I try to suspend, the laptop just wont suspend or it
suspends(randomly). But when I try to wake up I have got the same issue as
before: blank screen. I'd have to reboot blindly again to use the system

-- 
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/20140404/db00fb47/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

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

--- Comment #23 from SpacemanSpiff  ---
Works great on HP dv6z with 6755g2. thanks

-- 
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/20140404/6f463fbc/attachment.html>

[Bug 42960] Display does not work when resuming from suspend

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

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

--- Comment #22 from Swoorup  ---
Adding s3_bios to kernel parameters didn't work for me. The suspend just does
not work anymore. Laptop wont suspend anymore.

My hardware:
Asus -K55N
Radeon HD7250G

-- 
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/20140404/4aea2507/attachment.html>

[GIT PULL] exynos-drm-next

[inki....@samsung.com]

Hi Dave,
   Sorry for late.
   This pull request includes MIPI-DSI driver, two panel drivers,
   super device support, and relevant dt bindings.

Summaries:
- Add MIPI-DSI Driver, and dt bindigs
- Add S6E8AA0 MIPI-DSI based panel drivers, and dt bindings
- Add LD9040 parallel panel driver
  . this driver is placed in drivers/gpu/drm/panel, and it seems
to be used for exynos drm as of now,
- Add super device support, and dt bindings
  . this patch resolves the probe order issue to sub drivers
without specific lists
- Some fixups

If there is any problem, please kindly let me know.

Thanks,
Inki Dae


The following changes since commit 2844ea3f252331cc0ecf3ae74f6226db2f580f8a:

  Merge branch 'primary-plane' of git://people.freedesktop.org/~robclark/linux 
into drm-next (2014-04-02 12:09:09 +1000)

are available in the git repository at:


  git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git 
exynos-drm-next

for you to fetch changes up to a4521cbc01a711e78e22155885f991bcb96496de:

  drm/exynos: separate dpi from fimd (2014-04-04 02:22:16 +0900)


Andrzej Hajda (16):
  drm/mipi_dsi: add flags to DSI messages
  drm/mipi_dsi: create dsi devices only for nodes with reg property
  drm/exynos: disallow fbdev initialization if no device is connected
  exynos/dsim: add DT bindings
  drm/exynos: add DSIM driver
  panel/s6e8aa0: add DT bindings
  panel/ld9040: add DT bindings
  drm/panel: add ld9040 driver
  ARM: dts: exynos4210-universal_c210: add proper panel node
  drm/panel: add S6E8AA0 driver
  ARM: dts: exynos4: add MIPI DSI Master node
  ARM: dts: exynos4210-trats: add panel node
  ARM: dts: exynos4412-trats2: add panel node
  ARM: dts: exynos4210-trats: enable exynos/fimd node
  ARM: dts: exynos4412-trats2: enable exynos/fimd node
  drm/exynos: separate dpi from fimd

Inki Dae (7):
  drm/exynos: add super device support
  drm/exynos: dpi: fix hotplug fail issue
  drm/exynos: register platform driver at each kms sub drivers
  ARM: dts: exynos4210-universal: add super device node for exynos drm
  ARM: dts: exynos4210-trats: add super device node for exynos drm
  ARM: dts: exynos4412-trats2: add super device node for exynos drm
  exynos/drm: add DT bindings

 .../bindings/drm/exynos/samsung-exynos-drm.txt |   32 +
 .../devicetree/bindings/panel/samsung,ld9040.txt   |   66 +
 .../devicetree/bindings/panel/samsung,s6e8aa0.txt  |   56 +
 .../devicetree/bindings/video/exynos_dsim.txt  |   80 +
 arch/arm/boot/dts/exynos4.dtsi |   14 +
 arch/arm/boot/dts/exynos4210-trats.dts |   66 +
 arch/arm/boot/dts/exynos4210-universal_c210.dts|   76 +-
 arch/arm/boot/dts/exynos4412-trats2.dts|   75 +
 drivers/gpu/drm/drm_mipi_dsi.c |6 +-
 drivers/gpu/drm/exynos/Kconfig |9 +
 drivers/gpu/drm/exynos/Makefile|1 +
 drivers/gpu/drm/exynos/exynos_dp_core.c|   46 +-
 drivers/gpu/drm/exynos/exynos_drm_core.c   |  216 +--
 drivers/gpu/drm/exynos/exynos_drm_crtc.c   |   17 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.h   |4 +
 drivers/gpu/drm/exynos/exynos_drm_dpi.c|   51 +-
 drivers/gpu/drm/exynos/exynos_drm_drv.c|  243 ++-
 drivers/gpu/drm/exynos/exynos_drm_drv.h|   69 +-
 drivers/gpu/drm/exynos/exynos_drm_dsi.c| 1558 
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c  |   21 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c   |   75 +-
 drivers/gpu/drm/exynos/exynos_drm_vidi.c   |   61 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   |   60 +-
 drivers/gpu/drm/exynos/exynos_mixer.c  |   55 +-
 drivers/gpu/drm/panel/Kconfig  |   14 +
 drivers/gpu/drm/panel/Makefile |2 +
 drivers/gpu/drm/panel/panel-ld9040.c   |  376 +
 drivers/gpu/drm/panel/panel-s6e8aa0.c  | 1069 ++
 include/drm/drm_mipi_dsi.h |6 +
 29 files changed, 3929 insertions(+), 495 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/drm/exynos/samsung-exynos-drm.txt
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,ld9040.txt
 create mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt
 create mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_dsi.c
 create mode 100644 drivers/gpu/drm/panel/panel-ld9040.c
 create mode 100644 drivers/gpu/drm/panel/panel-s6e8aa0.c

[PATCH] drm/exynos: separate dpi from fimd

[Inki Dae]

2014-04-04 1:35 GMT+09:00 Inki Dae :
> 2014-04-03 23:26 GMT+09:00 Andrzej Hajda :
>> The patch separates dpi related routines from fimd.
>>
>> Signed-off-by: Andrzej Hajda 
>> ---
>> Hi Inki,
>>
>> This is my attempt to separate DPI from FIMD,
>> it requires putting real probe back into fimd_probe, but I
>> guess it should not be a problem, as it is done already for dsi.
>> It is based on v4 of your patch.
>>
>> The patch was written quickly without proper review, I can
>> do it tomorrow if you are interested.
>> If it is OK for you, please merge it with your patch.
>> Anyway, I have made few tests - it works.
>>
>> Regards
>> Andrzej
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  40 ++--
>>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |  15 ++---
>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 109 
>> +--
>>  3 files changed, 69 insertions(+), 95 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
>> index ac206e7..03cb126 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
>> @@ -40,20 +40,10 @@ exynos_dpi_detect(struct drm_connector *connector, bool 
>> force)
>>  {
>> struct exynos_dpi *ctx = connector_to_dpi(connector);
>>
>> -   /* panels supported only by boot-loader are always connected */
>> -   if (!ctx->panel_node)
>> -   return connector_status_connected;
>> -
>> -   if (!ctx->panel) {
>> -   ctx->panel = of_drm_find_panel(ctx->panel_node);
>> -   if (ctx->panel)
>> -   drm_panel_attach(ctx->panel, >connector);
>> -   }
>> +   if (!ctx->panel->connector)
>> +   drm_panel_attach(ctx->panel, >connector);
>>
>> -   if (ctx->panel)
>> -   return connector_status_connected;
>> -
>> -   return connector_status_disconnected;
>> +   return connector_status_connected;
>>  }
>>
>>  static void exynos_dpi_connector_destroy(struct drm_connector *connector)
>> @@ -291,8 +281,10 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
>> return -ENOMEM;
>>
>> ret = of_get_videomode(dn, vm, 0);
>> -   if (ret < 0)
>> +   if (ret < 0) {
>> +   devm_kfree(dev, vm);
>> return ret;
>> +   }
>>
>> ctx->vm = vm;
>>
>> @@ -305,27 +297,35 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
>> return 0;
>>  }
>>
>> -int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev)
>> +struct exynos_drm_display *exynos_dpi_probe(struct device *dev)
>>  {
>> struct exynos_dpi *ctx;
>> int ret;
>>
>> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> if (!ctx)
>> -   return -ENOMEM;
>> +   return NULL;
>>
>> ctx->dev = dev;
>> exynos_dpi_display.ctx = ctx;
>> ctx->dpms_mode = DRM_MODE_DPMS_OFF;
>>
>> ret = exynos_dpi_parse_dt(ctx);
>> -   if (ret < 0)
>> -   return ret;
>> +   if (ret < 0) {
>> +   devm_kfree(dev, ctx);
>> +   return NULL;
>> +   }
>> +
>> +   if (ctx->panel_node) {
>> +   ctx->panel = of_drm_find_panel(ctx->panel_node);
>> +   if (!ctx->panel)
>> +   return ERR_PTR(-EPROBE_DEFER);
>> +   }
>>
>> -   return exynos_drm_create_enc_conn(drm_dev, _dpi_display);
>> +   return _dpi_display;
>>  }
>>
>> -int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev)
>> +int exynos_dpi_remove(struct device *dev)
>>  {
>> struct drm_encoder *encoder = exynos_dpi_display.encoder;
>> struct exynos_dpi *ctx = exynos_dpi_display.ctx;
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 2b87eb7..583a0bd 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -334,17 +334,12 @@ int exynos_platform_device_ipp_register(void);
>>  void exynos_platform_device_ipp_unregister(void);
>>
>>  #ifdef CONFIG_DRM_EXYNOS_DPI
>> -int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev);
>> -int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev);
>> -struct device_node *exynos_dpi_of_find_panel_node(struct device *dev);
>> +struct exynos_drm_display * exynos_dpi_probe(struct device *dev);
>> +int exynos_dpi_remove(struct device *dev);
>>  #else
>> -static inline int exynos_dpi_probe(struct drm_device *drm_dev,
>> -   struct device *dev) { return 0; }
>> -static inline int exynos_dpi_remove(struct drm_device *drm_dev,
>> -   struct device *dev) { return 0; }
>> -static inline struct device_node
>> -   *exynos_dpi_of_find_panel_node(struct device *dev)
>> -{ return 

[PATCH] drm/exynos: separate dpi from fimd

[Inki Dae]

2014-04-03 23:26 GMT+09:00 Andrzej Hajda :
> The patch separates dpi related routines from fimd.
>
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Inki,
>
> This is my attempt to separate DPI from FIMD,
> it requires putting real probe back into fimd_probe, but I
> guess it should not be a problem, as it is done already for dsi.
> It is based on v4 of your patch.
>
> The patch was written quickly without proper review, I can
> do it tomorrow if you are interested.
> If it is OK for you, please merge it with your patch.
> Anyway, I have made few tests - it works.
>
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  40 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |  15 ++---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 109 
> +--
>  3 files changed, 69 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> index ac206e7..03cb126 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> @@ -40,20 +40,10 @@ exynos_dpi_detect(struct drm_connector *connector, bool 
> force)
>  {
> struct exynos_dpi *ctx = connector_to_dpi(connector);
>
> -   /* panels supported only by boot-loader are always connected */
> -   if (!ctx->panel_node)
> -   return connector_status_connected;
> -
> -   if (!ctx->panel) {
> -   ctx->panel = of_drm_find_panel(ctx->panel_node);
> -   if (ctx->panel)
> -   drm_panel_attach(ctx->panel, >connector);
> -   }
> +   if (!ctx->panel->connector)
> +   drm_panel_attach(ctx->panel, >connector);
>
> -   if (ctx->panel)
> -   return connector_status_connected;
> -
> -   return connector_status_disconnected;
> +   return connector_status_connected;
>  }
>
>  static void exynos_dpi_connector_destroy(struct drm_connector *connector)
> @@ -291,8 +281,10 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
> return -ENOMEM;
>
> ret = of_get_videomode(dn, vm, 0);
> -   if (ret < 0)
> +   if (ret < 0) {
> +   devm_kfree(dev, vm);
> return ret;
> +   }
>
> ctx->vm = vm;
>
> @@ -305,27 +297,35 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
> return 0;
>  }
>
> -int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev)
> +struct exynos_drm_display *exynos_dpi_probe(struct device *dev)
>  {
> struct exynos_dpi *ctx;
> int ret;
>
> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> -   return -ENOMEM;
> +   return NULL;
>
> ctx->dev = dev;
> exynos_dpi_display.ctx = ctx;
> ctx->dpms_mode = DRM_MODE_DPMS_OFF;
>
> ret = exynos_dpi_parse_dt(ctx);
> -   if (ret < 0)
> -   return ret;
> +   if (ret < 0) {
> +   devm_kfree(dev, ctx);
> +   return NULL;
> +   }
> +
> +   if (ctx->panel_node) {
> +   ctx->panel = of_drm_find_panel(ctx->panel_node);
> +   if (!ctx->panel)
> +   return ERR_PTR(-EPROBE_DEFER);
> +   }
>
> -   return exynos_drm_create_enc_conn(drm_dev, _dpi_display);
> +   return _dpi_display;
>  }
>
> -int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev)
> +int exynos_dpi_remove(struct device *dev)
>  {
> struct drm_encoder *encoder = exynos_dpi_display.encoder;
> struct exynos_dpi *ctx = exynos_dpi_display.ctx;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 2b87eb7..583a0bd 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -334,17 +334,12 @@ int exynos_platform_device_ipp_register(void);
>  void exynos_platform_device_ipp_unregister(void);
>
>  #ifdef CONFIG_DRM_EXYNOS_DPI
> -int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev);
> -int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev);
> -struct device_node *exynos_dpi_of_find_panel_node(struct device *dev);
> +struct exynos_drm_display * exynos_dpi_probe(struct device *dev);
> +int exynos_dpi_remove(struct device *dev);
>  #else
> -static inline int exynos_dpi_probe(struct drm_device *drm_dev,
> -   struct device *dev) { return 0; }
> -static inline int exynos_dpi_remove(struct drm_device *drm_dev,
> -   struct device *dev) { return 0; }
> -static inline struct device_node
> -   *exynos_dpi_of_find_panel_node(struct device *dev)
> -{ return NULL; }
> +static inline struct exynos_drm_display *
> +exynos_dpi_probe(struct device *dev) { return 0; }
> +static inline int exynos_dpi_remove(struct device *dev) { 

[PATCH] drm/exynos: separate dpi from fimd

[Inki Dae]

Hi Andrzej,

2014-04-03 23:26 GMT+09:00 Andrzej Hajda :
> The patch separates dpi related routines from fimd.
>
> Signed-off-by: Andrzej Hajda 
> ---
> Hi Inki,
>
> This is my attempt to separate DPI from FIMD,

Ah, I understood now. Right, if we can separate DPI from FIMD, we can
also move some codes for getting resources from fimd_bind to
fimd_probe.

Picked it up.

Thanks,
Inki Dae

> it requires putting real probe back into fimd_probe, but I
> guess it should not be a problem, as it is done already for dsi.
> It is based on v4 of your patch.
>
> The patch was written quickly without proper review, I can
> do it tomorrow if you are interested.
> If it is OK for you, please merge it with your patch.
> Anyway, I have made few tests - it works.
>
> Regards
> Andrzej
> ---
>  drivers/gpu/drm/exynos/exynos_drm_dpi.c  |  40 ++--
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |  15 ++---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 109 
> +--
>  3 files changed, 69 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c 
> b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> index ac206e7..03cb126 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
> @@ -40,20 +40,10 @@ exynos_dpi_detect(struct drm_connector *connector, bool 
> force)
>  {
> struct exynos_dpi *ctx = connector_to_dpi(connector);
>
> -   /* panels supported only by boot-loader are always connected */
> -   if (!ctx->panel_node)
> -   return connector_status_connected;
> -
> -   if (!ctx->panel) {
> -   ctx->panel = of_drm_find_panel(ctx->panel_node);
> -   if (ctx->panel)
> -   drm_panel_attach(ctx->panel, >connector);
> -   }
> +   if (!ctx->panel->connector)
> +   drm_panel_attach(ctx->panel, >connector);
>
> -   if (ctx->panel)
> -   return connector_status_connected;
> -
> -   return connector_status_disconnected;
> +   return connector_status_connected;
>  }
>
>  static void exynos_dpi_connector_destroy(struct drm_connector *connector)
> @@ -291,8 +281,10 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
> return -ENOMEM;
>
> ret = of_get_videomode(dn, vm, 0);
> -   if (ret < 0)
> +   if (ret < 0) {
> +   devm_kfree(dev, vm);
> return ret;
> +   }
>
> ctx->vm = vm;
>
> @@ -305,27 +297,35 @@ static int exynos_dpi_parse_dt(struct exynos_dpi *ctx)
> return 0;
>  }
>
> -int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev)
> +struct exynos_drm_display *exynos_dpi_probe(struct device *dev)
>  {
> struct exynos_dpi *ctx;
> int ret;
>
> ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> if (!ctx)
> -   return -ENOMEM;
> +   return NULL;
>
> ctx->dev = dev;
> exynos_dpi_display.ctx = ctx;
> ctx->dpms_mode = DRM_MODE_DPMS_OFF;
>
> ret = exynos_dpi_parse_dt(ctx);
> -   if (ret < 0)
> -   return ret;
> +   if (ret < 0) {
> +   devm_kfree(dev, ctx);
> +   return NULL;
> +   }
> +
> +   if (ctx->panel_node) {
> +   ctx->panel = of_drm_find_panel(ctx->panel_node);
> +   if (!ctx->panel)
> +   return ERR_PTR(-EPROBE_DEFER);
> +   }
>
> -   return exynos_drm_create_enc_conn(drm_dev, _dpi_display);
> +   return _dpi_display;
>  }
>
> -int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev)
> +int exynos_dpi_remove(struct device *dev)
>  {
> struct drm_encoder *encoder = exynos_dpi_display.encoder;
> struct exynos_dpi *ctx = exynos_dpi_display.ctx;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 2b87eb7..583a0bd 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -334,17 +334,12 @@ int exynos_platform_device_ipp_register(void);
>  void exynos_platform_device_ipp_unregister(void);
>
>  #ifdef CONFIG_DRM_EXYNOS_DPI
> -int exynos_dpi_probe(struct drm_device *drm_dev, struct device *dev);
> -int exynos_dpi_remove(struct drm_device *drm_dev, struct device *dev);
> -struct device_node *exynos_dpi_of_find_panel_node(struct device *dev);
> +struct exynos_drm_display * exynos_dpi_probe(struct device *dev);
> +int exynos_dpi_remove(struct device *dev);
>  #else
> -static inline int exynos_dpi_probe(struct drm_device *drm_dev,
> -   struct device *dev) { return 0; }
> -static inline int exynos_dpi_remove(struct drm_device *drm_dev,
> -   struct device *dev) { return 0; }
> -static inline struct device_node
> -   *exynos_dpi_of_find_panel_node(struct