drm i915 hangs on heavy io load
Hi Dave, hi Chris,
thanks for your answers.
On Di, 23 Okt 2012, Dave Airlie wrote:
> Does booting with i915.i915_enable_rc6=0 help?
No,booted with that, it happened again on a completely idle
system (well, I believe completely idle, I was doing the
dishes ;-)
[12437.995026] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[12437.995034] [drm] capturing error event; look for more information in
/debug/dri/0/i915_error_state
[12438.000213] [drm:init_ring_common] *ERROR* failed to set render ring head to
zero ctl head 5ee06f14 tail start 3000
[12438.054894] [drm:init_ring_common] *ERROR* render ring initialization failed
ctl 0001f001 head 5ee06f14 tail start 3000
[12439.583064] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU
hung
[12439.583176] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring wedged!
[12439.583182] [drm:i915_reset] *ERROR* Failed to reset chip.
New output see here:
http://www.logic.at/people/preining/i915_error_state.gz
> http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pile&id=0d5fed2de763b49bb1a90140758153481f043757
> is the missing ingredient.
I am compiling a kernel with this patch based on current git now.
Should I still use the above kernel cmd argument (i915...rc6=0)
or try without it?
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
What are you talking about?
Never mind, eat the fruit.
You know, this place almost looks like the Garden of Eden.
Eat the fruit.
Sounds quite like it too.
--- Douglas Adams, The Hitchhikers Guide to the Galaxy
[PATCH 2/2] drm: add support for monotonic vblank timestamps
On Die, 2012-10-23 at 21:53 +0300, Imre Deak wrote: > Jumps in the vblank and page flip event timestamps cause trouble for > clients, so we should avoid them. The timestamp we get currently with > gettimeofday can jump, so use instead monotonic timestamps. > > For backward compatibility use a module flag to revert back to using > gettimeofday timestamps. Add also a DRM_CAP_TIMESTAMP_MONOTONIC flag > that is simply a read only version of the module flag, so that clients > can query this without depending on sysfs. > > Signed-off-by: Imre Deak drm_timestamp_monotonic should probably be a bool rather than an int. Looks good to me otherwise, as does patch 1. -- Earthling Michel D?nzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer
drm i915 hangs on heavy io load
On Wed, 24 Oct 2012 09:36:59 +0900, Norbert Preining wrote: > Hi Dave, hi Chris, > > thanks for your answers. > > On Di, 23 Okt 2012, Dave Airlie wrote: > > Does booting with i915.i915_enable_rc6=0 help? > > No,booted with that, it happened again on a completely idle > system (well, I believe completely idle, I was doing the > dishes ;-) > > [12437.995026] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... > GPU hung > [12437.995034] [drm] capturing error event; look for more information in > /debug/dri/0/i915_error_state > [12438.000213] [drm:init_ring_common] *ERROR* failed to set render ring head > to zero ctl head 5ee06f14 tail start 3000 > [12438.054894] [drm:init_ring_common] *ERROR* render ring initialization > failed ctl 0001f001 head 5ee06f14 tail start 3000 > [12439.583064] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... > GPU hung > [12439.583176] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring > wedged! > [12439.583182] [drm:i915_reset] *ERROR* Failed to reset chip. > > New output see here: > http://www.logic.at/people/preining/i915_error_state.gz That has a very similar look to it, so reasonable to assume that is the same issue. > > http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pile&id=0d5fed2de763b49bb1a90140758153481f043757 > > is the missing ingredient. > > I am compiling a kernel with this patch based on current git now. > Should I still use the above kernel cmd argument (i915...rc6=0) > or try without it? Without any rc6 parameter would be best. But if rc6=0 wasn't the solution for you, then I may have identified the wrong w/a. Can I ask you try the patches in that branch until you find one (or more perhaps) that stabilise your system? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH 2/2] drm: add support for monotonic vblank timestamps
On Wed, 2012-10-24 at 10:08 +0200, Michel D?nzer wrote: > On Die, 2012-10-23 at 21:53 +0300, Imre Deak wrote: > > Jumps in the vblank and page flip event timestamps cause trouble for > > clients, so we should avoid them. The timestamp we get currently with > > gettimeofday can jump, so use instead monotonic timestamps. > > > > For backward compatibility use a module flag to revert back to using > > gettimeofday timestamps. Add also a DRM_CAP_TIMESTAMP_MONOTONIC flag > > that is simply a read only version of the module flag, so that clients > > can query this without depending on sysfs. > > > > Signed-off-by: Imre Deak > > drm_timestamp_monotonic should probably be a bool rather than an int. Ok, will change that. Also just realized that the permission could be 0644 isntead of 0600. --Imre > > Looks good to me otherwise, as does patch 1. > >
[PATCH] drm/radeon: fix ATPX regression in acpi rework
On Tue, Oct 23, 2012 at 5:59 PM, wrote:
> From: Alex Deucher
>
> Copy and paste typo in the apci rework.
>
> Fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=49351
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_atpx_handler.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> index 5c5e5bb..37f6a90 100644
> --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> @@ -87,7 +87,7 @@ static union acpi_object *radeon_atpx_call(acpi_handle
> handle, int function,
> atpx_arg_elements[1].integer.value = 0;
> }
>
> - status = acpi_evaluate_object(handle, "ATPX", &atpx_arg, &buffer);
> + status = acpi_evaluate_object(handle, NULL, &atpx_arg, &buffer);
>
> /* Fail only if calling the method fails and ATPX is supported */
> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH -fixes 0/2] TTM Race fixes
On Mon, Oct 22, 2012 at 02:51:24PM +0200, Thomas Hellstrom wrote: > A couple of fixes for theoretical races discovered during the lockdep > discussions with Maarten Lankhorst > For the serie Reviewed-by: Jerome Glisse
[PATCH] drm: don't unnecessarily enable the polling work
... by properly checking connector->polled. This doesn't matter too
much because the polling work itself gets this slightly more right and
doesn't set repoll if there's nothing to do. But we can do better.
v2: Chris Wilson noticed that I broke polling, since repoll will never
ever be set true. Fix this up, and simplify the logic a bit while at
it.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index bb94b6d..6f03afb 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -952,8 +952,7 @@ static void output_poll_execute(struct work_struct *work)
if (!connector->polled || connector->polled ==
DRM_CONNECTOR_POLL_HPD)
continue;
- else if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
- repoll = true;
+ repoll = true;
old_status = connector->status;
/* if we are connected and don't want to poll for disconnect
@@ -997,7 +996,8 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
return;
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (connector->polled)
+ if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
+DRM_CONNECTOR_POLL_DISCONNECT))
poll = true;
}
--
1.7.11.7
[PATCH] drm/radeon: fix and simplify pot argument checks v3
GART and VRAM size limits need to be a power of two.
Fix values greater than 1GB and simplify those checks a bit.
v2: also fix radeon_vram_limit usage, and simplify test even more.
v3: fix typo in function name
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_device.c | 60 +---
1 file changed, 24 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index bd13ca0..e2f5f88 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -355,6 +355,8 @@ int radeon_wb_init(struct radeon_device *rdev)
*/
void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc *mc,
u64 base)
{
+ uint64_t limit = (uint64_t)radeon_vram_limit << 20;
+
mc->vram_start = base;
if (mc->mc_vram_size > (0x - base + 1)) {
dev_warn(rdev->dev, "limiting VRAM to PCI aperture size\n");
@@ -368,8 +370,8 @@ void radeon_vram_location(struct radeon_device *rdev,
struct radeon_mc *mc, u64
mc->mc_vram_size = mc->aper_size;
}
mc->vram_end = mc->vram_start + mc->mc_vram_size - 1;
- if (radeon_vram_limit && radeon_vram_limit < mc->real_vram_size)
- mc->real_vram_size = radeon_vram_limit;
+ if (limit && limit < mc->real_vram_size)
+ mc->real_vram_size = limit;
dev_info(rdev->dev, "VRAM: %lluM 0x%016llX - 0x%016llX (%lluM used)\n",
mc->mc_vram_size >> 20, mc->vram_start,
mc->vram_end, mc->real_vram_size >> 20);
@@ -835,6 +837,19 @@ static unsigned int radeon_vga_set_decode(void *cookie,
bool state)
}
/**
+ * radeon_check_pot_argument - check that argument is a power of two
+ *
+ * @arg: value to check
+ *
+ * Validates that a certain argument is a power of two (all asics).
+ * Returns true if argument is valid.
+ */
+static bool radeon_check_pot_argument(int arg)
+{
+ return (arg & (arg - 1)) == 0;
+}
+
+/**
* radeon_check_arguments - validate module params
*
* @rdev: radeon_device pointer
@@ -845,52 +860,25 @@ static unsigned int radeon_vga_set_decode(void *cookie,
bool state)
static void radeon_check_arguments(struct radeon_device *rdev)
{
/* vramlimit must be a power of two */
- switch (radeon_vram_limit) {
- case 0:
- case 4:
- case 8:
- case 16:
- case 32:
- case 64:
- case 128:
- case 256:
- case 512:
- case 1024:
- case 2048:
- case 4096:
- break;
- default:
+ if (!radeon_check_pot_argument(radeon_vram_limit)) {
dev_warn(rdev->dev, "vram limit (%d) must be a power of 2\n",
radeon_vram_limit);
radeon_vram_limit = 0;
- break;
}
- radeon_vram_limit = radeon_vram_limit << 20;
+
/* gtt size must be power of two and greater or equal to 32M */
- switch (radeon_gart_size) {
- case 4:
- case 8:
- case 16:
+ if (radeon_gart_size < 32) {
dev_warn(rdev->dev, "gart size (%d) too small forcing to
512M\n",
radeon_gart_size);
radeon_gart_size = 512;
- break;
- case 32:
- case 64:
- case 128:
- case 256:
- case 512:
- case 1024:
- case 2048:
- case 4096:
- break;
- default:
+
+ } else if (!radeon_check_pot_argument(radeon_gart_size)) {
dev_warn(rdev->dev, "gart size (%d) must be a power of 2\n",
radeon_gart_size);
radeon_gart_size = 512;
- break;
}
- rdev->mc.gtt_size = radeon_gart_size * 1024 * 1024;
+ rdev->mc.gtt_size = (uint64_t)radeon_gart_size << 20;
+
/* AGP mode can only be -1, 1, 2, 4, 8 */
switch (radeon_agpmode) {
case -1:
--
1.7.9.5
[PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2
On 23.10.2012 18:45, Klaus Schnass wrote:
>> /**
>> + * radeon_check_pot_argument - check that argument is a power of two
>> + *
>> + * @arg: value to check
>> + *
>> + * Validates that a certain argument is a power of two (all asics).
>> + * Returns true if argument is valid.
>> + */
>> +static bool radeon_ckeck_pot_argument(int arg)
>> +{
>> +return (arg & (arg - 1)) == 0;
>> +}
> comment says "check_pot_argument" but is called c_K_eck_pot_argument
Good catch, that's indeed a typo.
>
>> +
>> +/**
>> * radeon_check_arguments - validate module params
>> *
>> * @rdev: radeon_device pointer
>> @@ -845,52 +860,25 @@ static unsigned int radeon_vga_set_decode(void *cookie,
> bool state)
>> static void radeon_check_arguments(struct radeon_device *rdev)
>> {
>> /* vramlimit must be a power of two */
>> -switch (radeon_vram_limit) {
>> -case 0:
>> -case 4:
>> -case 8:
>> -case 16:
>> -case 32:
>> -case 64:
>> -case 128:
>> -case 256:
>> -case 512:
>> -case 1024:
>> -case 2048:
>> -case 4096:
>> -break;
>> -default:
>> +if (!radeon_ckeck_pot_argument(radeon_vram_limit)) {
> check_pot_argument is also true for radeon_vram_limit = 1 and 2 which was
> missing from the previous case statement, was that intentional?
Not really, but I don't see a reason why 1 and 2 MB limits shouldn't
work (if your resolution is low enough).
Christian.
>
> Best regards,
> Klaus
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
[PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2
On Wed, Oct 24, 2012 at 11:31 AM, Christian K?nig
wrote:
> On 23.10.2012 18:45, Klaus Schnass wrote:
>>>
>>> /**
>>> + * radeon_check_pot_argument - check that argument is a power of two
>>> + *
>>> + * @arg: value to check
>>> + *
>>> + * Validates that a certain argument is a power of two (all asics).
>>> + * Returns true if argument is valid.
>>> + */
>>> +static bool radeon_ckeck_pot_argument(int arg)
>>> +{
>>> + return (arg & (arg - 1)) == 0;
>>> +}
>>
>> comment says "check_pot_argument" but is called c_K_eck_pot_argument
>
> Good catch, that's indeed a typo.
I've fixed that up locally in my tree.
Alex
>
>
>>
>>> +
>>> +/**
>>> * radeon_check_arguments - validate module params
>>> *
>>> * @rdev: radeon_device pointer
>>> @@ -845,52 +860,25 @@ static unsigned int radeon_vga_set_decode(void
>>> *cookie,
>>
>> bool state)
>>>
>>> static void radeon_check_arguments(struct radeon_device *rdev)
>>> {
>>> /* vramlimit must be a power of two */
>>> - switch (radeon_vram_limit) {
>>> - case 0:
>>> - case 4:
>>> - case 8:
>>> - case 16:
>>> - case 32:
>>> - case 64:
>>> - case 128:
>>> - case 256:
>>> - case 512:
>>> - case 1024:
>>> - case 2048:
>>> - case 4096:
>>> - break;
>>> - default:
>>> + if (!radeon_ckeck_pot_argument(radeon_vram_limit)) {
>>
>> check_pot_argument is also true for radeon_vram_limit = 1 and 2 which was
>> missing from the previous case statement, was that intentional?
>
> Not really, but I don't see a reason why 1 and 2 MB limits shouldn't work
> (if your resolution is low enough).
>
> Christian.
>
>
>>
>> Best regards,
>> Klaus
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon drm-fixes-3.7
From: Alex Deucher Hi Dave, Fixes pull request for radeon. The main things here are fixing a ATPX regression from the acpi rework, fixing some fallout from the async VM work, and fixing some module options that were broken in certain cases. Other than that, mainly just bug fixes. The following changes since commit b8e902f24fdd16c4373ddc37a4e150c4afe9c6db: drm/ttm: Fix a theoretical race in ttm_bo_cleanup_refs() (2012-10-23 10:15:21 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.7 Alex Deucher (6): drm/radeon: add some new SI PCI ids drm/radeon: fix sparse warning drm/radeon: give each backlight a unique id drm/radeon: add error output if VM CS fails on cayman drm/radeon: fix ATPX function documentation drm/radeon: fix ATPX regression in acpi rework Christian K?nig (9): drm/radeon: fix PFP sync in vm_flush drm/radeon: fix cayman_vm_set_page v2 drm/radeon: fix si_set_page v2 drm/radeon: remove set_page check from VM code drm/radeon: fix header size estimation in VM code drm/radeon: fix and simplify pot argument checks v3 drm/radeon: use vzalloc for gart pages drm/radeon: move size limits to gem_object_create. drm/radeon: move the retry to gem_object_create drivers/gpu/drm/radeon/atombios_encoders.c |5 ++- drivers/gpu/drm/radeon/evergreen_cs.c |1 + drivers/gpu/drm/radeon/ni.c | 45 ++--- drivers/gpu/drm/radeon/nid.h|1 + drivers/gpu/drm/radeon/radeon_atpx_handler.c|6 +- drivers/gpu/drm/radeon/radeon_device.c | 60 +-- drivers/gpu/drm/radeon/radeon_gart.c| 22 - drivers/gpu/drm/radeon/radeon_gem.c | 18 ++- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |5 ++- drivers/gpu/drm/radeon/radeon_object.c | 19 --- drivers/gpu/drm/radeon/si.c | 47 +++--- include/drm/drm_pciids.h|3 + 12 files changed, 122 insertions(+), 110 deletions(-)
[PATCH] DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.
TV DAC load detection did not take into account that there are
chips with a single CRTC when attempted to enable the 2nd CRTC.
This fix adds support for single CRTC chips and cleans up handling
of different chipset generations.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 70 ---
1 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index a13ad9d..2630e4e 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -679,6 +679,9 @@ static enum drm_connector_status
radeon_legacy_primary_dac_detect(struct drm_enc
if (RREG32(RADEON_DAC_CNTL) & RADEON_DAC_CMP_OUTPUT)
found = connector_status_connected;
+ DRM_DEBUG_KMS("[%s]: Load detected: %s\n",
drm_get_encoder_name(encoder),
+ (found == connector_status_connected) ? "yes" : "no");
+
/* restore the regs we used */
WREG32(RADEON_DAC_CNTL, dac_cntl);
WREG32(RADEON_DAC_MACRO_CNTL, dac_macro_cntl);
@@ -1419,7 +1422,8 @@ static enum drm_connector_status
radeon_legacy_tv_dac_detect(struct drm_encoder
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
uint32_t crtc2_gen_cntl, tv_dac_cntl, dac_cntl2, dac_ext_cntl;
- uint32_t disp_hw_debug, disp_output_cntl, gpiopad_a, pixclks_cntl, tmp;
+ uint32_t gpiopad_a, pixclks_cntl, tmp;
+ uint32_t disp_output_cntl = 0, disp_hw_debug = 0, fp2_gen_cntl = 0,
crtc_ext_cntl = 0;
enum drm_connector_status found = connector_status_disconnected;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_tv_dac *tv_dac = radeon_encoder->enc_priv;
@@ -1459,8 +1463,17 @@ static enum drm_connector_status
radeon_legacy_tv_dac_detect(struct drm_encoder
/* save the regs we need */
pixclks_cntl = RREG32_PLL(RADEON_PIXCLKS_CNTL);
gpiopad_a = ASIC_IS_R300(rdev) ? RREG32(RADEON_GPIOPAD_A) : 0;
- disp_output_cntl = ASIC_IS_R300(rdev) ? RREG32(RADEON_DISP_OUTPUT_CNTL)
: 0;
- disp_hw_debug = ASIC_IS_R300(rdev) ? 0 : RREG32(RADEON_DISP_HW_DEBUG);
+ if (rdev->flags & RADEON_SINGLE_CRTC) {
+ crtc_ext_cntl = RREG32(RADEON_CRTC_EXT_CNTL);
+ } else {
+ if (ASIC_IS_R300(rdev)) {
+ disp_output_cntl = RREG32(RADEON_DISP_OUTPUT_CNTL);
+ } else if (rdev->family == CHIP_R200) {
+ fp2_gen_cntl = RREG32(RADEON_FP2_GEN_CNTL);
+ } else {
+ disp_hw_debug = RREG32(RADEON_DISP_HW_DEBUG);
+ }
+ }
crtc2_gen_cntl = RREG32(RADEON_CRTC2_GEN_CNTL);
tv_dac_cntl = RREG32(RADEON_TV_DAC_CNTL);
dac_ext_cntl = RREG32(RADEON_DAC_EXT_CNTL);
@@ -1473,19 +1486,28 @@ static enum drm_connector_status
radeon_legacy_tv_dac_detect(struct drm_encoder
if (ASIC_IS_R300(rdev))
WREG32_P(RADEON_GPIOPAD_A, 1, ~1);
- tmp = crtc2_gen_cntl & ~RADEON_CRTC2_PIX_WIDTH_MASK;
- tmp |= RADEON_CRTC2_CRT2_ON |
- (2 << RADEON_CRTC2_PIX_WIDTH_SHIFT);
-
- WREG32(RADEON_CRTC2_GEN_CNTL, tmp);
-
- if (ASIC_IS_R300(rdev)) {
- tmp = disp_output_cntl & ~RADEON_DISP_TVDAC_SOURCE_MASK;
- tmp |= RADEON_DISP_TVDAC_SOURCE_CRTC2;
- WREG32(RADEON_DISP_OUTPUT_CNTL, tmp);
+ if (rdev->flags & RADEON_SINGLE_CRTC) {
+ tmp = crtc_ext_cntl | RADEON_CRTC_CRT_ON;
+ WREG32(RADEON_CRTC_EXT_CNTL, tmp);
} else {
- tmp = disp_hw_debug & ~RADEON_CRT2_DISP1_SEL;
- WREG32(RADEON_DISP_HW_DEBUG, tmp);
+ if (ASIC_IS_R300(rdev)) {
+ tmp = disp_output_cntl & ~RADEON_DISP_TVDAC_SOURCE_MASK;
+ tmp |= RADEON_DISP_TVDAC_SOURCE_CRTC2;
+ WREG32(RADEON_DISP_OUTPUT_CNTL, tmp);
+ } else if (rdev->family == CHIP_R200) {
+ tmp = fp2_gen_cntl & ~(R200_FP2_SOURCE_SEL_MASK |
+ RADEON_FP2_DVO_RATE_SEL_SDR);
+ tmp |= RADEON_DISP_TV_PATH_SRC_CRTC2;
+ WREG32(RADEON_FP2_GEN_CNTL, tmp);
+ } else {
+ tmp = disp_hw_debug & ~RADEON_CRT2_DISP1_SEL;
+ WREG32(RADEON_DISP_HW_DEBUG, tmp);
+ }
+ tmp = crtc2_gen_cntl & ~RADEON_CRTC2_PIX_WIDTH_MASK;
+ tmp |= RADEON_CRTC2_CRT2_ON |
+ (2 << RADEON_CRTC2_PIX_WIDTH_SHIFT);
+
+ WREG32(RADEON_CRTC2_GEN_CNTL, tmp);
}
tmp = RADEON_TV_DAC_NBLANK |
@@ -1523,17 +1545,25 @@ static enum drm_connector_status
radeon_legacy_tv_dac_detect(struct drm_encoder
[PATCH] DRM/Radeon: Fix Load Detection on legacy primary DAC.
An uninitialized variable led to broken load detection. Signed-off-by: Egbert Eich --- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c index 2630e4e..752e98b 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c @@ -668,6 +668,7 @@ static enum drm_connector_status radeon_legacy_primary_dac_detect(struct drm_enc tmp |= RADEON_DAC_RANGE_CNTL_PS2 | RADEON_DAC_CMP_EN; WREG32(RADEON_DAC_CNTL, tmp); + tmp = dac_macro_cntl; tmp &= ~(RADEON_DAC_PDWN_R | RADEON_DAC_PDWN_G | RADEON_DAC_PDWN_B); -- 1.7.6.3
[PATCH] DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.
For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value works better on ES1000 (RV100) chips, too, as it doesn't produce any false positives on any cards I have tested. Therefore let's assume that this value is good for all RV100 and RV200 chipset generations. Signed-off-by: Egbert Eich --- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c index 752e98b..c7916ac 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c @@ -659,6 +659,8 @@ static enum drm_connector_status radeon_legacy_primary_dac_detect(struct drm_enc if (ASIC_IS_R300(rdev)) tmp |= (0x1b6 << RADEON_DAC_FORCE_DATA_SHIFT); + else if (ASIC_IS_RV100(rdev)) + tmp |= (0x1ac << RADEON_DAC_FORCE_DATA_SHIFT); else tmp |= (0x180 << RADEON_DAC_FORCE_DATA_SHIFT); -- 1.7.6.3
[PATCH] DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.
The Radeon driver uses the analog/digital flag to determine if the
DAC or the TMDS encoder should be enabled on a DVI-I connector.
If the EDID is bogus this flag is no longer reliable. This fix
adds a fallback to DAC load detection to determine if anything
is connected to the DAC. If not and a (bogus) EDID is found it
assumes a digital display is connected.
This works around problems with some crappy IPMI devices using
Radeon ES1000.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/radeon/radeon_connectors.c | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 67cfc17..b884c36 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -941,7 +941,7 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
struct drm_mode_object *obj;
int i;
enum drm_connector_status ret = connector_status_disconnected;
- bool dret = false;
+ bool dret = false, broken_edid = false;
if (!force && radeon_check_hpd_status_unchanged(connector))
return connector->status;
@@ -965,6 +965,9 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
ret = connector_status_disconnected;
DRM_ERROR("%s: detected RS690 floating bus bug,
stopping ddc detect\n", drm_get_connector_name(connector));
radeon_connector->ddc_bus = NULL;
+ } else {
+ ret = connector_status_connected;
+ broken_edid = true; /* defer use_digital to
later */
}
} else {
radeon_connector->use_digital =
!!(radeon_connector->edid->input & DRM_EDID_INPUT_DIGITAL);
@@ -1047,13 +1050,24 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
encoder_funcs = encoder->helper_private;
if (encoder_funcs->detect) {
- if (ret != connector_status_connected) {
- ret = encoder_funcs->detect(encoder,
connector);
- if (ret == connector_status_connected) {
- radeon_connector->use_digital =
false;
+ if (!broken_edid) {
+ if (ret != connector_status_connected) {
+ /* deal with analog monitors
without DDC */
+ ret =
encoder_funcs->detect(encoder, connector);
+ if (ret ==
connector_status_connected) {
+
radeon_connector->use_digital = false;
+ }
+ if (ret !=
connector_status_disconnected)
+
radeon_connector->detected_by_load = true;
}
- if (ret !=
connector_status_disconnected)
-
radeon_connector->detected_by_load = true;
+ } else {
+ enum drm_connector_status lret;
+ /* assume digital unless load detected
otherwise */
+ radeon_connector->use_digital = true;
+ lret = encoder_funcs->detect(encoder,
connector);
+ DRM_DEBUG_KMS("load_detect %x returned:
%x\n",encoder->encoder_type,lret);
+ if (lret == connector_status_connected)
+ radeon_connector->use_digital =
false;
}
break;
}
--
1.7.6.3
[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.
The Radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32 Mb VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. It is done to give X more memory to work with since the console memory is not freed but remains allocated while X is active. Still, running the fbdev Xserver driver - which we do during installation - will give applications an 8bit pseudo-color visual which doesn't look too pretty. We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower and to 8 only if 8MB or less VRAM is found. This should be a reasonable compromise for us. This patch will most likely not ever make it upstream. This works around ugly modes on crappy IPMI cards using ES1000. Signed-off-by: Egbert Eich --- drivers/gpu/drm/radeon/radeon_fb.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index cc8489d..9e8e221 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -356,9 +356,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) int bpp_sel = 32; int ret; - /* select 8 bpp console on RN50 or 16MB cards */ - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) + /* select 16 bpp console on RN50 or 32MB cards */ + if (rdev->mc.real_vram_size <= (8*1024*1024)) bpp_sel = 8; + else if (ASIC_IS_RN50(rdev) + || rdev->mc.real_vram_size <= (32*1024*1024)) + bpp_sel = 16; rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); if (!rfbdev) -- 1.7.6.3
[Bug 27708] [KMS] Repeated EDID errors despite everything working
https://bugs.freedesktop.org/show_bug.cgi?id=27708 Lauri Kasanen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Lauri Kasanen --- I don't have that screen any longer, closing. Feel free to reopen if anyone sees this in current kernels. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121024/8eaa632c/attachment.html>
[PATCH] DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.
On Wed, Oct 24, 2012 at 12:28 PM, Egbert Eich wrote:
> TV DAC load detection did not take into account that there are
> chips with a single CRTC when attempted to enable the 2nd CRTC.
> This fix adds support for single CRTC chips and cleans up handling
> of different chipset generations.
I don't think this isn't quite right. CRTC_EXT_CNTL.CRTC_CRT_ON is
the enable bit for the primary dac. CRTC2_GEN_CNTL.CRTC2_CRT2_ON is
the enable bit for the tv dac. There are only two radeon variants
with a single crtc:
the original R100 and the RN50. The R100 did not have a TV dac, so
this path is not relevant. The RN50 does have a TV DAC, but since it
is based on RV100, it still has the relevant registers even if the
second crtc is not fully functional.
Is there a specific bug this addresses?
Thanks,
Alex
>
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 70
> ---
> 1 files changed, 50 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index a13ad9d..2630e4e 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -679,6 +679,9 @@ static enum drm_connector_status
> radeon_legacy_primary_dac_detect(struct drm_enc
> if (RREG32(RADEON_DAC_CNTL) & RADEON_DAC_CMP_OUTPUT)
> found = connector_status_connected;
>
> + DRM_DEBUG_KMS("[%s]: Load detected: %s\n",
> drm_get_encoder_name(encoder),
> + (found == connector_status_connected) ? "yes" : "no");
> +
> /* restore the regs we used */
> WREG32(RADEON_DAC_CNTL, dac_cntl);
> WREG32(RADEON_DAC_MACRO_CNTL, dac_macro_cntl);
> @@ -1419,7 +1422,8 @@ static enum drm_connector_status
> radeon_legacy_tv_dac_detect(struct drm_encoder
> struct drm_device *dev = encoder->dev;
> struct radeon_device *rdev = dev->dev_private;
> uint32_t crtc2_gen_cntl, tv_dac_cntl, dac_cntl2, dac_ext_cntl;
> - uint32_t disp_hw_debug, disp_output_cntl, gpiopad_a, pixclks_cntl,
> tmp;
> + uint32_t gpiopad_a, pixclks_cntl, tmp;
> + uint32_t disp_output_cntl = 0, disp_hw_debug = 0, fp2_gen_cntl = 0,
> crtc_ext_cntl = 0;
> enum drm_connector_status found = connector_status_disconnected;
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct radeon_encoder_tv_dac *tv_dac = radeon_encoder->enc_priv;
> @@ -1459,8 +1463,17 @@ static enum drm_connector_status
> radeon_legacy_tv_dac_detect(struct drm_encoder
> /* save the regs we need */
> pixclks_cntl = RREG32_PLL(RADEON_PIXCLKS_CNTL);
> gpiopad_a = ASIC_IS_R300(rdev) ? RREG32(RADEON_GPIOPAD_A) : 0;
> - disp_output_cntl = ASIC_IS_R300(rdev) ?
> RREG32(RADEON_DISP_OUTPUT_CNTL) : 0;
> - disp_hw_debug = ASIC_IS_R300(rdev) ? 0 : RREG32(RADEON_DISP_HW_DEBUG);
> + if (rdev->flags & RADEON_SINGLE_CRTC) {
> + crtc_ext_cntl = RREG32(RADEON_CRTC_EXT_CNTL);
> + } else {
> + if (ASIC_IS_R300(rdev)) {
> + disp_output_cntl = RREG32(RADEON_DISP_OUTPUT_CNTL);
> + } else if (rdev->family == CHIP_R200) {
> + fp2_gen_cntl = RREG32(RADEON_FP2_GEN_CNTL);
> + } else {
> + disp_hw_debug = RREG32(RADEON_DISP_HW_DEBUG);
> + }
> + }
> crtc2_gen_cntl = RREG32(RADEON_CRTC2_GEN_CNTL);
> tv_dac_cntl = RREG32(RADEON_TV_DAC_CNTL);
> dac_ext_cntl = RREG32(RADEON_DAC_EXT_CNTL);
> @@ -1473,19 +1486,28 @@ static enum drm_connector_status
> radeon_legacy_tv_dac_detect(struct drm_encoder
> if (ASIC_IS_R300(rdev))
> WREG32_P(RADEON_GPIOPAD_A, 1, ~1);
>
> - tmp = crtc2_gen_cntl & ~RADEON_CRTC2_PIX_WIDTH_MASK;
> - tmp |= RADEON_CRTC2_CRT2_ON |
> - (2 << RADEON_CRTC2_PIX_WIDTH_SHIFT);
> -
> - WREG32(RADEON_CRTC2_GEN_CNTL, tmp);
> -
> - if (ASIC_IS_R300(rdev)) {
> - tmp = disp_output_cntl & ~RADEON_DISP_TVDAC_SOURCE_MASK;
> - tmp |= RADEON_DISP_TVDAC_SOURCE_CRTC2;
> - WREG32(RADEON_DISP_OUTPUT_CNTL, tmp);
> + if (rdev->flags & RADEON_SINGLE_CRTC) {
> + tmp = crtc_ext_cntl | RADEON_CRTC_CRT_ON;
> + WREG32(RADEON_CRTC_EXT_CNTL, tmp);
> } else {
> - tmp = disp_hw_debug & ~RADEON_CRT2_DISP1_SEL;
> - WREG32(RADEON_DISP_HW_DEBUG, tmp);
> + if (ASIC_IS_R300(rdev)) {
> + tmp = disp_output_cntl &
> ~RADEON_DISP_TVDAC_SOURCE_MASK;
> + tmp |= RADEON_DISP_TVDAC_SOURCE_CRTC2;
> + WREG32(RADEON_DISP_OUTPUT_CNTL, tmp);
> + } else if (rdev->family == CHIP_R200) {
> + tmp = fp2_gen_cntl & ~(R200_FP2_SOURCE_SEL_MASK |
> +
[PATCH] DRM/Radeon: Fix Load Detection on legacy primary DAC.
On Wed, Oct 24, 2012 at 12:29 PM, Egbert Eich wrote: > An uninitialized variable led to broken load detection. Looks good. Added to by -fixes queue. Thanks! Alex > > Signed-off-by: Egbert Eich > --- > drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > index 2630e4e..752e98b 100644 > --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > @@ -668,6 +668,7 @@ static enum drm_connector_status > radeon_legacy_primary_dac_detect(struct drm_enc > tmp |= RADEON_DAC_RANGE_CNTL_PS2 | RADEON_DAC_CMP_EN; > WREG32(RADEON_DAC_CNTL, tmp); > > + tmp = dac_macro_cntl; > tmp &= ~(RADEON_DAC_PDWN_R | > RADEON_DAC_PDWN_G | > RADEON_DAC_PDWN_B); > -- > 1.7.6.3 >
[PATCH] DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.
On Wed, Oct 24, 2012 at 12:31 PM, Egbert Eich wrote: > For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value > works better on ES1000 (RV100) chips, too, as it doesn't produce any false > positives on any cards I have tested. Therefore let's assume that this > value is good for all RV100 and RV200 chipset generations. Looks good. Added to by -fixes queue. Thanks! Alex > > Signed-off-by: Egbert Eich > --- > drivers/gpu/drm/radeon/radeon_legacy_encoders.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > index 752e98b..c7916ac 100644 > --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > @@ -659,6 +659,8 @@ static enum drm_connector_status > radeon_legacy_primary_dac_detect(struct drm_enc > > if (ASIC_IS_R300(rdev)) > tmp |= (0x1b6 << RADEON_DAC_FORCE_DATA_SHIFT); > + else if (ASIC_IS_RV100(rdev)) > + tmp |= (0x1ac << RADEON_DAC_FORCE_DATA_SHIFT); > else > tmp |= (0x180 << RADEON_DAC_FORCE_DATA_SHIFT); > > -- > 1.7.6.3 >
[Bug 40211] texture probleme in wolfenstein enemy territory rv770
https://bugs.freedesktop.org/show_bug.cgi?id=40211 --- Comment #15 from pitamila at free.fr --- Sorry for the late reply, I was off last week. after settings LIBGL_DEBUG=verbose it appears I had in my environment a LIBGL_DRIVERS_PATH=/opt/mesa/ pointing on an old build of mesa tree. Enemy Territory work like a charm. close this (non-)bug I'm sorry for the noise Thank you for support PS: wine work perfectly PS2: I will continue testing games and try to make usefull report this time... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121024/cfd97535/attachment.html>
[Bug 40211] texture probleme in wolfenstein enemy territory rv770
https://bugs.freedesktop.org/show_bug.cgi?id=40211 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121024/06b144b2/attachment.html>
[PATCH] DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.
On Wed, Oct 24, 2012 at 12:32 PM, Egbert Eich wrote:
> The Radeon driver uses the analog/digital flag to determine if the
> DAC or the TMDS encoder should be enabled on a DVI-I connector.
> If the EDID is bogus this flag is no longer reliable. This fix
> adds a fallback to DAC load detection to determine if anything
> is connected to the DAC. If not and a (bogus) EDID is found it
> assumes a digital display is connected.
> This works around problems with some crappy IPMI devices using
> Radeon ES1000.
Looks good. Added to by -fixes queue.
Thanks!
Alex
>
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 28
> +---
> 1 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 67cfc17..b884c36 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -941,7 +941,7 @@ radeon_dvi_detect(struct drm_connector *connector, bool
> force)
> struct drm_mode_object *obj;
> int i;
> enum drm_connector_status ret = connector_status_disconnected;
> - bool dret = false;
> + bool dret = false, broken_edid = false;
>
> if (!force && radeon_check_hpd_status_unchanged(connector))
> return connector->status;
> @@ -965,6 +965,9 @@ radeon_dvi_detect(struct drm_connector *connector, bool
> force)
> ret = connector_status_disconnected;
> DRM_ERROR("%s: detected RS690 floating bus
> bug, stopping ddc detect\n", drm_get_connector_name(connector));
> radeon_connector->ddc_bus = NULL;
> + } else {
> + ret = connector_status_connected;
> + broken_edid = true; /* defer use_digital to
> later */
> }
> } else {
> radeon_connector->use_digital =
> !!(radeon_connector->edid->input & DRM_EDID_INPUT_DIGITAL);
> @@ -1047,13 +1050,24 @@ radeon_dvi_detect(struct drm_connector *connector,
> bool force)
>
> encoder_funcs = encoder->helper_private;
> if (encoder_funcs->detect) {
> - if (ret != connector_status_connected) {
> - ret = encoder_funcs->detect(encoder,
> connector);
> - if (ret ==
> connector_status_connected) {
> - radeon_connector->use_digital
> = false;
> + if (!broken_edid) {
> + if (ret !=
> connector_status_connected) {
> + /* deal with analog monitors
> without DDC */
> + ret =
> encoder_funcs->detect(encoder, connector);
> + if (ret ==
> connector_status_connected) {
> +
> radeon_connector->use_digital = false;
> + }
> + if (ret !=
> connector_status_disconnected)
> +
> radeon_connector->detected_by_load = true;
> }
> - if (ret !=
> connector_status_disconnected)
> -
> radeon_connector->detected_by_load = true;
> + } else {
> + enum drm_connector_status lret;
> + /* assume digital unless load
> detected otherwise */
> + radeon_connector->use_digital = true;
> + lret = encoder_funcs->detect(encoder,
> connector);
> + DRM_DEBUG_KMS("load_detect %x
> returned: %x\n",encoder->encoder_type,lret);
> + if (lret ==
> connector_status_connected)
> + radeon_connector->use_digital
> = false;
> }
> break;
> }
> --
> 1.7.6.3
>
[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.
On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich wrote: > The Radeon driver reduces the framebuffer resolution to 8bpp if > a device with less than 32 Mb VRAM is found. This causes the > framebuffer to run in 8 bit paletted mode. For a text console this > is not an issue as 256 different colors is more than one gets > on a VGA text console. > It is done to give X more memory to work with since the console memory > is not freed but remains allocated while X is active. > Still, running the fbdev Xserver driver - which we do during installation > - will give applications an 8bit pseudo-color visual which doesn't look > too pretty. > We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower > and to 8 only if 8MB or less VRAM is found. > This should be a reasonable compromise for us. > This patch will most likely not ever make it upstream. > > This works around ugly modes on crappy IPMI cards using ES1000. I don't have a strong opinion either way on this one. Alex > > Signed-off-by: Egbert Eich > --- > drivers/gpu/drm/radeon/radeon_fb.c |7 +-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_fb.c > b/drivers/gpu/drm/radeon/radeon_fb.c > index cc8489d..9e8e221 100644 > --- a/drivers/gpu/drm/radeon/radeon_fb.c > +++ b/drivers/gpu/drm/radeon/radeon_fb.c > @@ -356,9 +356,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) > int bpp_sel = 32; > int ret; > > - /* select 8 bpp console on RN50 or 16MB cards */ > - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) > + /* select 16 bpp console on RN50 or 32MB cards */ > + if (rdev->mc.real_vram_size <= (8*1024*1024)) > bpp_sel = 8; > + else if (ASIC_IS_RN50(rdev) > + || rdev->mc.real_vram_size <= (32*1024*1024)) > + bpp_sel = 16; > > rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); > if (!rfbdev) > -- > 1.7.6.3 >
[PATCH] drm: kms_helper: don't lose hotplug event
There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).
To avoid this, check whether the connector state changes in all other
->detect calls (in the current helper code that's only probe_single)
and if that's the case, fire off a hotplug event. Note that we can't
directly call the hotplug event handler, since that expects that no
locks are held (due to reentrancy with the fb code to update the kms
console).
Also, this requires that drivers using the probe_single helper
function set up the poll work. All current drivers do that already,
and with the reworked hpd handling there'll be no downside to
unconditionally setting up the poll work any more.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 33 -
include/drm/drm_crtc.h| 1 +
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9d186d0..b79d7cb 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -62,6 +62,7 @@ static void drm_mode_validate_flag(struct drm_connector
*connector,
return;
}
+
/**
* drm_helper_probe_single_connector_modes - get complete set of display modes
* @dev: DRM device
@@ -93,6 +94,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
connector->helper_private;
int count = 0;
int mode_flags = 0;
+ enum drm_connector_status old_status;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
drm_get_connector_name(connector));
@@ -108,7 +110,32 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
if (connector->funcs->force)
connector->funcs->force(connector);
} else {
+ old_status = connector->status;
+
connector->status = connector->funcs->detect(connector, true);
+
+ /*
+* Normally either the driver's hpd code or the poll loop should
+* pick up any changes and fire the hotplug event. But if
+* userspace sneaks in a probe, we might miss a change. Hence
+* check here, and if anything changed start the hotplug code.
+*/
+ if (old_status != connector->status) {
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d
to %d\n",
+ connector->base.id,
+ drm_get_connector_name(connector),
+ old_status, connector->status);
+
+ /*
+* The hotplug event code might call into the fb
+* helpers, and so expects that we do not hold any
+* locks. Fire up the poll struct instead, it will
+* disable itself again.
+*/
+ dev->mode_config.delayed_event = true;
+
schedule_delayed_work(&dev->mode_config.output_poll_work,
+ 0);
+ }
}
/* Re-enable polling in case the global poll config changed. */
@@ -939,7 +966,11 @@ static void output_poll_execute(struct work_struct *work)
struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_work);
struct drm_connector *connector;
enum drm_connector_status old_status;
- bool repoll = false, changed = false;
+ bool repoll = false, changed;
+
+ /* Pick up any changes detected by the probe functions. */
+ changed = dev->mode_config.delayed_event;
+ dev->mode_config.delayed_event = false;
if (!drm_kms_helper_poll)
return;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 89f8f7f..ec207a2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -793,6 +793,7 @@ struct drm_mode_config {
/* output poll support */
bool poll_enabled;
bool poll_running;
+ bool delayed_event;
struct delayed_work output_poll_work;
/* pointers to standard properties */
--
1.7.11.7
new error message: drm:__gen6_gt_force_wake_get
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since 21th of October (since 3.6.2) I'm getting that error sometimes at my ThinkPad T420 with an integrated intel i915 graphic - wasn't aware of it before. It is safe to ignore it ? - -- MfG/Sincerely Toralf F?rster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCIQDgACgkQhyrlCH22naPSxQCgqedXag1Oz12mvu5mOmDhqnW+ +3kAoJVTrAlBgDzjNwwi7bdIduJFHb+G =M7u0 -END PGP SIGNATURE-
new error message: drm:__gen6_gt_force_wake_get
On Wed, Oct 24, 2012 at 9:23 PM, Toralf F?rster wrote: > Since 21th of October (since 3.6.2) I'm getting that error sometimes > at my ThinkPad T420 with an integrated intel i915 graphic - wasn't > aware of it before. > > It is safe to ignore it ? If it happens at boot-up and after resume, yes. If it happens more often, watch out for bad side-effects like hangs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung
> > > On Tue, Oct 23, 2012 at 10:06:52AM -0700, Justin P. Mattock wrote: > > This is happening both with MAINLINE and NEXT. > > > > basically system is running fine, then under load system becomes > > really sluggish and unresponsive. I was able to get dmesg of the > > error..: > > > > [ 7745.007008] ath9k :05:00.0 wlan0: disabling VHT as WMM/QoS is > > not supported by the AP > > [ 7745.007736] wlan0: associate with 68:7f:74:b8:05:82 (try 1/3) > > [ 7745.011456] wlan0: RX AssocResp from 68:7f:74:b8:05:82 > > (capab=0x411 status=0 aid=5) > > [ 7745.011529] wlan0: associated > > [ 8120.812482] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 8120.812642] [drm] capturing error event; look for more > > information in /debug/dri/0/i915_error_state > > [ 8122.328682] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer > > elapsed... GPU hung > > [ 8122.328845] [drm:i915_reset] *ERROR* GPU hanging too fast, > > declaring wedged! > > [ 8122.328850] [drm:i915_reset] *ERROR* Failed to reset chip. > > > > full log is here: http://fpaste.org/7xH8/ > > > > as for good kernels from what I remember 3.6.0-rc1. I can try a > > bisect on this once I get the time. or if anybody has a patch I can > > test. > > Can you please rehand your machine, and then grab the i915_error_state > from debugfs? That contains the gpu hang dump we need to diagnose things. > > And the bisect would obviously be awesome. > > Thanks, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch took a bit to trigger, but finally fired off. here is a link to the file..: intel_error_decode http://www.filefactory.com/file/22bypyjhs4mx the file was to large to send to the list.. let me know if you need more info with this. also if anybody has any ideas to trigger this would be appreciated so the bisect can be more precise. right now dont even think its worth it, due to not being able to trigger the crash causing the bisect to go astray and pointing to a wrong commit(which has happened in the past) but then again you never know. Justin P. Mattock
[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
On 10/24/2012 01:14 PM, Arend van Spriel wrote:
> On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
>> I have this lockdep warning on wireless-testing tree based
>> on 3.7-rc1 (no other patches except wireless bits).
>>
>> =
>> Restarting tasks ... done.
>> [ INFO: possible recursive locking detected ]
>> 3.7.0-rc1-wl+ #2 Not tainted
>> -
>> Xorg/2269 is trying to acquire lock:
>> (&cli->mutex){+.+.+.}, at: []
>> nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
>>
>> but task is already holding lock:
>> (&cli->mutex){+.+.+.}, at: []
>> nouveau_abi16_get+0x34/0x100 [nouveau]
>>
>
> I have observed the same bug so I built and tested v3.7-rc2 tag with
> lockdep enabled. It has the same problem and it results in a failure to
> resume after suspend. See below.
>
> Gr. AvS
digging into the trace:
nouveau_gem_ioctl_pushbuf() calls nouveau_abi16_get() which grabs the
mutex. Assume this should protect the chan variable passed to
nouveau_gem_pushbuf_validate(), which does a bit more that validate as
it ends up in nouveau_bo_move_m2mf() which uses the drm->chan. However,
it deadlocks before that.
Gr. AvS
[BUG 3.7-rc1] nouveau cli->mutex possible recursive locking detected
On 10/16/2012 02:43 PM, Stanislaw Gruszka wrote:
> I have this lockdep warning on wireless-testing tree based
> on 3.7-rc1 (no other patches except wireless bits).
>
> =
> Restarting tasks ... done.
> [ INFO: possible recursive locking detected ]
> 3.7.0-rc1-wl+ #2 Not tainted
> -
> Xorg/2269 is trying to acquire lock:
> (&cli->mutex){+.+.+.}, at: []
> nouveau_bo_move_m2mf+0x5f/0x170 [nouveau]
>
> but task is already holding lock:
> (&cli->mutex){+.+.+.}, at: []
> nouveau_abi16_get+0x34/0x100 [nouveau]
>
I have observed the same bug so I built and tested v3.7-rc2 tag with
lockdep enabled. It has the same problem and it results in a failure to
resume after suspend. See below.
Gr. AvS
[ 76.272795] PM: suspend of devices complete after 2149.188 msecs
[ 76.273110] PM: suspend devices took 2.152 seconds
[ 76.273354] suspend debug: Waiting for 5 seconds.
[ 81.233082] ehci_hcd :00:1a.0: setting latency timer to 64
[ 81.233369] ehci_hcd :00:1d.0: setting latency timer to 64
[ 81.233422] pci :00:1e.0: setting latency timer to 64
[ 81.248934] e1000e :00:19.0: wake-up capability disabled by ACPI
[ 81.249398] e1000e :00:19.0: irq 41 for MSI/MSI-X
[ 81.249903] ahci :00:1f.2: setting latency timer to 64
[ 81.249982] snd_hda_intel :00:1b.0: irq 43 for MSI/MSI-X
[ 81.250515] nouveau [ DRM] re-enabling device...
[ 81.250548] nouveau [ DRM] resuming client object trees...
[ 81.250557] nouveau [ VBIOS][:01:00.0] running init tables
[ 81.701998] nouveau [ DRM] resuming display...
[ 81.803923] firewire_core :04:00.4: rediscovered device fw0
[ 81.823913] dell_wmi: Received unknown WMI event (0x11)
[ 81.824521] serial 00:08: activated
[ 82.135333] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 82.187115] ata6: SATA link down (SStatus 0 SControl 300)
[ 82.232290] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 82.284002] ata5: SATA link down (SStatus 0 SControl 300)
[ 82.330629] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by
device (Stat=0x51 Err=0x04)
[ 82.408079] ata2.00: configured for UDMA/133
[ 84.073571] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 84.127965] ata1.00: ACPI cmd 00/00:00:00:00:00:a0 (NOP) rejected by
device (Stat=0x51 Err=0x04)
[ 84.202292] ata1.00: failed to get Identify Device Data, Emask 0x1
[ 84.254039] ata1.00: configured for UDMA/133
[ 84.303718] sd 0:0:0:0: [sda] Starting disk
[ 84.360186] PM: resume of devices complete after 3132.774 msecs
[ 84.410322] PM: resume devices took 3.180 seconds
[ 84.449642] PM: Finishing wakeup.
[ 84.505964]
[ 84.506716] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow
Control: Rx
[ 84.477326] Restarting tasks ... done.
[ 84.575294] video LNXVIDEO:00: Restoring backlight state
[ 84.623825] =
[ 84.623825] [ INFO: possible recursive locking detected ]
[ 84.623826] 3.7.0-rc2-testing-lockdep #1 Not tainted
[ 84.623827] -
[ 84.623827] Xorg/1369 is trying to acquire lock:
[ 84.623828] (&cli->mutex){+.+.+.}, at: []
nouveau_bo_move_m2mf.isra.13+0x38/0x120 [nouveau]
[ 84.623856]
[ 84.623856] but task is already holding lock:
[ 84.623856] (&cli->mutex){+.+.+.}, at: []
nouveau_abi16_get+0x26/0x110 [nouveau]
[ 84.623871]
[ 84.623871] other info that might help us debug this:
[ 84.623872] Possible unsafe locking scenario:
[ 84.623872]
[ 84.623872]CPU0
[ 84.623872]
[ 84.623873] lock(&cli->mutex);
[ 84.623874] lock(&cli->mutex);
[ 84.623874]
[ 84.623874] *** DEADLOCK ***
[ 84.623874]
[ 84.623874] May be due to missing lock nesting notation
[ 84.623874]
[ 84.623875] 1 lock held by Xorg/1369:
[ 84.623889] #0: (&cli->mutex){+.+.+.}, at: []
nouveau_abi16_get+0x26/0x110 [nouveau]
[ 84.623890]
[PATCH] drivers/gpu/drm/radeon/evergreen_cs.c: Remove unnecessary semicolon
A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // @r1@ statement S; position p,p1; @@ S at p1;@p @script:python r2@ p << r1.p; p1 << r1.p1; @@ if p[0].line != p1[0].line_end: cocci.include_match(False) @@ position r1.p; @@ -;@p // Signed-off-by: Peter Senna Tschudin --- The full version of the semantic patch can be found at: http://www.mail-archive.com/cocci at systeme.lip6.fr/msg00014.html drivers/gpu/drm/radeon/evergreen_cs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c b/drivers/gpu/drm/radeon/evergreen_cs.c index 573ed1b..5daf0c5 100644 --- a/drivers/gpu/drm/radeon/evergreen_cs.c +++ b/drivers/gpu/drm/radeon/evergreen_cs.c @@ -264,7 +264,7 @@ static int evergreen_surface_check_2d(struct radeon_cs_parser *p, /* macro tile width & height */ palign = (8 * surf->bankw * track->npipes) * surf->mtilea; halign = (8 * surf->bankh * surf->nbanks) / surf->mtilea; - mtileb = (palign / 8) * (halign / 8) * tileb;; + mtileb = (palign / 8) * (halign / 8) * tileb; mtile_pr = surf->nbx / palign; mtile_ps = (mtile_pr * surf->nby) / halign; surf->layer_size = mtile_ps * mtileb * slice_pt; -- 1.7.11.7
Re: [PATCH 2/2] drm: add support for monotonic vblank timestamps
On Die, 2012-10-23 at 21:53 +0300, Imre Deak wrote: > Jumps in the vblank and page flip event timestamps cause trouble for > clients, so we should avoid them. The timestamp we get currently with > gettimeofday can jump, so use instead monotonic timestamps. > > For backward compatibility use a module flag to revert back to using > gettimeofday timestamps. Add also a DRM_CAP_TIMESTAMP_MONOTONIC flag > that is simply a read only version of the module flag, so that clients > can query this without depending on sysfs. > > Signed-off-by: Imre Deak drm_timestamp_monotonic should probably be a bool rather than an int. Looks good to me otherwise, as does patch 1. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm i915 hangs on heavy io load
On Wed, 24 Oct 2012 09:36:59 +0900, Norbert Preining wrote: > Hi Dave, hi Chris, > > thanks for your answers. > > On Di, 23 Okt 2012, Dave Airlie wrote: > > Does booting with i915.i915_enable_rc6=0 help? > > No,booted with that, it happened again on a completely idle > system (well, I believe completely idle, I was doing the > dishes ;-) > > [12437.995026] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... > GPU hung > [12437.995034] [drm] capturing error event; look for more information in > /debug/dri/0/i915_error_state > [12438.000213] [drm:init_ring_common] *ERROR* failed to set render ring head > to zero ctl head 5ee06f14 tail start 3000 > [12438.054894] [drm:init_ring_common] *ERROR* render ring initialization > failed ctl 0001f001 head 5ee06f14 tail start 3000 > [12439.583064] [drm:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... > GPU hung > [12439.583176] [drm:i915_reset] *ERROR* GPU hanging too fast, declaring > wedged! > [12439.583182] [drm:i915_reset] *ERROR* Failed to reset chip. > > New output see here: > http://www.logic.at/people/preining/i915_error_state.gz That has a very similar look to it, so reasonable to assume that is the same issue. > > http://cgit.freedesktop.org/~danvet/drm/commit/?h=ilk-wa-pile&id=0d5fed2de763b49bb1a90140758153481f043757 > > is the missing ingredient. > > I am compiling a kernel with this patch based on current git now. > Should I still use the above kernel cmd argument (i915...rc6=0) > or try without it? Without any rc6 parameter would be best. But if rc6=0 wasn't the solution for you, then I may have identified the wrong w/a. Can I ask you try the patches in that branch until you find one (or more perhaps) that stabilise your system? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: add support for monotonic vblank timestamps
On Wed, 2012-10-24 at 10:08 +0200, Michel Dänzer wrote: > On Die, 2012-10-23 at 21:53 +0300, Imre Deak wrote: > > Jumps in the vblank and page flip event timestamps cause trouble for > > clients, so we should avoid them. The timestamp we get currently with > > gettimeofday can jump, so use instead monotonic timestamps. > > > > For backward compatibility use a module flag to revert back to using > > gettimeofday timestamps. Add also a DRM_CAP_TIMESTAMP_MONOTONIC flag > > that is simply a read only version of the module flag, so that clients > > can query this without depending on sysfs. > > > > Signed-off-by: Imre Deak > > drm_timestamp_monotonic should probably be a bool rather than an int. Ok, will change that. Also just realized that the permission could be 0644 isntead of 0600. --Imre > > Looks good to me otherwise, as does patch 1. > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fix ATPX regression in acpi rework
On Tue, Oct 23, 2012 at 5:59 PM, wrote:
> From: Alex Deucher
>
> Copy and paste typo in the apci rework.
>
> Fixes:
> https://bugzilla.kernel.org/show_bug.cgi?id=49351
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> ---
> drivers/gpu/drm/radeon/radeon_atpx_handler.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> index 5c5e5bb..37f6a90 100644
> --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c
> @@ -87,7 +87,7 @@ static union acpi_object *radeon_atpx_call(acpi_handle
> handle, int function,
> atpx_arg_elements[1].integer.value = 0;
> }
>
> - status = acpi_evaluate_object(handle, "ATPX", &atpx_arg, &buffer);
> + status = acpi_evaluate_object(handle, NULL, &atpx_arg, &buffer);
>
> /* Fail only if calling the method fails and ATPX is supported */
> if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
> --
> 1.7.7.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -fixes 0/2] TTM Race fixes
On Mon, Oct 22, 2012 at 02:51:24PM +0200, Thomas Hellstrom wrote: > A couple of fixes for theoretical races discovered during the lockdep > discussions with Maarten Lankhorst > For the serie Reviewed-by: Jerome Glisse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: don't unnecessarily enable the polling work
... by properly checking connector->polled. This doesn't matter too
much because the polling work itself gets this slightly more right and
doesn't set repoll if there's nothing to do. But we can do better.
v2: Chris Wilson noticed that I broke polling, since repoll will never
ever be set true. Fix this up, and simplify the logic a bit while at
it.
Signed-Off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index bb94b6d..6f03afb 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -952,8 +952,7 @@ static void output_poll_execute(struct work_struct *work)
if (!connector->polled || connector->polled ==
DRM_CONNECTOR_POLL_HPD)
continue;
- else if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
- repoll = true;
+ repoll = true;
old_status = connector->status;
/* if we are connected and don't want to poll for disconnect
@@ -997,7 +996,8 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
return;
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
- if (connector->polled)
+ if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
+DRM_CONNECTOR_POLL_DISCONNECT))
poll = true;
}
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon: fix and simplify pot argument checks v3
GART and VRAM size limits need to be a power of two.
Fix values greater than 1GB and simplify those checks a bit.
v2: also fix radeon_vram_limit usage, and simplify test even more.
v3: fix typo in function name
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_device.c | 60 +---
1 file changed, 24 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index bd13ca0..e2f5f88 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -355,6 +355,8 @@ int radeon_wb_init(struct radeon_device *rdev)
*/
void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc *mc,
u64 base)
{
+ uint64_t limit = (uint64_t)radeon_vram_limit << 20;
+
mc->vram_start = base;
if (mc->mc_vram_size > (0x - base + 1)) {
dev_warn(rdev->dev, "limiting VRAM to PCI aperture size\n");
@@ -368,8 +370,8 @@ void radeon_vram_location(struct radeon_device *rdev,
struct radeon_mc *mc, u64
mc->mc_vram_size = mc->aper_size;
}
mc->vram_end = mc->vram_start + mc->mc_vram_size - 1;
- if (radeon_vram_limit && radeon_vram_limit < mc->real_vram_size)
- mc->real_vram_size = radeon_vram_limit;
+ if (limit && limit < mc->real_vram_size)
+ mc->real_vram_size = limit;
dev_info(rdev->dev, "VRAM: %lluM 0x%016llX - 0x%016llX (%lluM used)\n",
mc->mc_vram_size >> 20, mc->vram_start,
mc->vram_end, mc->real_vram_size >> 20);
@@ -835,6 +837,19 @@ static unsigned int radeon_vga_set_decode(void *cookie,
bool state)
}
/**
+ * radeon_check_pot_argument - check that argument is a power of two
+ *
+ * @arg: value to check
+ *
+ * Validates that a certain argument is a power of two (all asics).
+ * Returns true if argument is valid.
+ */
+static bool radeon_check_pot_argument(int arg)
+{
+ return (arg & (arg - 1)) == 0;
+}
+
+/**
* radeon_check_arguments - validate module params
*
* @rdev: radeon_device pointer
@@ -845,52 +860,25 @@ static unsigned int radeon_vga_set_decode(void *cookie,
bool state)
static void radeon_check_arguments(struct radeon_device *rdev)
{
/* vramlimit must be a power of two */
- switch (radeon_vram_limit) {
- case 0:
- case 4:
- case 8:
- case 16:
- case 32:
- case 64:
- case 128:
- case 256:
- case 512:
- case 1024:
- case 2048:
- case 4096:
- break;
- default:
+ if (!radeon_check_pot_argument(radeon_vram_limit)) {
dev_warn(rdev->dev, "vram limit (%d) must be a power of 2\n",
radeon_vram_limit);
radeon_vram_limit = 0;
- break;
}
- radeon_vram_limit = radeon_vram_limit << 20;
+
/* gtt size must be power of two and greater or equal to 32M */
- switch (radeon_gart_size) {
- case 4:
- case 8:
- case 16:
+ if (radeon_gart_size < 32) {
dev_warn(rdev->dev, "gart size (%d) too small forcing to
512M\n",
radeon_gart_size);
radeon_gart_size = 512;
- break;
- case 32:
- case 64:
- case 128:
- case 256:
- case 512:
- case 1024:
- case 2048:
- case 4096:
- break;
- default:
+
+ } else if (!radeon_check_pot_argument(radeon_gart_size)) {
dev_warn(rdev->dev, "gart size (%d) must be a power of 2\n",
radeon_gart_size);
radeon_gart_size = 512;
- break;
}
- rdev->mc.gtt_size = radeon_gart_size * 1024 * 1024;
+ rdev->mc.gtt_size = (uint64_t)radeon_gart_size << 20;
+
/* AGP mode can only be -1, 1, 2, 4, 8 */
switch (radeon_agpmode) {
case -1:
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2
On 23.10.2012 18:45, Klaus Schnass wrote:
/**
+ * radeon_check_pot_argument - check that argument is a power of two
+ *
+ * @arg: value to check
+ *
+ * Validates that a certain argument is a power of two (all asics).
+ * Returns true if argument is valid.
+ */
+static bool radeon_ckeck_pot_argument(int arg)
+{
+ return (arg & (arg - 1)) == 0;
+}
comment says "check_pot_argument" but is called c_K_eck_pot_argument
Good catch, that's indeed a typo.
+
+/**
* radeon_check_arguments - validate module params
*
* @rdev: radeon_device pointer
@@ -845,52 +860,25 @@ static unsigned int radeon_vga_set_decode(void *cookie,
bool state)
static void radeon_check_arguments(struct radeon_device *rdev)
{
/* vramlimit must be a power of two */
- switch (radeon_vram_limit) {
- case 0:
- case 4:
- case 8:
- case 16:
- case 32:
- case 64:
- case 128:
- case 256:
- case 512:
- case 1024:
- case 2048:
- case 4096:
- break;
- default:
+ if (!radeon_ckeck_pot_argument(radeon_vram_limit)) {
check_pot_argument is also true for radeon_vram_limit = 1 and 2 which was
missing from the previous case statement, was that intentional?
Not really, but I don't see a reason why 1 and 2 MB limits shouldn't
work (if your resolution is low enough).
Christian.
Best regards,
Klaus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm/radeon: fix and simplify pot argument checks v2
On Wed, Oct 24, 2012 at 11:31 AM, Christian König
wrote:
> On 23.10.2012 18:45, Klaus Schnass wrote:
>>>
>>> /**
>>> + * radeon_check_pot_argument - check that argument is a power of two
>>> + *
>>> + * @arg: value to check
>>> + *
>>> + * Validates that a certain argument is a power of two (all asics).
>>> + * Returns true if argument is valid.
>>> + */
>>> +static bool radeon_ckeck_pot_argument(int arg)
>>> +{
>>> + return (arg & (arg - 1)) == 0;
>>> +}
>>
>> comment says "check_pot_argument" but is called c_K_eck_pot_argument
>
> Good catch, that's indeed a typo.
I've fixed that up locally in my tree.
Alex
>
>
>>
>>> +
>>> +/**
>>> * radeon_check_arguments - validate module params
>>> *
>>> * @rdev: radeon_device pointer
>>> @@ -845,52 +860,25 @@ static unsigned int radeon_vga_set_decode(void
>>> *cookie,
>>
>> bool state)
>>>
>>> static void radeon_check_arguments(struct radeon_device *rdev)
>>> {
>>> /* vramlimit must be a power of two */
>>> - switch (radeon_vram_limit) {
>>> - case 0:
>>> - case 4:
>>> - case 8:
>>> - case 16:
>>> - case 32:
>>> - case 64:
>>> - case 128:
>>> - case 256:
>>> - case 512:
>>> - case 1024:
>>> - case 2048:
>>> - case 4096:
>>> - break;
>>> - default:
>>> + if (!radeon_ckeck_pot_argument(radeon_vram_limit)) {
>>
>> check_pot_argument is also true for radeon_vram_limit = 1 and 2 which was
>> missing from the previous case statement, was that intentional?
>
> Not really, but I don't see a reason why 1 and 2 MB limits shouldn't work
> (if your resolution is low enough).
>
> Christian.
>
>
>>
>> Best regards,
>> Klaus
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon drm-fixes-3.7
From: Alex Deucher Hi Dave, Fixes pull request for radeon. The main things here are fixing a ATPX regression from the acpi rework, fixing some fallout from the async VM work, and fixing some module options that were broken in certain cases. Other than that, mainly just bug fixes. The following changes since commit b8e902f24fdd16c4373ddc37a4e150c4afe9c6db: drm/ttm: Fix a theoretical race in ttm_bo_cleanup_refs() (2012-10-23 10:15:21 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-3.7 Alex Deucher (6): drm/radeon: add some new SI PCI ids drm/radeon: fix sparse warning drm/radeon: give each backlight a unique id drm/radeon: add error output if VM CS fails on cayman drm/radeon: fix ATPX function documentation drm/radeon: fix ATPX regression in acpi rework Christian König (9): drm/radeon: fix PFP sync in vm_flush drm/radeon: fix cayman_vm_set_page v2 drm/radeon: fix si_set_page v2 drm/radeon: remove set_page check from VM code drm/radeon: fix header size estimation in VM code drm/radeon: fix and simplify pot argument checks v3 drm/radeon: use vzalloc for gart pages drm/radeon: move size limits to gem_object_create. drm/radeon: move the retry to gem_object_create drivers/gpu/drm/radeon/atombios_encoders.c |5 ++- drivers/gpu/drm/radeon/evergreen_cs.c |1 + drivers/gpu/drm/radeon/ni.c | 45 ++--- drivers/gpu/drm/radeon/nid.h|1 + drivers/gpu/drm/radeon/radeon_atpx_handler.c|6 +- drivers/gpu/drm/radeon/radeon_device.c | 60 +-- drivers/gpu/drm/radeon/radeon_gart.c| 22 - drivers/gpu/drm/radeon/radeon_gem.c | 18 ++- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |5 ++- drivers/gpu/drm/radeon/radeon_object.c | 19 --- drivers/gpu/drm/radeon/si.c | 47 +++--- include/drm/drm_pciids.h|3 + 12 files changed, 122 insertions(+), 110 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.
TV DAC load detection did not take into account that there are
chips with a single CRTC when attempted to enable the 2nd CRTC.
This fix adds support for single CRTC chips and cleans up handling
of different chipset generations.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 70 ---
1 files changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index a13ad9d..2630e4e 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -679,6 +679,9 @@ static enum drm_connector_status
radeon_legacy_primary_dac_detect(struct drm_enc
if (RREG32(RADEON_DAC_CNTL) & RADEON_DAC_CMP_OUTPUT)
found = connector_status_connected;
+ DRM_DEBUG_KMS("[%s]: Load detected: %s\n",
drm_get_encoder_name(encoder),
+ (found == connector_status_connected) ? "yes" : "no");
+
/* restore the regs we used */
WREG32(RADEON_DAC_CNTL, dac_cntl);
WREG32(RADEON_DAC_MACRO_CNTL, dac_macro_cntl);
@@ -1419,7 +1422,8 @@ static enum drm_connector_status
radeon_legacy_tv_dac_detect(struct drm_encoder
struct drm_device *dev = encoder->dev;
struct radeon_device *rdev = dev->dev_private;
uint32_t crtc2_gen_cntl, tv_dac_cntl, dac_cntl2, dac_ext_cntl;
- uint32_t disp_hw_debug, disp_output_cntl, gpiopad_a, pixclks_cntl, tmp;
+ uint32_t gpiopad_a, pixclks_cntl, tmp;
+ uint32_t disp_output_cntl = 0, disp_hw_debug = 0, fp2_gen_cntl = 0,
crtc_ext_cntl = 0;
enum drm_connector_status found = connector_status_disconnected;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
struct radeon_encoder_tv_dac *tv_dac = radeon_encoder->enc_priv;
@@ -1459,8 +1463,17 @@ static enum drm_connector_status
radeon_legacy_tv_dac_detect(struct drm_encoder
/* save the regs we need */
pixclks_cntl = RREG32_PLL(RADEON_PIXCLKS_CNTL);
gpiopad_a = ASIC_IS_R300(rdev) ? RREG32(RADEON_GPIOPAD_A) : 0;
- disp_output_cntl = ASIC_IS_R300(rdev) ? RREG32(RADEON_DISP_OUTPUT_CNTL)
: 0;
- disp_hw_debug = ASIC_IS_R300(rdev) ? 0 : RREG32(RADEON_DISP_HW_DEBUG);
+ if (rdev->flags & RADEON_SINGLE_CRTC) {
+ crtc_ext_cntl = RREG32(RADEON_CRTC_EXT_CNTL);
+ } else {
+ if (ASIC_IS_R300(rdev)) {
+ disp_output_cntl = RREG32(RADEON_DISP_OUTPUT_CNTL);
+ } else if (rdev->family == CHIP_R200) {
+ fp2_gen_cntl = RREG32(RADEON_FP2_GEN_CNTL);
+ } else {
+ disp_hw_debug = RREG32(RADEON_DISP_HW_DEBUG);
+ }
+ }
crtc2_gen_cntl = RREG32(RADEON_CRTC2_GEN_CNTL);
tv_dac_cntl = RREG32(RADEON_TV_DAC_CNTL);
dac_ext_cntl = RREG32(RADEON_DAC_EXT_CNTL);
@@ -1473,19 +1486,28 @@ static enum drm_connector_status
radeon_legacy_tv_dac_detect(struct drm_encoder
if (ASIC_IS_R300(rdev))
WREG32_P(RADEON_GPIOPAD_A, 1, ~1);
- tmp = crtc2_gen_cntl & ~RADEON_CRTC2_PIX_WIDTH_MASK;
- tmp |= RADEON_CRTC2_CRT2_ON |
- (2 << RADEON_CRTC2_PIX_WIDTH_SHIFT);
-
- WREG32(RADEON_CRTC2_GEN_CNTL, tmp);
-
- if (ASIC_IS_R300(rdev)) {
- tmp = disp_output_cntl & ~RADEON_DISP_TVDAC_SOURCE_MASK;
- tmp |= RADEON_DISP_TVDAC_SOURCE_CRTC2;
- WREG32(RADEON_DISP_OUTPUT_CNTL, tmp);
+ if (rdev->flags & RADEON_SINGLE_CRTC) {
+ tmp = crtc_ext_cntl | RADEON_CRTC_CRT_ON;
+ WREG32(RADEON_CRTC_EXT_CNTL, tmp);
} else {
- tmp = disp_hw_debug & ~RADEON_CRT2_DISP1_SEL;
- WREG32(RADEON_DISP_HW_DEBUG, tmp);
+ if (ASIC_IS_R300(rdev)) {
+ tmp = disp_output_cntl & ~RADEON_DISP_TVDAC_SOURCE_MASK;
+ tmp |= RADEON_DISP_TVDAC_SOURCE_CRTC2;
+ WREG32(RADEON_DISP_OUTPUT_CNTL, tmp);
+ } else if (rdev->family == CHIP_R200) {
+ tmp = fp2_gen_cntl & ~(R200_FP2_SOURCE_SEL_MASK |
+ RADEON_FP2_DVO_RATE_SEL_SDR);
+ tmp |= RADEON_DISP_TV_PATH_SRC_CRTC2;
+ WREG32(RADEON_FP2_GEN_CNTL, tmp);
+ } else {
+ tmp = disp_hw_debug & ~RADEON_CRT2_DISP1_SEL;
+ WREG32(RADEON_DISP_HW_DEBUG, tmp);
+ }
+ tmp = crtc2_gen_cntl & ~RADEON_CRTC2_PIX_WIDTH_MASK;
+ tmp |= RADEON_CRTC2_CRT2_ON |
+ (2 << RADEON_CRTC2_PIX_WIDTH_SHIFT);
+
+ WREG32(RADEON_CRTC2_GEN_CNTL, tmp);
}
tmp = RADEON_TV_DAC_NBLANK |
@@ -1523,17 +1545,25 @@ static enum drm_connector_status
radeon_legacy_tv_dac_detect(struct drm_encoder
[PATCH] DRM/Radeon: Fix Load Detection on legacy primary DAC.
An uninitialized variable led to broken load detection. Signed-off-by: Egbert Eich --- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c index 2630e4e..752e98b 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c @@ -668,6 +668,7 @@ static enum drm_connector_status radeon_legacy_primary_dac_detect(struct drm_enc tmp |= RADEON_DAC_RANGE_CNTL_PS2 | RADEON_DAC_CMP_EN; WREG32(RADEON_DAC_CNTL, tmp); + tmp = dac_macro_cntl; tmp &= ~(RADEON_DAC_PDWN_R | RADEON_DAC_PDWN_G | RADEON_DAC_PDWN_B); -- 1.7.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.
For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value works better on ES1000 (RV100) chips, too, as it doesn't produce any false positives on any cards I have tested. Therefore let's assume that this value is good for all RV100 and RV200 chipset generations. Signed-off-by: Egbert Eich --- drivers/gpu/drm/radeon/radeon_legacy_encoders.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c index 752e98b..c7916ac 100644 --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c @@ -659,6 +659,8 @@ static enum drm_connector_status radeon_legacy_primary_dac_detect(struct drm_enc if (ASIC_IS_R300(rdev)) tmp |= (0x1b6 << RADEON_DAC_FORCE_DATA_SHIFT); + else if (ASIC_IS_RV100(rdev)) + tmp |= (0x1ac << RADEON_DAC_FORCE_DATA_SHIFT); else tmp |= (0x180 << RADEON_DAC_FORCE_DATA_SHIFT); -- 1.7.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.
The Radeon driver uses the analog/digital flag to determine if the
DAC or the TMDS encoder should be enabled on a DVI-I connector.
If the EDID is bogus this flag is no longer reliable. This fix
adds a fallback to DAC load detection to determine if anything
is connected to the DAC. If not and a (bogus) EDID is found it
assumes a digital display is connected.
This works around problems with some crappy IPMI devices using
Radeon ES1000.
Signed-off-by: Egbert Eich
---
drivers/gpu/drm/radeon/radeon_connectors.c | 28 +---
1 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 67cfc17..b884c36 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -941,7 +941,7 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
struct drm_mode_object *obj;
int i;
enum drm_connector_status ret = connector_status_disconnected;
- bool dret = false;
+ bool dret = false, broken_edid = false;
if (!force && radeon_check_hpd_status_unchanged(connector))
return connector->status;
@@ -965,6 +965,9 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
ret = connector_status_disconnected;
DRM_ERROR("%s: detected RS690 floating bus bug,
stopping ddc detect\n", drm_get_connector_name(connector));
radeon_connector->ddc_bus = NULL;
+ } else {
+ ret = connector_status_connected;
+ broken_edid = true; /* defer use_digital to
later */
}
} else {
radeon_connector->use_digital =
!!(radeon_connector->edid->input & DRM_EDID_INPUT_DIGITAL);
@@ -1047,13 +1050,24 @@ radeon_dvi_detect(struct drm_connector *connector, bool
force)
encoder_funcs = encoder->helper_private;
if (encoder_funcs->detect) {
- if (ret != connector_status_connected) {
- ret = encoder_funcs->detect(encoder,
connector);
- if (ret == connector_status_connected) {
- radeon_connector->use_digital =
false;
+ if (!broken_edid) {
+ if (ret != connector_status_connected) {
+ /* deal with analog monitors
without DDC */
+ ret =
encoder_funcs->detect(encoder, connector);
+ if (ret ==
connector_status_connected) {
+
radeon_connector->use_digital = false;
+ }
+ if (ret !=
connector_status_disconnected)
+
radeon_connector->detected_by_load = true;
}
- if (ret !=
connector_status_disconnected)
-
radeon_connector->detected_by_load = true;
+ } else {
+ enum drm_connector_status lret;
+ /* assume digital unless load detected
otherwise */
+ radeon_connector->use_digital = true;
+ lret = encoder_funcs->detect(encoder,
connector);
+ DRM_DEBUG_KMS("load_detect %x returned:
%x\n",encoder->encoder_type,lret);
+ if (lret == connector_status_connected)
+ radeon_connector->use_digital =
false;
}
break;
}
--
1.7.6.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.
The Radeon driver reduces the framebuffer resolution to 8bpp if a device with less than 32 Mb VRAM is found. This causes the framebuffer to run in 8 bit paletted mode. For a text console this is not an issue as 256 different colors is more than one gets on a VGA text console. It is done to give X more memory to work with since the console memory is not freed but remains allocated while X is active. Still, running the fbdev Xserver driver - which we do during installation - will give applications an 8bit pseudo-color visual which doesn't look too pretty. We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower and to 8 only if 8MB or less VRAM is found. This should be a reasonable compromise for us. This patch will most likely not ever make it upstream. This works around ugly modes on crappy IPMI cards using ES1000. Signed-off-by: Egbert Eich --- drivers/gpu/drm/radeon/radeon_fb.c |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_fb.c b/drivers/gpu/drm/radeon/radeon_fb.c index cc8489d..9e8e221 100644 --- a/drivers/gpu/drm/radeon/radeon_fb.c +++ b/drivers/gpu/drm/radeon/radeon_fb.c @@ -356,9 +356,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) int bpp_sel = 32; int ret; - /* select 8 bpp console on RN50 or 16MB cards */ - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) + /* select 16 bpp console on RN50 or 32MB cards */ + if (rdev->mc.real_vram_size <= (8*1024*1024)) bpp_sel = 8; + else if (ASIC_IS_RN50(rdev) + || rdev->mc.real_vram_size <= (32*1024*1024)) + bpp_sel = 16; rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); if (!rfbdev) -- 1.7.6.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 27708] [KMS] Repeated EDID errors despite everything working
https://bugs.freedesktop.org/show_bug.cgi?id=27708 Lauri Kasanen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Lauri Kasanen --- I don't have that screen any longer, closing. Feel free to reopen if anyone sees this in current kernels. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] DRM/Radeon: Fix TV DAC Load Detection for single CRTC chips.
On Wed, Oct 24, 2012 at 12:28 PM, Egbert Eich wrote:
> TV DAC load detection did not take into account that there are
> chips with a single CRTC when attempted to enable the 2nd CRTC.
> This fix adds support for single CRTC chips and cleans up handling
> of different chipset generations.
I don't think this isn't quite right. CRTC_EXT_CNTL.CRTC_CRT_ON is
the enable bit for the primary dac. CRTC2_GEN_CNTL.CRTC2_CRT2_ON is
the enable bit for the tv dac. There are only two radeon variants
with a single crtc:
the original R100 and the RN50. The R100 did not have a TV dac, so
this path is not relevant. The RN50 does have a TV DAC, but since it
is based on RV100, it still has the relevant registers even if the
second crtc is not fully functional.
Is there a specific bug this addresses?
Thanks,
Alex
>
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 70
> ---
> 1 files changed, 50 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index a13ad9d..2630e4e 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -679,6 +679,9 @@ static enum drm_connector_status
> radeon_legacy_primary_dac_detect(struct drm_enc
> if (RREG32(RADEON_DAC_CNTL) & RADEON_DAC_CMP_OUTPUT)
> found = connector_status_connected;
>
> + DRM_DEBUG_KMS("[%s]: Load detected: %s\n",
> drm_get_encoder_name(encoder),
> + (found == connector_status_connected) ? "yes" : "no");
> +
> /* restore the regs we used */
> WREG32(RADEON_DAC_CNTL, dac_cntl);
> WREG32(RADEON_DAC_MACRO_CNTL, dac_macro_cntl);
> @@ -1419,7 +1422,8 @@ static enum drm_connector_status
> radeon_legacy_tv_dac_detect(struct drm_encoder
> struct drm_device *dev = encoder->dev;
> struct radeon_device *rdev = dev->dev_private;
> uint32_t crtc2_gen_cntl, tv_dac_cntl, dac_cntl2, dac_ext_cntl;
> - uint32_t disp_hw_debug, disp_output_cntl, gpiopad_a, pixclks_cntl,
> tmp;
> + uint32_t gpiopad_a, pixclks_cntl, tmp;
> + uint32_t disp_output_cntl = 0, disp_hw_debug = 0, fp2_gen_cntl = 0,
> crtc_ext_cntl = 0;
> enum drm_connector_status found = connector_status_disconnected;
> struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
> struct radeon_encoder_tv_dac *tv_dac = radeon_encoder->enc_priv;
> @@ -1459,8 +1463,17 @@ static enum drm_connector_status
> radeon_legacy_tv_dac_detect(struct drm_encoder
> /* save the regs we need */
> pixclks_cntl = RREG32_PLL(RADEON_PIXCLKS_CNTL);
> gpiopad_a = ASIC_IS_R300(rdev) ? RREG32(RADEON_GPIOPAD_A) : 0;
> - disp_output_cntl = ASIC_IS_R300(rdev) ?
> RREG32(RADEON_DISP_OUTPUT_CNTL) : 0;
> - disp_hw_debug = ASIC_IS_R300(rdev) ? 0 : RREG32(RADEON_DISP_HW_DEBUG);
> + if (rdev->flags & RADEON_SINGLE_CRTC) {
> + crtc_ext_cntl = RREG32(RADEON_CRTC_EXT_CNTL);
> + } else {
> + if (ASIC_IS_R300(rdev)) {
> + disp_output_cntl = RREG32(RADEON_DISP_OUTPUT_CNTL);
> + } else if (rdev->family == CHIP_R200) {
> + fp2_gen_cntl = RREG32(RADEON_FP2_GEN_CNTL);
> + } else {
> + disp_hw_debug = RREG32(RADEON_DISP_HW_DEBUG);
> + }
> + }
> crtc2_gen_cntl = RREG32(RADEON_CRTC2_GEN_CNTL);
> tv_dac_cntl = RREG32(RADEON_TV_DAC_CNTL);
> dac_ext_cntl = RREG32(RADEON_DAC_EXT_CNTL);
> @@ -1473,19 +1486,28 @@ static enum drm_connector_status
> radeon_legacy_tv_dac_detect(struct drm_encoder
> if (ASIC_IS_R300(rdev))
> WREG32_P(RADEON_GPIOPAD_A, 1, ~1);
>
> - tmp = crtc2_gen_cntl & ~RADEON_CRTC2_PIX_WIDTH_MASK;
> - tmp |= RADEON_CRTC2_CRT2_ON |
> - (2 << RADEON_CRTC2_PIX_WIDTH_SHIFT);
> -
> - WREG32(RADEON_CRTC2_GEN_CNTL, tmp);
> -
> - if (ASIC_IS_R300(rdev)) {
> - tmp = disp_output_cntl & ~RADEON_DISP_TVDAC_SOURCE_MASK;
> - tmp |= RADEON_DISP_TVDAC_SOURCE_CRTC2;
> - WREG32(RADEON_DISP_OUTPUT_CNTL, tmp);
> + if (rdev->flags & RADEON_SINGLE_CRTC) {
> + tmp = crtc_ext_cntl | RADEON_CRTC_CRT_ON;
> + WREG32(RADEON_CRTC_EXT_CNTL, tmp);
> } else {
> - tmp = disp_hw_debug & ~RADEON_CRT2_DISP1_SEL;
> - WREG32(RADEON_DISP_HW_DEBUG, tmp);
> + if (ASIC_IS_R300(rdev)) {
> + tmp = disp_output_cntl &
> ~RADEON_DISP_TVDAC_SOURCE_MASK;
> + tmp |= RADEON_DISP_TVDAC_SOURCE_CRTC2;
> + WREG32(RADEON_DISP_OUTPUT_CNTL, tmp);
> + } else if (rdev->family == CHIP_R200) {
> + tmp = fp2_gen_cntl & ~(R200_FP2_SOURCE_SEL_MASK |
> +
Re: [PATCH] DRM/Radeon: Fix Load Detection on legacy primary DAC.
On Wed, Oct 24, 2012 at 12:29 PM, Egbert Eich wrote: > An uninitialized variable led to broken load detection. Looks good. Added to by -fixes queue. Thanks! Alex > > Signed-off-by: Egbert Eich > --- > drivers/gpu/drm/radeon/radeon_legacy_encoders.c |1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > index 2630e4e..752e98b 100644 > --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > @@ -668,6 +668,7 @@ static enum drm_connector_status > radeon_legacy_primary_dac_detect(struct drm_enc > tmp |= RADEON_DAC_RANGE_CNTL_PS2 | RADEON_DAC_CMP_EN; > WREG32(RADEON_DAC_CNTL, tmp); > > + tmp = dac_macro_cntl; > tmp &= ~(RADEON_DAC_PDWN_R | > RADEON_DAC_PDWN_G | > RADEON_DAC_PDWN_B); > -- > 1.7.6.3 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] DRM/Radeon: Fix primary DAC Load Detection for RV100 chips.
On Wed, Oct 24, 2012 at 12:31 PM, Egbert Eich wrote: > For Radeon 7500 ATI recommends a DAC_FORCE value of 0x1ac. This value > works better on ES1000 (RV100) chips, too, as it doesn't produce any false > positives on any cards I have tested. Therefore let's assume that this > value is good for all RV100 and RV200 chipset generations. Looks good. Added to by -fixes queue. Thanks! Alex > > Signed-off-by: Egbert Eich > --- > drivers/gpu/drm/radeon/radeon_legacy_encoders.c |2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > index 752e98b..c7916ac 100644 > --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c > @@ -659,6 +659,8 @@ static enum drm_connector_status > radeon_legacy_primary_dac_detect(struct drm_enc > > if (ASIC_IS_R300(rdev)) > tmp |= (0x1b6 << RADEON_DAC_FORCE_DATA_SHIFT); > + else if (ASIC_IS_RV100(rdev)) > + tmp |= (0x1ac << RADEON_DAC_FORCE_DATA_SHIFT); > else > tmp |= (0x180 << RADEON_DAC_FORCE_DATA_SHIFT); > > -- > 1.7.6.3 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40211] texture probleme in wolfenstein enemy territory rv770
https://bugs.freedesktop.org/show_bug.cgi?id=40211 --- Comment #15 from pitam...@free.fr --- Sorry for the late reply, I was off last week. after settings LIBGL_DEBUG=verbose it appears I had in my environment a LIBGL_DRIVERS_PATH=/opt/mesa/ pointing on an old build of mesa tree. Enemy Territory work like a charm. close this (non-)bug I'm sorry for the noise Thank you for support PS: wine work perfectly PS2: I will continue testing games and try to make usefull report this time... -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40211] texture probleme in wolfenstein enemy territory rv770
https://bugs.freedesktop.org/show_bug.cgi?id=40211 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTABUG -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.
On Wed, Oct 24, 2012 at 12:32 PM, Egbert Eich wrote:
> The Radeon driver uses the analog/digital flag to determine if the
> DAC or the TMDS encoder should be enabled on a DVI-I connector.
> If the EDID is bogus this flag is no longer reliable. This fix
> adds a fallback to DAC load detection to determine if anything
> is connected to the DAC. If not and a (bogus) EDID is found it
> assumes a digital display is connected.
> This works around problems with some crappy IPMI devices using
> Radeon ES1000.
Looks good. Added to by -fixes queue.
Thanks!
Alex
>
> Signed-off-by: Egbert Eich
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 28
> +---
> 1 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
> b/drivers/gpu/drm/radeon/radeon_connectors.c
> index 67cfc17..b884c36 100644
> --- a/drivers/gpu/drm/radeon/radeon_connectors.c
> +++ b/drivers/gpu/drm/radeon/radeon_connectors.c
> @@ -941,7 +941,7 @@ radeon_dvi_detect(struct drm_connector *connector, bool
> force)
> struct drm_mode_object *obj;
> int i;
> enum drm_connector_status ret = connector_status_disconnected;
> - bool dret = false;
> + bool dret = false, broken_edid = false;
>
> if (!force && radeon_check_hpd_status_unchanged(connector))
> return connector->status;
> @@ -965,6 +965,9 @@ radeon_dvi_detect(struct drm_connector *connector, bool
> force)
> ret = connector_status_disconnected;
> DRM_ERROR("%s: detected RS690 floating bus
> bug, stopping ddc detect\n", drm_get_connector_name(connector));
> radeon_connector->ddc_bus = NULL;
> + } else {
> + ret = connector_status_connected;
> + broken_edid = true; /* defer use_digital to
> later */
> }
> } else {
> radeon_connector->use_digital =
> !!(radeon_connector->edid->input & DRM_EDID_INPUT_DIGITAL);
> @@ -1047,13 +1050,24 @@ radeon_dvi_detect(struct drm_connector *connector,
> bool force)
>
> encoder_funcs = encoder->helper_private;
> if (encoder_funcs->detect) {
> - if (ret != connector_status_connected) {
> - ret = encoder_funcs->detect(encoder,
> connector);
> - if (ret ==
> connector_status_connected) {
> - radeon_connector->use_digital
> = false;
> + if (!broken_edid) {
> + if (ret !=
> connector_status_connected) {
> + /* deal with analog monitors
> without DDC */
> + ret =
> encoder_funcs->detect(encoder, connector);
> + if (ret ==
> connector_status_connected) {
> +
> radeon_connector->use_digital = false;
> + }
> + if (ret !=
> connector_status_disconnected)
> +
> radeon_connector->detected_by_load = true;
> }
> - if (ret !=
> connector_status_disconnected)
> -
> radeon_connector->detected_by_load = true;
> + } else {
> + enum drm_connector_status lret;
> + /* assume digital unless load
> detected otherwise */
> + radeon_connector->use_digital = true;
> + lret = encoder_funcs->detect(encoder,
> connector);
> + DRM_DEBUG_KMS("load_detect %x
> returned: %x\n",encoder->encoder_type,lret);
> + if (lret ==
> connector_status_connected)
> + radeon_connector->use_digital
> = false;
> }
> break;
> }
> --
> 1.7.6.3
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.
On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich wrote: > The Radeon driver reduces the framebuffer resolution to 8bpp if > a device with less than 32 Mb VRAM is found. This causes the > framebuffer to run in 8 bit paletted mode. For a text console this > is not an issue as 256 different colors is more than one gets > on a VGA text console. > It is done to give X more memory to work with since the console memory > is not freed but remains allocated while X is active. > Still, running the fbdev Xserver driver - which we do during installation > - will give applications an 8bit pseudo-color visual which doesn't look > too pretty. > We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower > and to 8 only if 8MB or less VRAM is found. > This should be a reasonable compromise for us. > This patch will most likely not ever make it upstream. > > This works around ugly modes on crappy IPMI cards using ES1000. I don't have a strong opinion either way on this one. Alex > > Signed-off-by: Egbert Eich > --- > drivers/gpu/drm/radeon/radeon_fb.c |7 +-- > 1 files changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_fb.c > b/drivers/gpu/drm/radeon/radeon_fb.c > index cc8489d..9e8e221 100644 > --- a/drivers/gpu/drm/radeon/radeon_fb.c > +++ b/drivers/gpu/drm/radeon/radeon_fb.c > @@ -356,9 +356,12 @@ int radeon_fbdev_init(struct radeon_device *rdev) > int bpp_sel = 32; > int ret; > > - /* select 8 bpp console on RN50 or 16MB cards */ > - if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024)) > + /* select 16 bpp console on RN50 or 32MB cards */ > + if (rdev->mc.real_vram_size <= (8*1024*1024)) > bpp_sel = 8; > + else if (ASIC_IS_RN50(rdev) > + || rdev->mc.real_vram_size <= (32*1024*1024)) > + bpp_sel = 16; > > rfbdev = kzalloc(sizeof(struct radeon_fbdev), GFP_KERNEL); > if (!rfbdev) > -- > 1.7.6.3 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: kms_helper: don't lose hotplug event
There's a race window (small for hpd, 10s large for polled outputs)
where userspace could sneak in with an unrelated connnector probe
ioctl call and eat the hotplug event (since neither the hpd nor the
poll code see a state change).
To avoid this, check whether the connector state changes in all other
->detect calls (in the current helper code that's only probe_single)
and if that's the case, fire off a hotplug event. Note that we can't
directly call the hotplug event handler, since that expects that no
locks are held (due to reentrancy with the fb code to update the kms
console).
Also, this requires that drivers using the probe_single helper
function set up the poll work. All current drivers do that already,
and with the reworked hpd handling there'll be no downside to
unconditionally setting up the poll work any more.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc_helper.c | 33 -
include/drm/drm_crtc.h| 1 +
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 9d186d0..b79d7cb 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -62,6 +62,7 @@ static void drm_mode_validate_flag(struct drm_connector
*connector,
return;
}
+
/**
* drm_helper_probe_single_connector_modes - get complete set of display modes
* @dev: DRM device
@@ -93,6 +94,7 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
connector->helper_private;
int count = 0;
int mode_flags = 0;
+ enum drm_connector_status old_status;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
drm_get_connector_name(connector));
@@ -108,7 +110,32 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
if (connector->funcs->force)
connector->funcs->force(connector);
} else {
+ old_status = connector->status;
+
connector->status = connector->funcs->detect(connector, true);
+
+ /*
+* Normally either the driver's hpd code or the poll loop should
+* pick up any changes and fire the hotplug event. But if
+* userspace sneaks in a probe, we might miss a change. Hence
+* check here, and if anything changed start the hotplug code.
+*/
+ if (old_status != connector->status) {
+ DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %d
to %d\n",
+ connector->base.id,
+ drm_get_connector_name(connector),
+ old_status, connector->status);
+
+ /*
+* The hotplug event code might call into the fb
+* helpers, and so expects that we do not hold any
+* locks. Fire up the poll struct instead, it will
+* disable itself again.
+*/
+ dev->mode_config.delayed_event = true;
+
schedule_delayed_work(&dev->mode_config.output_poll_work,
+ 0);
+ }
}
/* Re-enable polling in case the global poll config changed. */
@@ -939,7 +966,11 @@ static void output_poll_execute(struct work_struct *work)
struct drm_device *dev = container_of(delayed_work, struct drm_device,
mode_config.output_poll_work);
struct drm_connector *connector;
enum drm_connector_status old_status;
- bool repoll = false, changed = false;
+ bool repoll = false, changed;
+
+ /* Pick up any changes detected by the probe functions. */
+ changed = dev->mode_config.delayed_event;
+ dev->mode_config.delayed_event = false;
if (!drm_kms_helper_poll)
return;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 89f8f7f..ec207a2 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -793,6 +793,7 @@ struct drm_mode_config {
/* output poll support */
bool poll_enabled;
bool poll_running;
+ bool delayed_event;
struct delayed_work output_poll_work;
/* pointers to standard properties */
--
1.7.11.7
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
new error message: drm:__gen6_gt_force_wake_get
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since 21th of October (since 3.6.2) I'm getting that error sometimes at my ThinkPad T420 with an integrated intel i915 graphic - wasn't aware of it before. It is safe to ignore it ? - -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCIQDgACgkQhyrlCH22naPSxQCgqedXag1Oz12mvu5mOmDhqnW+ +3kAoJVTrAlBgDzjNwwi7bdIduJFHb+G =M7u0 -END PGP SIGNATURE- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: new error message: drm:__gen6_gt_force_wake_get
On Wed, Oct 24, 2012 at 9:23 PM, Toralf Förster wrote: > Since 21th of October (since 3.6.2) I'm getting that error sometimes > at my ThinkPad T420 with an integrated intel i915 graphic - wasn't > aware of it before. > > It is safe to ignore it ? If it happens at boot-up and after resume, yes. If it happens more often, watch out for bad side-effects like hangs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] DRM/Radeon: Set depth on low mem Radeon cards to 16 instead of 8.
On Thu, Oct 25, 2012 at 3:07 AM, Alex Deucher wrote: > On Wed, Oct 24, 2012 at 12:33 PM, Egbert Eich wrote: >> The Radeon driver reduces the framebuffer resolution to 8bpp if >> a device with less than 32 Mb VRAM is found. This causes the >> framebuffer to run in 8 bit paletted mode. For a text console this >> is not an issue as 256 different colors is more than one gets >> on a VGA text console. >> It is done to give X more memory to work with since the console memory >> is not freed but remains allocated while X is active. >> Still, running the fbdev Xserver driver - which we do during installation >> - will give applications an 8bit pseudo-color visual which doesn't look >> too pretty. >> We therefore limit the framebuffer bpp to 16 when memory is 24MB or lower >> and to 8 only if 8MB or less VRAM is found. >> This should be a reasonable compromise for us. >> This patch will most likely not ever make it upstream. >> >> This works around ugly modes on crappy IPMI cards using ES1000. > > I don't have a strong opinion either way on this one. Why would you use fbdev? package -modesetting at least if not the real ATI DDX. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: use monotonic time in drm_calc_vbltimestamp_from_scanoutpos
On 23.10.12 20:53, Imre Deak wrote:
For measuring duration we want to avoid that our start/end timestamps
jump, so use monotonic instead of real time for that.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/drm_irq.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 89b830d..7dc203d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -576,7 +576,8 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device
*dev, int crtc,
unsigned flags,
struct drm_crtc *refcrtc)
{
- struct timeval stime, raw_time;
+ ktime_t stime, etime, mono_time_offset;
+ struct timeval tv_etime;
struct drm_display_mode *mode;
int vbl_status, vtotal, vdisplay;
int vpos, hpos, i;
@@ -625,13 +626,14 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct
drm_device *dev, int crtc,
preempt_disable();
/* Get system timestamp before query. */
- do_gettimeofday(&stime);
+ stime = ktime_get();
/* Get vertical and horizontal scanout pos. vpos, hpos. */
vbl_status = dev->driver->get_scanout_position(dev, crtc, &vpos,
&hpos);
/* Get system timestamp after query. */
- do_gettimeofday(&raw_time);
+ etime = ktime_get();
Here is possibly a tiny race: The wall_to_monotonic offset value could
change between the ktime_get() - which uses it internally for wallclock
-> monotonic clock conversion, and the ktime_get_monotonic_offset()
query below, so the later subtraction of mono_time_offset from etime
would not cancel out the addition to etime inside ktime_get() and you
wouldn't get correct walltime back. There seem to be multiple sources of
change to the value, e.g., do_settimeofday(), do_adjtimex() - the admin
or ntp changing the system clock. The internal code, e.g., ktime_get()
use a seqlock to protect against this race.
There's a function ktime_get_real(void) which directly gives you the
wall time you want as ktime_t, but then you'd still need to do the
ktime_get() query in the !drm_timestamp_monotonic case to calculate
duration_ns below.
Same problem in the 2nd patch for get_drm_timestamp(). Otoh, the time
window for the race is small and it can only happen in the non-default
case of !drm_timestamp_monotonic, so i don't know if it is worth fixing it?
Other than that:
Reviewed-by: mario.kleiner
+ mono_time_offset = ktime_get_monotonic_offset();
preempt_enable();
@@ -642,7 +644,7 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct drm_device
*dev, int crtc,
return -EIO;
}
- duration_ns = timeval_to_ns(&raw_time) - timeval_to_ns(&stime);
+ duration_ns = ktime_to_ns(etime) - ktime_to_ns(stime);
/* Accept result with < max_error nsecs timing uncertainty. */
if (duration_ns <= (s64) *max_error)
@@ -689,14 +691,18 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct
drm_device *dev, int crtc,
vbl_status |= 0x8;
}
+ etime = ktime_sub(etime, mono_time_offset);
+ /* save this only for debugging purposes */
+ tv_etime = ktime_to_timeval(etime);
/* Subtract time delta from raw timestamp to get final
* vblank_time timestamp for end of vblank.
*/
- *vblank_time = ns_to_timeval(timeval_to_ns(&raw_time) - delta_ns);
+ etime = ktime_sub_ns(etime, delta_ns);
+ *vblank_time = ktime_to_timeval(etime);
DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d
rep]\n",
crtc, (int)vbl_status, hpos, vpos,
- (long)raw_time.tv_sec, (long)raw_time.tv_usec,
+ (long)tv_etime.tv_sec, (long)tv_etime.tv_usec,
(long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
(int)duration_ns/1000, i);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
