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() ,
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 bu
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
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
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
b/drivers/gpu/drm/gma500/intel_bios.
-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 stabl
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, 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, 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
> ins
> 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 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
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 have
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
http://lists.freedesktop.org/mailman/listinfo/dri-deve
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.
>
>
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 in
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(), whic
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 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-se
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
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 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 important, s
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
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
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
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
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 +
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
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
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
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
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
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
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
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 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
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
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
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 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
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 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
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 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 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 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-
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
> >
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
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
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: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: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
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 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 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
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 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 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
-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
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
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
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
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
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
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 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 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
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
; dri-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>
> -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, 2012-03
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
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
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
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
+++ b/driver
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
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
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 b/drivers/gpu/drm/i915/intel_i2c.c
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
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
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 +
1
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
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
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: https://bugs
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
GL_ARB_point_sprit
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: https://bugs.f
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 +++-
1 files changed
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() ,
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 bu
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
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
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
b/drivers/gpu/drm/gma500/intel_bios.
-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 stabl
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, 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, 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
> 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 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
1 - 100 of 148 matches
Mail list logo
