Re: [PATCH v2] drm: Keep disabled outputs disabled after suspend / resume
On 12/31/2009 12:00 PM, David John wrote: With the current DRM code, an output that has been powered off from userspace will automatically power back on when resuming from suspend. This patch fixes this behaviour. Tested only with the Intel i915 driver on an Intel GM45 Express chipset. Signed-off-by: David John david...@xenontk.org Ping. Any update on this? Correct? Incorrect? Utter rubbish that I should be ashamed of myself? Regards, David. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
On 01/07/2010 12:42 AM, Johan Hovold wrote: Yeap. The fix uncovered a bug in your driver. I haven't heard of problems with the other drm drivers. The backlight is handled via the DRI driver I assume. At least i9xx_crtc_dpms is called on powerdown. Can you post your dmesg and kernel config. [snip] Adding the Intel DRM people in CC as well. I have the same issue with my GM45. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Schedule host path read cache flush through the ring V2
R300 family will hard lockup if host path read cache flush is
done through MMIO to HOST_PATH_CNTL. But scheduling same flush
through ring seems harmless. This patch remove the hdp_flush
callback and add a flush after each fence emission which means
a flush after each IB schedule. Thus we should have same behavior
without the hard lockup.
Tested on R100,R200,R300,R400,R500,R600,R700 family.
V2: Adjust fence counts in r600_blit_prepare_copy()
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/r100.c | 14 ++
drivers/gpu/drm/radeon/r300.c | 16 +++-
drivers/gpu/drm/radeon/r420.c |1 +
drivers/gpu/drm/radeon/r520.c |1 +
drivers/gpu/drm/radeon/r600.c |7 ++-
drivers/gpu/drm/radeon/r600_blit_kms.c |4 ++--
drivers/gpu/drm/radeon/radeon.h|4 ++--
drivers/gpu/drm/radeon/radeon_asic.h | 12
drivers/gpu/drm/radeon/radeon_gem.c|2 --
drivers/gpu/drm/radeon/rs400.c |1 +
drivers/gpu/drm/radeon/rs600.c |1 +
drivers/gpu/drm/radeon/rs690.c |1 +
drivers/gpu/drm/radeon/rv515.c |1 +
13 files changed, 33 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 7172746..1a056b7 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -356,6 +356,11 @@ void r100_fence_ring_emit(struct radeon_device *rdev,
/* Wait until IDLE CLEAN */
radeon_ring_write(rdev, PACKET0(0x1720, 0));
radeon_ring_write(rdev, (1 16) | (1 17));
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev-config.r100.hdp_cntl |
+ RADEON_HDP_READ_BUFFER_INVALIDATE);
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev-config.r100.hdp_cntl);
/* Emit fence sequence fire IRQ */
radeon_ring_write(rdev, PACKET0(rdev-fence_drv.scratch_reg, 0));
radeon_ring_write(rdev, fence-seq);
@@ -1713,14 +1718,6 @@ void r100_gpu_init(struct radeon_device *rdev)
r100_hdp_reset(rdev);
}
-void r100_hdp_flush(struct radeon_device *rdev)
-{
- u32 tmp;
- tmp = RREG32(RADEON_HOST_PATH_CNTL);
- tmp |= RADEON_HDP_READ_BUFFER_INVALIDATE;
- WREG32(RADEON_HOST_PATH_CNTL, tmp);
-}
-
void r100_hdp_reset(struct radeon_device *rdev)
{
uint32_t tmp;
@@ -3313,6 +3310,7 @@ static int r100_startup(struct radeon_device *rdev)
}
/* Enable IRQ */
r100_irq_set(rdev);
+ rdev-config.r100.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
/* 1M ring buffer */
r = r100_cp_init(rdev, 1024 * 1024);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 3f2cc9e..b8623b7 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -36,7 +36,15 @@
#include rv350d.h
#include r300_reg_safe.h
-/* This files gather functions specifics to: r300,r350,rv350,rv370,rv380 */
+/* This files gather functions specifics to: r300,r350,rv350,rv370,rv380
+ *
+ * GPU Errata:
+ * - HOST_PATH_CNTL: r300 family seems to dislike write to HOST_PATH_CNTL
+ * using MMIO to flush host path read cache, this lead to HARDLOCKUP.
+ * However, scheduling such write to the ring seems harmless, i suspect
+ * the CP read collide with the flush somehow, or maybe the MC, hard to
+ * tell. (Jerome Glisse)
+ */
/*
* rv370,rv380 PCIE GART
@@ -178,6 +186,11 @@ void r300_fence_ring_emit(struct radeon_device *rdev,
/* Wait until IDLE CLEAN */
radeon_ring_write(rdev, PACKET0(0x1720, 0));
radeon_ring_write(rdev, (1 17) | (1 16) | (1 9));
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev-config.r300.hdp_cntl |
+ RADEON_HDP_READ_BUFFER_INVALIDATE);
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev-config.r300.hdp_cntl);
/* Emit fence sequence fire IRQ */
radeon_ring_write(rdev, PACKET0(rdev-fence_drv.scratch_reg, 0));
radeon_ring_write(rdev, fence-seq);
@@ -1258,6 +1271,7 @@ static int r300_startup(struct radeon_device *rdev)
}
/* Enable IRQ */
r100_irq_set(rdev);
+ rdev-config.r300.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
/* 1M ring buffer */
r = r100_cp_init(rdev, 1024 * 1024);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index f46502a..1d4d16e 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -219,6 +219,7 @@ static int r420_startup(struct radeon_device *rdev)
r420_pipes_init(rdev);
/* Enable IRQ */
r100_irq_set(rdev);
+ rdev-config.r300.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
[Bug 15002] New: invalid EDID checksum pause boot for 130 sec - kms, radeon
http://bugzilla.kernel.org/show_bug.cgi?id=15002 Summary: invalid EDID checksum pause boot for 130 sec - kms, radeon Product: Drivers Version: 2.5 Kernel Version: 2.6.33-rc3 2c1f1895ef2aa8f0e5497893eff71304aef332e1 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: pl4nk...@googlemail.com Regression: No macbook pro 2,2 M56P Radeon Mobility X1600 [0.295335] [drm] Initialized drm 1.1.0 20060810 [0.295388] [drm] radeon defaulting to kernel modesetting. [0.295389] [drm] radeon kernel modesetting enabled. [0.295434] radeon :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [0.295439] radeon :01:00.0: setting latency timer to 64 [0.298528] [drm] radeon: Initializing kernel modesetting. [0.298624] [drm] register mmio base: 0x9030 [0.298625] [drm] register mmio size: 65536 [0.298713] ATOM BIOS: M56P [0.298942] [drm] GPU reset succeed (RBBM_STATUS=0x1140) [0.298955] [drm] Generation 2 PCI interface, using max accessible memory [0.298958] [drm] radeon: VRAM 128M [0.298959] [drm] radeon: VRAM from 0x to 0x07FF [0.298961] [drm] radeon: GTT 512M [0.298962] [drm] radeon: GTT from 0x2000 to 0x3FFF [0.299018] radeon :01:00.0: irq 28 for MSI/MSI-X [0.299023] [drm] radeon: using MSI. [0.299047] [drm] radeon: irq initialized. [0.300510] [drm] Detected VRAM RAM=128M, BAR=128M [0.300514] [drm] RAM width 128bits DDR [0.300809] [TTM] Zone kernel: Available graphics memory: 1020878 kiB. [0.300823] [drm] radeon: 128M of VRAM memory ready [0.300825] [drm] radeon: 512M of GTT memory ready. [0.300841] [drm] GART: num cpu pages 131072, num gpu pages 131072 [0.302714] [drm] radeon: 1 quad pipes, 2 z pipes initialized. [0.302747] [drm] PCIE GART of 512M enabled (table at 0x0004). [0.302759] [drm] radeon: cp idle (0x1C03) [0.302856] [drm] Loading R500 Microcode [0.302859] platform radeon_cp.0: firmware: using built-in firmware radeon/R520_cp.bin [0.303028] [drm] radeon: ring at 0x2000 [0.303064] [drm] ring test succeeded in 9 usecs [0.303155] [drm] radeon: ib pool ready. [0.303237] [drm] ib test succeeded in 0 usecs [0.303425] [drm] Default TV standard: NTSC [0.303907] [drm] Radeon Display Connectors [0.303909] [drm] Connector 0: [0.303910] [drm] LVDS [0.303912] [drm] DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 0x7e6c [0.303913] [drm] Encoders: [0.303914] [drm] LCD1: INTERNAL_LVTM1 [0.303916] [drm] Connector 1: [0.303917] [drm] S-video [0.303918] [drm] Encoders: [0.303919] [drm] TV1: INTERNAL_KLDSCP_DAC2 [0.303920] [drm] Connector 2: [0.303922] [drm] DVI-I [0.303923] [drm] HPD1 [0.303924] [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c [0.303926] [drm] Encoders: [0.303927] [drm] DFP1: INTERNAL_KLDSCP_TMDS1 [0.303928] [drm] Connector 3: [0.303929] [drm] VGA [0.303931] [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c [0.303933] [drm] Encoders: [0.303934] [drm] CRT2: INTERNAL_KLDSCP_DAC2 [0.355828] [drm:edid_is_valid] *ERROR* EDID checksum is invalid, remainder is 130 [0.355872] [drm:edid_is_valid] *ERROR* Raw EDID: [0.355913] 300 ff ff ff ff ff ff 00 ff ff ff ff ff ff ff ff [0.355915] 3ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.355917] 3ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.355919] 3ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.355921] 3ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.355923] 3ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.355924] 3ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.355926] 3ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.355928] [0.397678] ACPI: Battery Slot [BAT0] (battery present) [0.584399] [drm] fb mappable at 0x800C [0.584401] [drm] vram apper at 0x8000 [0.584403] [drm] size 5299200 [0.584404] [drm] fb depth is 24 [0.584405] [drm]pitch is 5888 [ 131.169012] executing set pll [ 131.181016] executing set crtc timing [ 131.181043] [drm] LVDS-9: set mode 1440x900 1c [ 131.216058] Console: switching to colour frame buffer device 180x56 [ 131.219331] fb0: radeondrmfb frame buffer device [ 131.219333] registered panic notifier [ 131.219345] [drm] Initialized radeon 2.0.0 20080528 for :01:00.0 on minor 0 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are
[PATCH 1/2] drm: Avoid calling vblank function is vblank wasn't initialized
In some case vblank might not be initialized and we shouldn't
try to use associated function. This patch make sure this is
the case. It also export drm_vblank_cleanup so driver can cleanup
vblank if for any reason IRQ/MSI is not working.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/drm_irq.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 7998ee6..b98384d 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -115,6 +115,7 @@ void drm_vblank_cleanup(struct drm_device *dev)
dev-num_crtcs = 0;
}
+EXPORT_SYMBOL(drm_vblank_cleanup);
int drm_vblank_init(struct drm_device *dev, int num_crtcs)
{
@@ -163,7 +164,6 @@ int drm_vblank_init(struct drm_device *dev, int num_crtcs)
}
dev-vblank_disable_allowed = 0;
-
return 0;
err:
@@ -493,6 +493,9 @@ EXPORT_SYMBOL(drm_vblank_off);
*/
void drm_vblank_pre_modeset(struct drm_device *dev, int crtc)
{
+ /* vblank is not initialized (IRQ not installed ?) */
+ if (!dev-num_crtcs)
+ return;
/*
* To avoid all the problems that might happen if interrupts
* were enabled/disabled around or between these calls, we just
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/radeon/kms: Don't try to enable IRQ if we have no handler installed
If for any reason we haven't installed handler we shouldn't try to
enable IRQ/MSI on the hw so we don't get unhandled IRQ/MSI which
makes the kernel sad.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/r100.c |8 +++-
drivers/gpu/drm/radeon/r600.c |7 ++-
drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 --
drivers/gpu/drm/radeon/rs600.c |8 +++-
4 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 1a056b7..a88f444 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -131,7 +131,8 @@ void r100_hpd_init(struct radeon_device *rdev)
break;
}
}
- r100_irq_set(rdev);
+ if (rdev-irq.installed)
+ r100_irq_set(rdev);
}
void r100_hpd_fini(struct radeon_device *rdev)
@@ -243,6 +244,11 @@ int r100_irq_set(struct radeon_device *rdev)
{
uint32_t tmp = 0;
+ if (!rdev-irq.installed) {
+ WARN(1, Can't enable IRQ/MSI because no handler is
installed.\n);
+ WREG32(R_40_GEN_INT_CNTL, 0);
+ return -EINVAL;
+ }
if (rdev-irq.sw_int) {
tmp |= RADEON_SW_INT_ENABLE;
}
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index debf069..56d3001 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -285,7 +285,8 @@ void r600_hpd_init(struct radeon_device *rdev)
}
}
}
- r600_irq_set(rdev);
+ if (rdev-irq.installed)
+ r600_irq_set(rdev);
}
void r600_hpd_fini(struct radeon_device *rdev)
@@ -2458,6 +2459,10 @@ int r600_irq_set(struct radeon_device *rdev)
u32 mode_int = 0;
u32 hpd1, hpd2, hpd3, hpd4 = 0, hpd5 = 0, hpd6 = 0;
+ if (!rdev-irq.installed) {
+ WARN(1, Can't enable IRQ/MSI because no handler is
installed.\n);
+ return -EINVAL;
+ }
/* don't enable anything if the ih is disabled */
if (!rdev-ih.enabled)
return 0;
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 9223296..3cfd60f 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -97,6 +97,7 @@ void radeon_driver_irq_uninstall_kms(struct drm_device *dev)
rdev-irq.sw_int = false;
for (i = 0; i 2; i++) {
rdev-irq.crtc_vblank_int[i] = false;
+ rdev-irq.hpd[i] = false;
}
radeon_irq_set(rdev);
}
@@ -128,17 +129,22 @@ int radeon_irq_kms_init(struct radeon_device *rdev)
DRM_INFO(radeon: using MSI.\n);
}
}
- drm_irq_install(rdev-ddev);
rdev-irq.installed = true;
+ r = drm_irq_install(rdev-ddev);
+ if (r) {
+ rdev-irq.installed = false;
+ return r;
+ }
DRM_INFO(radeon: irq initialized.\n);
return 0;
}
void radeon_irq_kms_fini(struct radeon_device *rdev)
{
+ drm_vblank_cleanup(rdev-ddev);
if (rdev-irq.installed) {
- rdev-irq.installed = false;
drm_irq_uninstall(rdev-ddev);
+ rdev-irq.installed = false;
if (rdev-msi_enabled)
pci_disable_msi(rdev-pdev);
}
diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c
index d1f2d08..82dff70 100644
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -134,7 +134,8 @@ void rs600_hpd_init(struct radeon_device *rdev)
break;
}
}
- rs600_irq_set(rdev);
+ if (rdev-irq.installed)
+ rs600_irq_set(rdev);
}
void rs600_hpd_fini(struct radeon_device *rdev)
@@ -315,6 +316,11 @@ int rs600_irq_set(struct radeon_device *rdev)
u32 hpd2 = RREG32(R_007D18_DC_HOT_PLUG_DETECT2_INT_CONTROL)
~S_007D18_DC_HOT_PLUG_DETECT2_INT_EN(1);
+ if (!rdev-irq.installed) {
+ WARN(1, Can't enable IRQ/MSI because no handler is
installed.\n);
+ WREG32(R_40_GEN_INT_CNTL, 0);
+ return -EINVAL;
+ }
if (rdev-irq.sw_int) {
tmp |= S_40_SW_INT_EN(1);
}
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
DRM vblank fixes + radeon associated fixes
Following two patch avoid to activate hw IRQ/MSI when there is no handler. Such case might happen for various reasons (for instance if we disable accel we also disable irq along the way). -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon/kms: Schedule host path read cache flush through the ring
On Wed, Jan 6, 2010 at 3:51 PM, Jerome Glisse gli...@freedesktop.org wrote: On Wed, Jan 06, 2010 at 01:57:08PM -0500, Alex Deucher wrote: On Wed, Jan 6, 2010 at 1:29 PM, Jerome Glisse jgli...@redhat.com wrote: R300 family will hard lockup if host path read cache flush is done through MMIO to HOST_PATH_CNTL. But scheduling same flush through ring seems harmless. This patch remove the hdp_flush callback and add a flush after each fence emission which means a flush after each IB schedule. Thus we should have same behavior without the hard lockup. We really only need to flush the HDP cache after rendering to vram (or UMA in the IGP case). Wouldn't it be better to just flush in those cases? We may want to use the hdp flush callback after sw access to vram as well, so having a separate hdp callback might be better. See other comments inline below. Alex Do you know if always flushing impact performances ? I didn't benchmarked but i think arena did have same fps before or after the patch. The idea of the patch was to have the same behavior accross different family and avoid having fake callback. I'm not sure off hand how what sort of performance impact there is. On r6xx+, mmio should be ok. Yeah i did change every family just for consistency. Ok. @@ -1785,6 +1780,8 @@ void r600_fence_ring_emit(struct radeon_device *rdev, radeon_ring_write(rdev, PACKET3(PACKET3_SET_CONFIG_REG, 1)); radeon_ring_write(rdev, ((rdev-fence_drv.scratch_reg - PACKET3_SET_CONFIG_REG_OFFSET) 2)); radeon_ring_write(rdev, fence-seq); + radeon_ring_write(rdev, PACKET0(R_005480_HDP_MEM_COHERENCY_FLUSH_CNTL, 0)); + radeon_ring_write(rdev, 1); If you add additional packets here, you'll need to adjust the fence counts in r600_blit_prepare_copy() in r600_blit_kms.c as well. Will check that, what i did in others part of the code was to always ask for a lot of room in the ring (64 dwords) so that i could grow what is in fence emit or ib schedule without having to worry. I will change r600 path to do the same. It doesn't hurt to ask for more dword than needed. Cheers, Jerome -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15002] invalid EDID checksum pause boot for 130 sec - kms, radeon
http://bugzilla.kernel.org/show_bug.cgi?id=15002 Alex Deucher alexdeuc...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher alexdeuc...@gmail.com 2010-01-07 15:03:18 --- This might be related to fdo bug 25506: http://bugs.freedesktop.org/show_bug.cgi?id=25506 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: Make sure we release AGP device if we acquired it
In some case we weren't releasing the AGP device at module unloading.
This leaded to unfunctional AGP at next module load. This patch make
sure we release the AGP bus if we acquire it.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/r100.c |1 +
drivers/gpu/drm/radeon/r300.c |1 +
drivers/gpu/drm/radeon/r600.c |3 +--
drivers/gpu/drm/radeon/radeon_agp.c |6 ++
drivers/gpu/drm/radeon/rv770.c |3 +--
5 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 095cfea..62b27be 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3375,6 +3375,7 @@ void r100_fini(struct radeon_device *rdev)
radeon_gem_fini(rdev);
if (rdev-flags RADEON_IS_PCI)
r100_pci_gart_fini(rdev);
+ radeon_agp_fini(rdev);
radeon_irq_kms_fini(rdev);
radeon_fence_driver_fini(rdev);
radeon_bo_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index b8623b7..0051d11 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -1336,6 +1336,7 @@ void r300_fini(struct radeon_device *rdev)
rv370_pcie_gart_fini(rdev);
if (rdev-flags RADEON_IS_PCI)
r100_pci_gart_fini(rdev);
+ radeon_agp_fini(rdev);
radeon_irq_kms_fini(rdev);
radeon_fence_driver_fini(rdev);
radeon_bo_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 56d3001..611f870 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2087,8 +2087,7 @@ void r600_fini(struct radeon_device *rdev)
radeon_gem_fini(rdev);
radeon_fence_driver_fini(rdev);
radeon_clocks_fini(rdev);
- if (rdev-flags RADEON_IS_AGP)
- radeon_agp_fini(rdev);
+ radeon_agp_fini(rdev);
radeon_bo_fini(rdev);
radeon_atombios_fini(rdev);
kfree(rdev-bios);
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index 54bf49a..220f454 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -252,10 +252,8 @@ void radeon_agp_resume(struct radeon_device *rdev)
void radeon_agp_fini(struct radeon_device *rdev)
{
#if __OS_HAS_AGP
- if (rdev-flags RADEON_IS_AGP) {
- if (rdev-ddev-agp rdev-ddev-agp-acquired) {
- drm_agp_release(rdev-ddev);
- }
+ if (rdev-ddev-agp rdev-ddev-agp-acquired) {
+ drm_agp_release(rdev-ddev);
}
#endif
}
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index f58dc67..16f7317 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1096,8 +1096,7 @@ void rv770_fini(struct radeon_device *rdev)
radeon_gem_fini(rdev);
radeon_fence_driver_fini(rdev);
radeon_clocks_fini(rdev);
- if (rdev-flags RADEON_IS_AGP)
- radeon_agp_fini(rdev);
+ radeon_agp_fini(rdev);
radeon_bo_fini(rdev);
radeon_atombios_fini(rdev);
kfree(rdev-bios);
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Schedule host path read cache flush through the ring V2
On Thu, Jan 7, 2010 at 6:39 AM, Jerome Glisse jgli...@redhat.com wrote:
R300 family will hard lockup if host path read cache flush is
done through MMIO to HOST_PATH_CNTL. But scheduling same flush
through ring seems harmless. This patch remove the hdp_flush
callback and add a flush after each fence emission which means
a flush after each IB schedule. Thus we should have same behavior
without the hard lockup.
Tested on R100,R200,R300,R400,R500,R600,R700 family.
V2: Adjust fence counts in r600_blit_prepare_copy()
Looks good to me, other than the use of the ring rather than MMIO, it
shouldn't be any different than the previous behavior.
Signed-off-by: Jerome Glisse jgli...@redhat.com
Reviewed-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/r100.c | 14 ++
drivers/gpu/drm/radeon/r300.c | 16 +++-
drivers/gpu/drm/radeon/r420.c | 1 +
drivers/gpu/drm/radeon/r520.c | 1 +
drivers/gpu/drm/radeon/r600.c | 7 ++-
drivers/gpu/drm/radeon/r600_blit_kms.c | 4 ++--
drivers/gpu/drm/radeon/radeon.h | 4 ++--
drivers/gpu/drm/radeon/radeon_asic.h | 12
drivers/gpu/drm/radeon/radeon_gem.c | 2 --
drivers/gpu/drm/radeon/rs400.c | 1 +
drivers/gpu/drm/radeon/rs600.c | 1 +
drivers/gpu/drm/radeon/rs690.c | 1 +
drivers/gpu/drm/radeon/rv515.c | 1 +
13 files changed, 33 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 7172746..1a056b7 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -356,6 +356,11 @@ void r100_fence_ring_emit(struct radeon_device *rdev,
/* Wait until IDLE CLEAN */
radeon_ring_write(rdev, PACKET0(0x1720, 0));
radeon_ring_write(rdev, (1 16) | (1 17));
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev-config.r100.hdp_cntl |
+ RADEON_HDP_READ_BUFFER_INVALIDATE);
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev-config.r100.hdp_cntl);
/* Emit fence sequence fire IRQ */
radeon_ring_write(rdev, PACKET0(rdev-fence_drv.scratch_reg, 0));
radeon_ring_write(rdev, fence-seq);
@@ -1713,14 +1718,6 @@ void r100_gpu_init(struct radeon_device *rdev)
r100_hdp_reset(rdev);
}
-void r100_hdp_flush(struct radeon_device *rdev)
-{
- u32 tmp;
- tmp = RREG32(RADEON_HOST_PATH_CNTL);
- tmp |= RADEON_HDP_READ_BUFFER_INVALIDATE;
- WREG32(RADEON_HOST_PATH_CNTL, tmp);
-}
-
void r100_hdp_reset(struct radeon_device *rdev)
{
uint32_t tmp;
@@ -3313,6 +3310,7 @@ static int r100_startup(struct radeon_device *rdev)
}
/* Enable IRQ */
r100_irq_set(rdev);
+ rdev-config.r100.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
/* 1M ring buffer */
r = r100_cp_init(rdev, 1024 * 1024);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 3f2cc9e..b8623b7 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -36,7 +36,15 @@
#include rv350d.h
#include r300_reg_safe.h
-/* This files gather functions specifics to: r300,r350,rv350,rv370,rv380 */
+/* This files gather functions specifics to: r300,r350,rv350,rv370,rv380
+ *
+ * GPU Errata:
+ * - HOST_PATH_CNTL: r300 family seems to dislike write to HOST_PATH_CNTL
+ * using MMIO to flush host path read cache, this lead to HARDLOCKUP.
+ * However, scheduling such write to the ring seems harmless, i suspect
+ * the CP read collide with the flush somehow, or maybe the MC, hard to
+ * tell. (Jerome Glisse)
+ */
/*
* rv370,rv380 PCIE GART
@@ -178,6 +186,11 @@ void r300_fence_ring_emit(struct radeon_device *rdev,
/* Wait until IDLE CLEAN */
radeon_ring_write(rdev, PACKET0(0x1720, 0));
radeon_ring_write(rdev, (1 17) | (1 16) | (1 9));
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev-config.r300.hdp_cntl |
+ RADEON_HDP_READ_BUFFER_INVALIDATE);
+ radeon_ring_write(rdev, PACKET0(RADEON_HOST_PATH_CNTL, 0));
+ radeon_ring_write(rdev, rdev-config.r300.hdp_cntl);
/* Emit fence sequence fire IRQ */
radeon_ring_write(rdev, PACKET0(rdev-fence_drv.scratch_reg, 0));
radeon_ring_write(rdev, fence-seq);
@@ -1258,6 +1271,7 @@ static int r300_startup(struct radeon_device *rdev)
}
/* Enable IRQ */
r100_irq_set(rdev);
+ rdev-config.r300.hdp_cntl = RREG32(RADEON_HOST_PATH_CNTL);
/* 1M ring buffer */
r = r100_cp_init(rdev, 1024 * 1024);
if (r) {
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index
[Bug 25934] Segfaults while parsing a shader shown to work on other platforms
http://bugs.freedesktop.org/show_bug.cgi?id=25934 --- Comment #4 from Brian Paul brian.e.p...@gmail.com 2010-01-07 08:20:27 PST --- I can't reproduce this. I forced the parser to call the yyerror() function where your gdb log indicated. I don't get a segfault in vfprintf() or strlen(). Could you try recompiling Mesa for debug (-g) and retesting? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH v2] drm: Keep disabled outputs disabled after suspend / resume
On Thu, 07 Jan 2010 13:24:06 +0530 David John david...@xenontk.org wrote: On 12/31/2009 12:00 PM, David John wrote: With the current DRM code, an output that has been powered off from userspace will automatically power back on when resuming from suspend. This patch fixes this behaviour. Tested only with the Intel i915 driver on an Intel GM45 Express chipset. Signed-off-by: David John david...@xenontk.org Ping. Any update on this? Correct? Incorrect? Utter rubbish that I should be ashamed of myself? Yeah, sorry David, looks good to me. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- Jesse Barnes, Intel Open Source Technology Center -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25741] [R600/KMS] external display flickering
http://bugs.freedesktop.org/show_bug.cgi?id=25741 --- Comment #14 from Luca Tettamanti kronos...@gmail.com 2010-01-07 09:00:06 PST --- Created an attachment (id=32509) -- (http://bugs.freedesktop.org/attachment.cgi?id=32509) Add a module parameter to disable spread spectrum unconditionally In case this turns out to be a bug in my card bios or a hardware problem; it's really a show-stopper for me. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix typo in atom connector type handling
From 9d6da5df3ca3912ffdd4ad25e10f127d0c5e4354 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 7 Jan 2010 14:19:47 -0500
Subject: [PATCH] drm/radeon/kms: fix typo in atom connector type handling
Also remove the problematic enums that were unused
remnants from the ddx.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_encoders.c | 10 +-
drivers/gpu/drm/radeon/radeon_mode.h | 26 --
2 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c
b/drivers/gpu/drm/radeon/radeon_encoders.c
index 7e977ce..c14ef97 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -607,13 +607,13 @@ atombios_get_encoder_mode(struct drm_encoder *encoder)
else
return ATOM_ENCODER_MODE_DVI;
break;
- case CONNECTOR_DVI_A:
- case CONNECTOR_VGA:
+ case DRM_MODE_CONNECTOR_DVIA:
+ case DRM_MODE_CONNECTOR_VGA:
return ATOM_ENCODER_MODE_CRT;
break;
- case CONNECTOR_STV:
- case CONNECTOR_CTV:
- case CONNECTOR_DIN:
+ case DRM_MODE_CONNECTOR_Composite:
+ case DRM_MODE_CONNECTOR_SVIDEO:
+ case DRM_MODE_CONNECTOR_9PinDIN:
/* fix me */
return ATOM_ENCODER_MODE_TV;
/*return ATOM_ENCODER_MODE_CV;*/
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 402369d..91cb041 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -46,32 +46,6 @@ struct radeon_device;
#define to_radeon_encoder(x) container_of(x, struct radeon_encoder, base)
#define to_radeon_framebuffer(x) container_of(x, struct
radeon_framebuffer, base)
-enum radeon_connector_type {
- CONNECTOR_NONE,
- CONNECTOR_VGA,
- CONNECTOR_DVI_I,
- CONNECTOR_DVI_D,
- CONNECTOR_DVI_A,
- CONNECTOR_STV,
- CONNECTOR_CTV,
- CONNECTOR_LVDS,
- CONNECTOR_DIGITAL,
- CONNECTOR_SCART,
- CONNECTOR_HDMI_TYPE_A,
- CONNECTOR_HDMI_TYPE_B,
- CONNECTOR_0XC,
- CONNECTOR_0XD,
- CONNECTOR_DIN,
- CONNECTOR_DISPLAY_PORT,
- CONNECTOR_UNSUPPORTED
-};
-
-enum radeon_dvi_type {
- DVI_AUTO,
- DVI_DIGITAL,
- DVI_ANALOG
-};
-
enum radeon_rmx_type {
RMX_OFF,
RMX_FULL,
--
1.5.6.3
0001-drm-radeon-kms-fix-typo-in-atom-connector-type-hand.patch
Description: application/mbox
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev --
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Q1: speedup: parallel-make-jobs and/or ccache Q2: radeon*g*_dri.so Q3. enable XCB
On Thu, Jan 07, 2010 at 08:05:30PM +0100, Sedat Dilek wrote: Hi, I have a couple of questions which araised while building mesa from upstream master [1]. Partially, I discussed them on #radeon IRC [2,3]. [Q1] SpeedUp build of mesa: parallel-make-jobs and/or ccache? For a long time it was no problem to build mesa on my 32bit-host (Debian/sid, Intel Core2Duo T7200, 2GByte RAM, 80GByte SATA-HDD, etc.) with the following settings in my build-script: export MAKEFLAGS=-j3 Unfortunately, I noticed that mesa/src/mesa/libmesagallium.a does not exist and the build of r300g fails (see backlog #radeon 2010-01-02 in [2]). From the build-log: ... make[5]: Entering directory `/home/sd/src/mesa/mesa/src/gallium/winsys/drm/radeon/dri' make[5]: *** No rule to make target `../../../../../../src/mesa/libmesagallium.a', needed by `radeon_dri.so'. Stop. ... Commenting export MAKEFLAGS=-j3 in my build-script is a temporary fix. With ccache enabled I have a build-time around 6min (that's a fast build-time I know). Parallel make should work. Does the patch below fix the issue? -- Dan From 7ce28ade9e0f529a708e624f40c7e8f8f1aa71c3 Mon Sep 17 00:00:00 2001 From: Dan Nicholson dbn.li...@gmail.com Date: Thu, 7 Jan 2010 13:45:57 -0800 Subject: [PATCH] Build libmesagallium.a before descending into drivers Should fix this issue with parallel jobs: make[5]: *** No rule to make target `../../../../../../src/mesa/libmesagallium.a', needed by `radeon_dri.so'. Stop. Signed-off-by: Dan Nicholson dbn.li...@gmail.com --- src/mesa/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/Makefile b/src/mesa/Makefile index a815f46..f845d93 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -42,7 +42,7 @@ libglapi.a: $(GLAPI_OBJECTS) ## # Device drivers -driver_subdirs: libmesa.a libglapi.a +driver_subdirs: libmesa.a libglapi.a libmesagallium.a @ (cd drivers $(MAKE)) -- 1.6.5.2 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Q1: speedup: parallel-make-jobs and/or ccache Q2: radeon*g*_dri.so Q3. enable XCB
On Thu, Jan 7, 2010 at 2:40 PM, Sedat Dilek sedat.di...@googlemail.com wrote: Hi Dan, [src/mesa/Makefile] ... -driver_subdirs: libmesa.a libglapi.a +driver_subdirs: libmesa.a libmesagallium.a libglapi.a This one works :-). $ find mesa/ -name libmesa* mesa/src/mesa/libmesa.a mesa/src/mesa/libmesagallium.a $ find mesa/ -name libglapi* mesa/src/mesa/libglapi.a Can you please, push that, Thanks. That should be exactly the same as the patch I sent, so I don't know why mine would fail. Can you try a few more times to make sure it works right? Run make realclean ./config.status between runs to get back to a clean state. Thanks. -- Dan -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Q1: speedup: parallel-make-jobs and/or ccache Q2: radeon*g*_dri.so Q3. enable XCB
[PATCH] Build libmesagallium.a before descending into drivers ...does NOT fix the parallel-make-job problem. $ grep libmesagallium mesa/src/mesa/Makefile default: depend asm_subdirs glsl_builtin libmesa.a libmesagallium.a \ libmesagallium.a: $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) driver_subdirs: libmesa.a libglapi.a libmesagallium.a $ find mesa/ -name libmesa* mesa/src/mesa/libmesa.a File libmesagallium.a does not exist! Not sure, if this is interesting: ... make[5]: Entering directory `/home/sd/src/mesa/mesa/src/gallium/winsys/drm/radeon/dri' ../../Makefile.template:126: depend: No such file or directory ... - Sedat - On Thu, Jan 7, 2010 at 10:51 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Thu, Jan 07, 2010 at 08:05:30PM +0100, Sedat Dilek wrote: Hi, I have a couple of questions which araised while building mesa from upstream master [1]. Partially, I discussed them on #radeon IRC [2,3]. [Q1] SpeedUp build of mesa: parallel-make-jobs and/or ccache? For a long time it was no problem to build mesa on my 32bit-host (Debian/sid, Intel Core2Duo T7200, 2GByte RAM, 80GByte SATA-HDD, etc.) with the following settings in my build-script: export MAKEFLAGS=-j3 Unfortunately, I noticed that mesa/src/mesa/libmesagallium.a does not exist and the build of r300g fails (see backlog #radeon 2010-01-02 in [2]). From the build-log: ... make[5]: Entering directory `/home/sd/src/mesa/mesa/src/gallium/winsys/drm/radeon/dri' make[5]: *** No rule to make target `../../../../../../src/mesa/libmesagallium.a', needed by `radeon_dri.so'. Stop. ... Commenting export MAKEFLAGS=-j3 in my build-script is a temporary fix. With ccache enabled I have a build-time around 6min (that's a fast build-time I know). Parallel make should work. Does the patch below fix the issue? -- Dan From 7ce28ade9e0f529a708e624f40c7e8f8f1aa71c3 Mon Sep 17 00:00:00 2001 From: Dan Nicholson dbn.li...@gmail.com Date: Thu, 7 Jan 2010 13:45:57 -0800 Subject: [PATCH] Build libmesagallium.a before descending into drivers Should fix this issue with parallel jobs: make[5]: *** No rule to make target `../../../../../../src/mesa/libmesagallium.a', needed by `radeon_dri.so'. Stop. Signed-off-by: Dan Nicholson dbn.li...@gmail.com --- src/mesa/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/Makefile b/src/mesa/Makefile index a815f46..f845d93 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -42,7 +42,7 @@ libglapi.a: $(GLAPI_OBJECTS) ## # Device drivers -driver_subdirs: libmesa.a libglapi.a +driver_subdirs: libmesa.a libglapi.a libmesagallium.a @ (cd drivers $(MAKE)) -- 1.6.5.2 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Q1: speedup: parallel-make-jobs and/or ccache Q2: radeon*g*_dri.so Q3. enable XCB
Hi Dan, [src/mesa/Makefile] ... -driver_subdirs: libmesa.a libglapi.a +driver_subdirs: libmesa.a libmesagallium.a libglapi.a This one works :-). $ find mesa/ -name libmesa* mesa/src/mesa/libmesa.a mesa/src/mesa/libmesagallium.a $ find mesa/ -name libglapi* mesa/src/mesa/libglapi.a Can you please, push that, Thanks. - Sedat - On Thu, Jan 7, 2010 at 11:27 PM, Sedat Dilek sedat.di...@googlemail.com wrote: [PATCH] Build libmesagallium.a before descending into drivers ...does NOT fix the parallel-make-job problem. $ grep libmesagallium mesa/src/mesa/Makefile default: depend asm_subdirs glsl_builtin libmesa.a libmesagallium.a \ libmesagallium.a: $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) driver_subdirs: libmesa.a libglapi.a libmesagallium.a $ find mesa/ -name libmesa* mesa/src/mesa/libmesa.a File libmesagallium.a does not exist! Not sure, if this is interesting: ... make[5]: Entering directory `/home/sd/src/mesa/mesa/src/gallium/winsys/drm/radeon/dri' ../../Makefile.template:126: depend: No such file or directory ... - Sedat - On Thu, Jan 7, 2010 at 10:51 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Thu, Jan 07, 2010 at 08:05:30PM +0100, Sedat Dilek wrote: Hi, I have a couple of questions which araised while building mesa from upstream master [1]. Partially, I discussed them on #radeon IRC [2,3]. [Q1] SpeedUp build of mesa: parallel-make-jobs and/or ccache? For a long time it was no problem to build mesa on my 32bit-host (Debian/sid, Intel Core2Duo T7200, 2GByte RAM, 80GByte SATA-HDD, etc.) with the following settings in my build-script: export MAKEFLAGS=-j3 Unfortunately, I noticed that mesa/src/mesa/libmesagallium.a does not exist and the build of r300g fails (see backlog #radeon 2010-01-02 in [2]). From the build-log: ... make[5]: Entering directory `/home/sd/src/mesa/mesa/src/gallium/winsys/drm/radeon/dri' make[5]: *** No rule to make target `../../../../../../src/mesa/libmesagallium.a', needed by `radeon_dri.so'. Stop. ... Commenting export MAKEFLAGS=-j3 in my build-script is a temporary fix. With ccache enabled I have a build-time around 6min (that's a fast build-time I know). Parallel make should work. Does the patch below fix the issue? -- Dan From 7ce28ade9e0f529a708e624f40c7e8f8f1aa71c3 Mon Sep 17 00:00:00 2001 From: Dan Nicholson dbn.li...@gmail.com Date: Thu, 7 Jan 2010 13:45:57 -0800 Subject: [PATCH] Build libmesagallium.a before descending into drivers Should fix this issue with parallel jobs: make[5]: *** No rule to make target `../../../../../../src/mesa/libmesagallium.a', needed by `radeon_dri.so'. Stop. Signed-off-by: Dan Nicholson dbn.li...@gmail.com --- src/mesa/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/mesa/Makefile b/src/mesa/Makefile index a815f46..f845d93 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -42,7 +42,7 @@ libglapi.a: $(GLAPI_OBJECTS) ## # Device drivers -driver_subdirs: libmesa.a libglapi.a +driver_subdirs: libmesa.a libglapi.a libmesagallium.a @ (cd drivers $(MAKE)) -- 1.6.5.2 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/kms/fb: check for depth changes from userspace for resizing.
From: Dave Airlie airl...@redhat.com
If userspace (plymouth in this case) asks for a deeper depth,
refuse it as well due to lack of resizing.
This fixes an issue since 32MB cards went to 8bpp and plymouth
crashes on startup.
Signed-off-by: Dave Airlie airl...@redhat.com
---
drivers/gpu/drm/drm_fb_helper.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 1b49fa0..c9fa8d7 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -606,11 +606,10 @@ int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
return -EINVAL;
/* Need to resize the fb object !!! */
- if (var-xres fb-width || var-yres fb-height) {
- DRM_ERROR(Requested width/height is greater than current fb
- object %dx%d %dx%d\n, var-xres, var-yres,
- fb-width, fb-height);
- DRM_ERROR(Need resizing code.\n);
+ if (var-bits_per_pixel fb-bits_per_pixel || var-xres fb-width
|| var-yres fb-height) {
+ DRM_DEBUG(fb userspace requested width/height/bpp is greater
than current fb
+ object %dx%d-%d %dx%d-%d\n, var-xres, var-yres,
var-bits_per_pixel,
+ fb-width, fb-height, fb-bits_per_pixel);
return -EINVAL;
}
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Q1: speedup: parallel-make-jobs and/or ccache Q2: radeon*g*_dri.so Q3. enable XCB
On Thu, Jan 7, 2010 at 3:26 PM, Sedat Dilek sedat.di...@googlemail.com wrote: Indeed, I discovered a failure in both cases. But, I always do a clean checkout (build-from-scratch) and clean/clear the cache of ccache. $ grep libmesagallium.a mesa/src/mesa/Makefile default: depend asm_subdirs glsl_builtin libmesa.a libmesagallium.a \ libmesagallium.a: $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) driver_subdirs: libmesa.a libmesagallium.a libglapi.a In case of failure I have... $ grep libmesa build.log removed `mesa/src/mesa/libmesa.a' + PATCH=0001-Build-libmesagallium.a-before-descending-into-driver.patch + patch -Np1 -i ../patches/0001-Build-libmesagallium.a-before-descending-into-driver.patch mklib: Making Linux static library: libmesa.a ar: creating libmesa.a mklib: Making Linux static library: libmesagallium.a ar: creating libmesagallium.a ranlib: 'libmesagallium.a': No such file This seems to be the real issue. I have no idea why the file's not actually being created. It would be nice if mklib actually stopped on critical errors like these. Can you attach the full build log? It might not be that illuminating, but maybe there's something else going on. -- Dan -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Q1: speedup: parallel-make-jobs and/or ccache Q2: radeon*g*_dri.so Q3. enable XCB
On Thu, Jan 7, 2010 at 4:30 PM, Sedat Dilek sedat.di...@googlemail.com wrote: Yeah, I had a deeper look into the build-log: /bin/bash ../../bin/mklib -o glapi -static main/dispatch.o glapi/glapi.o glapi/glapi_getproc.o glapi/glthread.o x86/glapi_x86.o mklib: Making Linux static library: libglapi.a ar: creating libglapi.a mklib: Making Linux static library: libmesa.a ar: creating libmesa.a mklib: Making Linux static library: libmesagallium.a ar: creating libmesagallium.a ar: sl_pp_context.o: No such file or directory ranlib: 'libmesagallium.a': No such file NOTE: ar: sl_pp_context.o: No such file or directory $ grep sl_pp_context.o -r mesa/ | egrep 'libmesa|libglsl' Binary file mesa/src/glsl/pp/libglslpp.a matches Binary file mesa/src/mesa/libmesa.a matches Binary file mesa/src/mesa/libmesagallium.a matches Seems to me something wrong with GLSL_LIBS. OK, now I think I know what's going on. mklib will extract all the object files from dependent .a archives. libmesa.a and libmesagallium.a will both extract sl_pp_context.o to the current directory, repack them into their own archives, and then delete the extracted objects. Since libmesa.a and libmesagallium.a are building in parallel, there is a race where they're both extracting then deleting the objects. Something like this: libmesa.a: extract objects libmesagallium.a: extract same objects libmesa.a: insert objects libmesa.a: remove objects libmesagallium.a: insert now removed objects The failure is on the last step because libmesa.a has just removed sl_pp_context.o. Here's the hacky fix (you'll have to edit manually since gmail will break formatting): diff --git a/src/mesa/Makefile b/src/mesa/Makefile index f845d93..4425000 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -33,7 +33,7 @@ libmesa.a: $(MESA_OBJECTS) $(GLSL_LIBS) @ $(MKLIB) -o mesa -static $(MESA_OBJECTS) $(GLSL_LIBS) # Make archive of subset of core mesa object files for gallium -libmesagallium.a: $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) +libmesagallium.a: $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) libmesa.a @ $(MKLIB) -o mesagallium -static $(MESA_GALLIUM_OBJECTS) $(GLSL_LIBS) # Make archive of gl* API dispatcher functions only The more correct fix is to have mklib extract in a temporary directory. Something like this totally untested attached patch. -- Dan mklib-smarter-extract.patch Description: Binary data -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Set subject_prefix in this list
Hi, Would it be feasible to set subject_prefix to [dri-devel] by the admin/moderator of this list? -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Q1: speedup: parallel-make-jobs and/or ccache Q2: radeon*g*_dri.so Q3. enable XCB
On Fri, Jan 08, 2010 at 03:24:36AM +0100, Sedat Dilek wrote:
Here is the build.log with applied mklib-smarter-extract.patch (only this
one).
Maybe you have a look at the build-log:
...
mklib: Making Linux static library: libmesa.a
ar: ../../src/glsl/pp/libglslpp.a: No such file or directory
ar: ../../src/glsl/pp/libglslpp.a: No such file or directory
ar: ../../src/glsl/cl/libglslcl.a: No such file or directory
ar: ../../src/glsl/cl/libglslcl.a: No such file or directory
ar: creating libmesa.a
...
running /usr/bin/makedepend
ar: ../../src/glsl/pp/libglslpp.a: No such file or directory
ar: ../../src/glsl/pp/libglslpp.a: No such file or directory
ar: ../../src/glsl/cl/libglslcl.a: No such file or directory
ar: ../../src/glsl/cl/libglslcl.a: No such file or directory
ar: creating libmesagallium.a
...
$ grep sl_pp_context -r mesa/ | egrep 'libmesa|libglsl'
Binary file mesa/src/glsl/cl/libglslcl.a matches
Binary file mesa/src/glsl/pp/libglslpp.a matches
Binary file mesa/src/mesa/libmesa.a matches
Binary file mesa/src/mesa/libmesagallium.a matches
$ grep sl_pp_context.o -r mesa/ | egrep 'libmesa|libglsl'
Binary file mesa/src/glsl/pp/libglslpp.a matches
Here I am not sure why the object file is only in libglslpp.a.
Many thanks for your fast replies, patches and the detailed explanations.
Oops, just a bug about changing directories and breaking relative paths.
Can you try this new version of the patch? I actually tested it this time,
and I think it does the right thing.
--
Dan
From 59d8948fe55af2c783d8f7c5554ee44809e78bbd Mon Sep 17 00:00:00 2001
From: Dan Nicholson dbn.li...@gmail.com
Date: Thu, 7 Jan 2010 17:11:37 -0800
Subject: [PATCH] mklib: Extract archives into temporary directories
When static libraries are created from other archives, objects are
extracted and then deleted when the static library is done. This can
race when there are multiple static libraries being created from the
same archives as with libmesa.a and libmesagallium.a.
Should fix this issue with parallel jobs:
make[5]: *** No rule to make target
`../../../../../../src/mesa/libmesagallium.a', needed by
`radeon_dri.so'. Stop
Signed-off-by: Dan Nicholson dbn.li...@gmail.com
---
bin/mklib | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/bin/mklib b/bin/mklib
index 0acaeb9..652d6bd 100755
--- a/bin/mklib
+++ b/bin/mklib
@@ -28,15 +28,26 @@
# Given a list of files, look for .a archives and unpack them.
# Return the original list of files minus the .a files plus the unpacked files.
expand_archives() {
+DIR=$1
+shift
FILES=$@
NEWFILES=
+ORIG_DIR=`pwd`
+mkdir -p $DIR
+cd $DIR
for FILE in $FILES ; do
case $FILE in
*.a)
# extract the .o files from this .a archive
+case $FILE in
+/*) ;;
+*) FILE=$ORIG_DIR/$FILE ;;
+esac
MEMBERS=`ar t $FILE`
ar x $FILE
-NEWFILES=$NEWFILES $MEMBERS
+for MEMBER in $MEMBERS ; do
+NEWFILES=$NEWFILES $DIR/$MEMBER
+done
;;
*)
# other file type, just add to list
@@ -44,6 +55,7 @@ expand_archives() {
;;
esac
done
+cd $ORIG_DIR
echo $NEWFILES
}
@@ -360,13 +372,13 @@ case $ARCH in
fi
# expand .a into .o files
- NEW_OBJECTS=`expand_archives $OBJECTS`
+ NEW_OBJECTS=`expand_archives ${LIBNAME}.obj $OBJECTS`
# make static lib
FINAL_LIBS=`make_ar_static_lib ${OPTS} 1 ${LIBNAME} ${NEW_OBJECTS}`
# remove temporary extracted .o files
- rm -f `contents_of_archives $OBJECTS`
+ rm -rf ${LIBNAME}.obj
else
# make dynamic library
LIBNAME=lib${LIBNAME} # prefix with lib
@@ -553,12 +565,12 @@ case $ARCH in
echo mklib: Making FreeBSD static library: ${STLIB}
# expand .a into .o files
- NEW_OBJECTS=`expand_archives $OBJECTS`
+ NEW_OBJECTS=`expand_archives ${STLIB}.obj $OBJECTS`
FINAL_LIBS=`make_ar_static_lib cq 1 ${STLIB} ${NEW_OBJECTS}`
# remove temporary extracted .o files
- rm -f `contents_of_archives $OBJECTS`
+ rm -rf ${STLIB}.obj
else
# make dynamic library
SHLIB=lib${LIBNAME}.so.${MAJOR}
--
1.6.5.2
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel
