[PATCH] drm/i915: no-lvds quirk on MSI DC500

On Wed, Mar 28, 2012 at 11:43:23AM -0700, Jesse Barnes wrote: > Fine with me. > > Daniel? Contrary to the other quirks I've queued up for 3.5 this one is standalone, i.e. imo -fixes material. Keith? > > On Thu, 22 Mar 2012 23:12:38 +0100 > Anisse Astier wrote: > > > Hi again, > > > > Could

[PATCH 14/14 v5] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

On Wed, Mar 28, 2012 at 9:05 PM, Chris Wilson wrote: > On Wed, 28 Mar 2012 20:51:57 +0800, Daniel Kurtz > wrote: >> The POSTING_READ() calls were originally added to make sure the writes >> were flushed before any timing delays and across loops. >> However, the normal I915_READ() and

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

On Wed, Mar 28, 2012 at 10:30:20AM -0700, Jesse Barnes wrote: > On Tue, 27 Mar 2012 16:57:29 +0200 > David Herrmann wrote: > > > Hi > > > > Motivated by Jesse's letter to the lazyweb [1] I worked on a kmscon > > program. It provides a > > terminal-emulator similar to the in-kernel

[PATCH 14/14 v5] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

The POSTING_READ() calls were originally added to make sure the writes were flushed before any timing delays and across loops. However, the normal I915_READ() and I915_WRITE() macros already call readl() / writel(), which already have an explicit mb(). Now that the code has settled a bit, let's

[PATCH 13/14 v5] 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",

[PATCH 12/14 v5] 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

[PATCH 11/14 v5] 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 10/14 v5] drm/i915/intel_i2c: always wait for IDLE before clearing NAK

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, resulting in a confused GMBUS controller. This will leave the controller in a

[PATCH 09/14 v5] 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 --- drivers/gpu/drm/i915/intel_i2c.c | 14

[PATCH 08/14 v5] 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 07/14 v5] 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 Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.h |2 +- drivers/gpu/drm/i915/intel_i2c.c | 10 -- 2 files

[PATCH 06/14 v5] 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 05/14 v5] 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,

[PATCH 04/14 v5] 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 Reviewed-by: Daniel Vetter Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/intel_i2c.c | 60

[PATCH 03/14 v5] 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 02/14 v5] drm/i915/intel_i2c: cleanup error messages and comments

Signed-off-by: Daniel Kurtz Reviewed-by: Chris Wilson --- 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 01/14 v5] drm/i915/intel_i2c: refactor gmbus_xfer

Split out gmbus_xfer_read/write() helper functions. Signed-off-by: Daniel Kurtz Reviewed-by: Chris Wilson --- 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 00/14 v5] 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. *

[PATCH 7/7 v6] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

On Thu, 29 Mar 2012 02:26:39 +0800, Daniel Kurtz wrote: > The POSTING_READ() calls were originally added to make sure the writes > were flushed before any timing delays and across loops. > Now that the code has settled a bit, let's remove them. > > Signed-off-by: Daniel Kurtz Reviewed-by:

[PATCH 6/7 v6] drm/i915/intel_i2c: reuse GMBUS2 value read in polling loop

On Thu, 29 Mar 2012 02:26:38 +0800, Daniel Kurtz 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 > memory mapped IO

[PATCH 5/7 v6] drm/i915/intel_i2c: use INDEX cycles for i2c read transactions

On Thu, 29 Mar 2012 02:26:37 +0800, Daniel Kurtz wrote: > 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. Hmm, I

[PATCH 4/7 v6] drm/i915/intel_i2c: use WAIT cycle, not STOP

On Thu, 29 Mar 2012 02:26:36 +0800, Daniel Kurtz wrote: > 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. The original

[PATCH 2/7 v6] drm/i915/intel_i2c: use double-buffered writes

On Thu, 29 Mar 2012 02:26:34 +0800, Daniel Kurtz wrote: > 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. > >

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

On Wed, Mar 28, 2012 at 3:02 AM, Chris Wilson wrote: > On Wed, 28 Mar 2012 02:36:22 +0800, Daniel Kurtz > 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

[PATCH 1/7 v6] drm/i915/intel_i2c: handle zero-length writes

On Thu, 29 Mar 2012 02:26:33 +0800, Daniel Kurtz 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 > of the ways

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

On Wed, Mar 28, 2012 at 3:14 AM, Chris Wilson wrote: > On Wed, 28 Mar 2012 02:36:17 +0800, Daniel Kurtz > 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

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #14 from Andrew Randrianasulu 2012-03-28 11:45:44 PDT --- (In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #7) > > > (I tried DRAW_NO_LLVM=1 - bug was still there). > > > > > > FWIW, that's not a

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #13 from Andrew Randrianasulu 2012-03-28 11:04:52 PDT --- (In reply to comment #12) > (In reply to comment #7) > > (I tried DRAW_NO_LLVM=1 - bug was still there). > > > FWIW, that's not a recognized environment variable. You

[RFCv2 PATCH 3/9] v4l: vb2: Add dma-contig allocator as dma_buf user

Hi Tomasz, On Monday 26 March 2012 17:53:09 Tomasz Stanislawski wrote: > On 03/22/2012 12:04 PM, Laurent Pinchart wrote: > > On Tuesday 13 March 2012 11:17:01 Tomasz Stanislawski wrote: [snip] > >> +static void vb2_dc_detach_dmabuf(void *mem_priv) > >> +{ > >> + struct vb2_dc_buf *buf =

[ANNOUNCE] libdrm 2.4.33

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher (2): radeon: add TN surface support configure: Bump version for 2.4.33 Kenneth Graunke (1): intel: Add some PCI IDs for Haswell. Rob Clark (1): omap: add omapdrm support git tag: 2.4.33

[PATCH 14/14 v5] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

On Wed, Mar 28, 2012 at 03:30:13PM +0100, Chris Wilson wrote: > On Wed, 28 Mar 2012 21:21:42 +0800, Daniel Kurtz > wrote: > > On Wed, Mar 28, 2012 at 9:05 PM, Chris Wilson > > wrote: > > > We do need the write flush here (and set_data) as the next action is a > > > udelay loop which is not

[PATCH libdrm] omap: add omapdrm support

Hi Rob, I've a couple of (minor) comments: On Wed, Mar 21, 2012 at 01:00:36PM -0500, Rob Clark wrote: > --- /dev/null > +++ b/omap/omap_drm.c [...] > +/* allocate a new (un-tiled) buffer object */ > +struct omap_bo * omap_bo_new(struct omap_device *dev, > + uint32_t size, uint32_t

[PATCH libdrm] omap: add omapdrm support

On Wed, Mar 28, 2012 at 3:39 PM, Rob Clark wrote: > From: Rob Clark > > This adds libdrm_omap helper layer (as used by xf86-video-omap, > omapdrmtest, etc). > > Signed-off-by: Rob Clark > --- > v1: original > v2: address comments from Luca Tettamanti > v3: fix SET vs GET typo that Alex Deucher

[PATCH 14/14 v5] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

On Wed, 28 Mar 2012 21:21:42 +0800, Daniel Kurtz wrote: > On Wed, Mar 28, 2012 at 9:05 PM, Chris Wilson > wrote: > > We do need the write flush here (and set_data) as the next action is a > > udelay loop which is not per-se a mb. > > Now I am confused. I915_WRITE_NOTRACE() calls writel(),

[PATCH libdrm] omap: add omapdrm support

On Wed, Mar 28, 2012 at 12:54 PM, Rob Clark wrote: > From: Rob Clark > > This adds libdrm_omap helper layer (as used by xf86-video-omap, > omapdrmtest, etc). > > Signed-off-by: Rob Clark A couple of comments below, other than that, Reviewed-by: Alex Deucher > --- > v1: original > v2:

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

On Wed, Mar 28, 2012 at 02:36:21AM +0800, Daniel Kurtz wrote: > 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. >

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

On Wed, Mar 28, 2012 at 02:36:16AM +0800, Daniel Kurtz wrote: > 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 > Reviewed-by: Daniel Vetter I've picked up all your patches up and

[PATCH libdrm] omap: add omapdrm support

From: Rob Clark This adds libdrm_omap helper layer (as used by xf86-video-omap, omapdrmtest, etc). Signed-off-by: Rob Clark --- v1: original v2: address comments from Luca Tettamanti v3: fix SET vs GET typo that Alex Deucher caught Makefile.am |6 +-

[PATCH libdrm] omap: add omapdrm support

On Wed, Mar 28, 2012 at 2:24 PM, Alex Deucher wrote: > On Wed, Mar 28, 2012 at 12:54 PM, Rob Clark wrote: >> From: Rob Clark >> >> This adds libdrm_omap helper layer (as used by xf86-video-omap, >> omapdrmtest, etc). >> >> Signed-off-by: Rob Clark > > A couple of comments below, other than

libdrm release?

On Wed, Mar 28, 2012 at 10:01 AM, Rob Clark wrote: > any chance to get libdrm_omap support in beforehand? ?(Or at least for > someone to review the patch and point out if some changes are needed?) > Sure. Can you point me to the patches again? I saw them go by, but they've now fallen below the

[PATCH 14/14 v5] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

On Wed, 28 Mar 2012 20:51:57 +0800, Daniel Kurtz wrote: > The POSTING_READ() calls were originally added to make sure the writes > were flushed before any timing delays and across loops. > However, the normal I915_READ() and I915_WRITE() macros already call > readl() / writel(), which already

[git pull] drm fixes

> 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. I've added one more commit to this. commit d936622c36273a9ecfbb4aacf26cd29405995159 Author: Michel D?nzer

libdrm release?

On Wed, Mar 28, 2012 at 1:09 PM, Alex Deucher wrote: > On Wed, Mar 28, 2012 at 10:01 AM, Rob Clark wrote: >> any chance to get libdrm_omap support in beforehand? ?(Or at least for >> someone to review the patch and point out if some changes are needed?) >> > > Sure. ?Can you point me to the

[PATCH] drm/radeon/kms: add register definitions for audio

From: Alex Deucher This adds register definitions for HDMI/DP audio on DCE2/3/4/5 hardware. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/evergreend.h | 220 drivers/gpu/drm/radeon/r600d.h | 236

[patch] drm/i915/bios: cleanup return type of intel_parse_bios()

On Wed, Mar 28, 2012 at 09:59:42AM +0300, Dan Carpenter wrote: > These are unintuitive. These are type bool and return -1 casted to true > on failure. Let's just make it return an int. The callers don't care, > but let's change this as a cleanup. > > Signed-off-by: Dan Carpenter Acked-by:

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

On Wed, 28 Mar 2012 19:39:17 +0800, Daniel Kurtz wrote: > On Wed, Mar 28, 2012 at 3:02 AM, Chris Wilson > wrote: > > Might as well shave this read as well. > > Do you know why POSTING_READ() was there in the first place? > As far as I can tell, these are used to ensure memory barriers are >

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

On Wed, 28 Mar 2012 19:32:27 +0800, Daniel Kurtz wrote: > Unfortunately there is a bug in both my original patch (it wasn't > incrementing loop), and in your suggested cleanup (it always > decrements len, even when it is already 0... or if the loop test > fails). How about the following;

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 Tested-by: Benjamin Herrenschmidt > thanks, > > Dave

[PATCH libdrm] omap: add omapdrm support

From: Rob Clark This adds libdrm_omap helper layer (as used by xf86-video-omap, omapdrmtest, etc). Signed-off-by: Rob Clark --- v1: original v2: address comments from Luca Tettamanti Makefile.am |6 +- configure.ac | 12 ++ omap/Makefile.am

[PATCH] drm/i915: no-lvds quirk on MSI DC500

? ? ? ? ? ? ? ? DMI_MATCH(DMI_BOARD_VENDOR, "MICRO-STAR > > > INTERNATIONAL CO., LTD"), > > > + ? ? ? ? ? ? ? ? ? ? DMI_MATCH(DMI_BOARD_NAME, "MS-7469"), > > > + ? ? ? ? ? ? }, > > > + ? ? }, > > > > > > ? ? ? { } ? ? /* terminating entry */ > > > ?}; > -- Jesse Barnes, Intel Open Source Technology Center -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120328/01397927/attachment-0001.pgp>

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

Hi On Tue, Mar 27, 2012 at 5:59 PM, Ville Syrj?l? wrote: > 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

[PATCH libdrm] omap: add omapdrm support

On Wed, Mar 28, 2012 at 9:39 AM, Luca Tettamanti wrote: > Hi Rob, > I've a couple of (minor) comments: > > On Wed, Mar 21, 2012 at 01:00:36PM -0500, Rob Clark wrote: >> --- /dev/null >> +++ b/omap/omap_drm.c > [...] >> +/* allocate a new (un-tiled) buffer object */ >> +struct omap_bo *

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

nature.asc Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120328/d0946acd/attachment.pgp>

[patch] drm/i915/bios: cleanup return type of intel_parse_bios()

These are unintuitive. These are type bool and return -1 casted to true on failure. Let's just make it return an int. The callers don't care, but let's change this as a cleanup. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/gma500/intel_bios.h

[git pull] drm main pull for 3.4-rc1

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/03/12 21:39, Daniel Vetter wrote: > Yet another thing to try: Can you append intel_iommu=igfx_off to > your kernel cmdline? If you can, try this both on mainline kernels > and with my additional patches. To confirm, intel_iommu=igfx_off is

libdrm release?

Any objections to a libdrm release later today or tomorrow? I'd like to push a new one in preparation for a new -ati release. Thanks, Alex

libdrm release?

any chance to get libdrm_omap support in beforehand? (Or at least for someone to review the patch and point out if some changes are needed?) BR, -R On Wed, Mar 28, 2012 at 8:18 AM, Alex Deucher wrote: > Any objections to a libdrm release later today or tomorrow? ?I'd like > to push a new one

[PATCH] drm/radeon: Only warn if the intra-domain offset actually exceeds the limit.

From: Michel D?nzer Fixes spurious warnings. Tested-by: Dave Jones Tested-by: Steven Rostedt Tested-by: Benjamin Herrenschmidt Signed-off-by: Michel D?nzer --- Thanks to Dave, Steven and Ben for testing the patch! drivers/gpu/drm/radeon/radeon_object.c | 12

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #12 from Michel D?nzer 2012-03-28 00:14:58 PDT --- (In reply to comment #7) > (I tried DRAW_NO_LLVM=1 - bug was still there). FWIW, that's not a recognized environment variable. You probably meant DRAW_USE_LLVM=0. -- Configure

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #11 from Andrew Randrianasulu 2012-03-28 00:06:42 PDT --- Or http://cgit.freedesktop.org/mesa/mesa/commit/?id=1a69b50b3b441ce8f7a00af3a7f02c37df50f6c3 Namely calls to draw_create_fragment_shader() and draw_bind_fragment_shader() ,

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #10 from Andrew Randrianasulu 2012-03-27 23:48:29 PDT --- wild guess: r300g need something like this? http://cgit.freedesktop.org/mesa/mesa/commit/?id=022e270b1b972b6d04890f1ac1fc2a4a4ed03ff7 -- Configure bugmail:

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #9 from Andrew Randrianasulu 2012-03-27 23:17:54 PDT --- as far as I can see in celestia-1.6.1/src/celengine/render.cpp (function void Renderer::PointStarVertexBuffer::startSprites() ) - it uses some combination of

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #8 from Andrew Randrianasulu 2012-03-27 22:59:35 PDT --- If i set "Star style" to "Points" it works OK, another two options (default "Fuzzy Points" and "Scaled Disks") produces white slow screen. -- Configure bugmail:

[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",

[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

[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 10/13 v4] drm/i915/intel_i2c: always wait for IDLE before clearing NAK

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, resulting in a confused GMBUS controller. This will leave the controller in a

[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 --- drivers/gpu/drm/i915/intel_i2c.c | 14

[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 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 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,

[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 Reviewed-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_i2c.c | 60 +

[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 02/13 v4] drm/i915/intel_i2c: cleanup error messages and comments

Signed-off-by: Daniel Kurtz --- 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 --- a/drivers/gpu/drm/i915/intel_i2c.c +++

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

Split out gmbus_xfer_read/write() helper functions. Signed-off-by: Daniel Kurtz --- 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 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. *

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

-devel at lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel >> >> ___ >> Linaro-mm-sig mailing list >> Linaro-mm-sig at lists.linaro.org >> http://lists.linaro.org/mailman/listinfo/linaro-mm-sig > Reviewed-by: Inki Dae -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120328/87fc13e4/attachment.htm>

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

https://bugs.freedesktop.org/show_bug.cgi?id=47765 --- Comment #6 from Tvrtko Ursulin 2012-03-28 01:17:21 UTC --- (In reply to comment #5) > Created attachment 59126 [details] [review] > use linear aligned > > Does this patch against ddx help ? No, still the same corruption. -- Configure

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

> -Original Message- > From: Steven Rostedt [mailto:rostedt at goodmis.org] > Sent: Tuesday, March 27, 2012 8:16 PM > To: LKML > Cc: dri-devel; David Airlie; Daenzer, Michel; Deucher, Alexander > Subject: Re: [BUG] Warning at radeon_object.c:236 with latest Linus kernel > > On Tue,

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

On Tue, Mar 27, 2012 at 10:20:21AM +0200, Michel Dänzer wrote: 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

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

On Wed, 2012-03-28 at 00:17 +, Deucher, Alexander wrote: Can you try this patch: http://lists.freedesktop.org/archives/dri-devel/2012-March/020606.html Seems to have fixed the issue. Also, is there a way to get a raw version of a patch from this web site? I don't like manually cut and

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

I have a test box that is triggering the following: [ cut here ] WARNING: at /home/rostedt/work/git/linux-trace.git/drivers/gpu/drm/radeon/radeon_object.c:236 radeon_bo_pin_restricted+0x67/0x137 [radeon]() Hardware name: Precision WorkStation 470 Modules linked in:

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

On Tue, 2012-03-27 at 20: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 -- Steve ___

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #8 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 22:59:35 PDT --- If i set Star style to Points it works OK, another two options (default Fuzzy Points and Scaled Disks) produces white slow screen. -- Configure bugmail:

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #9 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 23:17:54 PDT --- as far as I can see in celestia-1.6.1/src/celengine/render.cpp (function void Renderer::PointStarVertexBuffer::startSprites() ) - it uses some combination of

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #10 from Andrew Randrianasulu rand...@mail.ru 2012-03-27 23:48:29 PDT --- wild guess: r300g need something like this? http://cgit.freedesktop.org/mesa/mesa/commit/?id=022e270b1b972b6d04890f1ac1fc2a4a4ed03ff7 -- Configure

[PATCH] drm/radeon: Only warn if the intra-domain offset actually exceeds the limit.

From: Michel Dänzer michel.daen...@amd.com Fixes spurious warnings. Tested-by: Dave Jones da...@redhat.com Tested-by: Steven Rostedt rost...@goodmis.org Tested-by: Benjamin Herrenschmidt b...@kernel.crashing.org Signed-off-by: Michel Dänzer michel.daen...@amd.com --- Thanks to Dave, Steven and

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #11 from Andrew Randrianasulu rand...@mail.ru 2012-03-28 00:06:42 PDT --- Or http://cgit.freedesktop.org/mesa/mesa/commit/?id=1a69b50b3b441ce8f7a00af3a7f02c37df50f6c3 Namely calls to draw_create_fragment_shader() and

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

https://bugs.freedesktop.org/show_bug.cgi?id=47955 --- Comment #12 from Michel Dänzer mic...@daenzer.net 2012-03-28 00:14:58 PDT --- (In reply to comment #7) (I tried DRAW_NO_LLVM=1 - bug was still there). FWIW, that's not a recognized environment variable. You probably meant DRAW_USE_LLVM=0.

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

https://bugs.freedesktop.org/show_bug.cgi?id=47765 --- Comment #6 from Tvrtko Ursulin tvrtko.ursu...@onelan.co.uk 2012-03-28 01:17:21 UTC --- (In reply to comment #5) Created attachment 59126 [details] [review] use linear aligned Does this patch against ddx help ? No, still the same

[patch] drm/i915/bios: cleanup return type of intel_parse_bios()

These are unintuitive. These are type bool and return -1 casted to true on failure. Let's just make it return an int. The callers don't care, but let's change this as a cleanup. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/gpu/drm/gma500/intel_bios.h

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27/03/12 21:39, Daniel Vetter wrote: Yet another thing to try: Can you append intel_iommu=igfx_off to your kernel cmdline? If you can, try this both on mainline kernels and with my additional patches. To confirm, intel_iommu=igfx_off is stable

Re: [patch] drm/i915/bios: cleanup return type of intel_parse_bios()

On Wed, Mar 28, 2012 at 09:59:42AM +0300, Dan Carpenter wrote: These are unintuitive. These are type bool and return -1 casted to true on failure. Let's just make it return an int. The callers don't care, but let's change this as a cleanup. Signed-off-by: Dan Carpenter

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

On Wed, 28 Mar 2012 19:39:17 +0800, Daniel Kurtz djku...@chromium.org wrote: On Wed, Mar 28, 2012 at 3:02 AM, Chris Wilson ch...@chris-wilson.co.uk wrote: Might as well shave this read as well. Do you know why POSTING_READ() was there in the first place? As far as I can tell, these are

Re: [PATCH 14/14 v5] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

On Wed, 28 Mar 2012 20:51:57 +0800, Daniel Kurtz djku...@chromium.org wrote: The POSTING_READ() calls were originally added to make sure the writes were flushed before any timing delays and across loops. However, the normal I915_READ() and I915_WRITE() macros already call readl() / writel(),

libdrm release?

Any objections to a libdrm release later today or tomorrow? I'd like to push a new one in preparation for a new -ati release. Thanks, Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org

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

On Wed, Mar 28, 2012 at 02:36:21AM +0800, Daniel Kurtz wrote: 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

Re: libdrm release?

any chance to get libdrm_omap support in beforehand? (Or at least for someone to review the patch and point out if some changes are needed?) BR, -R On Wed, Mar 28, 2012 at 8:18 AM, Alex Deucher alexdeuc...@gmail.com wrote: Any objections to a libdrm release later today or tomorrow?  I'd like

Re: [PATCH 14/14 v5] drm/i915/intel_i2c: remove POSTING_READ() from gmbus transfers

On Wed, 28 Mar 2012 21:21:42 +0800, Daniel Kurtz djku...@chromium.org wrote: On Wed, Mar 28, 2012 at 9:05 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: We do need the write flush here (and set_data) as the next action is a udelay loop which is not per-se a mb. Now I am confused.

Re: [PATCH libdrm] omap: add omapdrm support

Hi Rob, I've a couple of (minor) comments: On Wed, Mar 21, 2012 at 01:00:36PM -0500, Rob Clark wrote: --- /dev/null +++ b/omap/omap_drm.c [...] +/* allocate a new (un-tiled) buffer object */ +struct omap_bo * omap_bo_new(struct omap_device *dev, + uint32_t size, uint32_t flags)

  1   2   >