https://bugs.freedesktop.org/show_bug.cgi?id=46796
Michel Dänzer changed:
What|Removed |Added
Attachment #57853|0 |1
is obsolete|
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=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
https://bugs.freedesktop.org/show_bug.cgi?id=47039
Sylvain Réault changed:
What|Removed |Added
Priority|medium |highest
--
Configure bugmail: https://
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
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
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_
https://bugs.freedesktop.org/show_bug.cgi?id=41766
--- Comment #13 from runetmem...@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 wit
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/driv
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:
> >
> >> > Can there be more than one omapdrm device? I guess not. I
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 : NULL
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 bigger entity, of which TILER is only a small p
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 regi
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
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: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 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
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
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
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
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
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
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
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
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
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
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
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
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 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, 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, 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, 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
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=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.
https://bugs.freedesktop.org/show_bug.cgi?id=47039
Sylvain Réault changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 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
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 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
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
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
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=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
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=47007
Alex Deucher changed:
What|Removed |Added
Attachment #58063|application/octet-stream|text/plain
mime type|
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
--- 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
https://bugzilla.kernel.org/show_bug.cgi?id=42876
Sergio changed:
What|Removed |Added
CC||sergiomart...@gmail.com
--- Comment #1 from
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
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
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
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 |
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=46796
--- Comment #7 from jonathan 2012-03-06 19:41:29
PST ---
This is a bit above my head I think. I got the source for
xserver-xorg-video-ati from the Ubuntu repositories and tried to apply the
patch to it. It looks like a lot of the right files are
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=46796
Michel D?nzer changed:
What|Removed |Added
Attachment #57853|0 |1
is obsolete|
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=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
https://bugs.freedesktop.org/show_bug.cgi?id=47039
Sylvain R?ault changed:
What|Removed |Added
Priority|medium |highest
--
Configure bugmail: https://
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
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
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_
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
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
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>
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
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>
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
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: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: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 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
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
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
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
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
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
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
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
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
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
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
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
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 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:
>>
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>
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, 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
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=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.
https://bugs.freedesktop.org/show_bug.cgi?id=47039
Sylvain R?ault changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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 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
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 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
1 - 100 of 114 matches
Mail list logo
