dri-devel January 2012

dri-devel@lists.freedesktop.org

91 participants
570 discussions

[Bug 42580] New: [radeon RS690] resume fails when radeon firmware is not available
by bugzilla-daemon＠bugzilla.kernel.org 16 Jan '12

16 Jan '12

https://bugzilla.kernel.org/show_bug.cgi?id=42580 URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65593 4 Summary: [radeon RS690] resume fails when radeon firmware is not available Product: Drivers Version: 2.5 Kernel Version: 3.1.0 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri(a)kernel-bugs.osdl.org ReportedBy: paulepanter(a)users.sourceforge.net Regression: No Debian Sid/unstable is running on the system and not having `firmware-linux-nonfree` installed, that means the firmware is not available, resume does not work. The machine even cannot be pinged so no debugging output can be captured. This is the output of the kernel ring buffer (`dmesg […] [ 21.459824] [drm] Initialized drm 1.1.0 20060810 [ 21.558265] [drm] radeon defaulting to kernel modesetting. [ 21.558269] [drm] radeon kernel modesetting enabled. [ 21.558436] radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 21.558683] [drm] initializing kernel modesetting (RS690 0x1002:0x791E 0x1043:0x826D). [ 21.558707] [drm] register mmio base: 0xFDBF0000 [ 21.558710] [drm] register mmio size: 65536 [ 21.560653] ATOM BIOS: ATI [ 21.560677] radeon 0000:01:05.0: VRAM: 128M 0x0000000078000000 - 0x000000007FFFFFFF (128M used) [ 21.560681] radeon 0000:01:05.0: GTT: 512M 0x0000000080000000 - 0x000000009FFFFFFF [ 21.560703] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 21.560706] [drm] Driver supports precise vblank timestamp query. [ 21.560720] [drm] radeon: irq initialized. [ 21.560974] [drm] Detected VRAM RAM=128M, BAR=128M [ 21.560978] [drm] RAM width 128bits DDR [ 21.561079] [TTM] Zone kernel: Available graphics memory: 964468 kiB. [ 21.561082] [TTM] Initializing pool allocator. [ 21.561120] [drm] radeon: 128M of VRAM memory ready [ 21.561122] [drm] radeon: 512M of GTT memory ready. [ 21.561149] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 21.573396] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 21.581312] radeon 0000:01:05.0: WB enabled [ 21.581570] [drm] Loading RS690/RS740 Microcode [ 21.617903] radeon_cp: Failed to load firmware "radeon/RS690_cp.bin" [ 21.617947] [drm:r100_cp_init] *ERROR* Failed to load firmware! [ 21.617987] radeon 0000:01:05.0: failed initializing CP (-2). [ 21.618026] radeon 0000:01:05.0: Disabling GPU acceleration [ 21.618068] [drm] radeon: cp finalized [ 21.618832] failed to evaluate ATIF got AE_BAD_PARAMETER […] Here is the output with the firmware available. […] [ 86.301645] [drm] Initialized drm 1.1.0 20060810 [ 86.603650] [drm] radeon kernel modesetting enabled. [ 86.603836] radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [ 86.604121] [drm] initializing kernel modesetting (RS690 0x1002:0x791E 0x1043:0x826D). [ 86.604144] [drm] register mmio base: 0xFDBF0000 [ 86.604146] [drm] register mmio size: 65536 [ 86.605939] ATOM BIOS: ATI [ 86.605963] radeon 0000:01:05.0: VRAM: 128M 0x0000000078000000 - 0x000000007FFFFFFF (128M used) [ 86.605967] radeon 0000:01:05.0: GTT: 512M 0x0000000080000000 - 0x000000009FFFFFFF [ 86.605989] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 86.605991] [drm] Driver supports precise vblank timestamp query. [ 86.606003] [drm] radeon: irq initialized. [ 86.606238] [drm] Detected VRAM RAM=128M, BAR=128M [ 86.606242] [drm] RAM width 128bits DDR [ 86.606344] [TTM] Zone kernel: Available graphics memory: 964468 kiB. [ 86.606346] [TTM] Initializing pool allocator. [ 86.606384] [drm] radeon: 128M of VRAM memory ready [ 86.606387] [drm] radeon: 512M of GTT memory ready. [ 86.606412] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 86.616780] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 86.624447] radeon 0000:01:05.0: WB enabled [ 86.624519] [drm] Loading RS690/RS740 Microcode […] Please advise how to debug that problem further. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching the assignee of the bug.

1 2

Re: [Intel-gfx] [PATCH 1/2] drm: give up on edid retries when i2c bus is not responding
by Daniel Vetter 16 Jan '12

16 Jan '12

Hi Dave, Is it ok if I merge this through my -next tree? Otherwise please consider merging this for 3.4. Yours, Daniel On Thu, Jan 05, 2012 at 09:34:28AM -0200, Eugeni Dodonov wrote: > This allows to avoid talking to a non-responding bus repeatedly until we > finally timeout after 15 attempts. We can do this by catching the -ENXIO > error, provided by i2c_algo_bit:bit_doAddress call. > > Within the bit_doAddress we already try 3 times to get the edid data, so > if the routine tells us that bus is not responding, it is mostly pointless > to keep re-trying those attempts over and over again until we reach final > number of retries. > > This change should fix https://bugs.freedesktop.org/show_bug.cgi?id=41059 > and improve overall edid detection timing by 10-30% in most cases, and by > a much larger margin in case of phantom outputs (up to 30x in one worst > case). > > Timing results for i915-powered machines for 'time xrandr' command: > Machine 1: from 0.840s to 0.290s > Machine 2: from 0.315s to 0.280s > Machine 3: from +/- 4s to 0.184s > > Timing results for HD5770 with 'time xrandr' command: > Machine 4: from 3.210s to 1.060s > > Reviewed-by: Chris Wilson <chris(a)hchris-wilson.co.uk> > Reviewed-by: Keith Packard <keithp(a)keithp.com> > Tested-by: Sean Finney <seanius(a)seanius.net> > Tested-by: Soren Hansen <soren(a)linux2go.dk> > Tested-by: Hernando Torque <sirius(a)sonnenkinder.org> > Tested-by: Mike Lothian <mike(a)fireburn.co.uk> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41059 > Signed-off-by: Eugeni Dodonov <eugeni.dodonov(a)intel.com> > --- > drivers/gpu/drm/drm_edid.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 3e927ce..fb6c26c 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -266,6 +266,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf, > } > }; > ret = i2c_transfer(adapter, msgs, 2); > + if (ret == -ENXIO) { > + DRM_DEBUG_KMS("drm: skipping non-existent adapter %s\n", > + adapter->name); > + break; > + } > } while (ret != 2 && --retries); > > return ret == 2 ? 0 : -1; > -- > 1.7.8 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx(a)lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Mail: daniel(a)ffwll.ch Mobile: +41 (0)79 365 57 48

1 0

New drm-intel-next tree
by Daniel Vetter 16 Jan '12

16 Jan '12

Hi all, Because Keith is routinely really busy with all kinds of things, notably gathering fixes for drm-intel-fixes, the patch merge process for the next release cycle sometimes falls behind. To support him and improve things I've been volunteered to take over handling the -next tree. The main aim is to shift the drm/i915 -next merge process massively ahead with the goals to: - Reduce pressure to merge questionable patches into -rc kernels because the -next tree is not yet open for patches. - Allow our QA at Intel and also the community to actually test things before they land in mainline. The lack of such testing has severly bitten us in the past few releases. - Refocus -fixes on handling regressions with absolute top priority (as it should). - And generally get a steady and predictable patch-flow towards mainline back into gears. I plan to run this -next tree with a few simple rules: - I'll open the drm/i915 -next tree around -rc1 (maybe earlier in the future) and cut regular new trees about every 2nd week or so. 2 weeks should be enough for both our qa and the community to give it some decent testing. - I intend to send out the previous -next to Dave Airlie (assuming it tests ok) so that he has a good check on the stuff that's going on in i915-land. A few other people also asked for a better overview of what's going on on drm/i915 - I'll plan to announce every new -next tree with a short mail (maybe together with the pull request to Dave for the old one). - -next will close about 1-2 weeks before the merge opens. No new features after that point for a given release cycle. - To make this really work we also need to cut down on what can go into -fixes. drm/i915 unfortunately has the reputation that deserves it a bunch of draconian rules (which are stricter than drm/* in general): - Only fixes for serious issues and regressions after the -next tree went to Dave. - After -rc2 regression fixes only. It simply happend why too often that an "obvious" patch blew up late in the -rc release cycle, my patches included. - After -rc4/5 only reverts and disable patches. Imo it's way too late to play games by then, the real fix should go straight to -next (which will close only a few weeks afterwards already). - Regressions have top priority, if they get neglected due to ongoing work headed for -next I'll refuse to merge the patches. - We have a test-suite in the intel-gpu-tools package for the kernel. Expect me to be annoying about patches that should have testcases for them but don't. This includes new features, but also bugs that can be reproduced with a reasonable amount of effort. - To avoid me pushing utter crack I will only merge my own patches after they have gathered sufficient review on intel-gfx. Please yell at me at the top of your voice (and in public) if I violate this. - The main discussion list for patches to drm/i915 is intel-gfx(a)lists.freedesktop.org - I don't keep up with lkml usually. - I'll reserve my human right to act like an incompetent arrogant fool once in a while. Last but not least, the new tree is available at http://cgit.freedesktop.org/~danvet/drm-intel git://people.freedesktop.org/~danvet/drm-intel drm-intel-next is the main branch, but I expect at least a for-airlied branch for pull requests and maybe other branches with proposed patches to show up. Comments, flames and suggestions highly welcome. Yours, Daniel PS: Quick version for people with too short attentation spans: - -next will open around -rc1, a new tree should show up about every second week. -next trees that are tested will regurarly be forwarded to Dave. - No stuff in -fixes that should go into -next instead. - -next will close for features about 1-2 weeks ahead of the upstream merge window. - Regressions have top priority. - Implementing proper tests is required. - Hit me hard if I break these rules for my own patches. - Sometimes I'll screw things up badly. Now grab the tree from git://people.freedesktop.org/~danvet/drm-intel -- Daniel Vetter Mail: daniel(a)ffwll.ch Mobile: +41 (0)79 365 57 48

2 1

[PATCH 0/5] drm/omap: updates for latest master
by Rob Clark 16 Jan '12

16 Jan '12

From: Rob Clark <rob(a)ti.com> Now that drm and fbdev (omapdss) next trees have been pulled by Linus, here are the updates to keep omapdrm compiling. The first four are re-sends of what was sent earlier, and the fifth takes care of some API changes in omapdss contained in the fbdev pull. Rob Clark (5): drm/omap: drm API update: make fops struct const drm/omap: drm API update: addfb2 drm/omap: add drm_plane support drm/omap: multiplanar and YUV support drm/omap: updates for DSS fifomerge API changes drivers/staging/omapdrm/Makefile | 1 + drivers/staging/omapdrm/omap_crtc.c | 191 +++++-------------- drivers/staging/omapdrm/omap_drv.c | 77 +++++--- drivers/staging/omapdrm/omap_drv.h | 52 +++++- drivers/staging/omapdrm/omap_fb.c | 224 ++++++++++++++++------ drivers/staging/omapdrm/omap_fbdev.c | 55 ++++-- drivers/staging/omapdrm/omap_gem.c | 5 + drivers/staging/omapdrm/omap_plane.c | 344 ++++++++++++++++++++++++++++++++++ drivers/staging/omapdrm/omap_priv.h | 12 +- 9 files changed, 699 insertions(+), 262 deletions(-) create mode 100644 drivers/staging/omapdrm/omap_plane.c -- 1.7.5.4

1 5

[Bug 36441] [RV620] Artefacts in launcher and dash (horizontal noise lines and color loss)
by bugzilla-daemon＠freedesktop.org 16 Jan '12

16 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=36441 --- Comment #8 from Alex Deucher <agd5f(a)yahoo.com> 2012-01-16 06:16:23 PST --- Is this still an issue on newer versions of r600g? -- 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 36441] [RV620] Artefacts in launcher and dash (horizontal noise lines and color loss)
by bugzilla-daemon＠freedesktop.org 16 Jan '12

16 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=36441 --- Comment #7 from Tom Simnett <tom+freedesktop(a)simnett.com> 2012-01-16 05:40:18 PST --- Created attachment 55636 --> https://bugs.freedesktop.org/attachment.cgi?id=55636 artefacts under -nouveau This appears to happen in -nouveau too. Screenshot attached. What additional information do you need? I'm running xorg-edgers PPA versions of everything on Ubuntu. -- 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 36918] New: ETQW: Enabling "Soft Particles" causes major performance issue
by bugzilla-daemon＠freedesktop.org 15 Jan '12

15 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=36918 Summary: ETQW: Enabling "Soft Particles" causes major performance issue Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: sa(a)whiz.se Enabling the option "Soft Particles" in the game Enemy Territory Quake Wars causes a major performance drop to ~ 1 fps, CPU goes to 100% so I'm guessing some sort of software fallback is hit? Options → Settings → Advanced → Soft Particles I'll see if r300g has the same problem, if so it's probably a more general problem. System environment: -- system architecture: 32-bit -- Linux distribution: Debian unstable -- GPU: REDWOOD -- Model: XFX Radeon HD 5670 1GB -- Display connector: DVI -- xf86-video-ati: 6.14.1 -- xserver: 1.10.1 -- mesa: 27d3e0b25cc3f2bd9f72778f0c9f54cb90c48622 -- drm: 2.4.25 -- kernel: 2.6.39-rc5 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 4

[PATCH] drm/radeon/kms: Add an MSI quirk for Dell RS690
by alexdeucher＠gmail.com 15 Jan '12

15 Jan '12

From: Alex Deucher <alexander.deucher(a)amd.com> Interrupts only work with MSIs. https://bugs.freedesktop.org/show_bug.cgi?id=37679 Reported-by: Dmitry Podgorny <pasis.uax(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/radeon/radeon_irq_kms.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c b/drivers/gpu/drm/radeon/radeon_irq_kms.c index be38921..66d5fe1 100644 --- a/drivers/gpu/drm/radeon/radeon_irq_kms.c +++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c @@ -138,6 +138,12 @@ static bool radeon_msi_ok(struct radeon_device *rdev) /* Dell RS690 only seems to work with MSIs. */ if ((rdev->pdev->device == 0x791f) && (rdev->pdev->subsystem_vendor == 0x1028) && + (rdev->pdev->subsystem_device == 0x01fc)) + return true; + + /* Dell RS690 only seems to work with MSIs. */ + if ((rdev->pdev->device == 0x791f) && + (rdev->pdev->subsystem_vendor == 0x1028) && (rdev->pdev->subsystem_device == 0x01fd)) return true; -- 1.7.3.4

1 0

[Bug 27314] displayport link training fails on certain panels (channel equalization fails)
by bugzilla-daemon＠freedesktop.org 15 Jan '12

15 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=27314 --- Comment #64 from Jérémy Lal <kapouer(a)melix.org> 2012-01-15 04:16:02 PST --- FYI, linux 3.2-rc7 on iMac12,2 (27" 2011 model) has radeon kms running without any glitch, and even with pretty good performance ! I'm EFI-booting with default debian/experimental kernel, so it's not customized nor patched. -- 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 26891] Radeon KMS on Macs with EFI boot
by bugzilla-daemon＠freedesktop.org 15 Jan '12

15 Jan '12

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #10 from Jérémy Lal <kapouer(a)melix.org> 2012-01-15 04:09:51 PST --- linux 3.2-rc7 is working without any patch, just radeon kms, on iMac12,2 EFI boot. (grub-efi-amd64) -- 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

← Newer
1
...
46
47
48
49
50
51
52
...
57
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2012