[Bug 25934] Segfaults while parsing a shader shown to work on other platforms
http://bugs.freedesktop.org/show_bug.cgi?id=25934 Frank Richter changed: What|Removed |Added Attachment #32492|0 |1 is obsolete|| --- Comment #3 from Frank Richter 2010-01-06 23:55:45 PST --- Created an attachment (id=32495) --> (http://bugs.freedesktop.org/attachment.cgi?id=32495) Cg source Same data as attachment 32492, but with fixed MIME type -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25934] Segfaults while parsing a shader shown to work on other platforms
http://bugs.freedesktop.org/show_bug.cgi?id=25934 --- Comment #2 from Frank Richter 2010-01-06 23:54:19 PST --- Created an attachment (id=32494) --> (http://bugs.freedesktop.org/attachment.cgi?id=32494) Problematic ARB source code -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25934] Segfaults while parsing a shader shown to work on other platforms
http://bugs.freedesktop.org/show_bug.cgi?id=25934 --- Comment #1 from Lucas Paul 2010-01-06 23:41:04 PST --- Created an attachment (id=32492) --> (http://bugs.freedesktop.org/attachment.cgi?id=32492) The offending Cg source, extracted from gdb output and with some escape sequences converted It was suggested to me to make the shader's source a bit more readable/accessible, so here it is with \n, \t, and \\ converted into newlines, tabs, and \, repsectively. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: mkregtable.c: close a file before exit
Signed-off-by: Alexander Beregalov
---
drivers/gpu/drm/radeon/mkregtable.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/mkregtable.c
b/drivers/gpu/drm/radeon/mkregtable.c
index 0d79577..607241c 100644
--- a/drivers/gpu/drm/radeon/mkregtable.c
+++ b/drivers/gpu/drm/radeon/mkregtable.c
@@ -661,8 +661,10 @@ static int parser_auth(struct table *t, const char
*filename)
fseek(file, 0, SEEK_SET);
/* get header */
- if (fgets(buf, 1024, file) == NULL)
+ if (fgets(buf, 1024, file) == NULL) {
+ fclose(file);
return -1;
+ }
/* first line will contain the last register
* and gpu name */
--
1.6.6
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix a couple of array index errors
On Wed, Jan 6, 2010 at 10:55 PM, Dave Airlie wrote:
> On Wed, Dec 30, 2009 at 11:21 AM, Darren Jenkins
> wrote:
>> There are a couple of array overruns, and some associated confusion in
>> the code.
>> This is just a wild guess at what the code should actually look like.
>
> Alex can you take a look at this, though I suspect its mostly stuff
> that is wrong in the GATOS
> code in userspace as well.
>
> Might need to fix it there as well, the ARRAY_SIZE change is sane, the
> flicker removal
> is plausible, the array sizings also totally wierd.
>
I think the attached patch was the original intent of the h/v size
code. The ARRAY_SIZE and flicker removal changes look fine.
Alex
> Dave.
>>
>> Coverity CID: 13305 13306
>>
>>
>> Signed-off-by: Darren Jenkins
>>
>> diff --git drivers/gpu/drm/radeon/radeon_legacy_tv.c
>> drivers/gpu/drm/radeon/radeon_legacy_tv.c
>> index 3a12bb0..c37535a 100644
>> --- drivers/gpu/drm/radeon/radeon_legacy_tv.c
>> +++ drivers/gpu/drm/radeon/radeon_legacy_tv.c
>> @@ -112,6 +112,8 @@ static const uint16_t vert_timing_NTSC[] = {
>> 0x1817,
>> 0x21d4,
>> 0x0002,
>> + 0x,
>> + 0x,
>> 0
>> };
>>
>> @@ -623,9 +625,9 @@ void radeon_legacy_tv_mode_set(struct drm_encoder
>> *encoder,
>> }
>> flicker_removal = (tmp + 500) / 1000;
>>
>> - if (flicker_removal < 3)
>> - flicker_removal = 3;
>> - for (i = 0; i < 6; ++i) {
>> + if (flicker_removal < 2)
>> + flicker_removal = 2;
>> + for (i = 0; i < ARRAY_SIZE(SLOPE_limit); ++i) {
>> if (flicker_removal == SLOPE_limit[i])
>> break;
>> }
>> diff --git drivers/gpu/drm/radeon/radeon_mode.h
>> drivers/gpu/drm/radeon/radeon_mode.h
>> index 402369d..abee9a9 100644
>> --- drivers/gpu/drm/radeon/radeon_mode.h
>> +++ drivers/gpu/drm/radeon/radeon_mode.h
>> @@ -218,8 +218,8 @@ struct radeon_mode_info {
>>
>> };
>>
>> -#define MAX_H_CODE_TIMING_LEN 32
>> -#define MAX_V_CODE_TIMING_LEN 32
>> +#define MAX_H_CODE_TIMING_LEN 16
>> +#define MAX_V_CODE_TIMING_LEN 16
>>
>> /* need to store these as reading
>> back code tables is excessive */
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
0001-drm-radeon-fix-a-couple-of-array-index-errors.patch
Description: application/mbox
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev --
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25934] New: Segfaults while parsing a shader shown to work on other platforms
http://bugs.freedesktop.org/show_bug.cgi?id=25934 Summary: Segfaults while parsing a shader shown to work on other platforms Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: reilith...@gmail.com Created an attachment (id=32489) --> (http://bugs.freedesktop.org/attachment.cgi?id=32489) A log of the gdb session with backtrace and shader source After rebuilding Mesa (with debugging symbols) from the git master branch (at revision 6f498a7eff26dc055c0a1f75ce3102aa4a1a0141 ), I am unable to run a game that utilizes 3d accel and shaders that (mostly) worked previously. This particular issue did not appear to affect me in my previous build (which was also from git master branch built around 2009-12-24 or so, I believe). I am running Gentoo ~amd64. My graphics card is a Radeon X850. The bug manifests with the following versions of software: libdrm commit 5dbc1b333b85695735dc5b484372758b9979b693 mesa commit 6f498a7eff26dc055c0a1f75ce3102aa4a1a0141 xf86-video-ati commit 48aa5064aff4b9adf768e480df2312d4375e9c40 nvidia-cg-toolkit version 2.2.0010, build date Sep 29 2009 16:29:47. CrystalSpace Revision: 33500 Planeshift Revision: 5164 I have attached a gdb session which includes a backtrace and (I believe) the complete source of the shader that causes mesa to hiccup, and the full command arguments that were passed to cgc. I am willing to provide further information if required. Note that this shader does not seem to cause problems for other players of this game on other platforms, but that this does not necessarily mean it is not, itself, buggy or problematic. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[git pull] drm fixes
Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains some EDID parser fixups, a patch to make the drm_pci_alloc sane (follow up from Eric to fix Intel driver bug that required this fix), along with some kernel bug fixes for radeon kms and some coverity fixes. Dave. drivers/gpu/drm/ati_pcigart.c | 10 - drivers/gpu/drm/drm_bufs.c |4 +- drivers/gpu/drm/drm_edid.c | 14 +--- drivers/gpu/drm/drm_fb_helper.c|2 +- drivers/gpu/drm/drm_pci.c |8 + drivers/gpu/drm/i915/i915_dma.c|2 +- drivers/gpu/drm/i915/i915_gem.c|2 +- drivers/gpu/drm/radeon/radeon_atombios.c |2 + drivers/gpu/drm/radeon/radeon_combios.c| 50 +++- drivers/gpu/drm/radeon/radeon_connectors.c |2 +- drivers/gpu/drm/radeon/radeon_cp.c |1 + drivers/gpu/drm/radeon/radeon_device.c |6 ++- drivers/gpu/drm/radeon/radeon_display.c|5 ++- drivers/gpu/drm/radeon/radeon_fence.c |9 ++--- drivers/gpu/drm/radeon/radeon_irq.c| 10 +++--- drivers/gpu/drm/radeon/rs600.c |2 +- include/drm/drmP.h |2 +- 17 files changed, 87 insertions(+), 44 deletions(-) commit a81406b4143ff07e586bbe03c50f089da94eefe1 Merge: 90520b7 43b19f1 Author: Dave Airlie Date: Thu Jan 7 14:00:29 2010 +1000 Merge remote branch 'korg/drm-radeon-next' into drm-linus * korg/drm-radeon-next: drm/radeon/kms: rs600: use correct mask for SW interrupt gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test drm/radeon/radeon_device.c: move a dereference below a NULL test drm/radeon/radeon_fence.c: move a dereference below the NULL test drm/radeon/radeon_connectors.c: add a NULL test before dereference drm/radeon/kms: fix memory leak drm/radeon/kms: add missing breaks in i2c and ss lookups drm/radeon/kms: add primary dac adj values table drm/radeon/kms: fallback to default connector table commit 43b19f161c7a9941e3aa7db0e3ee19b93980e3d7 Author: Luca Tettamanti Date: Mon Dec 28 22:53:05 2009 +0100 drm/radeon/kms: rs600: use correct mask for SW interrupt The mask happens to be the same, but the IH is reading the status, not the not the control register. Signed-off-by: Luca Tettamanti Signed-off-by: Dave Airlie commit 65aa2f4e8d85b6145ef4834f440a63ab68bd7443 Author: Darren Jenkins Date: Wed Dec 30 12:16:35 2009 +1100 gpu/drm/radeon/radeon_irq.c: move a dereference below a NULL test If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13338 Signed-off-by: Darren Jenkins Signed-off-by: Dave Airlie commit 875c186620e017e62b773c93e46af21bb704fe6b Author: Darren Jenkins Date: Wed Dec 30 12:18:30 2009 +1100 drm/radeon/radeon_device.c: move a dereference below a NULL test If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13335 Signed-off-by: Darren Jenkins Signed-off-by: Dave Airlie commit 3655d54af8dd85788c3e5088387469703a0f8f12 Author: Darren Jenkins Date: Wed Dec 30 12:20:05 2009 +1100 drm/radeon/radeon_fence.c: move a dereference below the NULL test If a NULL value is possible, the dereference should only occur after the NULL test. Coverity CID: 13334 Signed-off-by: Darren Jenkins Signed-off-by: Dave Airlie commit d8a7f79246a447722bd90c2c4ba3ca068b2aa4c0 Author: Darren Jenkins Date: Wed Dec 30 12:22:55 2009 +1100 drm/radeon/radeon_connectors.c: add a NULL test before dereference The encoder variable can be NULL in this function so I believe it should be checked before dereference. Coverity CID: 13253 [airlied: extremely unlikely to happen] Signed-off-by: Darren Jenkins Signed-off-by: Dave Airlie commit 5eb226132f53d5ec36ce4e7ff9d6b49cceb50f3d Author: Jiri Slaby Date: Wed Jan 6 17:39:31 2010 +0100 drm/radeon/kms: fix memory leak Stanse found a memory leak in radeon_master_create. master_priv is not freed/assigned on all paths. Fix that. Signed-off-by: Jiri Slaby Signed-off-by: Dave Airlie commit 90520b78a4f8ba1faef75961eddd8192077e0ac2 Merge: d94a510 e89a8c9 Author: Dave Airlie Date: Thu Jan 7 13:36:00 2010 +1000 Merge branch 'drm-core-next' into drm-linus * drm-core-next: drm/kms: Fix &&/|| confusion in drm_fb_helper_connector_parse_command_line() drm/edid: Fix CVT width/height decode drm/edid: Skip empty CVT codepoints drm: remove address mask param for drm_pci_alloc() commit e89a8c901ca94a47c0e0b2fb335623d810e37545 Author: Roel Kluin Date: Thu Dec 31 13:06:29 2009 +010
Re: [PATCH] drm/radeon: fix a couple of array index errors
On Wed, Dec 30, 2009 at 11:21 AM, Darren Jenkins
wrote:
> There are a couple of array overruns, and some associated confusion in
> the code.
> This is just a wild guess at what the code should actually look like.
Alex can you take a look at this, though I suspect its mostly stuff
that is wrong in the GATOS
code in userspace as well.
Might need to fix it there as well, the ARRAY_SIZE change is sane, the
flicker removal
is plausible, the array sizings also totally wierd.
Dave.
>
> Coverity CID: 13305 13306
>
>
> Signed-off-by: Darren Jenkins
>
> diff --git drivers/gpu/drm/radeon/radeon_legacy_tv.c
> drivers/gpu/drm/radeon/radeon_legacy_tv.c
> index 3a12bb0..c37535a 100644
> --- drivers/gpu/drm/radeon/radeon_legacy_tv.c
> +++ drivers/gpu/drm/radeon/radeon_legacy_tv.c
> @@ -112,6 +112,8 @@ static const uint16_t vert_timing_NTSC[] = {
> 0x1817,
> 0x21d4,
> 0x0002,
> + 0x,
> + 0x,
> 0
> };
>
> @@ -623,9 +625,9 @@ void radeon_legacy_tv_mode_set(struct drm_encoder
> *encoder,
> }
> flicker_removal = (tmp + 500) / 1000;
>
> - if (flicker_removal < 3)
> - flicker_removal = 3;
> - for (i = 0; i < 6; ++i) {
> + if (flicker_removal < 2)
> + flicker_removal = 2;
> + for (i = 0; i < ARRAY_SIZE(SLOPE_limit); ++i) {
> if (flicker_removal == SLOPE_limit[i])
> break;
> }
> diff --git drivers/gpu/drm/radeon/radeon_mode.h
> drivers/gpu/drm/radeon/radeon_mode.h
> index 402369d..abee9a9 100644
> --- drivers/gpu/drm/radeon/radeon_mode.h
> +++ drivers/gpu/drm/radeon/radeon_mode.h
> @@ -218,8 +218,8 @@ struct radeon_mode_info {
>
> };
>
> -#define MAX_H_CODE_TIMING_LEN 32
> -#define MAX_V_CODE_TIMING_LEN 32
> +#define MAX_H_CODE_TIMING_LEN 16
> +#define MAX_V_CODE_TIMING_LEN 16
>
> /* need to store these as reading
> back code tables is excessive */
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/radeon_cp.c: check for invalid radeon family
On Wed, Dec 30, 2009 at 11:23 AM, Darren Jenkins wrote: > If there is an invalid radeon family the fw_name is NULL and causes an > NULL pointer dereference. > This just adds a check for something unexpected. > Same as for last one, unless a developer explicity writes code wrong, this cannot happen, and I'd prefer a developer would see an oops. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/radeon_cp.c: fix resource leak on error
On Wed, Dec 30, 2009 at 11:25 AM, Darren Jenkins wrote: > If drm_addmap() fails master_priv is leaked. > I got a patch from Roel Kluin to fix this already, will push it out soon. Dave. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/r100.c: check for invalid family
On Wed, Dec 30, 2009 at 11:24 AM, Darren Jenkins
wrote:
> If there is an invalid family the fw_name is NULL and causes an
> NULL pointer dereference.
> This just adds a check for something unexpected.
NAK.
This can't happen, only gpus with those families set can call this function,
so we can't get in here without the correct family, and if we did it would be
due to developer error, so oopsing is very appropriate.
Dave.
>
> Coverity CID: 13251
>
> Signed-off-by: Darren Jenkins
>
> diff --git drivers/gpu/drm/radeon/r100.c drivers/gpu/drm/radeon/r100.c
> index 7172746..e4b9770 100644
> --- drivers/gpu/drm/radeon/r100.c
> +++ drivers/gpu/drm/radeon/r100.c
> @@ -584,6 +584,8 @@ static int r100_cp_init_microcode(struct radeon_device
> *rdev)
> (rdev->family == CHIP_RV570)) {
> DRM_INFO("Loading R500 Microcode\n");
> fw_name = FIRMWARE_R520;
> + } else {
> + return -EINVAL;
> }
>
> err = request_firmware(&rdev->me_fw, fw_name, &pdev->dev);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: detect sideport enabled on rs690/740/780/880.
2010/1/6 Rafał Miłecki :
> 2010/1/5 Alex Deucher :
>> Updated patch to use bios tables attached.
>
> What about reading clock of sideport memory? Standard way? Could we do
> following?
Nope. Sideport mclk is different than the mclk on discrete chips. If
you look at the atom tables you'll notice that GetMemoryClock and
SetMemoryClock are empty on IGP chips. AFAIK, the sideport clock is
not usually changed.
Alex
>
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index c49cda9..b996a5e 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -392,7 +392,7 @@ int radeon_asic_init(struct radeon_device *rdev)
> return -EINVAL;
> }
>
> - if (rdev->flags & RADEON_IS_IGP) {
> + if (rdev->flags & RADEON_IS_IGP && !rdev->mc.igp_sideport_enabled) {
> rdev->asic->get_memory_clock = NULL;
> rdev->asic->set_memory_clock = NULL;
> }
>
>
> --
> Rafał
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: detect sideport enabled on rs690/740/780/880.
2010/1/5 Alex Deucher :
> Updated patch to use bios tables attached.
What about reading clock of sideport memory? Standard way? Could we do
following?
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index c49cda9..b996a5e 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -392,7 +392,7 @@ int radeon_asic_init(struct radeon_device *rdev)
return -EINVAL;
}
- if (rdev->flags & RADEON_IS_IGP) {
+ if (rdev->flags & RADEON_IS_IGP && !rdev->mc.igp_sideport_enabled) {
rdev->asic->get_memory_clock = NULL;
rdev->asic->set_memory_clock = NULL;
}
--
Rafał
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon/kms: Schedule host path read cache flush through the ring
On Wed, Jan 06, 2010 at 01:57:08PM -0500, Alex Deucher wrote: > On Wed, Jan 6, 2010 at 1:29 PM, Jerome Glisse wrote: > > R300 family will hard lockup if host path read cache flush is > > done through MMIO to HOST_PATH_CNTL. But scheduling same flush > > through ring seems harmless. This patch remove the hdp_flush > > callback and add a flush after each fence emission which means > > a flush after each IB schedule. Thus we should have same behavior > > without the hard lockup. > > We really only need to flush the HDP cache after rendering to vram (or > UMA in the IGP case). Wouldn't it be better to just flush in those > cases? We may want to use the hdp flush callback after sw access to > vram as well, so having a separate hdp callback might be better. See > other comments inline below. > > Alex Do you know if always flushing impact performances ? I didn't benchmarked but i think arena did have same fps before or after the patch. The idea of the patch was to have the same behavior accross different family and avoid having fake callback. > > On r6xx+, mmio should be ok. > Yeah i did change every family just for consistency. > > @@ -1785,6 +1780,8 @@ void r600_fence_ring_emit(struct radeon_device *rdev, > > radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1)); > > radeon_ring_write(rdev, ((rdev->fence_drv.scratch_reg - > > PACKET3_SET_CONFIG_REG_OFFSET) >> 2)); > > radeon_ring_write(rdev, fence->seq); > > + radeon_ring_write(rdev, > > PACKET0(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0)); > > + radeon_ring_write(rdev, 1); > > If you add additional packets here, you'll need to adjust the fence > counts in r600_blit_prepare_copy() in r600_blit_kms.c as well. > Will check that, what i did in others part of the code was to always ask for a lot of room in the ring (64 dwords) so that i could grow what is in fence emit or ib schedule without having to worry. I will change r600 path to do the same. It doesn't hurt to ask for more dword than needed. Cheers, Jerome -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch for 2.6.32? 1/3] drivers/gpu/drm/i915/i915_dma.c: fix unused var
On Tue, 17 Nov 2009 14:08:52 -0800, a...@linux-foundation.org wrote: > From: Andrew Morton > > drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load': > drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used > uninitialized in this function > > Partly this is because gcc isn't smart enough. But `ll_base' does get used > uninitialised in the DRM_DEBUG() call. > > Cc: Jesse Barnes > Cc: Eric Anholt > Cc: Dave Airlie > Signed-off-by: Andrew Morton Applied. thanks! pgpNDghQt7z80.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon/kms: Schedule host path read cache flush through the ring
On Wed, Jan 6, 2010 at 1:29 PM, Jerome Glisse wrote:
> R300 family will hard lockup if host path read cache flush is
> done through MMIO to HOST_PATH_CNTL. But scheduling same flush
> through ring seems harmless. This patch remove the hdp_flush
> callback and add a flush after each fence emission which means
> a flush after each IB schedule. Thus we should have same behavior
> without the hard lockup.
We really only need to flush the HDP cache after rendering to vram (or
UMA in the IGP case). Wouldn't it be better to just flush in those
cases? We may want to use the hdp flush callback after sw access to
vram as well, so having a separate hdp callback might be better. See
other comments inline below.
Alex
>
> Tested on R100,R200,R300,R400,R500,R600,R700 family.
>
> Signed-off-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/r100.c | 14 ++
> drivers/gpu/drm/radeon/r300.c | 16 +++-
> drivers/gpu/drm/radeon/r420.c | 1 +
> drivers/gpu/drm/radeon/r520.c | 1 +
> drivers/gpu/drm/radeon/r600.c | 7 ++-
> drivers/gpu/drm/radeon/radeon.h | 4 ++--
> drivers/gpu/drm/radeon/radeon_asic.h | 12
> drivers/gpu/drm/radeon/radeon_gem.c | 2 --
> drivers/gpu/drm/radeon/rs400.c | 1 +
> drivers/gpu/drm/radeon/rs600.c | 1 +
> drivers/gpu/drm/radeon/rs690.c | 1 +
> drivers/gpu/drm/radeon/rv515.c | 1 +
> 12 files changed, 31 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 44d599a..dc68493 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -356,6 +356,11 @@ void r100_fence_ring_emit(struct radeon_device *rdev,
> /* Wait until IDLE & CLEAN */
> radeon_ring_write(rdev, PACKET0(0x1720, 0));
> radeon_ring_write(rdev, (1 << 16) | (1 << 17));
> + radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
> + radeon_ring_write(rdev, rdev->config.r100.hdp_cntl |
> + RADEON_HDP_READ_BUFFER_INVALIDATE);
> + radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
> + radeon_ring_write(rdev, rdev->config.r100.hdp_cntl);
> /* Emit fence sequence & fire IRQ */
> radeon_ring_write(rdev, PACKET0(rdev->fence_drv.scratch_reg, 0));
> radeon_ring_write(rdev, fence->seq);
> @@ -1707,14 +1712,6 @@ void r100_gpu_init(struct radeon_device *rdev)
> r100_hdp_reset(rdev);
> }
>
> -void r100_hdp_flush(struct radeon_device *rdev)
> -{
> - u32 tmp;
> - tmp = RREG32(RADEON_HOST_PATH_CNTL);
> - tmp |= RADEON_HDP_READ_BUFFER_INVALIDATE;
> - WREG32(RADEON_HOST_PATH_CNTL, tmp);
> -}
> -
> void r100_hdp_reset(struct radeon_device *rdev)
> {
> uint32_t tmp;
> @@ -3265,6 +3262,7 @@ static int r100_startup(struct radeon_device *rdev)
> }
> /* Enable IRQ */
> r100_irq_set(rdev);
> + rdev->config.r100.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
> if (r) {
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index e47af52..f8a959a 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -36,7 +36,15 @@
> #include "rv350d.h"
> #include "r300_reg_safe.h"
>
> -/* This files gather functions specifics to: r300,r350,rv350,rv370,rv380 */
> +/* This files gather functions specifics to: r300,r350,rv350,rv370,rv380
> + *
> + * GPU Errata:
> + * - HOST_PATH_CNTL: r300 family seems to dislike write to HOST_PATH_CNTL
> + * using MMIO to flush host path read cache, this lead to HARDLOCKUP.
> + * However, scheduling such write to the ring seems harmless, i suspect
> + * the CP read collide with the flush somehow, or maybe the MC, hard to
> + * tell. (Jerome Glisse)
> + */
>
> /*
> * rv370,rv380 PCIE GART
> @@ -178,6 +186,11 @@ void r300_fence_ring_emit(struct radeon_device *rdev,
> /* Wait until IDLE & CLEAN */
> radeon_ring_write(rdev, PACKET0(0x1720, 0));
> radeon_ring_write(rdev, (1 << 17) | (1 << 16) | (1 << 9));
> + radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
> + radeon_ring_write(rdev, rdev->config.r300.hdp_cntl |
> + RADEON_HDP_READ_BUFFER_INVALIDATE);
> + radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
> + radeon_ring_write(rdev, rdev->config.r300.hdp_cntl);
> /* Emit fence sequence & fire IRQ */
> radeon_ring_write(rdev, PACKET0(rdev->fence_drv.scratch_reg, 0));
> radeon_ring_write(rdev, fence->seq);
> @@ -1214,6 +1227,7 @@ static int r300_startup(struct radeon_device *rdev)
> }
> /* Enable IRQ */
> r100_irq_set(rdev);
> + rdev->config.r300.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
> /* 1M ring buffer */
> r = r100_cp_init(rdev, 1024 * 1024);
[PATCH 2/2] drm/radeon/kms: Schedule host path read cache flush through the ring
R300 family will hard lockup if host path read cache flush is
done through MMIO to HOST_PATH_CNTL. But scheduling same flush
through ring seems harmless. This patch remove the hdp_flush
callback and add a flush after each fence emission which means
a flush after each IB schedule. Thus we should have same behavior
without the hard lockup.
Tested on R100,R200,R300,R400,R500,R600,R700 family.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r100.c| 14 ++
drivers/gpu/drm/radeon/r300.c| 16 +++-
drivers/gpu/drm/radeon/r420.c|1 +
drivers/gpu/drm/radeon/r520.c|1 +
drivers/gpu/drm/radeon/r600.c|7 ++-
drivers/gpu/drm/radeon/radeon.h |4 ++--
drivers/gpu/drm/radeon/radeon_asic.h | 12
drivers/gpu/drm/radeon/radeon_gem.c |2 --
drivers/gpu/drm/radeon/rs400.c |1 +
drivers/gpu/drm/radeon/rs600.c |1 +
drivers/gpu/drm/radeon/rs690.c |1 +
drivers/gpu/drm/radeon/rv515.c |1 +
12 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 44d599a..dc68493 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -356,6 +356,11 @@ void r100_fence_ring_emit(struct radeon_device *rdev,
/* Wait until IDLE & CLEAN */
radeon_ring_write(rdev, PACKET0(0x1720, 0));
radeon_ring_write(rdev, (1 << 16) | (1 << 17));
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev->config.r100.hdp_cntl |
+ RADEON_HDP_READ_BUFFER_INVALIDATE);
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev->config.r100.hdp_cntl);
/* Emit fence sequence & fire IRQ */
radeon_ring_write(rdev, PACKET0(rdev->fence_drv.scratch_reg, 0));
radeon_ring_write(rdev, fence->seq);
@@ -1707,14 +1712,6 @@ void r100_gpu_init(struct radeon_device *rdev)
r100_hdp_reset(rdev);
}
-void r100_hdp_flush(struct radeon_device *rdev)
-{
- u32 tmp;
- tmp = RREG32(RADEON_HOST_PATH_CNTL);
- tmp |= RADEON_HDP_READ_BUFFER_INVALIDATE;
- WREG32(RADEON_HOST_PATH_CNTL, tmp);
-}
-
void r100_hdp_reset(struct radeon_device *rdev)
{
uint32_t tmp;
@@ -3265,6 +3262,7 @@ static int r100_startup(struct radeon_device *rdev)
}
/* Enable IRQ */
r100_irq_set(rdev);
+ rdev->config.r100.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
/* 1M ring buffer */
r = r100_cp_init(rdev, 1024 * 1024);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index e47af52..f8a959a 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -36,7 +36,15 @@
#include "rv350d.h"
#include "r300_reg_safe.h"
-/* This files gather functions specifics to: r300,r350,rv350,rv370,rv380 */
+/* This files gather functions specifics to: r300,r350,rv350,rv370,rv380
+ *
+ * GPU Errata:
+ * - HOST_PATH_CNTL: r300 family seems to dislike write to HOST_PATH_CNTL
+ * using MMIO to flush host path read cache, this lead to HARDLOCKUP.
+ * However, scheduling such write to the ring seems harmless, i suspect
+ * the CP read collide with the flush somehow, or maybe the MC, hard to
+ * tell. (Jerome Glisse)
+ */
/*
* rv370,rv380 PCIE GART
@@ -178,6 +186,11 @@ void r300_fence_ring_emit(struct radeon_device *rdev,
/* Wait until IDLE & CLEAN */
radeon_ring_write(rdev, PACKET0(0x1720, 0));
radeon_ring_write(rdev, (1 << 17) | (1 << 16) | (1 << 9));
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev->config.r300.hdp_cntl |
+ RADEON_HDP_READ_BUFFER_INVALIDATE);
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev->config.r300.hdp_cntl);
/* Emit fence sequence & fire IRQ */
radeon_ring_write(rdev, PACKET0(rdev->fence_drv.scratch_reg, 0));
radeon_ring_write(rdev, fence->seq);
@@ -1214,6 +1227,7 @@ static int r300_startup(struct radeon_device *rdev)
}
/* Enable IRQ */
r100_irq_set(rdev);
+ rdev->config.r300.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
/* 1M ring buffer */
r = r100_cp_init(rdev, 1024 * 1024);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index f46502a..1d4d16e 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -219,6 +219,7 @@ static int r420_startup(struct radeon_device *rdev)
r420_pipes_init(rdev);
/* Enable IRQ */
r100_irq_set(rdev);
+ rdev->config.r300.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
/* 1M ring buffer */
r = r100_cp_init(rdev, 1024 * 1024);
if (r) {
diff --git a/drivers/gpu/drm/rade
[PATCH 1/2] drm/radeon/kms: Workaround RV410/R420 CP errata (V3)
From: Corbin Simpson
Long story short, this fixes sporadic hardlocks with my rv410 during
times of intense 2D acceleration (Flash on Fx3).
V2: Fix indentation and move errata_fini to suspend function so we
don't leak scratch register over suspend/resume cycle.
V3: Move scratch_reg to asic specific structure (aim is to slowly
move stuff to asic specific structure and avoid poluting
radeon_device struct with asic specific variables)
Signed-off-by: Corbin Simpson
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r420.c | 31 +++
drivers/gpu/drm/radeon/radeon.h |1 +
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index c05a727..f46502a 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -30,6 +30,7 @@
#include "radeon_reg.h"
#include "radeon.h"
#include "atom.h"
+#include "r100d.h"
#include "r420d.h"
int r420_mc_init(struct radeon_device *rdev)
@@ -165,6 +166,34 @@ static void r420_clock_resume(struct radeon_device *rdev)
WREG32_PLL(R_0D_SCLK_CNTL, sclk_cntl);
}
+static void r420_cp_errata_init(struct radeon_device *rdev)
+{
+ /* RV410 and R420 can lock up if CP DMA to host memory happens
+* while the 2D engine is busy.
+*
+* The proper workaround is to queue a RESYNC at the beginning
+* of the CP init, apparently.
+*/
+ radeon_scratch_get(rdev, &rdev->config.r300.resync_scratch);
+ radeon_ring_lock(rdev, 8);
+ radeon_ring_write(rdev, PACKET0(R300_CP_RESYNC_ADDR, 1));
+ radeon_ring_write(rdev, rdev->config.r300.resync_scratch);
+ radeon_ring_write(rdev, 0xDEADBEEF);
+ radeon_ring_unlock_commit(rdev);
+}
+
+static void r420_cp_errata_fini(struct radeon_device *rdev)
+{
+ /* Catch the RESYNC we dispatched all the way back,
+* at the very beginning of the CP init.
+*/
+ radeon_ring_lock(rdev, 8);
+ radeon_ring_write(rdev, PACKET0(R300_RB3D_DSTCACHE_CTLSTAT, 0));
+ radeon_ring_write(rdev, R300_RB3D_DC_FINISH);
+ radeon_ring_unlock_commit(rdev);
+ radeon_scratch_free(rdev, rdev->config.r300.resync_scratch);
+}
+
static int r420_startup(struct radeon_device *rdev)
{
int r;
@@ -196,6 +225,7 @@ static int r420_startup(struct radeon_device *rdev)
dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
return r;
}
+ r420_cp_errata_init(rdev);
r = r100_wb_init(rdev);
if (r) {
dev_err(rdev->dev, "failled initializing WB (%d).\n", r);
@@ -238,6 +268,7 @@ int r420_resume(struct radeon_device *rdev)
int r420_suspend(struct radeon_device *rdev)
{
+ r420_cp_errata_fini(rdev);
r100_cp_disable(rdev);
r100_wb_disable(rdev);
r100_irq_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index cd650fd..b1ad408 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -670,6 +670,7 @@ struct r100_asic {
struct r300_asic {
const unsigned *reg_safe_bm;
unsignedreg_safe_bm_size;
+ u32 resync_scratch;
};
struct r600_asic {
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> > Commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly > > handle fbdev blanking) breaks console blanking on my laptop (GM45 > > chipset). Instead of blanking the screen, it is dimmed and then the > > backlight starts "glowing" in the lower edges of the screen. The glowing > > then slowly spreads upwards. Does not look healthy at all... > > > > This patch reverts to the old behaviour of going directly to > > DPMS_STANDBY. > > The current fbdev blank is correct. Normal blanking doesn't power down > the hsync or the vsync signals. If you look at fbdev drivers you will see > this type of behavior. If you want a full power down then a > FB_BLANK_POWERDOWN > is needed. As for the blacklight that is a another problem not related to > this issue. The fbdev layer sends a event to the backlight layer to tell > it to power down. That powerdown happens for the backlight in all cases > except FB_BLANK_UNBLANK. How is your backlight setup. Is the backlight > handled via the DRI driver or acpi? > The change itself looks correct but it triggers something that seems to hurt my screen bad. :) The backlight is handled via the DRI driver I assume. At least i9xx_crtc_dpms is called on powerdown. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Compile-tested OK.
- Sedat -
On Wed, Jan 6, 2010 at 6:39 PM, michal wrote:
> Brian Paul wrote on 2010-01-06 18:07:
>>
>> Sedat Dilek wrote:
>>
>>>
>>> Hi,
>>>
>>> this patch fixes a build-error in mesa GIT master after...
>>>
>>> commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch)
>>> "configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster"
>>>
>>> >From my build-log:
>>> ...
>>> In file included from svga_pipe_fs.c:37:
>>> svga_tgsi.h: In function 'svga_fs_key_size':
>>> svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target'
>>> make[4]: *** [svga_pipe_fs.o] Error 1
>>>
>>> Might be introduced in...
>>>
>>> commit 955f51270bb60ad77dba049799587dc7c0fb4dda
>>> "Make sure we use only signed/unsigned ints with bitfields."
>>>
>>> Kind Regars,
>>> - Sedat -
>>>
>>>
>>
>> I just fixed that.
>>
>>
>
> Actually, we could go back to bitfields and fix broken svga_fs_key_size().
>
> Attached a patch.
>
> Can somebody review, test-build and commit?
>
>
> From 7321aef0dfc5bb160ec8a33d1d4e686419f2ed3d Mon Sep 17 00:00:00 2001
> From: Michal Krol
> Date: Wed, 6 Jan 2010 18:36:45 +0100
> Subject: [PATCH] svga: Fix fs key size computation and key comparison.
>
> This also allows us to have texture_target
> back as a bitfield and save us a few bytes.
> ---
> src/gallium/drivers/svga/svga_state_fs.c | 9 +++--
> src/gallium/drivers/svga/svga_tgsi.h | 5 ++---
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/src/gallium/drivers/svga/svga_state_fs.c
> b/src/gallium/drivers/svga/svga_state_fs.c
> index 272d1dd..bba80a9 100644
> --- a/src/gallium/drivers/svga/svga_state_fs.c
> +++ b/src/gallium/drivers/svga/svga_state_fs.c
> @@ -40,8 +40,13 @@
> static INLINE int compare_fs_keys( const struct svga_fs_compile_key *a,
> const struct svga_fs_compile_key *b )
> {
> - unsigned keysize = svga_fs_key_size( a );
> - return memcmp( a, b, keysize );
> + unsigned keysize_a = svga_fs_key_size( a );
> + unsigned keysize_b = svga_fs_key_size( b );
> +
> + if (keysize_a != keysize_b) {
> + return (int)(keysize_a - keysize_b);
> + }
> + return memcmp( a, b, keysize_a );
> }
>
>
> diff --git a/src/gallium/drivers/svga/svga_tgsi.h
> b/src/gallium/drivers/svga/svga_tgsi.h
> index 043b991..737a221 100644
> --- a/src/gallium/drivers/svga/svga_tgsi.h
> +++ b/src/gallium/drivers/svga/svga_tgsi.h
> @@ -56,7 +56,7 @@ struct svga_fs_compile_key
> unsigned compare_func:3;
> unsigned unnormalized:1;
> unsigned width_height_idx:7;
> - ubyte texture_target;
> + unsigned texture_target:8;
> } tex[PIPE_MAX_SAMPLERS];
> };
>
> @@ -119,8 +119,7 @@ static INLINE unsigned svga_vs_key_size( const struct
> svga_vs_compile_key *key )
>
> static INLINE unsigned svga_fs_key_size( const struct svga_fs_compile_key
> *key )
> {
> - return (const char *)&key->tex[key->num_textures].texture_target -
> - (const char *)key;
> + return (const char *)&key->tex[key->num_textures] - (const char *)key;
> }
>
> struct svga_shader_result *
> --
> 1.6.4.msysgit.0
>
>
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Thanks, your patch fixed the problem. - Sedat - On Wed, Jan 6, 2010 at 6:38 PM, Brian Paul wrote: > r300_translate_tex_filters() was missing the is_anisotropic parameter. I > fixed that, but there may be other issues. Looks like some of the r300 code > isn't c99. > > -Brian > > > Sedat Dilek wrote: >> >> OK. >> >> That's the next one :-) >> ... >> In file included from r300_emit.c:36: >> r300_state_inlines.h: In function ‘r300_translate_tex_filters’: >> r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first >> use in this function) >> r300_state_inlines.h:263: error: (Each undeclared identifier is >> reported only once >> r300_state_inlines.h:263: error: for each function it appears in.) >> make: *** [r300_emit.o] Error 1 >> ... >> >> I am having dinner, now >> >> - Sedat - >> >> On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul wrote: >>> >>> Sedat Dilek wrote: Hi, this patch fixes a build-error in mesa GIT master after... commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) "configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster" > From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit 955f51270bb60ad77dba049799587dc7c0fb4dda "Make sure we use only signed/unsigned ints with bitfields." Kind Regars, - Sedat - >>> I just fixed that. >>> >>> -Brian >>> > > -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> > > Commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly > > > handle fbdev blanking) breaks console blanking on my laptop (GM45 > > > chipset). Instead of blanking the screen, it is dimmed and then the > > > backlight starts "glowing" in the lower edges of the screen. The glowing > > > then slowly spreads upwards. Does not look healthy at all... > > > > > > This patch reverts to the old behaviour of going directly to > > > DPMS_STANDBY. > > > > The current fbdev blank is correct. Normal blanking doesn't power down > > the hsync or the vsync signals. If you look at fbdev drivers you will see > > this type of behavior. If you want a full power down then a > > FB_BLANK_POWERDOWN > > is needed. As for the blacklight that is a another problem not related to > > this issue. The fbdev layer sends a event to the backlight layer to tell > > it to power down. That powerdown happens for the backlight in all cases > > except FB_BLANK_UNBLANK. How is your backlight setup. Is the backlight > > handled via the DRI driver or acpi? > > > > The change itself looks correct but it triggers something that seems to > hurt my screen bad. :) Yeap. The fix uncovered a bug in your driver. I haven't heard of problems with the other drm drivers. > The backlight is handled via the DRI driver I assume. At least > i9xx_crtc_dpms is called on powerdown. Can you post your dmesg and kernel config. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Brian Paul wrote on 2010-01-06 18:07:
Sedat Dilek wrote:
Hi,
this patch fixes a build-error in mesa GIT master after...
commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch)
"configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster"
>From my build-log:
...
In file included from svga_pipe_fs.c:37:
svga_tgsi.h: In function 'svga_fs_key_size':
svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target'
make[4]: *** [svga_pipe_fs.o] Error 1
Might be introduced in...
commit 955f51270bb60ad77dba049799587dc7c0fb4dda
"Make sure we use only signed/unsigned ints with bitfields."
Kind Regars,
- Sedat -
I just fixed that.
Actually, we could go back to bitfields and fix broken svga_fs_key_size().
Attached a patch.
Can somebody review, test-build and commit?
>From 7321aef0dfc5bb160ec8a33d1d4e686419f2ed3d Mon Sep 17 00:00:00 2001
From: Michal Krol
Date: Wed, 6 Jan 2010 18:36:45 +0100
Subject: [PATCH] svga: Fix fs key size computation and key comparison.
This also allows us to have texture_target
back as a bitfield and save us a few bytes.
---
src/gallium/drivers/svga/svga_state_fs.c |9 +++--
src/gallium/drivers/svga/svga_tgsi.h |5 ++---
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/src/gallium/drivers/svga/svga_state_fs.c
b/src/gallium/drivers/svga/svga_state_fs.c
index 272d1dd..bba80a9 100644
--- a/src/gallium/drivers/svga/svga_state_fs.c
+++ b/src/gallium/drivers/svga/svga_state_fs.c
@@ -40,8 +40,13 @@
static INLINE int compare_fs_keys( const struct svga_fs_compile_key *a,
const struct svga_fs_compile_key *b )
{
- unsigned keysize = svga_fs_key_size( a );
- return memcmp( a, b, keysize );
+ unsigned keysize_a = svga_fs_key_size( a );
+ unsigned keysize_b = svga_fs_key_size( b );
+
+ if (keysize_a != keysize_b) {
+ return (int)(keysize_a - keysize_b);
+ }
+ return memcmp( a, b, keysize_a );
}
diff --git a/src/gallium/drivers/svga/svga_tgsi.h
b/src/gallium/drivers/svga/svga_tgsi.h
index 043b991..737a221 100644
--- a/src/gallium/drivers/svga/svga_tgsi.h
+++ b/src/gallium/drivers/svga/svga_tgsi.h
@@ -56,7 +56,7 @@ struct svga_fs_compile_key
unsigned compare_func:3;
unsigned unnormalized:1;
unsigned width_height_idx:7;
- ubyte texture_target;
+ unsigned texture_target:8;
} tex[PIPE_MAX_SAMPLERS];
};
@@ -119,8 +119,7 @@ static INLINE unsigned svga_vs_key_size( const struct
svga_vs_compile_key *key )
static INLINE unsigned svga_fs_key_size( const struct svga_fs_compile_key *key
)
{
- return (const char *)&key->tex[key->num_textures].texture_target -
- (const char *)key;
+ return (const char *)&key->tex[key->num_textures] - (const char *)key;
}
struct svga_shader_result *
--
1.6.4.msysgit.0
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev --
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/1] GPU: radeon, fix memory leak
Stanse found a memory leak in radeon_master_create. master_priv is not
freed/assigned on all paths. Fix that.
Signed-off-by: Jiri Slaby
---
drivers/gpu/drm/radeon/radeon_cp.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 0b2f9c2..06123ba 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -2145,6 +2145,7 @@ int radeon_master_create(struct drm_device *dev, struct
drm_master *master)
&master_priv->sarea);
if (ret) {
DRM_ERROR("SAREA setup failed\n");
+ kfree(master_priv);
return ret;
}
master_priv->sarea_priv = master_priv->sarea->handle + sizeof(struct
drm_sarea);
--
1.6.5.7
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Workaround RV410/R420 CP errata (V2)
On Wed, 2010-01-06 at 11:41 +0100, Jerome Glisse wrote:
> From: Corbin Simpson
>
> Long story short, this fixes sporadic hardlocks with my rv410 during
> times of intense 2D acceleration (Flash on Fx3).
>
> V2: Fix indentation and move errata_fini to suspend function so we
> don't leak scratch register over suspend/resume cycle.
>
> Signed-off-by: Corbin Simpson
> Signed-off-by: Jerome Glisse
> ---
[...]
> diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
> index cd650fd..b272065 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -798,6 +798,7 @@ struct radeon_device {
> struct radeon_gem gem;
> struct radeon_pmpm;
> uint32_tbios_scratch[RADEON_BIOS_NUM_SCRATCH];
> +uint32_t resync_scratch;
> struct mutexcs_mutex;
> struct radeon_wbwb;
> struct radeon_dummy_pagedummy_page;
Indentation still looks wrong in this hunk.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25916] floating point texture components reversed
http://bugs.freedesktop.org/show_bug.cgi?id=25916 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Alex Deucher 2010-01-06 09:46:15 PST --- pushed: c9befda13a000f7ad2221e957615c909bff279f8 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
r300_translate_tex_filters() was missing the is_anisotropic parameter. I fixed that, but there may be other issues. Looks like some of the r300 code isn't c99. -Brian Sedat Dilek wrote: > OK. > > That's the next one :-) > ... > In file included from r300_emit.c:36: > r300_state_inlines.h: In function ‘r300_translate_tex_filters’: > r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first > use in this function) > r300_state_inlines.h:263: error: (Each undeclared identifier is > reported only once > r300_state_inlines.h:263: error: for each function it appears in.) > make: *** [r300_emit.o] Error 1 > ... > > I am having dinner, now > > - Sedat - > > On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul wrote: >> Sedat Dilek wrote: >>> Hi, >>> >>> this patch fixes a build-error in mesa GIT master after... >>> >>> commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) >>> "configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster" >>> From my build-log: >>> ... >>> In file included from svga_pipe_fs.c:37: >>> svga_tgsi.h: In function 'svga_fs_key_size': >>> svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' >>> make[4]: *** [svga_pipe_fs.o] Error 1 >>> >>> Might be introduced in... >>> >>> commit 955f51270bb60ad77dba049799587dc7c0fb4dda >>> "Make sure we use only signed/unsigned ints with bitfields." >>> >>> Kind Regars, >>> - Sedat - >>> >> I just fixed that. >> >> -Brian >> -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
This looks like my fault. It would be nice to have the r300 and nvidia drivers building by default (eg on linux-debug builds), even if they don't create full drivers, so that a single build can get greater coverage. Keith On Wed, 2010-01-06 at 09:09 -0800, Sedat Dilek wrote: > OK. > > That's the next one :-) > ... > In file included from r300_emit.c:36: > r300_state_inlines.h: In function ‘r300_translate_tex_filters’: > r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first > use in this function) > r300_state_inlines.h:263: error: (Each undeclared identifier is > reported only once > r300_state_inlines.h:263: error: for each function it appears in.) > make: *** [r300_emit.o] Error 1 > ... > > I am having dinner, now > > - Sedat - > > On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul wrote: > > Sedat Dilek wrote: > >> > >> Hi, > >> > >> this patch fixes a build-error in mesa GIT master after... > >> > >> commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) > >> "configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster" > >> > >>> From my build-log: > >> > >> ... > >> In file included from svga_pipe_fs.c:37: > >> svga_tgsi.h: In function 'svga_fs_key_size': > >> svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' > >> make[4]: *** [svga_pipe_fs.o] Error 1 > >> > >> Might be introduced in... > >> > >> commit 955f51270bb60ad77dba049799587dc7c0fb4dda > >> "Make sure we use only signed/unsigned ints with bitfields." > >> > >> Kind Regars, > >> - Sedat - > >> > > > > I just fixed that. > > > > -Brian > > > > -- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > ___ > Mesa3d-dev mailing list > mesa3d-...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mesa3d-dev -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Workaround RV410/R420 CP errata (V2)
I will pop my rv410 back in and test when I get back home.
Posting from a mobile, pardon my terseness. ~ C.
On Jan 6, 2010 2:41 AM, "Jerome Glisse" wrote:
From: Corbin Simpson
Long story short, this fixes sporadic hardlocks with my rv410 during
times of intense 2D acceleration (Flash on Fx3).
V2: Fix indentation and move errata_fini to suspend function so we
don't leak scratch register over suspend/resume cycle.
Signed-off-by: Corbin Simpson
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r420.c | 31 +++
drivers/gpu/drm/radeon/radeon.h |1 +
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index c05a727..48ab18f 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -30,6 +30,7 @@
#include "radeon_reg.h"
#include "radeon.h"
#include "atom.h"
+#include "r100d.h"
#include "r420d.h"
int r420_mc_init(struct radeon_device *rdev)
@@ -165,6 +166,34 @@ static void r420_clock_resume(struct radeon_device
*rdev)
WREG32_PLL(R_0D_SCLK_CNTL, sclk_cntl);
}
+static void r420_cp_errata_init(struct radeon_device *rdev)
+{
+ /* RV410 and R420 can lock up if CP DMA to host memory happens
+* while the 2D engine is busy.
+*
+* The proper workaround is to queue a RESYNC at the beginning
+* of the CP init, apparently.
+*/
+ radeon_scratch_get(rdev, &rdev->resync_scratch);
+ radeon_ring_lock(rdev, 8);
+ radeon_ring_write(rdev, PACKET0(R300_CP_RESYNC_ADDR, 1));
+ radeon_ring_write(rdev, rdev->resync_scratch);
+ radeon_ring_write(rdev, 0xDEADBEEF);
+ radeon_ring_unlock_commit(rdev);
+}
+
+static void r420_cp_errata_fini(struct radeon_device *rdev)
+{
+ /* Catch the RESYNC we dispatched all the way back,
+* at the very beginning of the CP init.
+*/
+ radeon_ring_lock(rdev, 8);
+ radeon_ring_write(rdev, PACKET0(R300_RB3D_DSTCACHE_CTLSTAT, 0));
+ radeon_ring_write(rdev, R300_RB3D_DC_FINISH);
+ radeon_ring_unlock_commit(rdev);
+ radeon_scratch_free(rdev, rdev->resync_scratch);
+}
+
static int r420_startup(struct radeon_device *rdev)
{
int r;
@@ -196,6 +225,7 @@ static int r420_startup(struct radeon_device *rdev)
dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
return r;
}
+ r420_cp_errata_init(rdev);
r = r100_wb_init(rdev);
if (r) {
dev_err(rdev->dev, "failled initializing WB (%d).\n", r);
@@ -238,6 +268,7 @@ int r420_resume(struct radeon_device *rdev)
int r420_suspend(struct radeon_device *rdev)
{
+ r420_cp_errata_fini(rdev);
r100_cp_disable(rdev);
r100_wb_disable(rdev);
r100_irq_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon.h
b/drivers/gpu/drm/radeon/radeon.h
index cd650fd..b272065 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -798,6 +798,7 @@ struct radeon_device {
struct radeon_gem gem;
struct radeon_pmpm;
uint32_t
bios_scratch[RADEON_BIOS_NUM_SCRATCH];
+uint32_t resync_scratch;
struct mutexcs_mutex;
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev --
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[bisected] drm/ksm: fbdev blanking regression in 2.6.33
Hi, Console blanking broke on my laptop with GM45 chipset with 2.6.33. Instead of blanking, the screen was dimmed and the backlight started glowing in the lower edges of the screen. The glowing then slowly spread upwards. Did not look healthy at all. Easily reproduced by issuing "setterm -blank force". I bisected it down to 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly handle fbdev blanking). Which instead of going directly to DPMS_STANDBY now calls the encoder dpms helper with DRM_MODE_DPMS_ON and the crtc dpms helper with DRM_MODE_DPMS_OFF. I've verified that is this combination that triggers the bug. If I don't call crtc_funcs->dpms(crtc, DRM_MODE_DPMS_OFF) on FB_BLANK_NORMAL but still encoder_funcs->dpms(encoder, DRM_MODE_DPMS_ON), the bug is not triggered, but the screen is not cleared either. For now, I simply reverted to the old behaviour of going directly to DPMS_STANDBY (see follow-up patch). Thanks, Johan Johan Hovold (1): drm/kms: fix fbdev blanking regression drivers/gpu/drm/drm_fb_helper.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
OK. That's the next one :-) ... In file included from r300_emit.c:36: r300_state_inlines.h: In function ‘r300_translate_tex_filters’: r300_state_inlines.h:263: error: ‘is_anisotropic’ undeclared (first use in this function) r300_state_inlines.h:263: error: (Each undeclared identifier is reported only once r300_state_inlines.h:263: error: for each function it appears in.) make: *** [r300_emit.o] Error 1 ... I am having dinner, now - Sedat - On Wed, Jan 6, 2010 at 6:07 PM, Brian Paul wrote: > Sedat Dilek wrote: >> >> Hi, >> >> this patch fixes a build-error in mesa GIT master after... >> >> commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) >> "configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster" >> >>> From my build-log: >> >> ... >> In file included from svga_pipe_fs.c:37: >> svga_tgsi.h: In function 'svga_fs_key_size': >> svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' >> make[4]: *** [svga_pipe_fs.o] Error 1 >> >> Might be introduced in... >> >> commit 955f51270bb60ad77dba049799587dc7c0fb4dda >> "Make sure we use only signed/unsigned ints with bitfields." >> >> Kind Regars, >> - Sedat - >> > > I just fixed that. > > -Brian > -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
> Commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly > handle fbdev blanking) breaks console blanking on my laptop (GM45 > chipset). Instead of blanking the screen, it is dimmed and then the > backlight starts "glowing" in the lower edges of the screen. The glowing > then slowly spreads upwards. Does not look healthy at all... > > This patch reverts to the old behaviour of going directly to > DPMS_STANDBY. The current fbdev blank is correct. Normal blanking doesn't power down the hsync or the vsync signals. If you look at fbdev drivers you will see this type of behavior. If you want a full power down then a FB_BLANK_POWERDOWN is needed. As for the blacklight that is a another problem not related to this issue. The fbdev layer sends a event to the backlight layer to tell it to power down. That powerdown happens for the backlight in all cases except FB_BLANK_UNBLANK. How is your backlight setup. Is the backlight handled via the DRI driver or acpi? > Signed-off-by: Johan Hovold > --- > drivers/gpu/drm/drm_fb_helper.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 1b49fa0..9008583 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -389,7 +389,7 @@ int drm_fb_helper_blank(int blank, struct fb_info *info) > break; > /* Display: Off; HSync: On, VSync: On */ > case FB_BLANK_NORMAL: > - drm_fb_helper_off(info, DRM_MODE_DPMS_ON); > + drm_fb_helper_off(info, DRM_MODE_DPMS_STANDBY); > break; > /* Display: Off; HSync: Off, VSync: On */ > case FB_BLANK_HSYNC_SUSPEND: > -- > 1.6.6 > > -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25916] floating point texture components reversed
http://bugs.freedesktop.org/show_bug.cgi?id=25916 Pierre Ossman changed: What|Removed |Added Summary|floating point texture |floating point texture |coordinates inverted|components reversed --- Comment #2 from Pierre Ossman 2010-01-06 09:22:31 PST --- As Alex guessed, it was a swizzling problem, not a coordinate one (the texture I was using made the it more or less impossible to tell the difference). Patch has been sent to Alex, and is also available here for a while: http://pastebin.com/m72ead66 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] [mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Sedat Dilek wrote: > Hi, > > this patch fixes a build-error in mesa GIT master after... > > commit251363e8f1287b54dc7734e690daf2ae96728faf (patch) > "configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster" > >>From my build-log: > ... > In file included from svga_pipe_fs.c:37: > svga_tgsi.h: In function 'svga_fs_key_size': > svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' > make[4]: *** [svga_pipe_fs.o] Error 1 > > Might be introduced in... > > commit955f51270bb60ad77dba049799587dc7c0fb4dda > "Make sure we use only signed/unsigned ints with bitfields." > > Kind Regars, > - Sedat - > I just fixed that. -Brian -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/kms: fix fbdev blanking regression
Commit 731b5a15a3b1474a41c2ca29b4c32b0f21bc852e (drm/kms: properly handle fbdev blanking) breaks console blanking on my laptop (GM45 chipset). Instead of blanking the screen, it is dimmed and then the backlight starts "glowing" in the lower edges of the screen. The glowing then slowly spreads upwards. Does not look healthy at all... This patch reverts to the old behaviour of going directly to DPMS_STANDBY. Signed-off-by: Johan Hovold --- drivers/gpu/drm/drm_fb_helper.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 1b49fa0..9008583 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -389,7 +389,7 @@ int drm_fb_helper_blank(int blank, struct fb_info *info) break; /* Display: Off; HSync: On, VSync: On */ case FB_BLANK_NORMAL: - drm_fb_helper_off(info, DRM_MODE_DPMS_ON); + drm_fb_helper_off(info, DRM_MODE_DPMS_STANDBY); break; /* Display: Off; HSync: Off, VSync: On */ case FB_BLANK_HSYNC_SUSPEND: -- 1.6.6 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[mesa] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h
Hi, this patch fixes a build-error in mesa GIT master after... commit 251363e8f1287b54dc7734e690daf2ae96728faf (patch) "configs: set INTEL_LIBS, INTEL_CFLAGS, etcmaster" >From my build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 Might be introduced in... commit 955f51270bb60ad77dba049799587dc7c0fb4dda "Make sure we use only signed/unsigned ints with bitfields." Kind Regars, - Sedat - From 856679477f7350553ee983f9b2bd4ff73e86f1ac Mon Sep 17 00:00:00 2001 From: Sedat Dilek Date: Wed, 6 Jan 2010 17:22:14 +0100 Subject: [PATCH] svga: Fix error: cannot take address of bit-field 'texture_target' in svga_tgsi.h From build-log: ... In file included from svga_pipe_fs.c:37: svga_tgsi.h: In function 'svga_fs_key_size': svga_tgsi.h:122: error: cannot take address of bit-field 'texture_target' make[4]: *** [svga_pipe_fs.o] Error 1 --- src/gallium/drivers/svga/svga_tgsi.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/svga/svga_tgsi.h b/src/gallium/drivers/svga/svga_tgsi.h index 1309c33..d49920d 100644 --- a/src/gallium/drivers/svga/svga_tgsi.h +++ b/src/gallium/drivers/svga/svga_tgsi.h @@ -56,7 +56,7 @@ struct svga_fs_compile_key unsigned compare_func:3; unsigned unnormalized:1; unsigned width_height_idx:7; - unsigned texture_target:8; + unsigned texture_target; } tex[PIPE_MAX_SAMPLERS]; }; -- 1.6.6 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25916] floating point texture coordinates inverted
http://bugs.freedesktop.org/show_bug.cgi?id=25916 --- Comment #1 from Alex Deucher 2010-01-06 08:48:07 PST --- The swizzles may be wrong for some texture formats. See r600GetTexFormat() in r600_texstate.c. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25916] New: floating point texture coordinates inverted
http://bugs.freedesktop.org/show_bug.cgi?id=25916 Summary: floating point texture coordinates inverted Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: pierre-bugzi...@ossman.eu All floating point textures seem to get their coordinates inverted. I don't know if this is a generic mesa bug or something specific to r600 as swrast doesn't support float textures yet. Works fine with fglrx though. I've confirmed the issue by using the exact same program and just switching between a GL_RGBA16F_ARB and a GL_RGBA texture. The first gets both the s and t coordinate inverted and the second works fine. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] Failure with swiotlb
On 01/05/2010 04:20 PM, Zhenyu Wang wrote: > On 2010.01.04 13:11:56 -0800, Eric Anholt wrote: >> On Mon, 4 Jan 2010 17:27:45 +0800, Zhenyu Wang >> wrote: >>> On 2009.12.31 12:33:06 +0800, Zhenyu Wang wrote: On 2009.12.30 10:26:27 +, David Woodhouse wrote: > On Wed, 2009-12-30 at 11:02 +0800, Zhenyu Wang wrote: >> We have .31->.32 regression as reported in >> http://bugs.freedesktop.org/show_bug.cgi?id=25690 >> http://bugzilla.kernel.org/show_bug.cgi?id=14627 >> >> It's triggered on non VT-d machine (or machine that should have VT-d, >> but no way to turn it on in BIOS.) and with large memory, and swiotlb >> is used for PCI dma ops. swiotlb uses a bounce buffer to copy between >> CPU pages and real pages made for DMA, but we can't make it real coherent >> as we don't call pci_dma_sync_single_for_cpu() alike APIs. And in GEM >> domain change, we also can't flush pages for bounce buffer. It looks like >> our usual non-cache-coherent graphics device can't love swiotlb. >> >> This patch trys to only handle pci dma mapping in case of real iommu >> hardware detected, the only case for that is VT-d. And fallback to origin >> method to insert physical page directly in other case. This fixes the >> GPU hang on our Q965 with 8G memory in 64-bit OS. Comments? > > I don't understand. Why is swiotlb doing anything here anyway, when the > device has a dma_mask of 36 bits? > > Shouldn't dma_capable() return 1, causing swiotlb_map_page() to return > the original address unmangled? Good point, I didn't look into swiotlb code, coz my debug showed it returned mangled dma address. So looks the real problem is 36 bit dma mask got corrupted somehow, which matches first report in fd.o bug 25690. Looks we should setup dma mask in drm/i915 driver too, as they both operate on graphics device. But I can't test that on our 8G mem machine until after new year. >>> >>> Finally caught it! It's within drm_pci_alloc() which will try to setup dma >>> mask >>> for pci_dev again! That is used for physical address based hardware status >>> page >>> for 965G (i915_init_phys_hws()), as alloc with pci coherent interface. But >>> trying >>> to set mask again in an alloc function looks wrong to me, and driver should >>> setup >>> their own consistent dma mask according to hw. >>> >>> So following patch trys to remove mask setting in drm_pci_alloc(), which >>> fixed >>> the origin problem as dma mask now has the right 36bit setting on intel hw. >>> I >>> can't test if ati bits looks correct, Dave? >>> >>> As intel hws page does support 36bit physical address, that will be another >>> patch >>> for setup pci consistent 36bit mask for it. Any comment? >> >> Looks like this patch doesn't set the dma mask that used to get set for >> the drivers that were relying on it. Once all the drivers are fixed to >> set it up at load time, this seems like a good interface fix. > > In my patch all removed ones were 32bit mask, which is pci dma default mask. > So if driver doesn't set dma mask before, it should also be fine with this > change. This failure also seems to be responsible for the bug 25510 since applying the patch to the last git kernel fix it. I will add a comment on the bug 25510 file. I was not able to apply the patch on the v2.6.32.x series because of multiple declarations though. Mathieu -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25892] segfault in r300_dri.so
http://bugs.freedesktop.org/show_bug.cgi?id=25892 --- Comment #5 from Michel Dänzer 2010-01-06 05:11:02 PST --- (In reply to comment #4) > However on calling glxinfo within gdb I still get: > > "Reading symbols from /usr/bin/glxinfo...(no debugging symbols found)...done." That should be okay, so long as it can get debugging symbols for r300_dri.so. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25892] segfault in r300_dri.so
http://bugs.freedesktop.org/show_bug.cgi?id=25892 --- Comment #4 from Heinrich Fu Jin Wang 2010-01-06 04:59:39 PST --- I tried to receive a backtrace from gdb but obviously my computer skills are not sufficient. After reading a couple of howtos on debugging with gdb in the internet I installed xserver-xorg-core-dbg, recompiled drm, ddx and mesa with CFLAGS="-march=native -O2 -ggdb" (and aditionally configured mesa with --enable-debug running ./autogen.sh). However on calling glxinfo within gdb I still get: "Reading symbols from /usr/bin/glxinfo...(no debugging symbols found)...done." Sorry, it seems as though I cannot contribute anything useful at the moment. Best regards, Heinrich -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Workaround RV410/R420 CP errata (V2)
From: Corbin Simpson
Long story short, this fixes sporadic hardlocks with my rv410 during
times of intense 2D acceleration (Flash on Fx3).
V2: Fix indentation and move errata_fini to suspend function so we
don't leak scratch register over suspend/resume cycle.
Signed-off-by: Corbin Simpson
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/r420.c | 31 +++
drivers/gpu/drm/radeon/radeon.h |1 +
2 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index c05a727..48ab18f 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -30,6 +30,7 @@
#include "radeon_reg.h"
#include "radeon.h"
#include "atom.h"
+#include "r100d.h"
#include "r420d.h"
int r420_mc_init(struct radeon_device *rdev)
@@ -165,6 +166,34 @@ static void r420_clock_resume(struct radeon_device *rdev)
WREG32_PLL(R_0D_SCLK_CNTL, sclk_cntl);
}
+static void r420_cp_errata_init(struct radeon_device *rdev)
+{
+ /* RV410 and R420 can lock up if CP DMA to host memory happens
+* while the 2D engine is busy.
+*
+* The proper workaround is to queue a RESYNC at the beginning
+* of the CP init, apparently.
+*/
+ radeon_scratch_get(rdev, &rdev->resync_scratch);
+ radeon_ring_lock(rdev, 8);
+ radeon_ring_write(rdev, PACKET0(R300_CP_RESYNC_ADDR, 1));
+ radeon_ring_write(rdev, rdev->resync_scratch);
+ radeon_ring_write(rdev, 0xDEADBEEF);
+ radeon_ring_unlock_commit(rdev);
+}
+
+static void r420_cp_errata_fini(struct radeon_device *rdev)
+{
+ /* Catch the RESYNC we dispatched all the way back,
+* at the very beginning of the CP init.
+*/
+ radeon_ring_lock(rdev, 8);
+ radeon_ring_write(rdev, PACKET0(R300_RB3D_DSTCACHE_CTLSTAT, 0));
+ radeon_ring_write(rdev, R300_RB3D_DC_FINISH);
+ radeon_ring_unlock_commit(rdev);
+ radeon_scratch_free(rdev, rdev->resync_scratch);
+}
+
static int r420_startup(struct radeon_device *rdev)
{
int r;
@@ -196,6 +225,7 @@ static int r420_startup(struct radeon_device *rdev)
dev_err(rdev->dev, "failled initializing CP (%d).\n", r);
return r;
}
+ r420_cp_errata_init(rdev);
r = r100_wb_init(rdev);
if (r) {
dev_err(rdev->dev, "failled initializing WB (%d).\n", r);
@@ -238,6 +268,7 @@ int r420_resume(struct radeon_device *rdev)
int r420_suspend(struct radeon_device *rdev)
{
+ r420_cp_errata_fini(rdev);
r100_cp_disable(rdev);
r100_wb_disable(rdev);
r100_irq_disable(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index cd650fd..b272065 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -798,6 +798,7 @@ struct radeon_device {
struct radeon_gem gem;
struct radeon_pmpm;
uint32_tbios_scratch[RADEON_BIOS_NUM_SCRATCH];
+uint32_t resync_scratch;
struct mutexcs_mutex;
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
