On Thu, Mar 1, 2012 at 8:26 PM, Lars-Peter Clausen wrote:
> On 02/28/2012 07:04 PM, Jesse Barnes wrote:
>> On Tue, 28 Feb 2012 10:21:44 +0100
>> Lars-Peter Clausen wrote:
>>
>>> The code should obviously check the EDID feature field for EDID feature
>>> flags
>>> and not the color_formats field
On Thu, Mar 1, 2012 at 8:26 PM, Lars-Peter Clausen l...@metafoo.de wrote:
On 02/28/2012 07:04 PM, Jesse Barnes wrote:
On Tue, 28 Feb 2012 10:21:44 +0100
Lars-Peter Clausen l...@metafoo.de wrote:
The code should obviously check the EDID feature field for EDID feature
flags
and not the
? ? ? memcpy(raw_edid, edid_header, sizeof(edid_header));
> + ? ? ? } else {
> + ? ? ? ? ? ? ? goto bad;
> ? ? ? ?}
>
> ? ? ? ?for (i = 0; i < EDID_LENGTH; i++)
> --
> 1.7.6.4
Acked by: Tormod Volden
Also, I don't find the empty "if" statement very elegant. A
EDID_LENGTH; i++)
--
1.7.6.4
Acked by: Tormod Volden debian.tor...@gmail.com
Also, I don't find the empty if statement very elegant. And the 8 is
not so magic, is it? What about:
+ if (score 6)
+ goto bad;
+ else if (score sizeof(edid_header)) {
+ DRM_DEBUG
On Mon, Nov 7, 2011 at 5:08 PM, Alex Deucher wrote:
> On Mon, Nov 7, 2011 at 11:05 AM, Tormod Volden
> wrote:
>> On Mon, Nov 7, 2011 at 2:50 PM, Konrad Rzeszutek Wilk
>> wrote:
>>> On Sun, Nov 06, 2011 at 04:03:21PM +0100, Tormod Volden wrote:
>>>> Fr
On Mon, Nov 7, 2011 at 2:50 PM, Konrad Rzeszutek Wilk
wrote:
> On Sun, Nov 06, 2011 at 04:03:21PM +0100, Tormod Volden wrote:
>> From: Tormod Volden
>>
>> Some cards report that they support only 4x, in which case they
>> should support 2x and 1x as well, according to
On Mon, Nov 7, 2011 at 2:50 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Sun, Nov 06, 2011 at 04:03:21PM +0100, Tormod Volden wrote:
From: Tormod Volden debian.tor...@gmail.com
Some cards report that they support only 4x, in which case they
should support 2x and 1x as well
On Mon, Nov 7, 2011 at 5:08 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Nov 7, 2011 at 11:05 AM, Tormod Volden lists.tor...@gmail.com wrote:
On Mon, Nov 7, 2011 at 2:50 PM, Konrad Rzeszutek Wilk
konrad.w...@oracle.com wrote:
On Sun, Nov 06, 2011 at 04:03:21PM +0100, Tormod Volden
stants everywhere if that would be desired.
Thanks for looking at it!
Tormod
>
> Sending from a mobile, pardon my terseness. ~ C.
>
> On Nov 6, 2011 7:03 AM, "Tormod Volden" wrote:
>>
>> From: Tormod Volden
>>
>> Some cards report that they support on
From: Tormod Volden <debian.tor...@gmail.com>
Signed-off-by: Tormod Volden
---
drivers/char/agp/generic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index c5d04e5..2dc2d5b 100644
--- a/drivers/ch
From: Tormod Volden <debian.tor...@gmail.com>
Some cards report that they support only 4x, in which case they
should support 2x and 1x as well, according to the AGP spec.
Otherwise a requested 1x or 2x rate will result in 0 being set:
agpgart-via :00:00.0: putting AGP V2 device into 0
= savage_driver_unload,
> - ? ? ? .reclaim_buffers = savage_reclaim_buffers,
> ? ? ? ?.ioctls = savage_ioctls,
> ? ? ? ?.dma_ioctl = savage_bci_buffers,
> ? ? ? ?.fops = {
> --
> 1.7.7.1
Hi Daniel,
This works fine on my savage Twister card (laptop).
Tested-by: Tormod Volden
Cheers,
Tormod
= savage_driver_lastclose,
.unload = savage_driver_unload,
- .reclaim_buffers = savage_reclaim_buffers,
.ioctls = savage_ioctls,
.dma_ioctl = savage_bci_buffers,
.fops = {
--
1.7.7.1
Hi Daniel,
This works fine on my savage Twister card (laptop).
Tested-by: Tormod
From: Tormod Volden debian.tor...@gmail.com
Some cards report that they support only 4x, in which case they
should support 2x and 1x as well, according to the AGP spec.
Otherwise a requested 1x or 2x rate will result in 0 being set:
agpgart-via :00:00.0: putting AGP V2 device into 0x mode
From: Tormod Volden debian.tor...@gmail.com
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
drivers/char/agp/generic.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index c5d04e5..2dc2d5b 100644
if that would be desired.
Thanks for looking at it!
Tormod
Sending from a mobile, pardon my terseness. ~ C.
On Nov 6, 2011 7:03 AM, Tormod Volden lists.tor...@gmail.com wrote:
From: Tormod Volden debian.tor...@gmail.com
Some cards report that they support only 4x, in which case they
should support
On Sat, Oct 29, 2011 at 2:25 AM, Daniel Vetter wrote:
> On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
>> On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter
>> wrote:
>> ...
>> > @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *de
From: Tormod Volden <debian.tor...@gmail.com>
---
On top of danvet's kill-with-fire ad83cc3.
Tormod
drivers/gpu/drm/sis/sis_mm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_mm.c b/drivers/gpu/drm/sis/sis_mm.c
index 112a43b..6
On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter
wrote:
...
> @@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, struct
> drm_file *file,
...
> +#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
> + ? ? ? ? ? ? ? item->req.size = mem->size;
> + ? ? ? ? ? ? ?
On Sat, Oct 29, 2011 at 2:25 AM, Daniel Vetter dan...@ffwll.ch wrote:
On Sat, Oct 29, 2011 at 12:47:18AM +0200, Tormod Volden wrote:
On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter daniel.vet...@ffwll.ch
wrote:
...
@@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev
On Thu, Oct 27, 2011 at 1:07 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote:
...
@@ -139,13 +99,35 @@ static int sis_drm_alloc(struct drm_device *dev, struct
drm_file *file,
...
+#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
+ item-req.size = mem-size;
+
From: Tormod Volden debian.tor...@gmail.com
---
On top of danvet's kill-with-fire ad83cc3.
Tormod
drivers/gpu/drm/sis/sis_mm.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sis/sis_mm.c b/drivers/gpu/drm/sis/sis_mm.c
index 112a43b..63c2f75 100644
On Wed, Sep 21, 2011 at 8:52 PM, Michael Witten wrote:
> Because my hardware does appear to be malfunctioning due to a corrupt
> video BIOS, it seems prudent to salvage as much as possible from
> its output, so that it is possible to figure out which other values
> need to be hardcoded in case of
On Wed, Sep 21, 2011 at 8:52 PM, Michael Witten wrote:
Because my hardware does appear to be malfunctioning due to a corrupt
video BIOS, it seems prudent to salvage as much as possible from
its output, so that it is possible to figure out which other values
need to be hardcoded in case of
From: Tormod Volden <debian.tor...@gmail.com>
This was previously done for r300 only. Use %016llX instead of %08X for
printing the table address.
Also fix typos in gart warning messages.
Signed-off-by: Tormod Volden
---
drivers/gpu/drm/radeon/evergreen.c |3 +++
drivers/gpu/drm/
2011/8/31 Michel D?nzer :
> On Die, 2011-08-30 at 11:15 +0200, Tormod Volden wrote:
>> 2011/8/30 Michel D?nzer :
>> >> This was previously done for r300 only. Use %p instead of %08X for
>> >> printing the table address.
>> >
>> > sizeo
2011/8/31 Michel Dänzer mic...@daenzer.net:
On Die, 2011-08-30 at 11:15 +0200, Tormod Volden wrote:
2011/8/30 Michel Dänzer mic...@daenzer.net:
This was previously done for r300 only. Use %p instead of %08X for
printing the table address.
sizeof(dma_addr_t) can be 8 even when sizeof(void
From: Tormod Volden debian.tor...@gmail.com
This was previously done for r300 only. Use %016llX instead of %08X for
printing the table address.
Also fix typos in gart warning messages.
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
drivers/gpu/drm/radeon/evergreen.c |3
From: Tormod Volden <debian.tor...@gmail.com>
This was previously done for r300 only. Use %016lX instead of %08X for
printing the table address.
Also fix typos in gart warning messages.
Signed-off-by: Tormod Volden
---
drivers/gpu/drm/radeon/evergreen.c |2 ++
drivers/gpu/drm/
2011/8/30 Michel D?nzer :
>> This was previously done for r300 only. Use %p instead of %08X for
>> printing the table address.
>
> sizeof(dma_addr_t) can be 8 even when sizeof(void*) is 4.
Thanks, I will send a new patch, using "0x%016lX". Will that work for
everybody?
> While you're at it,
2011/8/30 Michel Dänzer mic...@daenzer.net:
This was previously done for r300 only. Use %p instead of %08X for
printing the table address.
sizeof(dma_addr_t) can be 8 even when sizeof(void*) is 4.
Thanks, I will send a new patch, using 0x%016lX. Will that work for
everybody?
While you're at
From: Tormod Volden debian.tor...@gmail.com
This was previously done for r300 only. Use %016lX instead of %08X for
printing the table address.
Also fix typos in gart warning messages.
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
drivers/gpu/drm/radeon/evergreen.c |2
From: Tormod Volden <debian.tor...@gmail.com>
The same way it was already done for r300.
Also fix typo in gart warning messages.
v2: Replace 0x%08X string format by %p
Signed-off-by: Tormod Volden
---
On Mon, Jul 25, 2011 at 1:03 PM, Dave Airlie wrote:
> Causes a new warning
From: Tormod Volden debian.tor...@gmail.com
The same way it was already done for r300.
Also fix typo in gart warning messages.
v2: Replace 0x%08X string format by %p
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
On Mon, Jul 25, 2011 at 1:03 PM, Dave Airlie airl...@gmail.com wrote
From: Tormod Volden <debian.tor...@gmail.com>
The same way it was already done for r300.
Also fix typo in gart warning messages.
Signed-off-by: Tormod Volden
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |2 ++
drivers/gpu/drm/radeon/ni.c
From: Tormod Volden <debian.tor...@gmail.com>
Also disable the ascii dump and remove the literal printing of the
KERN_ERR macro in the log:
[drm:drm_edid_block_valid] *ERROR* Raw EDID:
<3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
v2: Remove the trailin
From: Tormod Volden debian.tor...@gmail.com
The same way it was already done for r300.
Also fix typo in gart warning messages.
Signed-off-by: Tormod Volden debian.tor...@gmail.com
Reviewed-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/evergreen.c |2 ++
drivers/gpu
On Mon, Jun 27, 2011 at 3:32 PM, Jean Delvare wrote:
> * print_hex_dump_bytes() already includes a log level, so we shouldn't
> ?add one. That log level is KERN_DEBUG so use the same for our header
> ?for consistency.
> * print_hex_dump_bytes() properly puts a newline at the end of the
> ?last
On Mon, Jun 27, 2011 at 3:32 PM, Jean Delvare wrote:
* print_hex_dump_bytes() already includes a log level, so we shouldn't
add one. That log level is KERN_DEBUG so use the same for our header
for consistency.
* print_hex_dump_bytes() properly puts a newline at the end of the
last line, so
On Tue, Jun 14, 2011 at 8:13 AM, Dave Airlie wrote:
> this puts the header and followup at the same loglevel as the
> hex dump code.
...
> ?bad:
> ? ? ? ?if (raw_edid) {
> - ? ? ? ? ? ? ? DRM_ERROR("Raw EDID:\n");
> + ? ? ? ? ? ? ? printk(KERN_ERR "Raw EDID:\n");
> ? ? ? ? ? ? ?
and can wait for 3.1
also.
Maybe we eventually should print out in a format like xrandr and Xorg
do, so tools like edid-decode can eat it.
Cheers,
Tormod
From f64fd288c2d8555df82be884d48787138ee02c3b Mon Sep 17 00:00:00 2001
From: Tormod Volden debian.tor...@gmail.com
Date: Fri, 17 Jun 2011 18:45:19
On Mon, May 30, 2011 at 9:45 PM, Tormod Volden wrote:
> From: Tormod Volden
>
> Drivers using multiple framebuffers got broken by commit
> 41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
> (or register) map offset when looking for existing maps
On Mon, May 30, 2011 at 9:45 PM, Tormod Volden wrote:
> (*) It actually checks if _DRM_CONTAINS_LOCK is the /only/ flag set. I
> suppose this is intentional. My v2 patch does not change anything in the
> case of _DRM_SHM: If it contains a lock, it returns a match without
> compa
On Mon, May 30, 2011 at 9:45 PM, Tormod Volden wrote:
(*) It actually checks if _DRM_CONTAINS_LOCK is the /only/ flag set. I
suppose this is intentional. My v2 patch does not change anything in the
case of _DRM_SHM: If it contains a lock, it returns a match without
comparing offsets
From: Tormod Volden <debian.tor...@gmail.com>
Drivers using multiple framebuffers got broken by commit
41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed a
From: Tormod Volden <debian.tor...@gmail.com>
Drivers using multiple framebuffers got broken by commit
41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed a
From: Tormod Volden debian.tor...@gmail.com
Drivers using multiple framebuffers got broken by commit
41c2e75e60200a860a74b7c84a6375c105e7437f which ignored the framebuffer
(or register) map offset when looking for existing maps. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit
On Fri, May 27, 2011 at 10:48 PM, Dave Airlie wrote:
> On Sat, May 28, 2011 at 4:19 AM, Tormod Volden
> wrote:
>> From: Tormod Volden
>>
>> Since multiple framebuffer maps are not supported any longer (commit
>> 41c2e75e60200a860a74b7c84a6375c105e743
From: Tormod Volden <debian.tor...@gmail.com>
Since multiple framebuffer maps are not supported any longer (commit
41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
and they are not used by the drm anyway.
Leave it to userspace to create one working map instead.
Sign
From: Tormod Volden debian.tor...@gmail.com
Since multiple framebuffer maps are not supported any longer (commit
41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
and they are not used by the drm anyway.
Leave it to userspace to create one working map instead.
Signed-off
From: Tormod Volden <debian.tor...@gmail.com>
Since multiple framebuffer maps are not supported any longer (commit
41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
and they are not used by the drm anyway.
Leave it to userspace to create one working map instead.
Sign
From: Tormod Volden debian.tor...@gmail.com
Since multiple framebuffer maps are not supported any longer (commit
41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
and they are not used by the drm anyway.
Leave it to userspace to create one working map instead.
Signed-off
From: Tormod Volden <debian.tor...@gmail.com>
The same way it was already done for r300.
Also fix typo in gart warning messages.
Signed-off-by: Tormod Volden
---
> While you are at it, you might want to update rv770, evergreen, and cayman.
> Alex
And all the others as well...
From: Tormod Volden <debian.tor...@gmail.com>
Similar to what is being done for other chip families.
Also fix typos in gart messages.
Signed-off-by: Tormod Volden
---
Just noticed there is no gart initialization message on r600 like there
is for other chips, while studying
From: Tormod Volden <debian.tor...@gmail.com>
Subject: [PATCH] drm/savage: Do not add framebuffer and aperture maps
Since multiple framebuffer maps are not supported any longer (commit
41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
and they are not used by the drm
From: Tormod Volden <debian.tor...@gmail.com>
Subject: [PATCH] drm: Add flag for multiple framebuffer support
Do not ignore the offset when looking for existing framebuffer maps
if the new _DRM_MATCH_FB_OFFSET flag is passed to drm_addmap_core.
---
>
From: Tormod Volden debian.tor...@gmail.com
Similar to what is being done for other chip families.
Also fix typos in gart messages.
Signed-off-by: Tormod Volden debian.tor...@gmail.com
---
Just noticed there is no gart initialization message on r600 like there
is for other chips, while
From: Tormod Volden debian.tor...@gmail.com
Subject: [PATCH] drm: Add flag for multiple framebuffer support
Do not ignore the offset when looking for existing framebuffer maps
if the new _DRM_MATCH_FB_OFFSET flag is passed to drm_addmap_core.
---
In commit
From: Tormod Volden debian.tor...@gmail.com
Subject: [PATCH] drm/savage: Do not add framebuffer and aperture maps
Since multiple framebuffer maps are not supported any longer (commit
41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would be broken,
and they are not used by the drm anyway
In commit 41c2e75e60200a860a74b7c84a6375c105e7437f "drm: Make
drm_local_map use a resource_size_t offset" [1] the support for multiple
_DRM_FRAMEBUFFER maps per device was taken away. This change made the
savage drivers upset, since these cards have several apertures (the
layout is different
In commit 41c2e75e60200a860a74b7c84a6375c105e7437f drm: Make
drm_local_map use a resource_size_t offset [1] the support for multiple
_DRM_FRAMEBUFFER maps per device was taken away. This change made the
savage drivers upset, since these cards have several apertures (the
layout is different between
Although these cards have 2 pipelines on the silicon only
the first passed the QA and the other should be disabled.
http://www.digital-daily.com/video/ati-radeon9800se/
http://www.rojakpot.com/showarticle.aspx?artno=101=1
agd5f: add some other SE cards as well; fix up kms
Signed-off-by: Tormod
On Wed, Apr 14, 2010 at 11:16 PM, Brian Paul wrote:
> Dan Nicholson wrote:
>>
>> On Wed, Apr 14, 2010 at 1:52 PM, Brian Paul wrote:
>>>
>>> Matthew W. S. Bell wrote:
On Thu, 2010-04-08 at 16:37 -0700, Jesse Barnes wrote:
>
> On Thu, 8 Apr 2010 18:38:03 -0400
> Alex Deucher
63 matches
Mail list logo
