Hi Alan,
On Sat, Jan 28, 2012 at 20:37:50 +, you wrote:
> Can you do the following. In gma500/framebuffer.c find the code that
> reads
>
> info->flags = FBINFO_DEFAULT;
> if (dev_priv->ops->accel_2d && pitch_lines > 8) /* 2D engine */
> info->fbops = &psbfb_op
le
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120128/d876516b/attachment-0001.pgp>
> 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
In the function compat_drm_getclient, I have the impression that the
structure c32 is copied to user level with the field idx uninitialized?
julia
Maybe I'm missing something here...
Shouldn't I be able to build and test support for Intel even if I've got an
nVidia card in my box now? Or is this support for Intel CPUs rather than Intel
GPUs?
On Jan 28, 2012, at 17:55, Eric Anholt wrote:
> On Sat, 28 Jan 2012 12:57:10 -0800, Jeremy Huddl
https://bugzilla.kernel.org/show_bug.cgi?id=42678
J?r?me Glisse changed:
What|Removed |Added
CC||glisse at freedesktop.org
Sum
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
to
try it on your own? Or I could try to blindly write a patch for you to
try.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archiv
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
827 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120128/6614cb55/attachment.pgp>
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
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120128/8562ac5c/attachment.pgp>
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Nikoli changed:
What|Removed |Added
CC||nikoli at lavabit.com
--- Comment #21 from Niko
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Maciej Rutecki changed:
What|Removed |Added
Blocks||42644
--
Configure bugmail: https:/
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
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 commit below (which added the failing tests). Are these
tests broken? Can the
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
> 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
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=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
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Jérôme Glisse changed:
What|Removed |Added
CC||gli...@freedesktop.org
Summar
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
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: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
https://bugs.freedesktop.org/show_bug.cgi?id=41569
Nikoli changed:
What|Removed |Added
CC||nik...@lavabit.com
--- Comment #21 from Nikoli
The assignment of handle in vmw_framebuffer_create_handle doesn't actually do
anything useful and is incorrectly assigning an integer value to a pointer
argument. It appears that this is a typo and should be dereferencing handle
rather than assigning to it directly. This fixes a bug where an und
https://bugzilla.kernel.org/show_bug.cgi?id=42678
Maciej Rutecki changed:
What|Removed |Added
Blocks||42644
--
Configure bugmail: https:/
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
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
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: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
https://bugs.freedesktop.org/show_bug.cgi?id=45018
--- Comment #9 from Alexandre Demers
2012-01-27 21:59:44 PST ---
Here is why I thought the bug was fixed: for another reason, I booted with a
3.2 kernel instead of a 3.3-rc1. The bugs is not visible under kernel 3.2, but
is under 3.3-rc1 since t
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
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=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
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
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
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
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
43 matches
Mail list logo
