[GIT PULL v2] exynos-drm-next
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
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)
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(&msg, 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, &msg); > + 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(&msg, 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, &msg); > 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, &msg); > + > + 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)
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&query=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
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)
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
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
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
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(&msg, 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 = &buf; Maybe just pass NULL and let buggy implementations explode? > + msg.size = 0; > + err = drm_dp_i2c_do_msg(aux, &msg); > + 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(&msg, 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, &msg); > 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 = &buf; Another chance to make buggy drivers explode ;) > + msg.size = 0; > + (void)drm_dp_i2c_do_msg(aux, &msg); > + > + 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)
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
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
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
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&action=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
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&action=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
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
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(&msg, 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 = &buf; > + msg.size = 0; > + err = drm_dp_i2c_do_msg(aux, &msg); > + 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(&msg, 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, &msg); > 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 = &buf; > + msg.size = 0; > + (void)drm_dp_i2c_do_msg(aux, &msg); > + > + 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
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 > M: Kumar Gala > L: devicetree at
[PATCH 2/2] drm/exynos/fbdev: don't set mode_config.fb_base
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}
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
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&Ville) - 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
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(&bo->lru)); man = &bdev->man[bo->mem.mem_type]; - list_add_tail(&bo->lru, &man->lru); + + if (bdev->use_pqueue && bo->mem.mem_type == TTM_PL_VRAM) + ttm_prio_add(&man->pqueue, &bo->pqueue); + else + list_add_tail(&bo->lru, &man->lru); + kref_get(&bo->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 = &bdev->man[bo->mem.mem_type]; if (!list_empty(&bo->swap)) { list_del_init(&bo->swap); @@ -194,6 +201,10 @@ int ttm_bo_del_from_lru(struct ttm_buffer_object *bo) if (!list_empty(&bo->lru)) { list_del_init(&bo->lru); ++put_count; + } else if (bdev->use_pqueue && bo->mem.mem_type == TTM_PL_VRAM && + ttm_prio_is_queued(&bo->pqueue)) { + ttm_prio_remove(&man->pqueue, &bo->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(&glob->lru_lock); - list_for_each_entry(bo, &man->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(&man->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, &man->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(&bo->ddestroy); INIT_LIST_HEAD(&bo->swap); INIT_LIST_HEAD(&bo->io_reserve_lru); + ttm_prio_init_entry(&bo->pqueue); mutex_init(&bo->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(&glob->lru_lock); - while (!list_empty(&man->lru)) { - spin_unlock(&glob->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(&man->pqueue)) { + spin_unlock(&glob->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(&glob->lru_lock); + } + } else { + while (!list_empty(&man->lru)) { + spin_unlock(&glob->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(&glob->lru_lock); } - spin_lock(&glob->lru_lock); } spin_unlock(&glob->lru_lock); return 0; @@ -1338,6 +1377,7 @@ int ttm_bo_init_mm(struct ttm_bo_device *bdev, unsigned type, man->size
[PATCH 4/4] Revert "drm/exynos: add mout_hdmi clock in hdmi driver to change parent"
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
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
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
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
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) &nouveau_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, &qxl_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 caf7cd
[PATCH 0/4] Update to Exynos clocks
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
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(&data->node, parent, where); + rb_insert_color(&data->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 = &root->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 = &queue->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, &parent, &place); + + if (!test) + ttm_prio_insert_rb(tree, entry, parent, place); + else + list_add_tail(&entry->list, &test->list); +} + +struct ttm_pqueue_entry *ttm_prio_query_lowest(const struct ttm_pqueue * const queue) +{ + const struct rb_root * const root = &queue->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 = &queue->tree; + + if (list
[RFC 0/3] TTM priority queue logic
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
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
> -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
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
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
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
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
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
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, &ack); - 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(&radeon_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_devi
[PATCH 3/4] drm/dp/i2c: Update comments about common i2c over dp assumptions
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)
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(&msg, 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, &msg); + 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(&msg, 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, &msg); 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, &msg); + + 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
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, &ack); @@ -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, &ack); 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)
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
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 = <&fimd>, <&dsi>; > }; > > In case of using DisplayPort, > display-subsystem { > compatible = "samsung,exynos-display-subsystem"; > ports = <&fimd>, <&dp>; > }; > > In case of using Parallel panel, > display-subsystem { > compatible = "samsung,exynos-display-subsystem"; > ports = <&fimd>; > }; > > 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
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&action=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
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&action=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
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
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
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
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
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
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)
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
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, &ack); - 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(&radeon_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_devi
[PATCH 3/4] drm/dp/i2c: Update comments about common i2c over dp assumptions
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)
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(&msg, 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, &msg); + 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(&msg, 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, &msg); 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, &msg); + + 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
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, &ack); @@ -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, &ack); 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)
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)
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)
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)
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
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?
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
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
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
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
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&action=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
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&action=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
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&action=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
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
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
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, &ack); - 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(&radeon_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_devi
[PATCH 2/3] drm/dp/i2c: send bare addresses to properly reset i2c connections
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(&msg, 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 = &buf; + msg.size = 0; + err = drm_dp_i2c_do_msg(aux, &msg); + 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(&msg, 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, &msg); 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 = &buf; + msg.size = 0; + (void)drm_dp_i2c_do_msg(aux, &msg); + + 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
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, &ack); @@ -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, &ack); 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
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)
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
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 *) > &ovr->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
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
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
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
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
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
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 *) &ovr- > >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
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
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
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
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
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
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
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
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?
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
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 = <&gpx3 7 1>; >> ddc = <&hdmi_ddc_node>; >> phy = <&hdmi_phy_node>; >> + samsung,syscon-phandle = <&pmu_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
[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. Best regards, Tomasz
[Bug 42960] Display does not work when resuming from suspend
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
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
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
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
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
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, &ctx->connector); >> - } >> + if (!ctx->panel->connector) >> + drm_panel_attach(ctx->panel, &ctx->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, &exynos_dpi_display); >> + return &exynos_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 de
[PATCH] drm/exynos: separate dpi from fimd
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, &ctx->connector); > - } > + if (!ctx->panel->connector) > + drm_panel_attach(ctx->panel, &ctx->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, &exynos_dpi_display); > + return &exynos_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(
[PATCH] drm/exynos: separate dpi from fimd
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, &ctx->connector); > - } > + if (!ctx->panel->connector) > + drm_panel_attach(ctx->panel, &ctx->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, &exynos_dpi_display); > + return &exynos_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_fin