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 f
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;
> + sis_malloc(
From: Tormod Volden
---
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
--- a/drivers/gp
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
> .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 Volden
Cheers,
Tormod
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
From: Tormod Volden
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
For instance ProSavage
From: Tormod Volden
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/char/agp/generic.c
+++ b/drivers
named constants 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
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 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:
>>>> From: Tormod
+ 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
Hi Dave,
Can you pick up this, or do I have to reroll the patch with the R-B?
Cheers,
Tormod
On Sun, Nov 6, 2011 at 4:35 PM, Corbin Simpson
wrote:
> FWIW, Reviewed-by: Corbin Simpson
>
> Sending from a mobile, pardon my terseness. ~ C.
>
> On Nov 6, 2011 7:04 AM, "T
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
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 betwee
From: Tormod Volden
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 41c2e75e60200a860a74b7c84a6375c105e7437f "d
From: Tormod Volden
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.
Leave it to userspace to
From: Tormod Volden
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 a log with "unitialized" errors.
From: Tormod Volden
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...
Tormod
PS. Why can't y
From: Tormod Volden
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-by: Tormod Volden
From: Tormod Volden
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-by: Tormod Volden
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
>> 41c2e75e60200a860a74b7c84a6375c105e7437f) these maps would
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. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real
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. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real
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 of
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. The rationale
uot;dmesg -r" - I think Linus prefers tested patches at this
point in the cycle :) But it is purely cosmetic 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 f64fd288c2d8555df82be884
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
From: Tormod Volden
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 trailing empty line as well.
Signed-
From: Tormod Volden
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 |2 ++
drivers/gpu/drm/radeon/r100.c
From: Tormod Volden
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 per line on x86-64 bu
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, 'unbi
From: Tormod Volden
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/radeon/ni.c |2
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
From: Tormod Volden
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/radeon/ni.c |3
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
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;
> + ? ? ? ? ? ? ? sis_malloc
From: Tormod Volden
---
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
--- a/drivers/gp
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
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 f
Hi Dave,
Can you pick up this, or do I have to reroll the patch with the R-B?
Cheers,
Tormod
On Sun, Nov 6, 2011 at 4:35 PM, Corbin Simpson
wrote:
> FWIW, Reviewed-by: Corbin Simpson
>
> Sending from a mobile, pardon my terseness. ~ C.
>
> On Nov 6, 2011 7:04 AM, "T
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 betwee
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, 'unbi
From: Tormod Volden
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/radeon/ni.c |2
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
From: Tormod Volden
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/radeon/ni.c |3
+ ? ? ? ? ? ? ? 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
From: Tormod Volden
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 41c2e75e60200a860a74b7c84a6375c105e7437f "d
From: Tormod Volden
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.
Leave it to userspace to
From: Tormod Volden
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 a log with "unitialized" errors.
From: Tormod Volden
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...
Tormod
PS. Why can't y
From: Tormod Volden
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-by: Tormod Volden
From: Tormod Volden
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-by: Tormod Volden
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
>> 41c2e75e60200a860a74b7c84a6375c105e7437f) these map
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. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real
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. The rationale
was that the kernel-userspace ABI is fixed at a 32-bit offset, so the
real
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 of
tclose,
> ? ? ? ?.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 Volden
Cheers,
Tormod
From: Tormod Volden
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
For instance ProSavage
From: Tormod Volden
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/char/agp/generic.c
+++ b/drivers
named constants 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
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 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 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
f-by: Tormod Volden
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r300.c |5 ++---
drivers/gpu/drm/radeon/r420.c |6 ++
drivers/gpu/drm/radeon/radeon_cp.c |9 +++--
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300
From: Tormod Volden
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 trailing empty line as well.
Signed-
From: Tormod Volden
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 |2 ++
drivers/gpu/drm/radeon/r100.c
From: Tormod Volden
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 per line on x86-64 bu
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. The rationale
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");
> ? ? ? ? ? ? ? ?print_hex_dump_byt
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
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
71 matches
Mail list logo
