[GIT PULL]: dma-buf updates for 3.4

Hi Linus, Could you please pull the dma-buf updates for 3.4? This includes the following key items: - kernel cpu access support, - flag-passing to dma_buf_fd, - relevant Documentation updates, and - some minor cleanups and fixes. These changes are needed for the drm prime/dma-buf interface code

[PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

According to i915 documentation [1], Port D (DP/HDMI Port D) is actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b). Pin pair 7 is a reserved pair. [1] Documentation for [DevSNB+] and [DevIBX], as found on http://intellinuxgraphics.org Note: the reserved and disabled pairs do not

[PATCH 04/11 v3] drm/i915/intel_i2c: cleanup gmbus/gpio pin assignments

There is no GMBUS disabled port 0, nor reserved port 7. For the other 6 ports there is a fixed 1:1 mapping between pin pairs and gmbus ports, which means every real gmbus port has a gpio pin. Given these realizations, clean up gmbus initialization. Tested on Sandybridge (gen 6, PCH ==

[PATCH 00/11 v3] fix gmbus writes and related issues

This patchset addresses a couple of issues with the i915 gmbus implementation: * fixes misassigned pin port pair for HDMI-D * fixes write transactions when they are the only transaction requested (including large 4-byte writes) by terminating every transaction with a WAIT cycle. * returns

[PATCH 01/11 v3] drm/i915/intel_i2c: cleanup

80 col, spaces around operators and other basic cleanup. Some info message cleanup. Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/i915/intel_i2c.c | 32 +--- 1 files changed, 21 insertions(+), 11 deletions(-) diff --git

[PATCH 10/11 v3] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

It is very common for an i2c device to require a small 1 or 2 byte write followed by a read. For example, when reading from an i2c EEPROM it is common to write and address, offset or index followed by a reading some values. The i915 gmbus controller provides a special INDEX cycle for performing

[PATCH 03/11 v3] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

Instead of rolling our own custom quirk_xfer function, use the bit_algo pre_xfer and post_xfer functions to setup and teardown bit-banged i2c transactions. gmbus_xfer uses .force_bit to determine which i2c_algorithm to use, either i2c_bit_algo.master_xfer or its own. So, Similarly, let

[PATCH 07/11 v3] drm/i915/intel_i2c: handle zero-length writes

A common method of probing an i2c bus is trying to do a zero-length write. Handle this case by checking the length first before decrementing it. This is actually important, since attempting a zero-length write is one of the ways that i2cdetect and i2c_new_probed_device detect whether there is

[PATCH 05/11 v3] drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

This memory is always allocated, and it is always a fixed size, so just allocate it along with the rest of the driver state. Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/i915/i915_drv.h |2 +- drivers/gpu/drm/i915/intel_i2c.c | 10 -- 2 files changed, 1

[PATCH 11/11 v3] drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop

Save the GMBUS2 value read while polling for state changes, and then reuse this value when determining for which reason the loops were exited. This is a small optimization which saves a couple of bus accesses for memory mapped IO registers. Signed-off-by: Daniel Kurtz djku...@chromium.org

[PATCH 09/11 v3] drm/i915/intel_i2c: use WAIT cycle, not STOP

The i915 is only able to generate a STOP cycle (i.e. finalize an i2c transaction) during a DATA or WAIT phase. In other words, the controller rejects a STOP requested as part of the first transaction in a sequence. Thus, for the first transaction we must always use a WAIT cycle, detect when the

[PATCH 06/11 v3] drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter

Instead of letting other modules directly access the -gmbus array, introduce a new API, intel_gmbus_get_adapter(), to lookup an i2c_adapter for a given gmbus pin pair identifier. This API enables later refactoring of the gmbus pin pair list. Note: The gmbus pin must be checked for validity

Re: [git pull] drm main pull for 3.4-rc1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/03/12 15:32, Daniel Vetter wrote: Ok, this is ugly. Do you have any special module options for i915 set (like i915_enable_rc6)? None set: adrastea ~ # cat /proc/cmdline BOOT_IMAGE=3.3.0-04074-g53 rw root=0 Also, can you check whether

Re: [git pull] drm main pull for 3.4-rc1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/03/12 15:32, Daniel Vetter wrote: Also, can you check whether disabling vt-d does work around the issue? Yes, that does appear to stay operational for longer on: Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Mon Mar 26 11:29:21 BST 2012

Re: [PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

On Mon, Mar 26, 2012 at 11:08 PM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Mar 26, 2012 at 04:47:11PM +0200, Daniel Vetter wrote: On Mon, Mar 26, 2012 at 10:26:41PM +0800, Daniel Kurtz wrote: According to i915 documentation [1], Port D (DP/HDMI Port D) is actually gmbus pin pair 6

Re: [PATCH 03/11 v3] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

On Mon, Mar 26, 2012 at 10:49 PM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote: Instead of rolling our own custom quirk_xfer function, use the bit_algo pre_xfer and post_xfer functions to setup and teardown bit-banged i2c transactions.

RE: [lm-sensors] Incorrect Temperature Readings

-I've been running the computer for over an hour currently and it feels perfectly fine. Even the hard drive feels only mildly warm. Nonetheless, I'm getting 96C readings for my PCI Adapter. Is there a way to modify my /etc/sensors.conf file to change the input levels or high/crit temps for

Re: [lm-sensors] Incorrect Temperature Readings

Hi Scott, Please don't top-post. On Mon, 26 Mar 2012 15:59:56 -0400, Scott Ondercin wrote: -I've been running the computer for over an hour currently and it feels perfectly fine. Even the hard drive feels only mildly warm. Nonetheless, I'm getting 96C readings for my PCI Adapter. Is

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #7 from Artyom Kunyov art...@guitarplayer.ru 2012-03-27 06:57:00 --- (In reply to comment #6) I have tried booting with both nouveau and nvidia blacklisted in console mode and still get the same behaviour. As mention in

[Bug 47039] radeon: The kernel rejected CS

https://bugs.freedesktop.org/show_bug.cgi?id=47039 Sylvain Réault vindicato...@yahoo.fr changed: What|Removed |Added Status|RESOLVED|CLOSED --

Re: [PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

On Tue, Mar 27, 2012 at 01:49:51AM +0800, Daniel Kurtz wrote: I'm not sure what a Bspec is, but here is the documents I used: [DevSNB+]: http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf Section 2.2.2 lists the 6 gmbus ports (gpio pin pairs): [ 5: HDMI/DPD, 4: HDMIB,

Re: WARNING: at drivers/gpu/drm/radeon/radeon_object.c:236

On Die, 2012-03-27 at 17:21 +1100, Benjamin Herrenschmidt wrote: On Mon, 2012-03-26 at 17:32 -0400, Dave Jones wrote: Seeing this in Linus' tree as of v3.3-6972-ge22057c Same WARN_ON hit here on a G5 with rv350 Thanks for the report, guys. Does the patch

i915_driver_irq_handler: irq 42: nobody cared

Hi, I'm getting spurious interrupts leading to disabling the interrupt: 42:19168532471662 PCI-MSI-edge i915@pci::00:02.0 The message: irq 42: nobody cared (try booting with the irqpoll option) Pid: 20716, comm: virtuoso-t Not tainted 3.3.0-next-20120326_64+ #1673 It is not

Re: i915_driver_irq_handler: irq 42: nobody cared

On 03/27/2012 10:40 AM, Jiri Slaby wrote: Hi, I'm getting spurious interrupts leading to disabling the interrupt: 42:19168532471662 PCI-MSI-edge i915@pci::00:02.0 The message: irq 42: nobody cared (try booting with the irqpoll option) Pid: 20716, comm: virtuoso-t Not

Re: i915_driver_irq_handler: irq 42: nobody cared

On Tue, Mar 27, 2012 at 10:40:03AM +0200, Jiri Slaby wrote: Hi, I'm getting spurious interrupts leading to disabling the interrupt: 42:19168532471662 PCI-MSI-edge i915@pci::00:02.0 The message: irq 42: nobody cared (try booting with the irqpoll option) Pid: 20716,

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #11 from Jon Dowland jon+bugzilla.kernel@alcopop.org 2012-03-27 09:21:24 --- Sadly, this patch doesn't seem to solve it. I'll add a printk and re-try just to be doubly sure I'm not messing things up and loading the wrong

[PATCH] drm: base prime/dma-buf support (v5)

From: Dave Airlie airl...@redhat.com This adds the basic drm dma-buf interface layer, called PRIME, The main APIs exposed to userspace allow translating a 32-bit object handle to a file descriptor, and a file descriptor to a 32-bit object handle. The flags value is currently limited to

[Bug 46724] radeon_drm_winsys compile fail with libdrm in non standard directory

https://bugs.freedesktop.org/show_bug.cgi?id=46724 va...@gmx.de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

Re: [git pull] drm main pull for 3.4-rc1

On Mon, Mar 26, 2012 at 03:36:53PM +0100, Tony Vroon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/03/12 15:32, Daniel Vetter wrote: Ok, this is ugly. Do you have any special module options for i915 set (like i915_enable_rc6)? None set: adrastea ~ # cat /proc/cmdline

Re: [RFCv2 PATCH 4/9] v4l: add buffer exporting via dmabuf

Hi Tomasz, On Friday 23 March 2012 12:33:24 Tomasz Stanislawski wrote: On 03/22/2012 12:16 PM, Laurent Pinchart wrote: On Tuesday 13 March 2012 11:17:02 Tomasz Stanislawski wrote: [snip] + case VIDIOC_EXPBUF: + { + struct v4l2_exportbuffer *p = arg; + + if

Re: [RFCv2 PATCH 7/9] v4l: vb2-dma-contig: change map/unmap behaviour

Hi Daniel, On Thursday 22 March 2012 13:25:20 Daniel Vetter wrote: On Thu, Mar 22, 2012 at 13:15, Laurent Pinchart wrote: On Tuesday 13 March 2012 11:17:05 Tomasz Stanislawski wrote: The DMABUF documentation says that the map_dma_buf callback should return scatterlist that is mapped into a

[Bug 47900] Sampler does not work with cubemaps in 16-bit floating-point pixel format

https://bugs.freedesktop.org/show_bug.cgi?id=47900 Vic Lee ll...@163.com changed: What|Removed |Added Summary|Sampler does not work with |Sampler does not work with

[Bug 47900] Sampler does not work with cubemaps in 16-bit floating-point pixel format

https://bugs.freedesktop.org/show_bug.cgi?id=47900 --- Comment #1 from Vic Lee ll...@163.com 2012-03-27 03:53:10 PDT --- EDIT: Only PIPE_FORMAT_R16G16B16A16_FLOAT does not work. 16-bit integer types work. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are

Re: i915_driver_irq_handler: irq 42: nobody cared

On 03/27/2012 10:57 AM, Daniel Vetter wrote: And please mind the guy with bad memory and tell us which chip you have again? Where's that? In xorg.log: https://bugs.freedesktop.org/attachment.cgi?id=58771 ? (II) intel(0): Integrated Graphics Chipset: Intel(R) G33 (--) intel(0): Chipset: G33

Re: [Linaro-mm-sig] [PATCH] drm: base prime/dma-buf support (v5)

On Tue, Mar 27, 2012 at 10:47:46AM +0100, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com This adds the basic drm dma-buf interface layer, called PRIME, The main APIs exposed to userspace allow translating a 32-bit object handle to a file descriptor, and a file descriptor to a

[git pull] drm fixes

Hi Linus, gma500 build fix + some regression fixes for nouveau/radeon, along with one radeon patch that was posted a while ago and I missed and it also required rebasing around some other stuff. Dave. The following changes since commit e22057c8599373e5caef0bc42bdb95d2a361ab0d: Merge tag

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #12 from Alex Deucher alexdeuc...@gmail.com 2012-03-27 13:41:08 --- Created an attachment (id=72731) -- (https://bugzilla.kernel.org/attachment.cgi?id=72731) alternate fix After you verify the first patch does not fix the

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #13 from Alex Deucher alexdeuc...@gmail.com 2012-03-27 13:42:05 --- Ignore the last hunk of that patch (rv770.c). -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail

Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring

Hi Tomasz, On Thursday 22 March 2012 16:58:27 Tomasz Stanislawski wrote: On 03/22/2012 03:42 PM, Laurent Pinchart wrote: On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote: On 03/22/2012 11:50 AM, Laurent Pinchart wrote: On Thursday 22 March 2012 11:02:23 Laurent Pinchart wrote:

Re: [Linaro-mm-sig] [PATCH] drm: base prime/dma-buf support (v5)

On Tue, Mar 27, 2012 at 6:46 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Mar 27, 2012 at 10:47:46AM +0100, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com This adds the basic drm dma-buf interface layer, called PRIME, The main APIs exposed to userspace allow translating a 32-bit

Re: [ANNOUNCE] kmscon: Lazy-web's DRM based terminal emulator

On Tue, Mar 27, 2012 at 04:57:29PM +0200, David Herrmann wrote: It needs some more work in the VTE layer and on the UI but it's I had several issues while writing it but most of them are fixed. One thing I remember is a performance issue running it on my Intel Atom N450. With 80x24 it works

Re: [PATCH] drm: base prime/dma-buf support (v5)

2012년 3월 28일 수요일에 Sumit Semwalsumit.sem...@linaro.org님이 작성: On Mar 27, 2012 9:18 PM, Rob Clark robdcl...@gmail.com wrote: On Tue, Mar 27, 2012 at 6:46 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Mar 27, 2012 at 10:47:46AM +0100, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com

[Bug 47765] Corrupt rendering to a window between 57 and 63 pixels high

https://bugs.freedesktop.org/show_bug.cgi?id=47765 --- Comment #4 from Jerome Glisse gli...@freedesktop.org 2012-03-27 09:30:15 PDT --- Please attach patch corresponding to 9b3ad51ae5fd9654df8ef75de845a519015150bb -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email

Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring

On Tue, Mar 27, 2012 at 11:01 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Tomasz, On Thursday 22 March 2012 16:58:27 Tomasz Stanislawski wrote: On 03/22/2012 03:42 PM, Laurent Pinchart wrote: On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski wrote: On 03/22/2012

Re: [Linaro-mm-sig] [RFCv2 PATCH 2/9 - 4/4] v4l: vb2-dma-contig: update and code refactoring

Hi Jerome, On Tuesday 27 March 2012 12:45:23 Jerome Glisse wrote: On Tue, Mar 27, 2012 at 11:01 AM, Laurent Pinchart wrote: On Thursday 22 March 2012 16:58:27 Tomasz Stanislawski wrote: On 03/22/2012 03:42 PM, Laurent Pinchart wrote: On Thursday 22 March 2012 14:36:33 Tomasz Stanislawski

[Bug 47955] New: Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 Bug #: 47955 Summary: Celestia hit fallback on r300g from git? Classification: Unclassified Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All)

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #1 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 10:46:04 PDT --- Created attachment 59120 -- https://bugs.freedesktop.org/attachment.cgi?id=59120 dmesg -- Configure bugmail:

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #2 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 10:47:05 PDT --- Created attachment 59121 -- https://bugs.freedesktop.org/attachment.cgi?id=59121 lspci -vvvn -- Configure bugmail:

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 Marek Olšák mar...@gmail.com changed: What|Removed |Added Component|Drivers/DRI/r300|Drivers/Gallium/r300 --

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 Marek Olšák mar...@gmail.com changed: What|Removed |Added Component|Drivers/DRI/r300|Drivers/Gallium/r300 ---

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #4 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 10:48:58 PDT --- Created attachment 59123 -- https://bugs.freedesktop.org/attachment.cgi?id=59123 glxinfo -- Configure bugmail:

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #5 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 10:49:41 PDT --- Created attachment 59124 -- https://bugs.freedesktop.org/attachment.cgi?id=59124 rs600's rom (from sysfs) -- Configure bugmail:

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #6 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 10:50:16 PDT --- Created attachment 59125 -- https://bugs.freedesktop.org/attachment.cgi?id=59125 Screenshot -- Configure bugmail:

[Bug 47955] Celestia hit fallback on r300g from git?

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #7 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 11:24:08 PDT --- Mesa was compiled with ./configure --prefix=/usr/X11R7 --disable-egl --enable-gallium-llvm --with-gallium-drivers=i915 nouveau r600 r300 swrast

Re: [PATCH 09/13 v4] drm/i915/intel_i2c: use double-buffered writes

On Wed, 28 Mar 2012 02:36:18 +0800, Daniel Kurtz djku...@chromium.org wrote: @@ -276,6 +269,13 @@ gmbus_xfer_write(struct drm_i915_private *dev_priv, struct i2c_msg *msg, I915_WRITE(GMBUS3 + reg_offset, val); POSTING_READ(GMBUS2 + reg_offset); You might as well

Re: [PATCH 02/13 v4] drm/i915/intel_i2c: cleanup error messages and comments

On Wed, 28 Mar 2012 02:36:11 +0800, Daniel Kurtz djku...@chromium.org wrote: Signed-off-by: Daniel Kurtz djku...@chromium.org Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing

[Bug 47765] Corrupt rendering to a window between 57 and 63 pixels high

https://bugs.freedesktop.org/show_bug.cgi?id=47765 --- Comment #5 from Jerome Glisse gli...@freedesktop.org 2012-03-27 11:49:06 PDT --- Created attachment 59126 -- https://bugs.freedesktop.org/attachment.cgi?id=59126 use linear aligned Does this patch against ddx help ? -- Configure

Re: [PATCH 04/13 v4] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

On Wed, 28 Mar 2012 02:36:13 +0800, Daniel Kurtz djku...@chromium.org wrote: Instead of rolling our own custom quirk_xfer function, use the bit_algo pre_xfer and post_xfer functions to setup and teardown bit-banged i2c transactions. Signed-off-by: Daniel Kurtz djku...@chromium.org

Re: [PATCH 13/13 v4] drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop

On Wed, 28 Mar 2012 02:36:22 +0800, Daniel Kurtz djku...@chromium.org wrote: Save the GMBUS2 value read while polling for state changes, and then reuse this value when determining for which reason the loops were exited. This is a small optimization which saves a couple of bus accesses for

Re: [PATCH 01/13 v4] drm/i915/intel_i2c: refactor gmbus_xfer

On Wed, 28 Mar 2012 02:36:10 +0800, Daniel Kurtz djku...@chromium.org wrote: Split out gmbus_xfer_read/write() helper functions. Signed-off-by: Daniel Kurtz djku...@chromium.org Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH 08/13 v4] drm/i915/intel_i2c: handle zero-length writes

On Wed, 28 Mar 2012 02:36:17 +0800, Daniel Kurtz djku...@chromium.org wrote: A common method of probing an i2c bus is trying to do a zero-length write. Handle this case by checking the length first before decrementing it. This is actually important, since attempting a zero-length write is one

Re: [PATCH 10/13 v4] drm/i915/intel_i2c: always wait for IDLE before clearing NAK

On Wed, 28 Mar 2012 02:36:19 +0800, Daniel Kurtz djku...@chromium.org wrote: The GMBUS controller can report a NAK condition while a transaction is still active. If the driver is fast enough, and the bus is slow enough, the driver may clear the NAK condition while the controller is still busy,

Re: [git pull] drm main pull for 3.4-rc1

On Mon, Mar 26, 2012 at 03:44:33PM +0100, Tony Vroon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/03/12 15:32, Daniel Vetter wrote: Also, can you check whether disabling vt-d does work around the issue? Yes, that does appear to stay operational for longer on: Linux

Re: [git pull] drm main pull for 3.4-rc1

On Tue, Mar 27, 2012 at 09:31:24PM +0200, Daniel Vetter wrote: On Mon, Mar 26, 2012 at 03:44:33PM +0100, Tony Vroon wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/03/12 15:32, Daniel Vetter wrote: Also, can you check whether disabling vt-d does work around the issue?

RE: [BUG] Warning at radeon_object.c:236 with latest Linus kernel

:14 -0400, Steven Rostedt wrote: You can get the full dmesg here: http://rostedt.homelinux.com/private/dmesg-bxf-20120327 And the config is here: http://rostedt.homelinux.com/private/config-bxf-20120327 Can you try this patch: http://lists.freedesktop.org/archives/dri-devel/2012-March

Re: WARNING: at drivers/gpu/drm/radeon/radeon_object.c:236

On Tue, 2012-03-27 at 20:21 -0400, Dave Jones wrote: Stops the warning, and there are no additional side-effects, so looks all good here. Same. Tested-by: Dave Jones da...@redhat.com Tested-by: Benjamin Herrenschmidt b...@kernel.crashing.org thanks, Dave

Re: [Linaro-mm-sig] [PATCH] drm: base prime/dma-buf support (v5)

On Tue, 27 Mar 2012 10:47:46 +0100 Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com This adds the basic drm dma-buf interface layer, called PRIME, The main APIs exposed to userspace allow translating a 32-bit object handle to a file descriptor, and a file

[PATCH 05/13 v4] drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter

Instead of letting other modules directly access the -gmbus array, introduce intel_gmbus_get_adapter() for looking up an i2c_adapter for a given gmbus port identifier. This will enable later refactoring of the gmbus port list. Note: Before requesting an adapter for a given gmbus port number, the

[PATCH 00/13 v4] fix gmbus writes and related issues

This patchset addresses a couple of issues with the i915 gmbus implementation: * fixes misassigned pin port pair for HDMI-D * fixes write transactions when they are the only transaction requested (including large 4-byte writes) by terminating every transaction with a WAIT cycle. * returns

Re: [git pull] drm main pull for 3.4-rc1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/03/12 11:01, Daniel Vetter wrote: Another thing for you to try is booting with i915.i915_enable_ppgtt=0 (and vt-d enabled of course). That appears to be a winner: adrastea ~ # uname -a Linux adrastea 3.3.0-06972-ge22057c #1 SMP PREEMPT Tue

Re: [git pull] drm main pull for 3.4-rc1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/03/12 11:11, Tony Vroon wrote: No DMAR complaints in dmesg yet; it would have crashed by now if the fault was present. To confirm, it is stable. So ppgtt + VT-d is problematic on: 00:02.0 VGA compatible controller [0300]: Intel Corporation

Re: [Linaro-mm-sig] [PATCH] drm: base prime/dma-buf support (v5)

On Mar 27, 2012 9:18 PM, Rob Clark robdcl...@gmail.com wrote: On Tue, Mar 27, 2012 at 6:46 AM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Mar 27, 2012 at 10:47:46AM +0100, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com This adds the basic drm dma-buf interface layer, called

[PATCH 02/13 v4] drm/i915/intel_i2c: cleanup error messages and comments

Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/i915/intel_i2c.c | 11 +++ 1 files changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c index 30675ce..e6c090b 100644 ---

[PATCH 08/13 v4] drm/i915/intel_i2c: handle zero-length writes

A common method of probing an i2c bus is trying to do a zero-length write. Handle this case by checking the length first before decrementing it. This is actually important, since attempting a zero-length write is one of the ways that i2cdetect and i2c_new_probed_device detect whether there is

[PATCH 03/13 v4] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

According to i915 documentation [1], Port D (DP/HDMI Port D) is actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b). Pin pair 7 is a reserved pair. [1] Documentation for [DevSNB+] and [DevIBX], as found on http://intellinuxgraphics.org: [DevSNB+]:

[PATCH 01/13 v4] drm/i915/intel_i2c: refactor gmbus_xfer

Split out gmbus_xfer_read/write() helper functions. Signed-off-by: Daniel Kurtz djku...@chromium.org --- drivers/gpu/drm/i915/intel_i2c.c | 151 +++--- 1 files changed, 92 insertions(+), 59 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_i2c.c

[PATCH 07/13 v4] drm/i915/intel_i2c: allocate gmbus array as part of drm_i915_private

This memory is always allocated, and it is always a fixed size, so just allocate it along with the rest of the driver state. Signed-off-by: Daniel Kurtz djku...@chromium.org Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/i915_drv.h |2 +-

[PATCH 12/13 v4] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

It is very common for an i2c device to require a small 1 or 2 byte write followed by a read. For example, when reading from an i2c EEPROM it is common to write and address, offset or index followed by a reading some values. The i915 gmbus controller provides a special INDEX cycle for performing

[PATCH 06/13 v4] drm/i915/intel_i2c: gmbus disabled and reserved ports are invalid

There is no GMBUS disabled port 0, nor reserved port 7. For the other 6 ports there is a fixed 1:1 mapping between pin pairs and gmbus ports, which means every real gmbus port has a gpio pin. Given these realizations, clean up gmbus initialization. Tested on Sandybridge (gen 6, PCH ==

[PATCH 09/13 v4] drm/i915/intel_i2c: use double-buffered writes

The GMBUS controller GMBUS3 register is double-buffered. Take advantage of this by writing two 4-byte words before the first wait for HW_RDY. This helps keep the GMBUS controller from becoming idle during long writes. Signed-off-by: Daniel Kurtz djku...@chromium.org ---

[PATCH 04/13 v4] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

Instead of rolling our own custom quirk_xfer function, use the bit_algo pre_xfer and post_xfer functions to setup and teardown bit-banged i2c transactions. Signed-off-by: Daniel Kurtz djku...@chromium.org Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch --- drivers/gpu/drm/i915/intel_i2c.c |

[PATCH 13/13 v4] drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop

Save the GMBUS2 value read while polling for state changes, and then reuse this value when determining for which reason the loops were exited. This is a small optimization which saves a couple of bus accesses for memory mapped IO registers. To avoid assigning in if clause checkpatch errors, use a

[PATCH 11/13 v4] drm/i915/intel_i2c: use WAIT cycle, not STOP

The i915 is only able to generate a STOP cycle (i.e. finalize an i2c transaction) during a DATA or WAIT phase. In other words, the controller rejects a STOP requested as part of the first transaction in a sequence. Thus, for the first transaction we must always use a WAIT cycle, detect when the

[PATCH] drm: base prime/dma-buf support

Reviewed-by: Inki Dae 2012. 3. 27. ?? 12:02 Dave Airlie ??: > From: Dave Airlie > > This adds the basic drm dma-buf interface layer, called PRIME, > > The main APIs exposed to userspace allow translating a 32-bit object handle > to a file descriptor, and a file descriptor to a 32-bit object

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 ArTourter changed: What|Removed |Added CC||artourter at gmail.com --- Comment #6

[Bug 42941] Resume from suspend to memory leaves display blank on Lenovo Ideapad U455

https://bugzilla.kernel.org/show_bug.cgi?id=42941 Len Brown changed: What|Removed |Added CC||lenb at kernel.org

[PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

On Mon, Mar 26, 2012 at 11:08 PM, Daniel Vetter wrote: > > On Mon, Mar 26, 2012 at 04:47:11PM +0200, Daniel Vetter wrote: > > On Mon, Mar 26, 2012 at 10:26:41PM +0800, Daniel Kurtz wrote: > > > According to i915 documentation [1], "Port D" (DP/HDMI Port D) is > > > actually gmbus pin pair 6

[PATCH 03/11 v3] drm/i915/intel_i2c: use i2c pre/post_xfer functions to setup gpio xfers

On Mon, Mar 26, 2012 at 10:49 PM, Daniel Vetter wrote: > On Mon, Mar 26, 2012 at 10:26:42PM +0800, Daniel Kurtz wrote: >> Instead of rolling our own custom quirk_xfer function, use the bit_algo >> pre_xfer and post_xfer functions to setup and teardown bit-banged >> i2c transactions. >> >>

[lm-sensors] Incorrect Temperature Readings

Hi Scott, Please don't top-post. On Mon, 26 Mar 2012 15:59:56 -0400, Scott Ondercin wrote: > -I've been running the computer for over an hour currently and it feels > perfectly fine. Even the hard drive feels only mildly warm. Nonetheless, > I'm getting 96C readings for my PCI Adapter. > >

[Bug 42876] System doesn't boot with GTX 550 Ti

https://bugzilla.kernel.org/show_bug.cgi?id=42876 --- Comment #7 from Artyom Kunyov 2012-03-27 06:57:00 --- (In reply to comment #6) > I have tried booting with both nouveau and nvidia blacklisted in console mode > and still get the same behaviour. > > As mention in comment #4, acpi=off

[Bug 47039] radeon: The kernel rejected CS

https://bugs.freedesktop.org/show_bug.cgi?id=47039 Sylvain R?ault changed: What|Removed |Added Status|RESOLVED|CLOSED -- Configure bugmail:

[PATCH 02/11 v3] drm/i915/intel_i2c: assign HDMI port D to pin pair 6

On Tue, Mar 27, 2012 at 01:49:51AM +0800, Daniel Kurtz wrote: > I'm not sure what a "Bspec" is, but here is the documents I used: > > [DevSNB+]: > http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf > Section 2.2.2 lists the 6 gmbus ports (gpio pin pairs): > [ 5: HDMI/DPD, 4:

WARNING: at drivers/gpu/drm/radeon/radeon_object.c:236

On Die, 2012-03-27 at 17:21 +1100, Benjamin Herrenschmidt wrote: > On Mon, 2012-03-26 at 17:32 -0400, Dave Jones wrote: > > Seeing this in Linus' tree as of v3.3-6972-ge22057c > > Same WARN_ON hit here on a G5 with rv350 Thanks for the report, guys. Does the patch

i915_driver_irq_handler: irq 42: nobody cared

Hi, I'm getting spurious interrupts leading to disabling the interrupt: 42:19168532471662 PCI-MSI-edge i915 at pci::00:02.0 The message: irq 42: nobody cared (try booting with the "irqpoll" option) Pid: 20716, comm: virtuoso-t Not tainted 3.3.0-next-20120326_64+ #1673 It is

i915_driver_irq_handler: irq 42: nobody cared

On 03/27/2012 10:40 AM, Jiri Slaby wrote: > Hi, > > I'm getting spurious interrupts leading to disabling the interrupt: > 42:19168532471662 PCI-MSI-edge i915 at pci::00:02.0 > > The message: > irq 42: nobody cared (try booting with the "irqpoll" option) > Pid: 20716, comm:

i915_driver_irq_handler: irq 42: nobody cared

On Tue, Mar 27, 2012 at 10:40:03AM +0200, Jiri Slaby wrote: > Hi, > > I'm getting spurious interrupts leading to disabling the interrupt: > 42:19168532471662 PCI-MSI-edge i915 at pci::00:02.0 > > The message: > irq 42: nobody cared (try booting with the "irqpoll" option) >

[Bug 29412] fans running at full-speed after resume from suspend with radeon and KMS

https://bugzilla.kernel.org/show_bug.cgi?id=29412 --- Comment #11 from Jon Dowland 2012-03-27 09:21:24 --- Sadly, this patch doesn't seem to solve it. I'll add a printk and re-try just to be doubly sure I'm not messing things up and loading the

[PATCH] drm: base prime/dma-buf support (v5)

From: Dave Airlie This adds the basic drm dma-buf interface layer, called PRIME, The main APIs exposed to userspace allow translating a 32-bit object handle to a file descriptor, and a file descriptor to a 32-bit object handle. The flags value is currently limited to

[Bug 46724] radeon_drm_winsys compile fail with libdrm in non standard directory

https://bugs.freedesktop.org/show_bug.cgi?id=46724 vand2 at gmx.de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[git pull] drm main pull for 3.4-rc1

On Mon, Mar 26, 2012 at 03:36:53PM +0100, Tony Vroon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 26/03/12 15:32, Daniel Vetter wrote: > > Ok, this is ugly. Do you have any special module options for i915 > > set (like i915_enable_rc6)? > > None set: > adrastea ~ # cat

  1   2   >