From: Dave Airlie
Looking at hibernate overwriting I though it looked like a cursor,
so I tracked down this missing piece to stop the cursor blink
timer. I've no idea if this is sufficient to fix the hibernate
problems people are seeing, but please test it.
Both radeon and nouveau have done this
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 d
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
---
drivers/gpu/drm/i915/intel_i2c.c |3 ---
1 files changed, 0 insertions(+), 3
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
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
This patchset addresses a couple of issues with the i915 gmbus
implementation.
v6 is a rebased and trimmed version of the patchset,
since the first few patches have already been merged onto drm-intel-next-queued.
* Cleans up INDEX cycle implementation
* Only remove POSTING_READ() when it immedia
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
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 devi
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 ba
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
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 I915_WRITE
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 terminal-emula
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 re
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
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
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 d
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 ba
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
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 devi
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 changed
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 == CougarP
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
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 +
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+]:
http://intellinuxgraphics.org/do
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
--- a/drivers/gpu/drm/i9
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 b/drive
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
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: Chris
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 reg
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
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 doc
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.
>
> Signed-off
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 w
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 t
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 importan
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 recog
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 probab
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 = mem_pri
-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
http://dri.freedesktop.o
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 per-
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 flag
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 c
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(), whi
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: address
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.
>
>
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 incl
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 +-
configure.ac
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 that
-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
http://dri.freedesktop.o
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
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 hav
> 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
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
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 +++
drivers/gpu/d
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: Dan
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 c
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
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
> in
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 +-
configure.ac
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; despite
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 that
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: address
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 = mem_pri
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
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: Chris
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 | 22 +++
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 regi
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 h
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 docs
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 recog
Fine with me.
Daniel?
On Thu, 22 Mar 2012 23:12:38 +0100
Anisse Astier wrote:
> Hi again,
>
> Could anyone have a look at this ?
>
> On Tue, Mar 13, 2012 at 3:16 PM, Anisse Astier wrote:
> >
> > Any opinion on this quirk ?
> >
> > On Wed, 7 Mar 2012 18:36:35 +0100, Anisse Astier wrote
> >
> + ? ? ? ? ? ? ? ? ? ? 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>
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.
>
> Signed-off-
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 performan
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 th
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
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 * omap_bo_new
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
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 terminal-emula
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 probab
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 terminal-emulator based on
> DRM. It is written
> from scratch and needs as external depende
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120328/d0946acd/attachment.pgp>
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 +++
drivers/gpu/d
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 I915_WRITE() m
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
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
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 devi
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 d
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 re
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
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
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 == CougarP
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
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 ba
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 changed
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 +
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
--- a/drivers/gpu/drm/i9
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 b/drive
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+]:
http://intellinuxgraphics.org/do
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 which
1 - 100 of 148 matches
Mail list logo
