dri-devel January 2011

dri-devel@lists.freedesktop.org

70 participants
451 discussions

[PATCH] drm/radeon/kms: balance asic_reset functions
by Alex Deucher 11 Jan '11

11 Jan '11

First, we were calling mc_stop() at the top of the function which turns off all MC (memory controller) clients, then checking if the GPU is idle. If it was idle we returned without re-enabling the MC clients which would lead to a blank screen, etc. This patch checks if the GPU is idle before calling mc_stop(). Second, if the reset failed, we were returning without re-enabling the MC clients. This patch re-enables the MC clients before returning regardless of whether the reset was successful or not. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/r100.c | 11 ++++++----- drivers/gpu/drm/radeon/r300.c | 11 ++++++----- drivers/gpu/drm/radeon/rs600.c | 16 ++++++++-------- 3 files changed, 20 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c index f637595..46da514 100644 --- a/drivers/gpu/drm/radeon/r100.c +++ b/drivers/gpu/drm/radeon/r100.c @@ -2086,12 +2086,13 @@ int r100_asic_reset(struct radeon_device *rdev) { struct r100_mc_save save; u32 status, tmp; + int ret = 0; - r100_mc_stop(rdev, &save); status = RREG32(R_000E40_RBBM_STATUS); if (!G_000E40_GUI_ACTIVE(status)) { return 0; } + r100_mc_stop(rdev, &save); status = RREG32(R_000E40_RBBM_STATUS); dev_info(rdev->dev, "(%s:%d) RBBM_STATUS=0x%08X\n", __func__, __LINE__, status); /* stop CP */ @@ -2131,11 +2132,11 @@ int r100_asic_reset(struct radeon_device *rdev) G_000E40_TAM_BUSY(status) || G_000E40_PB_BUSY(status)) { dev_err(rdev->dev, "failed to reset GPU\n"); rdev->gpu_lockup = true; - return -1; - } + ret = -1; + } else + dev_info(rdev->dev, "GPU reset succeed\n"); r100_mc_resume(rdev, &save); - dev_info(rdev->dev, "GPU reset succeed\n"); - return 0; + return ret; } void r100_set_common_regs(struct radeon_device *rdev) diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index fae5e70..cf862ca 100644 --- a/drivers/gpu/drm/radeon/r300.c +++ b/drivers/gpu/drm/radeon/r300.c @@ -405,12 +405,13 @@ int r300_asic_reset(struct radeon_device *rdev) { struct r100_mc_save save; u32 status, tmp; + int ret = 0; - r100_mc_stop(rdev, &save); status = RREG32(R_000E40_RBBM_STATUS); if (!G_000E40_GUI_ACTIVE(status)) { return 0; } + r100_mc_stop(rdev, &save); status = RREG32(R_000E40_RBBM_STATUS); dev_info(rdev->dev, "(%s:%d) RBBM_STATUS=0x%08X\n", __func__, __LINE__, status); /* stop CP */ @@ -451,11 +452,11 @@ int r300_asic_reset(struct radeon_device *rdev) if (G_000E40_GA_BUSY(status) || G_000E40_VAP_BUSY(status)) { dev_err(rdev->dev, "failed to reset GPU\n"); rdev->gpu_lockup = true; - return -1; - } + ret = -1; + } else + dev_info(rdev->dev, "GPU reset succeed\n"); r100_mc_resume(rdev, &save); - dev_info(rdev->dev, "GPU reset succeed\n"); - return 0; + return ret; } /* diff --git a/drivers/gpu/drm/radeon/rs600.c b/drivers/gpu/drm/radeon/rs600.c index b4192ac..5afe294 100644 --- a/drivers/gpu/drm/radeon/rs600.c +++ b/drivers/gpu/drm/radeon/rs600.c @@ -339,16 +339,16 @@ void rs600_bm_disable(struct radeon_device *rdev) int rs600_asic_reset(struct radeon_device *rdev) { - u32 status, tmp; - struct rv515_mc_save save; + u32 status, tmp; + int ret = 0; - /* Stops all mc clients */ - rv515_mc_stop(rdev, &save); status = RREG32(R_000E40_RBBM_STATUS); if (!G_000E40_GUI_ACTIVE(status)) { return 0; } + /* Stops all mc clients */ + rv515_mc_stop(rdev, &save); status = RREG32(R_000E40_RBBM_STATUS); dev_info(rdev->dev, "(%s:%d) RBBM_STATUS=0x%08X\n", __func__, __LINE__, status); /* stop CP */ @@ -392,11 +392,11 @@ int rs600_asic_reset(struct radeon_device *rdev) if (G_000E40_GA_BUSY(status) || G_000E40_VAP_BUSY(status)) { dev_err(rdev->dev, "failed to reset GPU\n"); rdev->gpu_lockup = true; - return -1; - } + ret = -1; + } else + dev_info(rdev->dev, "GPU reset succeed\n"); rv515_mc_resume(rdev, &save); - dev_info(rdev->dev, "GPU reset succeed\n"); - return 0; + return ret; } /* -- 1.7.1.1

1 0

Re: A query on frame buffers
by Michel Dänzer 11 Jan '11

11 Jan '11

On Fre, 2011-01-07 at 02:42 +0000, Prasad Joshi wrote: > On Mon, Dec 27, 2010 at 3:30 PM, Konrad Rzeszutek Wilk > <konrad.wilk(a)oracle.com> wrote: > > On Tue, Dec 21, 2010 at 04:51:04AM +0000, Prasad Joshi wrote: > >> Hello All, > >> > >> This is probably my first mail on this mailing list. I am working on a > >> university project on Nvidia or any GPU Pass-through in KVM. I have a > > > > You picking the hard ones first, eh? I would suggest you do Intel > > or ATI as they have actually posted patches for this. > > Thanks a lot for your reply. > > Yes indeed, I started with the ATI Radeon RV370 card. Passing the > Nvidia card is the ultimate aim of the project. > > > > >> question related to framebuffer. > >> > >> I was reading few documents on XEN VGA pass-through, the document says > >> the first step for pass-through is mapping the framebuffers in the VM > >> at specific address, specifically speaking 0xA0000 till 0xC0000. > > > > I would suggest you look at the code - there have been some patches > > posted by AMD engineers on xen-devel for this. > > > > Yes I am looking at those patches as well, including some research > papers on the same topic. > > Here is what I have tried so far. > I have 2 graphics cards connected to my machine > 1. Nvidia: This is being used by host machine. > 2. ATI: Want to pass-through this card to the VM. > > I tried to pass-through the ATI card to VM. First, there was a problem > with ROM BIOS. Then I passed a correct ROM BIOS to QEMU-KVM. Now when > I start the VM with ATI card in pass-through mode. > > I see some garbage output on the monitor attached to the ATI card. I > also saw following messages in the system log. > > [ 2.162294] [drm] Initialized drm 1.1.0 20060810 > [ 2.459594] [drm] radeon defaulting to kernel modesetting. > [ 2.459596] [drm] radeon kernel modesetting enabled. > [ 2.766698] radeon 0000:00:04.0: PCI INT A -> Link[LNKD] -> GSI 10 > (level, high) -> IRQ 10 > [ 2.766734] radeon 0000:00:04.0: setting latency timer to 64 > [ 2.783512] [drm] initializing kernel modesetting (RV380 0x1002:0x5B64). > [ 2.792407] [drm] register mmio base: 0x40000000 > [ 2.792408] [drm] register mmio size: 65536 > [ 2.797177] [drm] Generation 2 PCI interface, using max accessible memory > [ 2.797275] radeon 0000:00:04.0: VRAM: 128M 0x00000000F8000000 - > 0x00000000FFFFFFFF (128M used) > [ 2.797284] radeon 0000:00:04.0: GTT: 512M 0x00000000D8000000 - > 0x00000000F7FFFFFF > [ 2.798370] radeon 0000:00:04.0: irq 40 for MSI/MSI-X > [ 2.870703] radeon 0000:00:04.0: radeon: using MSI. > [ 3.151162] [drm] radeon: irq initialized. > [ 3.151539] [drm] Detected VRAM RAM=128M, BAR=128M > [ 3.151541] [drm] RAM width 128bits DDR > [ 3.151610] [drm] radeon: 128M of VRAM memory ready > [ 3.151611] [drm] radeon: 512M of GTT memory ready. > [ 3.151627] [drm] GART: num cpu pages 131072, num gpu pages 131072 > [ 3.152701] [drm] radeon: 1 quad pipes, 1 Z pipes initialized. > [ 3.544943] [drm] PCIE GART of 512M enabled (table at 0xF8040000). > [ 3.548479] radeon 0000:00:04.0: WB enabled > [ 3.549020] [drm] Loading R300 Microcode > [ 3.554278] [drm] radeon: ring at 0x00000000D8001000 > [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed > (sracth(0x15E4)=0xCAFEDEAD) > [ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). > [ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22). > [ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration > [ 3.793709] [drm] radeon: cp finalized > [ 3.834875] radeon 0000:00:04.0: ffff8800320b4c00 unpin not necessary > [ 3.841759] [drm] Radeon Display Connectors > [ 3.841766] [drm] Connector 0: > [ 3.841771] [drm] VGA > [ 3.841777] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 > [ 3.841781] [drm] Encoders: > [ 3.841785] [drm] CRT1: INTERNAL_DAC1 > [ 3.841788] [drm] Connector 1: > [ 3.841791] [drm] DVI-I > [ 3.841794] [drm] HPD1 > [ 3.841799] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 > [ 3.841803] [drm] Encoders: > [ 3.841806] [drm] CRT2: INTERNAL_DAC2 > [ 3.841809] [drm] DFP1: INTERNAL_TMDS1 > [ 6.158753] [drm] fb mappable at 0xF8040000 > [ 6.158756] [drm] vram apper at 0xF8000000 > [ 6.158757] [drm] size 5242880 > [ 6.158758] [drm] fb depth is 24 > [ 6.158759] [drm] pitch is 5120 > [ 13.914196] fb0: radeondrmfb frame buffer device > [ 13.914198] drm: registered panic notifier > [ 13.914683] [drm] Initialized radeon 2.7.0 20080528 for > 0000:00:04.0 on minor 0 > > The errors > > [ 3.778476] [drm:r100_ring_test] *ERROR* radeon: ring test failed > (sracth(0x15E4)=0xCAFEDEAD) > [ 3.781010] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). > [ 3.782542] radeon 0000:00:04.0: failled initializing CP (-22). > [ 3.784006] radeon 0000:00:04.0: Disabling GPU acceleration > > Seem to be disabling GPU functionality. For now, I am interested in > Graphics functionality of the ATI card and not GPGPU functionality. > > I will appreciate if you can help me with some information on solving > this problem. Let me know if I should be asking this question on > another forum. Please keep me in CC. Looks like dri-devel material, added to CC. As a first guess, maybe the system memory pages accessed by the GPU GART aren't the same ones intended for this by the VM. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer

4 11

[Bug 32918] gnome-shell / mutter crashing.
by bugzilla-daemon＠freedesktop.org 11 Jan '11

11 Jan '11

https://bugs.freedesktop.org/show_bug.cgi?id=32918 --- Comment #7 from Lee Wilson <vixsandlee(a)gmail.com> 2011-01-11 10:12:53 PST --- I just checked it and yeah, its clutter built from git ** Checking out clutter *** [13/33] git clone git://git.clutter-project.org/clutter Initialized -- 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 17819] R300 Colourspace problem
by bugzilla-daemon＠freedesktop.org 11 Jan '11

11 Jan '11

https://bugs.freedesktop.org/show_bug.cgi?id=17819 --- Comment #3 from Thierry Vignaud <thierry.vignaud(a)gmail.com> 2011-01-11 08:20:18 PST --- Looks somewhat like Bug #32871 which I'm seeing for quite a lot of time (maybe since 2008 at least) Bug #32871 show image comparaisons, provides the user case that seems to cause this bug (suspending/resuming), so maybe should we close this one as duplicate of #32871, especially since there're been no answer on this one for more than one year... -- 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: Initialize pageflip spinlocks.
by Michel Dänzer 11 Jan '11

11 Jan '11

From: Michel Dänzer <daenzer(a)vmware.com> I'm amazed but not really surprised this worked on x86... Signed-off-by: Michel Dänzer <daenzer(a)vmware.com> --- drivers/gpu/drm/radeon/radeon_irq_kms.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c index a289646..9ec830c 100644 --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c @@ -110,11 +110,14 @@ void radeon_driver_irq_uninstall_kms(struct drm_device *dev) int radeon_irq_kms_init(struct radeon_device *rdev) { + int i; int r = 0; INIT_WORK(&rdev->hotplug_work, radeon_hotplug_work_func); spin_lock_init(&rdev->irq.sw_lock); + for (i = 0; i < rdev->num_crtc; i++) + spin_lock_init(&rdev->irq.pflip_lock[i]); r = drm_vblank_init(rdev->ddev, rdev->num_crtc); if (r) { return r; -- 1.7.2.3

1 0

[Bug 32978] New: Write access to mesa master repository
by bugzilla-daemon＠freedesktop.org 10 Jan '11

10 Jan '11

https://bugs.freedesktop.org/show_bug.cgi?id=32978 Summary: Write access to mesa master repository Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: deathsimple(a)vodafone.de Hi, because of my continues work on r600g and g3dvl i would like to gain write access to mesa master repository. Regards, Christian. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 1

[PATCH 1/2] drm/radeon/kms: add new PREFER_CLOSEST_HIGHER pll flag
by Alex Deucher 10 Jan '11

10 Jan '11

Partner to the existing PREFER_CLOSEST_LOWER. A new flag to prefer slightly higher target frequencies if the target cannot be hit exactly. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_display.c | 5 +++++ drivers/gpu/drm/radeon/radeon_mode.h | 5 +++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index 5c9451e..0eae4a4 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -908,6 +908,11 @@ void radeon_compute_pll(struct radeon_pll *pll, error = 0xffffffff; else error = freq - current_freq; + } else if (pll->flags & RADEON_PLL_PREFER_CLOSEST_HIGHER) { + if (freq > current_freq) + error = 0xffffffff; + else + error = current_freq - freq; } else error = abs(current_freq - freq); vco_diff = abs(vco - best_vco); diff --git a/drivers/gpu/drm/radeon/radeon_mode.h b/drivers/gpu/drm/radeon/radeon_mode.h index 162f36b..6b92dec 100644 --- a/drivers/gpu/drm/radeon/radeon_mode.h +++ b/drivers/gpu/drm/radeon/radeon_mode.h @@ -147,8 +147,9 @@ struct radeon_tmds_pll { #define RADEON_PLL_PREFER_HIGH_POST_DIV (1 << 9) #define RADEON_PLL_USE_FRAC_FB_DIV (1 << 10) #define RADEON_PLL_PREFER_CLOSEST_LOWER (1 << 11) -#define RADEON_PLL_USE_POST_DIV (1 << 12) -#define RADEON_PLL_IS_LCD (1 << 13) +#define RADEON_PLL_PREFER_CLOSEST_HIGHER (1 << 12) +#define RADEON_PLL_USE_POST_DIV (1 << 13) +#define RADEON_PLL_IS_LCD (1 << 14) struct radeon_pll { /* reference frequency */ -- 1.7.1.1

1 2

Re: 2.6.37-rc8: Reported regressions from 2.6.36
by Rafael J. Wysocki 10 Jan '11

10 Jan '11

On Monday, January 10, 2011, David Miller wrote: > From: "Rafael J. Wysocki" <rjw(a)sisk.pl> > Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET) > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592 > > Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect > > Submitter : Jeremy Fitzhardinge <jeremy(a)goop.org> > > Date : 2010-12-08 21:09 (22 days old) > > Message-ID : <4CFFF3F3.90100(a)goop.org> > > References : http://marc.info/?l=linux-kernel&m=129184256629712&w=2 > > This bug is intended to be fixed by: > > commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb > Author: David S. Miller <davem(a)davemloft.net> > Date: Wed Jan 5 15:38:53 2011 -0800 > > af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks. > > unix_release() can asynchornously set socket->sk to NULL, and > it does so without holding the unix_state_lock() on "other" > during stream connects. > > However, the reverse mapping, sk->sk_socket, is only transitioned > to NULL under the unix_state_lock(). > > Therefore make the security hooks follow the reverse mapping instead > of the forward mapping. > > Reported-by: Jeremy Fitzhardinge <jeremy(a)goop.org> > Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org> > Signed-off-by: David S. Miller <davem(a)davemloft.net> > OK, thanks for the info, closing. Rafael

1 0

[Bug 24592] Re: 2.6.37-rc8: Reported regressions from 2.6.36
by Rafael J. Wysocki 10 Jan '11

10 Jan '11

On Monday, January 10, 2011, David Miller wrote: > From: "Rafael J. Wysocki" <rjw(a)sisk.pl> > Date: Wed, 29 Dec 2010 23:59:38 +0100 (CET) > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=24592 > > Subject : 2.6.37-rc5: NULL pointer oops in selinux_socket_unix_stream_connect > > Submitter : Jeremy Fitzhardinge <jeremy(a)goop.org> > > Date : 2010-12-08 21:09 (22 days old) > > This bug is intended to be fixed by: > > commit 3610cda53f247e176bcbb7a7cca64bc53b12acdb > Author: David S. Miller <davem(a)davemloft.net> > Date: Wed Jan 5 15:38:53 2011 -0800 > > af_unix: Avoid socket->sk NULL OOPS in stream connect security hooks. > > unix_release() can asynchornously set socket->sk to NULL, and > it does so without holding the unix_state_lock() on "other" > during stream connects. > > However, the reverse mapping, sk->sk_socket, is only transitioned > to NULL under the unix_state_lock(). > > Therefore make the security hooks follow the reverse mapping instead > of the forward mapping. > > Reported-by: Jeremy Fitzhardinge <jeremy(a)goop.org> > Reported-by: Linus Torvalds <torvalds(a)linux-foundation.org> > Signed-off-by: David S. Miller <davem(a)davemloft.net>

1 0

[Bug 25052] kernel modesetting still does not work
by bugzilla-daemon＠bugzilla.kernel.org 10 Jan '11

10 Jan '11

https://bugzilla.kernel.org/show_bug.cgi?id=25052 --- Comment #8 from Elmar Stellnberger <estellnb(a)gmail.com> 2011-01-10 19:21:45 --- Without the vga= option the integrated screen becomes colorfully vertical lined and the mouse appears as pixel-soup-box. The external screen does however stay dark as well. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug. ------------------------------------------------------------------------------ Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl -- _______________________________________________ Dri-devel mailing list Dri-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel

1 0

← Newer
1
...
36
37
38
39
40
41
42
...
46
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2011