On Tue, Jan 24, 2012 at 8:34 AM, Torsten Kaiser
wrote:
> On Mon, Jan 23, 2012 at 7:01 PM, Torsten Kaiser
> wrote:
>> On Mon, Jan 23, 2012 at 5:57 PM, Jerome Glisse wrote:
>>> On Sat, Jan 21, 2012 at 08:03:37PM +0100, Torsten Kaiser wrote:
After updating to kernel 3.3-rc1 I have experienced
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Use exactly that (as the i915 driver does) instead of hard-coding a
jiffy count.
Signed-off-by: Jean Delvare
Reviewed-by: Keith Packard
Cc: Dave Airlie
Cc: Alex Deucher
---
Already sent on: 2011-10-21.
drivers/gpu/drm/radeon/r
Properly set the parent device of i2c buses before registering them so
that they will show at the right place in the device tree (rather than
in /sys/devices directly.)
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c |1 +
1 file changed
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #2 from Dave Airlie 2012-01-28 04:14:21
PST ---
Can you upgrade to a DDX from -git?
I think the fix is in there, it was allocating too small depth buffers.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #3 from Dave Airlie 2012-01-28 04:15:05
PST ---
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=98b2d5fe1722a43c4bbe7711ed7180a3fb65305f
this fix in particular.
--
Configure bugmail: https://bugs.freedesktop.org/
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #10 from Michel Dänzer 2012-01-28 04:52:09 PST
---
(In reply to comment #9)
> The bugs is not visible under kernel 3.2, [...]
3.2 lacks Radeon virtual address space support.
> I will try with a 3.3-rc2 kernel once it will be availa
On Sat, Jan 28, 2012 at 5:10 AM, Jean Delvare wrote:
> Properly set the parent device of i2c buses before registering them so
> that they will show at the right place in the device tree (rather than
> in /sys/devices directly.)
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
On Sat, Jan 28, 2012 at 5:08 AM, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
>
> Signed-off-by: Jean Delvare
> Reviewed-by: Keith Packard
> Cc: Dave Airlie
> Cc: Alex
On Sat, Jan 28, 2012 at 5:07 AM, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, the va
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Summary: [3.3-rc1]radeon :07:00.0: GPU lockup CP stall for
more than 1msec
Product: Drivers
Version: 2.5
Kernel Version: 3.3-rc1
Platform: All
OS/Version: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Maciej Rutecki changed:
What|Removed |Added
Blocks||42644
--
Configure bugmail: https:/
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Nikoli changed:
What|Removed |Added
CC||nik...@lavabit.com
--- Comment #21 from Nikoli
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
Summar
> top half of the screen after booting on my fit-pc2 [1]. The bottom
> half keeps the last output of the console. During booting the console
> is shown on the complete screen in the correct monitor resolution.
I have an idea what that is actually and I've seen similar on Fedora I
think
Can you do
On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, th
On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
The Vesa spec seems to say 2ms; at least according to the DDC/CI spec
paragraph 6.6. us
On Sat, 28 Jan 2012 12:57:10 -0800, Jeremy Huddleston
wrote:
> libdrm is still failing 'make check':
>
> Linux/ppc - http://tinderbox.x.org/builds/2012-01-28-0007/logs/libdrm/#check
> Linux/ppc64 - http://tinderbox.x.org/builds/2012-01-28-0013/logs/libdrm/#check
>
> I bisected it to the commi
On Tue, Jan 24, 2012 at 8:34 AM, Torsten Kaiser
wrote:
> On Mon, Jan 23, 2012 at 7:01 PM, Torsten Kaiser
> wrote:
>> On Mon, Jan 23, 2012 at 5:57 PM, Jerome Glisse wrote:
>>> On Sat, Jan 21, 2012 at 08:03:37PM +0100, Torsten Kaiser wrote:
After updating to kernel 3.3-rc1 I have experienced
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Use exactly that (as the i915 driver does) instead of hard-coding a
jiffy count.
Signed-off-by: Jean Delvare
Reviewed-by: Keith Packard
Cc: Dave Airlie
Cc: Alex Deucher
---
Already sent on: 2011-10-21.
drivers/gpu/drm/radeon/r
Properly set the parent device of i2c buses before registering them so
that they will show at the right place in the device tree (rather than
in /sys/devices directly.)
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c |1 +
1 file changed
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #2 from Dave Airlie 2012-01-28 04:14:21
PST ---
Can you upgrade to a DDX from -git?
I think the fix is in there, it was allocating too small depth buffers.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #3 from Dave Airlie 2012-01-28 04:15:05
PST ---
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=98b2d5fe1722a43c4bbe7711ed7180a3fb65305f
this fix in particular.
--
Configure bugmail: https://bugs.freedesktop.org/
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #10 from Michel Dänzer 2012-01-28 04:52:09 PST
---
(In reply to comment #9)
> The bugs is not visible under kernel 3.2, [...]
3.2 lacks Radeon virtual address space support.
> I will try with a 3.3-rc2 kernel once it will be availa
On Sat, Jan 28, 2012 at 5:10 AM, Jean Delvare wrote:
> Properly set the parent device of i2c buses before registering them so
> that they will show at the right place in the device tree (rather than
> in /sys/devices directly.)
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
On Sat, Jan 28, 2012 at 5:08 AM, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
>
> Signed-off-by: Jean Delvare
> Reviewed-by: Keith Packard
> Cc: Dave Airlie
> Cc: Alex
On Sat, Jan 28, 2012 at 5:07 AM, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, the va
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Summary: [3.3-rc1]radeon :07:00.0: GPU lockup CP stall for
more than 1msec
Product: Drivers
Version: 2.5
Kernel Version: 3.3-rc1
Platform: All
OS/Version: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Maciej Rutecki changed:
What|Removed |Added
Blocks||42644
--
Configure bugmail: https:/
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Nikoli changed:
What|Removed |Added
CC||nik...@lavabit.com
--- Comment #21 from Nikoli
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
Summar
> top half of the screen after booting on my fit-pc2 [1]. The bottom
> half keeps the last output of the console. During booting the console
> is shown on the complete screen in the correct monitor resolution.
I have an idea what that is actually and I've seen similar on Fedora I
think
Can you do
On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, th
On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
The Vesa spec seems to say 2ms; at least according to the DDC/CI spec
paragraph 6.6. us
On Sat, 28 Jan 2012 12:57:10 -0800, Jeremy Huddleston
wrote:
> libdrm is still failing 'make check':
>
> Linux/ppc - http://tinderbox.x.org/builds/2012-01-28-0007/logs/libdrm/#check
> Linux/ppc64 - http://tinderbox.x.org/builds/2012-01-28-0013/logs/libdrm/#check
>
> I bisected it to the commi
On Tue, Jan 24, 2012 at 8:34 AM, Torsten Kaiser
wrote:
> On Mon, Jan 23, 2012 at 7:01 PM, Torsten Kaiser
> wrote:
>> On Mon, Jan 23, 2012 at 5:57 PM, Jerome Glisse wrote:
>>> On Sat, Jan 21, 2012 at 08:03:37PM +0100, Torsten Kaiser wrote:
After updating to kernel 3.3-rc1 I have experienced
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Use exactly that (as the i915 driver does) instead of hard-coding a
jiffy count.
Signed-off-by: Jean Delvare
Reviewed-by: Keith Packard
Cc: Dave Airlie
Cc: Alex Deucher
---
Already sent on: 2011-10-21.
drivers/gpu/drm/radeon/r
Properly set the parent device of i2c buses before registering them so
that they will show at the right place in the device tree (rather than
in /sys/devices directly.)
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c |1 +
1 file changed
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #2 from Dave Airlie 2012-01-28 04:14:21
PST ---
Can you upgrade to a DDX from -git?
I think the fix is in there, it was allocating too small depth buffers.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #3 from Dave Airlie 2012-01-28 04:15:05
PST ---
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=98b2d5fe1722a43c4bbe7711ed7180a3fb65305f
this fix in particular.
--
Configure bugmail: https://bugs.freedesktop.org/
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #10 from Michel Dänzer 2012-01-28 04:52:09 PST
---
(In reply to comment #9)
> The bugs is not visible under kernel 3.2, [...]
3.2 lacks Radeon virtual address space support.
> I will try with a 3.3-rc2 kernel once it will be availa
On Sat, Jan 28, 2012 at 5:10 AM, Jean Delvare wrote:
> Properly set the parent device of i2c buses before registering them so
> that they will show at the right place in the device tree (rather than
> in /sys/devices directly.)
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
On Sat, Jan 28, 2012 at 5:08 AM, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
>
> Signed-off-by: Jean Delvare
> Reviewed-by: Keith Packard
> Cc: Dave Airlie
> Cc: Alex
On Sat, Jan 28, 2012 at 5:07 AM, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, the va
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Summary: [3.3-rc1]radeon :07:00.0: GPU lockup CP stall for
more than 1msec
Product: Drivers
Version: 2.5
Kernel Version: 3.3-rc1
Platform: All
OS/Version: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Maciej Rutecki changed:
What|Removed |Added
Blocks||42644
--
Configure bugmail: https:/
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Nikoli changed:
What|Removed |Added
CC||nik...@lavabit.com
--- Comment #21 from Nikoli
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
Summar
> top half of the screen after booting on my fit-pc2 [1]. The bottom
> half keeps the last output of the console. During booting the console
> is shown on the complete screen in the correct monitor resolution.
I have an idea what that is actually and I've seen similar on Fedora I
think
Can you do
On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, th
On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
The Vesa spec seems to say 2ms; at least according to the DDC/CI spec
paragraph 6.6. us
On Sat, 28 Jan 2012 12:57:10 -0800, Jeremy Huddleston
wrote:
> libdrm is still failing 'make check':
>
> Linux/ppc - http://tinderbox.x.org/builds/2012-01-28-0007/logs/libdrm/#check
> Linux/ppc64 - http://tinderbox.x.org/builds/2012-01-28-0013/logs/libdrm/#check
>
> I bisected it to the commi
On Tue, Jan 24, 2012 at 8:34 AM, Torsten Kaiser
wrote:
> On Mon, Jan 23, 2012 at 7:01 PM, Torsten Kaiser
> wrote:
>> On Mon, Jan 23, 2012 at 5:57 PM, Jerome Glisse wrote:
>>> On Sat, Jan 21, 2012 at 08:03:37PM +0100, Torsten Kaiser wrote:
After updating to kernel 3.3-rc1 I have experienced
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Use exactly that (as the i915 driver does) instead of hard-coding a
jiffy count.
Signed-off-by: Jean Delvare
Reviewed-by: Keith Packard
Cc: Dave Airlie
Cc: Alex Deucher
---
Already sent on: 2011-10-21.
drivers/gpu/drm/radeon/r
Properly set the parent device of i2c buses before registering them so
that they will show at the right place in the device tree (rather than
in /sys/devices directly.)
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c |1 +
1 file changed
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #2 from Dave Airlie 2012-01-28 04:14:21
PST ---
Can you upgrade to a DDX from -git?
I think the fix is in there, it was allocating too small depth buffers.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #3 from Dave Airlie 2012-01-28 04:15:05
PST ---
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=98b2d5fe1722a43c4bbe7711ed7180a3fb65305f
this fix in particular.
--
Configure bugmail: https://bugs.freedesktop.org/
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #10 from Michel Dänzer 2012-01-28 04:52:09 PST
---
(In reply to comment #9)
> The bugs is not visible under kernel 3.2, [...]
3.2 lacks Radeon virtual address space support.
> I will try with a 3.3-rc2 kernel once it will be availa
On Sat, Jan 28, 2012 at 5:10 AM, Jean Delvare wrote:
> Properly set the parent device of i2c buses before registering them so
> that they will show at the right place in the device tree (rather than
> in /sys/devices directly.)
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
On Sat, Jan 28, 2012 at 5:08 AM, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
>
> Signed-off-by: Jean Delvare
> Reviewed-by: Keith Packard
> Cc: Dave Airlie
> Cc: Alex
On Sat, Jan 28, 2012 at 5:07 AM, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, the va
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Summary: [3.3-rc1]radeon :07:00.0: GPU lockup CP stall for
more than 1msec
Product: Drivers
Version: 2.5
Kernel Version: 3.3-rc1
Platform: All
OS/Version: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Maciej Rutecki changed:
What|Removed |Added
Blocks||42644
--
Configure bugmail: https:/
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Nikoli changed:
What|Removed |Added
CC||nik...@lavabit.com
--- Comment #21 from Nikoli
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
Summar
> top half of the screen after booting on my fit-pc2 [1]. The bottom
> half keeps the last output of the console. During booting the console
> is shown on the complete screen in the correct monitor resolution.
I have an idea what that is actually and I've seen similar on Fedora I
think
Can you do
On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, th
On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
The Vesa spec seems to say 2ms; at least according to the DDC/CI spec
paragraph 6.6. us
On Sat, 28 Jan 2012 12:57:10 -0800, Jeremy Huddleston
wrote:
> libdrm is still failing 'make check':
>
> Linux/ppc - http://tinderbox.x.org/builds/2012-01-28-0007/logs/libdrm/#check
> Linux/ppc64 - http://tinderbox.x.org/builds/2012-01-28-0013/logs/libdrm/#check
>
> I bisected it to the commi
On Tue, Jan 24, 2012 at 8:34 AM, Torsten Kaiser
wrote:
> On Mon, Jan 23, 2012 at 7:01 PM, Torsten Kaiser
> wrote:
>> On Mon, Jan 23, 2012 at 5:57 PM, Jerome Glisse wrote:
>>> On Sat, Jan 21, 2012 at 08:03:37PM +0100, Torsten Kaiser wrote:
After updating to kernel 3.3-rc1 I have experienced
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Use exactly that (as the i915 driver does) instead of hard-coding a
jiffy count.
Signed-off-by: Jean Delvare
Reviewed-by: Keith Packard
Cc: Dave Airlie
Cc: Alex Deucher
---
Already sent on: 2011-10-21.
drivers/gpu/drm/radeon/r
Properly set the parent device of i2c buses before registering them so
that they will show at the right place in the device tree (rather than
in /sys/devices directly.)
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c |1 +
1 file changed
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #2 from Dave Airlie 2012-01-28 04:14:21
PST ---
Can you upgrade to a DDX from -git?
I think the fix is in there, it was allocating too small depth buffers.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #3 from Dave Airlie 2012-01-28 04:15:05
PST ---
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=98b2d5fe1722a43c4bbe7711ed7180a3fb65305f
this fix in particular.
--
Configure bugmail: https://bugs.freedesktop.org/
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #10 from Michel Dänzer 2012-01-28 04:52:09 PST
---
(In reply to comment #9)
> The bugs is not visible under kernel 3.2, [...]
3.2 lacks Radeon virtual address space support.
> I will try with a 3.3-rc2 kernel once it will be availa
On Sat, Jan 28, 2012 at 5:10 AM, Jean Delvare wrote:
> Properly set the parent device of i2c buses before registering them so
> that they will show at the right place in the device tree (rather than
> in /sys/devices directly.)
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
On Sat, Jan 28, 2012 at 5:08 AM, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
>
> Signed-off-by: Jean Delvare
> Reviewed-by: Keith Packard
> Cc: Dave Airlie
> Cc: Alex
On Sat, Jan 28, 2012 at 5:07 AM, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, the va
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Summary: [3.3-rc1]radeon :07:00.0: GPU lockup CP stall for
more than 1msec
Product: Drivers
Version: 2.5
Kernel Version: 3.3-rc1
Platform: All
OS/Version: Linux
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Maciej Rutecki changed:
What|Removed |Added
Blocks||42644
--
Configure bugmail: https:/
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Nikoli changed:
What|Removed |Added
CC||nik...@lavabit.com
--- Comment #21 from Nikoli
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
Summar
> top half of the screen after booting on my fit-pc2 [1]. The bottom
> half keeps the last output of the console. During booting the console
> is shown on the complete screen in the correct monitor resolution.
I have an idea what that is actually and I've seen similar on Fedora I
think
Can you do
On Sat, 28 Jan 2012 11:07:09 +0100, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, th
On Sat, 28 Jan 2012 11:08:58 +0100, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
The Vesa spec seems to say 2ms; at least according to the DDC/CI spec
paragraph 6.6. us
On Sat, 28 Jan 2012 12:57:10 -0800, Jeremy Huddleston
wrote:
> libdrm is still failing 'make check':
>
> Linux/ppc - http://tinderbox.x.org/builds/2012-01-28-0007/logs/libdrm/#check
> Linux/ppc64 - http://tinderbox.x.org/builds/2012-01-28-0013/logs/libdrm/#check
>
> I bisected it to the commi
On Tue, Jan 24, 2012 at 8:34 AM, Torsten Kaiser
wrote:
> On Mon, Jan 23, 2012 at 7:01 PM, Torsten Kaiser
> wrote:
>> On Mon, Jan 23, 2012 at 5:57 PM, Jerome Glisse wrote:
>>> On Sat, Jan 21, 2012 at 08:03:37PM +0100, Torsten Kaiser wrote:
After updating to kernel 3.3-rc1 I have experienced
A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
devices can typically operate faster than this, 50 kbps should be fine
for all devices (and compliant devices can always stretch the clock if
needed.)
FWIW, the vast majority of framebuffer drivers set udelay to 10
already. So s
The VESA specification suggests a 2.2 ms timeout on DDC channels.
Use exactly that (as the i915 driver does) instead of hard-coding a
jiffy count.
Signed-off-by: Jean Delvare
Reviewed-by: Keith Packard
Cc: Dave Airlie
Cc: Alex Deucher
---
Already sent on: 2011-10-21.
drivers/gpu/drm/radeon/r
Properly set the parent device of i2c buses before registering them so
that they will show at the right place in the device tree (rather than
in /sys/devices directly.)
Signed-off-by: Jean Delvare
Cc: Dave Airlie
Cc: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_i2c.c |1 +
1 file changed
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #2 from Dave Airlie 2012-01-28 04:14:21
PST ---
Can you upgrade to a DDX from -git?
I think the fix is in there, it was allocating too small depth buffers.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
https://bugs.freedesktop.org/show_bug.cgi?id=45290
--- Comment #3 from Dave Airlie 2012-01-28 04:15:05
PST ---
http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=98b2d5fe1722a43c4bbe7711ed7180a3fb65305f
this fix in particular.
--
Configure bugmail: https://bugs.freedesktop.org/
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #10 from Michel Dänzer 2012-01-28 04:52:09 PST
---
(In reply to comment #9)
> The bugs is not visible under kernel 3.2, [...]
3.2 lacks Radeon virtual address space support.
> I will try with a 3.3-rc2 kernel once it will be availa
On Sat, Jan 28, 2012 at 5:10 AM, Jean Delvare wrote:
> Properly set the parent device of i2c buses before registering them so
> that they will show at the right place in the device tree (rather than
> in /sys/devices directly.)
>
> Signed-off-by: Jean Delvare
> Cc: Dave Airlie
> Cc: Alex Deucher
On Sat, Jan 28, 2012 at 5:08 AM, Jean Delvare wrote:
> The VESA specification suggests a 2.2 ms timeout on DDC channels.
> Use exactly that (as the i915 driver does) instead of hard-coding a
> jiffy count.
>
> Signed-off-by: Jean Delvare
> Reviewed-by: Keith Packard
> Cc: Dave Airlie
> Cc: Alex
On Sat, Jan 28, 2012 at 5:07 AM, Jean Delvare wrote:
> A udelay value of 20 leads to an I2C bus running at only 25 kbps. I2C
> devices can typically operate faster than this, 50 kbps should be fine
> for all devices (and compliant devices can always stretch the clock if
> needed.)
>
> FWIW, the va
1 - 100 of 108 matches
Mail list logo
