On Wed, 2012-03-07 at 09:59 -0600, Gross, Andy wrote:
> On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen wrote:
> >
> > Does this "DMM has become synonymous" mean that people just started
> > calling TILER DMM, and thus the name has stuck, or are there technical
> > reasons to handle it as DMM in th
Mesa may set it to 1, causing all primitives to be killed.
v2: also update the r7xx code
Signed-off-by: Marek Ol??k
Cc: stable at kernel.org
---
drivers/gpu/drm/radeon/r600_blit_shaders.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600
https://bugzilla.kernel.org/show_bug.cgi?id=42887
Summary: Garbled display on external screen when using
1920x1080 instead of 1920x1200
Product: Drivers
Version: 2.5
Kernel Version: 3.3
Platform: All
OS/Version: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=42876
Sergio changed:
What|Removed |Added
CC||sergiomartinj at gmail.com
--- Comment #1 fr
On Wed, Mar 7, 2012 at 8:17 PM, Chris Wilson
wrote:
> On Wed, ?7 Mar 2012 19:50:45 +0800, Daniel Kurtz
> wrote:
>> There is no "disabled" port 0. ?So, don't even try to initialize/scan
>> it, etc. ?This saves a bit of time when initializing the driver, since
>> the we can avoid a 50ms timeout w
On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson
wrote:
> On Wed, ?7 Mar 2012 19:50:47 +0800, Daniel Kurtz
> wrote:
>> Return -ENXIO if a device NAKs a transaction.
>>
>> Note: We should return -ETIMEDOUT, too if the transaction times out,
>> however, that error path is currently handled by the 'bi
https://bugs.freedesktop.org/show_bug.cgi?id=47007
--- Comment #8 from Alex Deucher 2012-03-07 12:03:07 PST
---
(In reply to comment #7)
> Poll helper is running every ten seconds because VGA connector "asks it to",
> given how it has DRM_CONNECTOR_POLL_CONNECT set.
Right. The VGA connector ha
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.
Note: checkpatch doesn't like this ('assigning in if cond
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
Return -ENXIO if a device NAKs a transaction.
Note: We should return -ETIMEDOUT, too if the transaction times out,
however, that error path is currently handled by the 'bit-bang fallback'.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/intel_i2c.c |4 +++-
1 files changed, 3 insertion
The i915 has multiple i2c adapters. However, they all share a single
single set of i2c control registers (algorithm). Thus, different threads
trying to access different adapters could interfere with each other.
Note: different threads trying to access the same channel is already
handled in the i
There is no "disabled" port 0. So, don't even try to initialize/scan
it, etc. This saves a bit of time when initializing the driver, since
the we can avoid a 50ms timeout waiting for a device to respond on
a port that doesn't even exist.
Similarly, don't initialize the reserved port, either.
Te
Instead of letting other modules directly access the ->gmbus array,
introduce a new API, intel_gmbus_get_bus(), to lookup an i2c_adapter for
a given gmbus pin pair identifier. This API enables later refactoring
of the gmbus pin pair list.
Note: It is critical that intel_setup_gmbus() gets called
According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
Pin pair 7 is a reserved pair.
[1] Documentation for [DevSNB+] and [DevIBX], as found on
http://intellinuxgraphics.org
Note: the "reserved" and "disabled" pairs do
80 col, spaces around operators and other basic cleanup.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/intel_i2c.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d30
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)
* returns -ENXIO and -ETIMEDOUT as appropriate so upper laye
https://bugs.freedesktop.org/show_bug.cgi?id=47007
Alex Deucher changed:
What|Removed |Added
Attachment #58064|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=47007
Alex Deucher changed:
What|Removed |Added
Attachment #58063|application/octet-stream|text/plain
mime type|
On Wed, Mar 7, 2012 at 6:56 PM, Marek Ol??k wrote:
> Signed-off-by: Marek Ol??k
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/evergreen_cs.c ? ? | ? ?8
> ?drivers/gpu/drm/radeon/r600_cs.c ? ? ? ? ?| ? ?8
> ?drivers/gpu/drm/radeon/reg_srcs/cayman ? ?| ? ?1 -
> ?dri
From: Alex Deucher
All pre-SI chips are limited to 165 Mhz for single link.
Code in question will be re-enabled when SI support is added.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=44755
https://bugzilla.kernel.org/show_bug.cgi?id=42887
Signed-off-by: Alex Deucher
Cc: stable at vger.k
This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.
Cc: stable at kernel.org
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/d
On Wed, Mar 7, 2012 at 5:33 PM, Marek Ol??k wrote:
> Mesa may set it to 1, causing all primitives to be killed.
>
> v2: also update the r7xx code
>
> Signed-off-by: Marek Ol??k
> Cc: stable at kernel.org
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/r600_blit_shaders.c | ? ?8 +
https://bugs.freedesktop.org/show_bug.cgi?id=41766
--- Comment #15 from runetmember at gmail.com 2012-03-07 10:17:06 PST ---
Ok, filled: https://bugs.freedesktop.org/show_bug.cgi?id=47067
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this ma
On Thu, 8 Mar 2012 02:02:03 +0800, Daniel Kurtz wrote:
> I'm not sure what exactly you mean by gen2 and gen3 specs, but, as far as I
> can tell, the GPIO pin assignment is the same for both Cougar Point (Sandy
> Bridge) [1] and Ibex Peak (?) [2]. Although, the documentation is a bit
> confusing a
If Mesa set it to 1, the DDX would not render anything = the monitor would
basically freeze.
---
If it's right, please apply it to xf86-video-ati. I don't have commit access.
src/r6xx_accel.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/r6xx_accel.c b/src/r6xx_acce
Mesa may set it to 1, causing all primitives to be killed.
Signed-off-by: Marek Ol??k
---
I hope it's right.
drivers/gpu/drm/radeon/r600_blit_shaders.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c
b/drivers/gpu/drm/radeo
On Wed, Mar 7, 2012 at 6:56 PM, Marek Olšák wrote:
> Signed-off-by: Marek Olšák
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/evergreen_cs.c | 8
> drivers/gpu/drm/radeon/r600_cs.c | 8
> drivers/gpu/drm/radeon/reg_srcs/cayman | 1 -
> dri
From: Alex Deucher
All pre-SI chips are limited to 165 Mhz for single link.
Code in question will be re-enabled when SI support is added.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=44755
https://bugzilla.kernel.org/show_bug.cgi?id=42887
Signed-off-by: Alex Deucher
Cc: sta...@vger.kern
Signed-off-by: Marek Olšák
---
drivers/gpu/drm/radeon/evergreen_cs.c |8
drivers/gpu/drm/radeon/r600_cs.c |8
drivers/gpu/drm/radeon/reg_srcs/cayman|1 -
drivers/gpu/drm/radeon/reg_srcs/evergreen |1 -
drivers/gpu/drm/radeon/reg_srcs/r600 |
On Wed, Mar 7, 2012 at 5:33 PM, Marek Olšák wrote:
> Mesa may set it to 1, causing all primitives to be killed.
>
> v2: also update the r7xx code
>
> Signed-off-by: Marek Olšák
> Cc: sta...@kernel.org
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600_blit_shaders.c | 8
by the DMM so that we can do the PAT programming and that can only be
gotten from the hwmod entry. And if you use the hwmod device entry,
you have to match the name used for that entry.
Regards,
Andy
2MB.
My point was, what if I need more, or I don't need any.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120307/e7575ca0/attachment.pgp>
https://bugzilla.kernel.org/show_bug.cgi?id=42887
Summary: Garbled display on external screen when using
1920x1080 instead of 1920x1200
Product: Drivers
Version: 2.5
Kernel Version: 3.3
Platform: All
OS/Version: Linux
Mesa may set it to 1, causing all primitives to be killed.
v2: also update the r7xx code
Signed-off-by: Marek Olšák
Cc: sta...@kernel.org
---
drivers/gpu/drm/radeon/r600_blit_shaders.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_bl
ure
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120307/d36b10a7/attachment.pgp>
he above? =) And
> > if so, it should be configurable. You could have a board with no display
> > at all, and you probably don't want to have 32MB allocated for DRM in
> > that case.
>
> Basically the short version is memory from a CMA carveout can be
> re-used for unpinnable memory. Not kmalloc, but it can be used for
> anon userspace pages, for example. Userspace needs memory too.
Okay, let me ask the other way. Is 32MB enough for everyone? Hardcoding
a value like that without any possibility to adjust it just sounds like
a rather bad thing.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120307/5e6daa8a/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=47039
Sylvain R?ault changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugzilla.kernel.org/show_bug.cgi?id=42876
Sergio changed:
What|Removed |Added
CC||sergiomart...@gmail.com
--- Comment #1 from
https://bugs.freedesktop.org/show_bug.cgi?id=41766
--- Comment #14 from Alex Deucher 2012-03-07 05:37:50 PST
---
(In reply to comment #13)
>
> The interesting thing I notice: issue reproduceable only with OpenGL version
> of
> KWin. I never can get it reproduced with OpenGL ES version of KWin.
On Wed, 7 Mar 2012 19:50:43 +0800, Daniel Kurtz
wrote:
> 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:
On Wed, 7 Mar 2012 20:41:03 +0800, Daniel Kurtz wrote:
> On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson
> wrote:
> > On Wed, ??7 Mar 2012 19:50:47 +0800, Daniel Kurtz
> > wrote:
> >> Return -ENXIO if a device NAKs a transaction.
> >>
> >> Note: We should return -ETIMEDOUT, too if the transaction
On Wed, 7 Mar 2012 19:50:45 +0800, Daniel Kurtz
wrote:
> There is no "disabled" port 0. So, don't even try to initialize/scan
> it, etc. This saves a bit of time when initializing the driver, since
> the we can avoid a 50ms timeout waiting for a device to respond on
> a port that doesn't even
On Wed, 7 Mar 2012 19:50:44 +0800, Daniel Kurtz
wrote:
> Instead of letting other modules directly access the ->gmbus array,
> introduce a new API, intel_gmbus_get_bus(), to lookup an i2c_adapter for
> a given gmbus pin pair identifier. This API enables later refactoring
> of the gmbus pin pair
On Wed, 7 Mar 2012 19:50:47 +0800, Daniel Kurtz
wrote:
> Return -ENXIO if a device NAKs a transaction.
>
> Note: We should return -ETIMEDOUT, too if the transaction times out,
> however, that error path is currently handled by the 'bit-bang fallback'.
>
> Signed-off-by: Daniel Kurtz
Can you
On Wed, 7 Mar 2012 19:50:50 +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
https://bugs.freedesktop.org/show_bug.cgi?id=47007
--- Comment #8 from Alex Deucher 2012-03-07 12:03:07 PST ---
(In reply to comment #7)
> Poll helper is running every ten seconds because VGA connector "asks it to",
> given how it has DRM_CONNECTOR_POLL_CONNECT set.
Right. The VGA connector has
On Wed, 7 Mar 2012 19:50:44 +0800, Daniel Kurtz
wrote:
> +struct i2c_adapter *intel_gmbus_get_bus(struct drm_i915_private *dev_priv,
> + int pin)
> +{
BUG_ON(pin >= GMBUS_NUM_PORTS);
> + return (pin < GMBUS_NUM_PORTS) ? &dev_priv->gmbus[pin].adapter : NUL
On Wed, 7 Mar 2012 19:50:42 +0800, Daniel Kurtz
wrote:
> 80 col, spaces around operators and other basic cleanup.
>
> Signed-off-by: Daniel Kurtz
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 24
> 1 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/dri
https://bugs.freedesktop.org/show_bug.cgi?id=41766
--- Comment #13 from runetmember at gmail.com 2012-03-07 03:58:22 PST ---
> I just tried with the latest Fedora 16 Final RC1 (using Linux 3.1.0 final),
> and
I noticed the LVDS flickering actually happens *sometimes* also when booting
the laptop
https://bugs.freedesktop.org/show_bug.cgi?id=47007
Alex Deucher changed:
What|Removed |Added
Attachment #58064|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=47007
Alex Deucher changed:
What|Removed |Added
Attachment #58063|application/octet-stream|text/plain
mime type|
The out of order execution of semaphore commands on
pre cayman asics doesn't work correctly and can
cause deadlocks, so turn it off for now.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r600.c |3 +++
drivers/gpu/drm/radeon/r600d.h |1 +
2 files changed, 4 insertions(+), 0
On Wed, Mar 7, 2012 at 10:56 AM, Marek Ol??k wrote:
> If Mesa set it to 1, the DDX would not render anything = the monitor would
> basically freeze.
> ---
> If it's right, please apply it to xf86-video-ati. I don't have commit access.
Pushed. thanks!
>
> ?src/r6xx_accel.c | ? ?1 +
> ?1 files ch
On Wed, Mar 7, 2012 at 10:51 AM, Marek Ol??k wrote:
> Mesa may set it to 1, causing all primitives to be killed.
>
> Signed-off-by: Marek Ol??k
Looks good. Should probably cc stable as well.
Reviewed-by: Alex Deucher
> ---
> I hope it's right.
>
> ?drivers/gpu/drm/radeon/r600_blit_shaders.c
https://bugs.freedesktop.org/show_bug.cgi?id=47007
--- Comment #7 from Tvrtko Ursulin 2012-03-07
02:42:18 PST ---
Poll helper is running every ten seconds because VGA connector "asks it to",
given how it has DRM_CONNECTOR_POLL_CONNECT set.
Since the poll helper runs, and HDMI connector has DRM_
On Wed, Mar 7, 2012 at 9:23 PM, Chris Wilson wrote:
>
> On Wed, 7 Mar 2012 19:50:43 +0800, Daniel Kurtz
> wrote:
> > 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.
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=41766
--- Comment #15 from runetmem...@gmail.com 2012-03-07 10:17:06 PST ---
Ok, filled: https://bugs.freedesktop.org/show_bug.cgi?id=47067
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=47007
--- Comment #6 from Tvrtko Ursulin 2012-03-07
02:10:26 PST ---
Further investigation along the lines of your comment.
For the HDMI connector ATOM_HPD_INT_RECORD_TYPE contains a gpio->mask of 0x100
which translates to RADEON_HPD_2. hpd.plugged_s
On Thu, 8 Mar 2012 02:02:03 +0800, Daniel Kurtz wrote:
> I'm not sure what exactly you mean by gen2 and gen3 specs, but, as far as I
> can tell, the GPIO pin assignment is the same for both Cougar Point (Sandy
> Bridge) [1] and Ibex Peak (?) [2]. Although, the documentation is a bit
> confusing a
https://bugs.freedesktop.org/show_bug.cgi?id=47039
Sylvain R?ault changed:
What|Removed |Added
Priority|medium |highest
--
Configure bugmail: https://
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen wrote:
>
> Does this "DMM has become synonymous" mean that people just started
> calling TILER DMM, and thus the name has stuck, or are there technical
> reasons to handle it as DMM in the kernel? If the former, and if TILER
> is the technically exact
This hardware doesn't have an LVDS, it's a desktop box. Fix incorrect
LVDS detection.
Cc: sta...@kernel.org
Signed-off-by: Anisse Astier
---
drivers/gpu/drm/i915/intel_lvds.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/driv
https://bugs.freedesktop.org/show_bug.cgi?id=47039
Bug #: 47039
Summary: radeon: The kernel rejected CS
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: N
2012/3/7 Christian K?nig :
> The out of order execution of semaphore commands on
> pre cayman asics doesn't work correctly and can
> cause deadlocks, so turn it off for now.
>
> Signed-off-by: Christian K?nig
Good catch.
Reviewed-by: Alex Deucher
> ---
> ?drivers/gpu/drm/radeon/r600.c ?| ? ?3
https://bugs.freedesktop.org/show_bug.cgi?id=46796
--- Comment #8 from Michel D?nzer 2012-03-07 00:21:12
PST ---
(In reply to comment #7)
> I got the source for xserver-xorg-video-ati from the Ubuntu repositories and
> tried to apply the patch to it.
That can't work, as the patch is for the ker
https://bugs.freedesktop.org/show_bug.cgi?id=46796
Michel D?nzer changed:
What|Removed |Added
Attachment #57853|0 |1
is obsolete|
On Wed, Mar 7, 2012 at 10:56 AM, Marek Olšák wrote:
> If Mesa set it to 1, the DDX would not render anything = the monitor would
> basically freeze.
> ---
> If it's right, please apply it to xf86-video-ati. I don't have commit access.
Pushed. thanks!
>
> src/r6xx_accel.c | 1 +
> 1 files ch
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen wrote:
>
> Does this "DMM has become synonymous" mean that people just started
> calling TILER DMM, and thus the name has stuck, or are there technical
> reasons to handle it as DMM in the kernel? If the former, and if TILER
> is the technically exact
If Mesa set it to 1, the DDX would not render anything = the monitor would
basically freeze.
---
If it's right, please apply it to xf86-video-ati. I don't have commit access.
src/r6xx_accel.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/src/r6xx_accel.c b/src/r6xx_acce
On Wed, Mar 7, 2012 at 10:51 AM, Marek Olšák wrote:
> Mesa may set it to 1, causing all primitives to be killed.
>
> Signed-off-by: Marek Olšák
Looks good. Should probably cc stable as well.
Reviewed-by: Alex Deucher
> ---
> I hope it's right.
>
> drivers/gpu/drm/radeon/r600_blit_shaders.c
Mesa may set it to 1, causing all primitives to be killed.
Signed-off-by: Marek Olšák
---
I hope it's right.
drivers/gpu/drm/radeon/r600_blit_shaders.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_blit_shaders.c
b/drivers/gpu/drm/radeo
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen wrote:
> On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
>>
>>
>> On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen
>> wrote:
>>
>>
>> ? ? ? ? I have to say I don't know much about DMM, but my
>> ? ? ? ? understanding is that
>> ? ? ? ? DMM is a b
On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen wrote:
> On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
>> On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen
>> wrote:
>> > On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
>> >> On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen
>> >> wrote:
>>
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #39 from Alexandre Demers
2012-03-06 22:25:26 PST ---
(In reply to comment #38)
> Some news: today, I updated xserver and it seems I'm now able to boot under
> Gnome-Shell correctly.
>
> However, launching RenderFeatTest.bin64 still
https://bugs.freedesktop.org/show_bug.cgi?id=47039
Sylvain Réault changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://bugs.freedesktop.org/show_bug.cgi?id=41766
--- Comment #14 from Alex Deucher 2012-03-07 05:37:50 PST ---
(In reply to comment #13)
>
> The interesting thing I notice: issue reproduceable only with OpenGL version
> of
> KWin. I never can get it reproduced with OpenGL ES version of KWin.
2012/3/7 Christian König :
> The out of order execution of semaphore commands on
> pre cayman asics doesn't work correctly and can
> cause deadlocks, so turn it off for now.
>
> Signed-off-by: Christian König
Good catch.
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/r600.c | 3
On Wed, Mar 7, 2012 at 6:05 AM, Tomi Valkeinen wrote:
> On Tue, 2012-03-06 at 09:50 -0600, Gross, Andy wrote:
>>
>>
>> On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen
>> wrote:
>>
>>
>> I have to say I don't know much about DMM, but my
>> understanding is that
>> DMM is a b
On Wed, 7 Mar 2012 19:50:43 +0800, Daniel Kurtz wrote:
> 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:/
On Wed, 2012-03-07 at 07:06 -0600, Rob Clark wrote:
> On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen wrote:
> > Hmm, why does the drm core care about it?
>
> Because it is the one generating the bus-id.. see
> drivers/gpu/drm/drm_platform.c drm_platform_set_busid()
>
> Anyways, it's just a deta
On Wed, Mar 7, 2012 at 5:59 AM, Tomi Valkeinen wrote:
> On Tue, 2012-03-06 at 09:29 -0600, Rob Clark wrote:
>> On Tue, Mar 6, 2012 at 8:35 AM, Tomi Valkeinen wrote:
>> > On Tue, 2012-03-06 at 08:01 -0600, Rob Clark wrote:
>> >> On Tue, Mar 6, 2012 at 7:26 AM, Tomi Valkeinen
>> >> wrote:
>> >
>>
On Wed, Mar 7, 2012 at 8:17 PM, Chris Wilson wrote:
> On Wed, 7 Mar 2012 19:50:45 +0800, Daniel Kurtz wrote:
>> There is no "disabled" port 0. So, don't even try to initialize/scan
>> it, etc. This saves a bit of time when initializing the driver, since
>> the we can avoid a 50ms timeout waiti
On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson wrote:
> On Wed, 7 Mar 2012 19:50:47 +0800, Daniel Kurtz wrote:
>> Return -ENXIO if a device NAKs a transaction.
>>
>> Note: We should return -ETIMEDOUT, too if the transaction times out,
>> however, that error path is currently handled by the 'bit-ba
Instead of letting other modules directly access the ->gmbus array,
introduce a new API, intel_gmbus_get_bus(), to lookup an i2c_adapter for
a given gmbus pin pair identifier. This API enables later refactoring
of the gmbus pin pair list.
Note: It is critical that intel_setup_gmbus() gets called
Return -ENXIO if a device NAKs a transaction.
Note: We should return -ETIMEDOUT, too if the transaction times out,
however, that error path is currently handled by the 'bit-bang fallback'.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/intel_i2c.c |4 +++-
1 files changed, 3 insertion
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
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.
Note: checkpatch doesn't like this ('assigning in if cond
There is no "disabled" port 0. So, don't even try to initialize/scan
it, etc. This saves a bit of time when initializing the driver, since
the we can avoid a 50ms timeout waiting for a device to respond on
a port that doesn't even exist.
Similarly, don't initialize the reserved port, either.
Te
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
According to i915 documentation [1], "Port D" (DP/HDMI Port D) is
actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b).
Pin pair 7 is a reserved pair.
[1] Documentation for [DevSNB+] and [DevIBX], as found on
http://intellinuxgraphics.org
Note: the "reserved" and "disabled" pairs do
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)
* returns -ENXIO and -ETIMEDOUT as appropriate so upper laye
The i915 has multiple i2c adapters. However, they all share a single
single set of i2c control registers (algorithm). Thus, different threads
trying to access different adapters could interfere with each other.
Note: different threads trying to access the same channel is already
handled in the i
80 col, spaces around operators and other basic cleanup.
Signed-off-by: Daniel Kurtz
---
drivers/gpu/drm/i915/intel_i2c.c | 24
1 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d30
https://bugs.freedesktop.org/show_bug.cgi?id=47039
--- Comment #1 from Marek Olšák 2012-03-07 04:55:45 UTC ---
The commit d0f8561574023aa8f2e0fdf553ee168253567437 should fix this. Please
test Mesa master and close this bug if the issue is gone.
--
Configure bugmail: https://bugs.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=47039
--- Comment #1 from Marek Ol??k 2012-03-07 04:55:45 UTC
---
The commit d0f8561574023aa8f2e0fdf553ee168253567437 should fix this. Please
test Mesa master and close this bug if the issue is gone.
--
Configure bugmail: https://bugs.freedesktop.or
On Wed, 7 Mar 2012 20:41:03 +0800, Daniel Kurtz wrote:
> On Wed, Mar 7, 2012 at 8:12 PM, Chris Wilson wrote:
> > On Wed, Â 7 Mar 2012 19:50:47 +0800, Daniel Kurtz
> > wrote:
> >> Return -ENXIO if a device NAKs a transaction.
> >>
> >> Note: We should return -ETIMEDOUT, too if the transaction ti
On Wed, 7 Mar 2012 19:50:45 +0800, Daniel Kurtz wrote:
> There is no "disabled" port 0. So, don't even try to initialize/scan
> it, etc. This saves a bit of time when initializing the driver, since
> the we can avoid a 50ms timeout waiting for a device to respond on
> a port that doesn't even e
On Wed, 7 Mar 2012 19:50:44 +0800, Daniel Kurtz wrote:
> Instead of letting other modules directly access the ->gmbus array,
> introduce a new API, intel_gmbus_get_bus(), to lookup an i2c_adapter for
> a given gmbus pin pair identifier. This API enables later refactoring
> of the gmbus pin pair
On Wed, 7 Mar 2012 19:50:47 +0800, Daniel Kurtz wrote:
> Return -ENXIO if a device NAKs a transaction.
>
> Note: We should return -ETIMEDOUT, too if the transaction times out,
> however, that error path is currently handled by the 'bit-bang fallback'.
>
> Signed-off-by: Daniel Kurtz
Can you c
1 - 100 of 114 matches
Mail list logo
