dri-devel September 2010

dri-devel@lists.freedesktop.org

71 participants
367 discussions

[Bug 28402] Kernel 2.6.34 freezes randomly
by bugzilla-daemon＠freedesktop.org 08 Sep '10

08 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #51 from Lukas Schneiderbauer <lukas.schneiderbauer(a)gmail.com> 2010-09-08 09:09:41 PDT --- (In reply to comment #45) > I'm testing the 2.6.36-rc3 kernel with airlied's patch at the moment. Looks > promising for me as well. But I still need some hours to really confirm it. 1.5 days uptime and no freeze. So definitely confirmed. (In reply to comment #48) > I'm sorry to report that it does not. I've tried with > 96576a9e1a0cdb8a43d3af5846be0948f52b4460 (current drm-next in airlied's tree). > This freezes without any patches, seems stable with airlied's patch to put vmem > at address 0, but freezes still with your patch. > > Lukas, can you confirm that this patch still freezes? 2.6.36-rc3 with alex' patch up for > 3 hours and waiting.. :) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

drm: fix building on non-PCI platforms
by Arnd Bergmann 08 Sep '10

08 Sep '10

BenH's fix to correct building on multi-domain systems broke building DRM for platforms without PCI support. This makes the call to pci_domain_nr conditional in order to fix compilation. Signed-off-by: Arnd Bergmann <arnd(a)arndb.de> diff --git a/include/drm/drmP.h b/include/drm/drmP.h index 7809d23..5ff5819 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -1099,7 +1099,11 @@ static inline int drm_get_pci_domain(struct drm_device *dev) return 0; #endif /* __alpha__ */ +#ifdef CONFIG_PCI return pci_domain_nr(dev->pdev->bus); +#else + return 0; +#endif } #if __OS_HAS_AGP

2 1

[Bug 28402] Kernel 2.6.34 freezes randomly
by bugzilla-daemon＠freedesktop.org 08 Sep '10

08 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #50 from Da Fox <da_fox(a)mad.scientist.com> 2010-09-08 05:02:14 PDT --- (In reply to comment #49) > I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've > tried to wake the PCs from "DPMS OFF", only to find them completely > unresponsive and needing a reboot instead. However, only one of those PCs has > an RV350 card. The other two have rv280 and rv100 cards instead, so Dave > Airlie's patch to r300.c cannot possibly help them. Chris: these freezes do occur during normal operation, i.e. while working with the computer, not only during DMPS. It happens during all kinds of activities, e.g. it may happen while browsing, typing a letter, chatting, alt-tabbing, or even not doing anything. However almost always it seems to be triggered by some activity. For me for example, for me starting firefox after a fresh boot has a 99% chance of causing a freeze during the 'restore tabs from last time' phase. Although it is quite possible that the freeze will also occur during DPMS sleep, I have not experienced it yet (mostly because the freeze will occur while working, so the computer didn't get a chance to go into DPMS sleep). So the first thing to do would be to verify that you indeed are experiencing the same issue (and not an unrelated DPMS problem) is to keep using your computer and wait for a freeze to occur during usage. Your best bet would be to try the rv350 card, I have mostly only seen people with r300 and/or rv350 describe this problem, and both me and lukas have an rv350 card (we both have a Mobility Radeon 9600 M10). Once you have confirmed that the freeze occurs during normal working operations also, you should proceed to verify our git-bisect results and test the patches provided by Dave Airlie and Alex Deucher. Best of luck! p.s. Is the rv350 card a PC or a laptop? I noticed both lukas and I have a laptop with an rv350 card, so perhaps it has something to do with mobility editions? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 28402] Kernel 2.6.34 freezes randomly
by bugzilla-daemon＠freedesktop.org 08 Sep '10

08 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #49 from Chris Rankin <rankincj(a)googlemail.com> 2010-09-08 01:45:45 PDT --- I've also noticed (rare) random freezes with 2.6.34.x kernels. Basically, I've tried to wake the PCs from "DPMS OFF", only to find them completely unresponsive and needing a reboot instead. However, only one of those PCs has an RV350 card. The other two have rv280 and rv100 cards instead, so Dave Airlie's patch to r300.c cannot possibly help them. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 28402] Kernel 2.6.34 freezes randomly
by bugzilla-daemon＠freedesktop.org 07 Sep '10

07 Sep '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #48 from Da Fox <da_fox(a)mad.scientist.com> 2010-09-07 12:25:46 PDT --- (In reply to comment #47) > Created an attachment (id=38516) View: https://bugs.freedesktop.org/attachment.cgi?id=38516 Review: https://bugs.freedesktop.org/review?bug=28402&attachment=38516 > possible fix > > Does this patch help? It always aligns the MC vram and gtt bases to size. I'm sorry to report that it does not. I've tried with 96576a9e1a0cdb8a43d3af5846be0948f52b4460 (current drm-next in airlied's tree). This freezes without any patches, seems stable with airlied's patch to put vmem at address 0, but freezes still with your patch. Lukas, can you confirm that this patch still freezes? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[PATCH] drm/radeon/kms: add connector table for Mac x800
by Alex Deucher 07 Sep '10

07 Sep '10

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=28671 Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_combios.c | 47 +++++++++++++++++++++++++++++++ drivers/gpu/drm/radeon/radeon_mode.h | 3 +- 2 files changed, 49 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c index bd74e42..a04b7a6 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -1485,6 +1485,11 @@ bool radeon_get_legacy_connector_info_from_table(struct drm_device *dev) /* PowerMac8,1 ? */ /* imac g5 isight */ rdev->mode_info.connector_table = CT_IMAC_G5_ISIGHT; + } else if ((rdev->pdev->device == 0x4a48) && + (rdev->pdev->subsystem_vendor == 0x1002) && + (rdev->pdev->subsystem_device == 0x4a48)) { + /* Mac X800 */ + rdev->mode_info.connector_table = CT_MAC_X800; } else #endif /* CONFIG_PPC_PMAC */ #ifdef CONFIG_PPC64 @@ -1961,6 +1966,48 @@ bool radeon_get_legacy_connector_info_from_table(struct drm_device *dev) CONNECTOR_OBJECT_ID_VGA, &hpd); break; + case CT_MAC_X800: + DRM_INFO("Connector Table: %d (mac x800)\n", + rdev->mode_info.connector_table); + /* DVI - primary dac, internal tmds */ + ddc_i2c = combios_setup_i2c_bus(rdev, DDC_DVI, 0, 0); + hpd.hpd = RADEON_HPD_1; /* ??? */ + radeon_add_legacy_encoder(dev, + radeon_get_encoder_enum(dev, + ATOM_DEVICE_DFP1_SUPPORT, + 0), + ATOM_DEVICE_DFP1_SUPPORT); + radeon_add_legacy_encoder(dev, + radeon_get_encoder_enum(dev, + ATOM_DEVICE_CRT1_SUPPORT, + 1), + ATOM_DEVICE_CRT1_SUPPORT); + radeon_add_legacy_connector(dev, 0, + ATOM_DEVICE_DFP1_SUPPORT | + ATOM_DEVICE_CRT1_SUPPORT, + DRM_MODE_CONNECTOR_DVII, &ddc_i2c, + CONNECTOR_OBJECT_ID_SINGLE_LINK_DVI_I, + &hpd); + /* DVI - tv dac, dvo */ + ddc_i2c = combios_setup_i2c_bus(rdev, DDC_MONID, 0, 0); + hpd.hpd = RADEON_HPD_2; /* ??? */ + radeon_add_legacy_encoder(dev, + radeon_get_encoder_enum(dev, + ATOM_DEVICE_DFP2_SUPPORT, + 0), + ATOM_DEVICE_DFP2_SUPPORT); + radeon_add_legacy_encoder(dev, + radeon_get_encoder_enum(dev, + ATOM_DEVICE_CRT2_SUPPORT, + 2), + ATOM_DEVICE_CRT2_SUPPORT); + radeon_add_legacy_connector(dev, 1, + ATOM_DEVICE_DFP2_SUPPORT | + ATOM_DEVICE_CRT2_SUPPORT, + DRM_MODE_CONNECTOR_DVII, &ddc_i2c, + CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_I, + &hpd); + break; default: DRM_INFO("Connector table: %d (invalid)\n", rdev->mode_info.connector_table); diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h index efbe975..17a6602 100644 --- a/drivers/gpu/drm/radeon/radeon_mode.h +++ b/drivers/gpu/drm/radeon/radeon_mode.h @@ -204,7 +204,7 @@ struct radeon_i2c_chan { /* mostly for macs, but really any system without connector tables */ enum radeon_connector_table { - CT_NONE, + CT_NONE = 0, CT_GENERIC, CT_IBOOK, CT_POWERBOOK_EXTERNAL, @@ -215,6 +215,7 @@ enum radeon_connector_table { CT_IMAC_G5_ISIGHT, CT_EMAC, CT_RN50_POWER, + CT_MAC_X800, }; enum radeon_dvo_chip { -- 1.7.1.1

1 0

[PATCH] drm/radeon/kms: fix regression in RMX code (v2)
by Alex Deucher 07 Sep '10

07 Sep '10

caused by d65d65b175a29bd7ea2bb69c046419329c4a5db7 need to update the radeon crtc priv native mode before using it. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=30049 v2: integrate v/h copy paste typo Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_display.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 6dd434a..8c987c9 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1140,14 +1140,14 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc, radeon_crtc->rmx_type = radeon_encoder->rmx_type; else radeon_crtc->rmx_type = RMX_OFF; - src_v = crtc->mode.vdisplay; - dst_v = radeon_crtc->native_mode.vdisplay; - src_h = crtc->mode.hdisplay; - dst_h = radeon_crtc->native_mode.vdisplay; /* copy native mode */ memcpy(&radeon_crtc->native_mode, &radeon_encoder->native_mode, sizeof(struct drm_display_mode)); + src_v = crtc->mode.vdisplay; + dst_v = radeon_crtc->native_mode.vdisplay; + src_h = crtc->mode.hdisplay; + dst_h = radeon_crtc->native_mode.hdisplay; /* fix up for overscan on hdmi */ if (ASIC_IS_AVIVO(rdev) && -- 1.7.1.1

1 0

[PATCH] drm/radeon/kms: fix regression in RMX code
by Alex Deucher 07 Sep '10

07 Sep '10

caused by d65d65b175a29bd7ea2bb69c046419329c4a5db7 need to update the radeon crtc priv native mode before using it. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=30049 Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_display.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index c7f5017..8c987c9 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1140,14 +1140,14 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc, radeon_crtc->rmx_type = radeon_encoder->rmx_type; else radeon_crtc->rmx_type = RMX_OFF; - src_v = crtc->mode.vdisplay; - dst_v = radeon_crtc->native_mode.vdisplay; - src_h = crtc->mode.hdisplay; - dst_h = radeon_crtc->native_mode.hdisplay; /* copy native mode */ memcpy(&radeon_crtc->native_mode, &radeon_encoder->native_mode, sizeof(struct drm_display_mode)); + src_v = crtc->mode.vdisplay; + dst_v = radeon_crtc->native_mode.vdisplay; + src_h = crtc->mode.hdisplay; + dst_h = radeon_crtc->native_mode.hdisplay; /* fix up for overscan on hdmi */ if (ASIC_IS_AVIVO(rdev) && -- 1.7.1.1

1 1

[PATCH] drm/radeon/kms: fix typo in d65d65b175a29bd7ea2bb69c046419329c4a5db7
by Alex Deucher 07 Sep '10

07 Sep '10

copy paste error. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 6dd434a..c7f5017 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -1143,7 +1143,7 @@ bool radeon_crtc_scaling_mode_fixup(struct drm_crtc *crtc, src_v = crtc->mode.vdisplay; dst_v = radeon_crtc->native_mode.vdisplay; src_h = crtc->mode.hdisplay; - dst_h = radeon_crtc->native_mode.vdisplay; + dst_h = radeon_crtc->native_mode.hdisplay; /* copy native mode */ memcpy(&radeon_crtc->native_mode, &radeon_encoder->native_mode, -- 1.7.1.1

1 1

[PATCH] drm/radeon/kms: force legacy pll algo for RV620 LVDS
by Alex Deucher 07 Sep '10

07 Sep '10

There has been periodic evidence that LVDS, on at least some panels, prefers the dividers selected by the legacy pll algo. This patch forces the use of the legacy pll algo on RV620 LVDS panels. The old behavior (new pll algo) can be selected by setting the new_pll module parameter to 1. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=30029 Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: stable(a)kernel.org --- drivers/gpu/drm/radeon/atombios_crtc.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 464a81a..cd0290f 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -539,14 +539,15 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, pll->algo = PLL_ALGO_LEGACY; pll->flags |= RADEON_PLL_PREFER_CLOSEST_LOWER; } - /* There is some evidence (often anecdotal) that RV515 LVDS + /* There is some evidence (often anecdotal) that RV515/RV620 LVDS * (on some boards at least) prefers the legacy algo. I'm not * sure whether this should handled generically or on a * case-by-case quirk basis. Both algos should work fine in the * majority of cases. */ if ((radeon_encoder->active_device & (ATOM_DEVICE_LCD_SUPPORT)) && - (rdev->family == CHIP_RV515)) { + ((rdev->family == CHIP_RV515) || + (rdev->family == CHIP_RV620))) { /* allow the user to overrride just in case */ if (radeon_new_pll == 1) pll->algo = PLL_ALGO_NEW; -- 1.7.1.1

1 0

← Newer
1
...
28
29
30
31
32
33
34
...
37
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2010