[PATCH] drm/radeon/kms: adjust eDP handling
eDP is usually used as an LVDS replacement, so treat
it more like LVDS from the user perspective.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 30 +++
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 5f45fa1..a7bdcc7 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1314,7 +1314,6 @@ radeon_add_atom_connector(struct drm_device *dev,
connector->doublescan_allowed = false;
break;
case DRM_MODE_CONNECTOR_DisplayPort:
- case DRM_MODE_CONNECTOR_eDP:
radeon_dig_connector = kzalloc(sizeof(struct
radeon_connector_atom_dig), GFP_KERNEL);
if (!radeon_dig_connector)
goto failed;
@@ -1324,10 +1323,7 @@ radeon_add_atom_connector(struct drm_device *dev,
drm_connector_helper_add(&radeon_connector->base,
&radeon_dp_connector_helper_funcs);
if (i2c_bus->valid) {
/* add DP i2c bus */
- if (connector_type == DRM_MODE_CONNECTOR_eDP)
- radeon_dig_connector->dp_i2c_bus =
radeon_i2c_create_dp(dev, i2c_bus, "eDP-auxch");
- else
- radeon_dig_connector->dp_i2c_bus =
radeon_i2c_create_dp(dev, i2c_bus, "DP-auxch");
+ radeon_dig_connector->dp_i2c_bus =
radeon_i2c_create_dp(dev, i2c_bus, "DP-auxch");
if (!radeon_dig_connector->dp_i2c_bus)
DRM_ERROR("DP: Failed to assign dp ddc bus!
Check dmesg for i2c errors.\n");
radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
@@ -1353,6 +1349,30 @@ radeon_add_atom_connector(struct drm_device *dev,
/* in theory with a DP to VGA converter... */
connector->doublescan_allowed = false;
break;
+ case DRM_MODE_CONNECTOR_eDP:
+ radeon_dig_connector = kzalloc(sizeof(struct
radeon_connector_atom_dig), GFP_KERNEL);
+ if (!radeon_dig_connector)
+ goto failed;
+ radeon_dig_connector->igp_lane_info = igp_lane_info;
+ radeon_connector->con_priv = radeon_dig_connector;
+ drm_connector_init(dev, &radeon_connector->base,
&radeon_dp_connector_funcs, connector_type);
+ drm_connector_helper_add(&radeon_connector->base,
&radeon_dp_connector_helper_funcs);
+ if (i2c_bus->valid) {
+ /* add DP i2c bus */
+ radeon_dig_connector->dp_i2c_bus =
radeon_i2c_create_dp(dev, i2c_bus, "eDP-auxch");
+ if (!radeon_dig_connector->dp_i2c_bus)
+ DRM_ERROR("DP: Failed to assign dp ddc bus!
Check dmesg for i2c errors.\n");
+ radeon_connector->ddc_bus = radeon_i2c_lookup(rdev,
i2c_bus);
+ if (!radeon_connector->ddc_bus)
+ DRM_ERROR("DP: Failed to assign ddc bus! Check
dmesg for i2c errors.\n");
+ }
+ drm_connector_attach_property(&radeon_connector->base,
+
dev->mode_config.scaling_mode_property,
+ DRM_MODE_SCALE_FULLSCREEN);
+ subpixel_order = SubPixelHorizontalRGB;
+ connector->interlace_allowed = false;
+ connector->doublescan_allowed = false;
+ break;
case DRM_MODE_CONNECTOR_SVIDEO:
case DRM_MODE_CONNECTOR_Composite:
case DRM_MODE_CONNECTOR_9PinDIN:
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 29495] [r300g] Shadowgrounds: character portraits rendered wrong
https://bugs.freedesktop.org/show_bug.cgi?id=29495 --- Comment #3 from Tom Stellard 2011-04-18 22:20:07 PDT --- Can you try this again with the latest git version of mesa (commit ffc1d166d24532aeaa4dcf06a431e43ab7e7e315 or newer)? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Add a driver for kvm emulated Cirrus
On Mon, Apr 18, 2011 at 10:03:06PM +0100, Alan Cox wrote:
> So has this been benchmarked - intuitively I'd agree and expect that a
> shadowfb driver ought to give best performance.
No, but it's noticably nicer to use under virt-manager. I'll try to come
up with some numbers.
> > +/* Map the framebuffer from the card and configure the core */
> > +static int cirrus_vram_init(struct cirrus_device *cdev)
> > +{
> > + int ret;
> > +
> > + /* BAR 0 is VRAM */
> > + cdev->mc.vram_base = pci_resource_start(cdev->ddev->pdev, 0);
> > + /* We have 4MB of VRAM */
> > + cdev->mc.vram_size = 4 * 1024 * 1024;
>
> For real hardware at least you should check that the pci resource is at
> least 4Mb long before doing this, otherwise the resulting progression in
> the fail case is that you map some other device into user address space,
> which isn't good!
True. The PCI table is restrictive enough that it won't bind to real
hardware, so I don't know if it's worth it to be paranoid.
> > +static void cirrus_encoder_mode_set(struct drm_encoder *encoder,
> > + struct drm_display_mode *mode,
> > + struct drm_display_mode *adjusted_mode)
> > +{
> > + struct drm_device *dev = encoder->dev;
> > + struct cirrus_device *cdev = dev->dev_private;
> > +
> > + unsigned char tmp;
> > +
> > + switch (encoder->crtc->fb->bits_per_pixel) {
> > + case 8:
> > + tmp = 0x0;
> > + break;
> > + case 16:
> > + /* Enable 16 bit mode */
> > + WREG_HDR(0x01);
>
> If you switch back from 16 does this not need clearing ?
Nope. qemu just looks at this to distinguish between 15 and 16 bit, and
I've no intention of supporting 15 bit...
--
Matthew Garrett | mjg59 at srcf.ucam.org
[Bug 29495] [r300g] Shadowgrounds: character portraits rendered wrong
https://bugs.freedesktop.org/show_bug.cgi?id=29495 --- Comment #3 from Tom Stellard 2011-04-18 22:20:07 PDT --- Can you try this again with the latest git version of mesa (commit ffc1d166d24532aeaa4dcf06a431e43ab7e7e315 or newer)? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34218] [r300g] Unigine Sanctuary: some surfaces are reflecting too much light
https://bugs.freedesktop.org/show_bug.cgi?id=34218 --- Comment #6 from Tom Stellard 2011-04-18 22:04:20 PDT --- Can you try this again with the latest git version of mesa (commit ffc1d166d24532aeaa4dcf06a431e43ab7e7e315 or newer)? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34218] [r300g] Unigine Sanctuary: some surfaces are reflecting too much light
https://bugs.freedesktop.org/show_bug.cgi?id=34218 --- Comment #6 from Tom Stellard 2011-04-18 22:04:20 PDT --- Can you try this again with the latest git version of mesa (commit ffc1d166d24532aeaa4dcf06a431e43ab7e7e315 or newer)? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm: Add a driver for kvm emulated Cirrus
So has this been benchmarked - intuitively I'd agree and expect that a
shadowfb driver ought to give best performance.
> +/* Map the framebuffer from the card and configure the core */
> +static int cirrus_vram_init(struct cirrus_device *cdev)
> +{
> + int ret;
> +
> + /* BAR 0 is VRAM */
> + cdev->mc.vram_base = pci_resource_start(cdev->ddev->pdev, 0);
> + /* We have 4MB of VRAM */
> + cdev->mc.vram_size = 4 * 1024 * 1024;
For real hardware at least you should check that the pci resource is at
least 4Mb long before doing this, otherwise the resulting progression in
the fail case is that you map some other device into user address space,
which isn't good!
> +static void cirrus_encoder_mode_set(struct drm_encoder *encoder,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct drm_device *dev = encoder->dev;
> + struct cirrus_device *cdev = dev->dev_private;
> +
> + unsigned char tmp;
> +
> + switch (encoder->crtc->fb->bits_per_pixel) {
> + case 8:
> + tmp = 0x0;
> + break;
> + case 16:
> + /* Enable 16 bit mode */
> + WREG_HDR(0x01);
If you switch back from 16 does this not need clearing ?
Alan
2.6.39-rc1 nouveau(?) regression (bisected)
On Sun, Apr 17, 2011 at 06:49:20PM +0200, Marcin Slusarz wrote: > On Sun, Apr 17, 2011 at 12:24:27PM -0400, Kyle Spaans wrote: > > On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote: > > > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > > > > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > > > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski > > > > > > >> wrote: > > > > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as > > > > > > >>> "calm" > > > > > > >>> to everyone, but then chose to CC Maciej instead: Would you be > > > > > > >>> so kind and > > > > > > >>> add this to your regression list? Thanks! > > > > > > >>> > > > > > > >>> Since commit 38f1cff > > > > > > >>> > > > > > > >>> From: Dave Airlie > > > > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > > > > >>> Subject: [PATCH] Merge commit > > > > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > > > > >>> > > > > > > >>> This commit changed an internal radeon structure, that > > > > > > >>> meant a new driver > > > > > > >>> in -next had to be fixed up, merge in the commit and fix up > > > > > > >>> the driver. > > > > > > >>> > > > > > > >>> Also fixes a trivial nouveau merge. > > > > > > >>> > > > > > > >>> Conflicts: > > > > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > > > > >>> > > > > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, > > > > > > >>> right after > > > > > > >>> blanking the screen, and before the initramfs gets loaded. I > > > > > > >>> just > > > > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do > > > > > > >>> indeed work > > > > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip > > > > > > >>> ( 85f2e68 ). > > > > > > >> Can you activate netconsole and check whether kernel spits > > > > > > >> anything interesting? > > > > > > >> You might try to load nouveau module after boot - maybe > > > > > > >> something will be saved > > > > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > > > > Compiling it as a module seems to work fine. When I do so, no > > > > > > > regression is > > > > > > > obvious from what gets reported in "dmesg". However, somehow I > > > > > > > now do get > > > > > > > some output: The last message I see is > > > > > > > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > > > > > > > > > > > > > > > > > > > Then, nothing more. However, it really is quite strange why this > > > > > > > error only > > > > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that > > > > > > it is > > > > > > causing me an oops at boot, but my bug has been ignored there so > > > > > > far - > > > > > > perhaps I should have posted it here instead. > > > > > > > > > > I'm getting the exact same symptoms on my Atom + ION hardware. > > > > > Crashes before it > > > > > can write any logs if it's compiled in and the logo is selected, but > > > > > boots fine > > > > > if compiled as a module or the logo is removed. > > > > > > > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > > > > mm/vmalloc.c) > > > > > to be the first bad one in 2.6.38+. This makes me think that it's not > > > > > a bug in > > > > > nouveau, but maybe a bug in the order that things are initialized? > > > > > > > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on > > > > 2.6.39-rc3+ > > > > makes my system boot just fine with the nouveau drivers compiled into > > > > the > > > > kernel. I've seen some similar looking bugs on LKML that this > > > > regression may or > > > > may not be related to? It works fine on 2.6.38. > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > > > > http://lkml.org/lkml/2011/4/15/194 > > > > > > > > I'm still trying to figure out exactly where the kernel is crashing > > > > after > > > > printing > > > > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 > > > > f4cf7600 > > > > > > > > Any thoughts on what else I should look for? > > > > > > I reproduced this bug today, and reverting > > > 89699605fe7cfd8611900346f61cb6cbf179b10a > > > does not fix it for me. Here's the backtrace: > > > > > > Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: > > > (null) > > > due to oops @ 0x81255081 > > > CPU 6 Modules linked in: > > > > > > Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System > > > manufacturer System Product Name/P6T SE > > > RIP: 0010:[] [] > > > iowrite32+0x12/0x34 > > > RSP: :8801becab4b0 EFLAGS: 00010296 > >
[Bug 36236] Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #16 from imamdxl8...@gmail.com 2011-04-18 21:10:55 PDT --- Tested as of today 19 April 2011, cloned mesa git glxinfo | grep OpenGL OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset x86/MMX/SSE2 OpenGL version string: 2.1 Mesa 7.11-devel (git-f41e1db) OpenGL shading language version string: 1.20 OpenGL extensions: it runs but looks like the attachment "Screenshot of the problem" in any graphic settings. It seems that everything is in there but no lighting on them except the sprite. Ubuntu 10.10 (32 Bit) Linux 2.6.36-02063604-generic Mesa 7.11-devel (cloned from git) Intel GMA 4500 256MB -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36236] Problems with lights in Trine game from www.humblebundle.com
https://bugs.freedesktop.org/show_bug.cgi?id=36236 --- Comment #16 from imamdxl8805 at gmail.com 2011-04-18 21:10:55 PDT --- Tested as of today 19 April 2011, cloned mesa git glxinfo | grep OpenGL OpenGL vendor string: Tungsten Graphics, Inc OpenGL renderer string: Mesa DRI Mobile Intel? GM45 Express Chipset x86/MMX/SSE2 OpenGL version string: 2.1 Mesa 7.11-devel (git-f41e1db) OpenGL shading language version string: 1.20 OpenGL extensions: it runs but looks like the attachment "Screenshot of the problem" in any graphic settings. It seems that everything is in there but no lighting on them except the sprite. Ubuntu 10.10 (32 Bit) Linux 2.6.36-02063604-generic Mesa 7.11-devel (cloned from git) Intel GMA 4500 256MB -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #8 from Benjamin Bellec 2011-04-18 17:19:15 PDT --- Here is a screencast of these textures problems. The first part show especially the texture corruption, and the second part the artifacts. http://dl.free.fr/hUqycZ1Qo etqw-bugzilla-35434.ogv -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35434] [RADEON:KMS:R600G] etqw: broken ground textures
https://bugs.freedesktop.org/show_bug.cgi?id=35434 --- Comment #8 from Benjamin Bellec 2011-04-18 17:19:15 PDT --- Here is a screencast of these textures problems. The first part show especially the texture corruption, and the second part the artifacts. http://dl.free.fr/hUqycZ1Qo etqw-bugzilla-35434.ogv -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 Евгений М. changed: What|Removed |Added Attachment #45792|lspci -vnn on my Toshiba on |lspci -vnn on my Toshiba description|my Satellite L35-S2366 |Satellite L35-S2366 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Add a driver for kvm emulated Cirrus
On Mon, Apr 18, 2011 at 4:04 PM, Matthew Garrett wrote: > qemu-kvm emulates a Cirrus GPU, including its acceleration engine. We > typically then run a Cirrus-specific X driver on top of this, which > turns requests into commands and sends them to the emulated accelerator. > This all seems to be unnecessary overhead given that we're just going > to end up writing to memory from the host instead, and performance is > almost certainly going to be better using an unaccelerated framebuffer > and a guest-side shadow. > > This patch provides a simple modesetting-only KMS driver for the hardware > emulated in qemu-kvm. It's stripped down to the point where it's able to > program the emulation, but would almost certainly fail miserably if asked > to run on real hardware. It's intended to reduce virt overhead slightly, > but also to serve as a template to writing a basic KMS driver. > > The code and structure are heavily derived from Matt Turner's glint > driver, with the modesetting code cribbed from cirrusfb (hence the > license). Nice! > +#define CIRRUS_DPMS_CLEARED (-1) I wanted to add a DPMS_CLEARED to DRM, since it's duplicated in at least Nouveau, glint, and now cirrusfb. I guess we should fix that at some point. The only other nit-pick I've got is that I named variables gfb and gfbdev because I'm uncreative with variable names and because glint started with a 'g'. Not important though. Thanks, I'll have to give it a try. Please have a Reviewed-by: Matt Turner Matt
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 ??? ?. changed: What|Removed |Added Attachment #45792|lspci -vnn on my Toshiba on |lspci -vnn on my Toshiba description|my Satellite L35-S2366 |Satellite L35-S2366 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33582] New: unable to hibernate with nouveau and NV11
https://bugzilla.kernel.org/show_bug.cgi?id=33582 Summary: unable to hibernate with nouveau and NV11 Product: Drivers Version: 2.5 Kernel Version: 2.6. Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: csights at fastmail.fm Regression: Yes Hi, I'm able to successfully hibernate while using nouveau with kernel version 2.6.35 (and before) but unable to hibernate in 2.6.36 (and after up to 2.6.39-rc$YESTERDAY). I am not using X. From the console I test whether hibernate is possible using "pm-hibernate". I've bisected this and located a range of possible commits which changed this behavior. last known good: d17f395cdcec39033a481f96d75e8b3d3c41d43a first known bad: 816544b21b020bdb9dcb9a5003fe3e1f109e8698 Between these commits the kernel would not compile. This is the nVidia card in the machine. 02:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) (prog-if 00 [VGA controller]) Subsystem: nVidia Corporation Device 0054 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11 Memory at dc00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (32-bit, prefetchable) [size=128M] [virtual] Expansion ROM at dd00 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 Let me know if I can provide more info or test patches! Thanks, Chad. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #10 from Евгений М. 2011-04-18 16:19:55 PDT --- Created an attachment (id=45792) --> (https://bugs.freedesktop.org/attachment.cgi?id=45792) lspci -vnn on my Toshiba on my Satellite L35-S2366 This bug has been around for more than 3 years for me. My experience is that if in the xorg.conf file I put Option "DRI" "off" I can resume from suspend if booting with radeon.modeset=0 kernel option. That does not give me 3D acceleration. If I put Option "DRI" "on" I lose resume, no matter what the kernel option is, however get 3D. I tried a variety of kernel and usually grab and build the freshest stable release from the kernel.org E.g., currently it is 2.6.38.3 (Apr 17) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #10 from ??? ?. 2011-04-18 16:19:55 PDT --- Created an attachment (id=45792) --> (https://bugs.freedesktop.org/attachment.cgi?id=45792) lspci -vnn on my Toshiba on my Satellite L35-S2366 This bug has been around for more than 3 years for me. My experience is that if in the xorg.conf file I put Option "DRI" "off" I can resume from suspend if booting with radeon.modeset=0 kernel option. That does not give me 3D acceleration. If I put Option "DRI" "on" I lose resume, no matter what the kernel option is, however get 3D. I tried a variety of kernel and usually grab and build the freshest stable release from the kernel.org E.g., currently it is 2.6.38.3 (Apr 17) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH 2/2] drm: Verify debug message arguments
On Mon, 2011-04-18 at 16:01 -0700, Ian Romanick wrote:
> > @@ -214,9 +214,9 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
> > i915_lvds_downclock) {
> > dev_priv->lvds_downclock_avail = 1;
> > dev_priv->lvds_downclock = temp_downclock;
> > - DRM_DEBUG_KMS("LVDS downclock is found in VBT. ",
> > - "Normal Clock %dKHz, downclock %dKHz\n",
> > - temp_downclock, panel_fixed_mode->clock);
> > + DRM_DEBUG_KMS("LVDS downclock is found in VBT. "
> > + "Normal Clock %dKHz, downclock %dKHz\n",
> > + temp_downclock, panel_fixed_mode->clock);
> > }
> > return;
> > }
> Does this hunk only change white space, or am I missing something?
No, you're right. It's just whitespace.
I prefer arguments aligned to open paren.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: Verify debug message arguments
On Mon, 2011-04-18 at 16:01 -0700, Ian Romanick wrote:
> > @@ -214,9 +214,9 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
> > i915_lvds_downclock) {
> > dev_priv->lvds_downclock_avail = 1;
> > dev_priv->lvds_downclock = temp_downclock;
> > - DRM_DEBUG_KMS("LVDS downclock is found in VBT. ",
> > - "Normal Clock %dKHz, downclock %dKHz\n",
> > - temp_downclock, panel_fixed_mode->clock);
> > + DRM_DEBUG_KMS("LVDS downclock is found in VBT. "
> > + "Normal Clock %dKHz, downclock %dKHz\n",
> > + temp_downclock, panel_fixed_mode->clock);
> > }
> > return;
> > }
> Does this hunk only change white space, or am I missing something?
No, you're right. It's just whitespace.
I prefer arguments aligned to open paren.
Re: [PATCH 1/2] drm: Create and use drm_err
On Mon, 2011-04-18 at 15:56 -0700, Ian Romanick wrote:
> I believe that DRM_NAME is a define, and drm_stub.c is in common code.
> As a result, won't this change cause something different to get logged?
Nope. DRM_NAME is #defined only once.
include/drm/drm.h:#define DRM_NAME "drm"
The only real reason to do this is the "*ERROR*"
used in:
> > -#define DRM_ERROR(fmt, arg...) \
> > - printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __func__ , ##arg)
It'd be more or less similar to use:
#define DRM_ERROR(fmt, ...) \
pr_err("%s: " fmt, __func__, ##__VA_ARGS__)
or just convert DRM_ERROR to pr_err and DRM_INFO to pr_info.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Create and use drm_err
On Mon, 2011-04-18 at 15:56 -0700, Ian Romanick wrote:
> I believe that DRM_NAME is a define, and drm_stub.c is in common code.
> As a result, won't this change cause something different to get logged?
Nope. DRM_NAME is #defined only once.
include/drm/drm.h:#define DRM_NAME "drm"
The only real reason to do this is the "*ERROR*"
used in:
> > -#define DRM_ERROR(fmt, arg...) \
> > - printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __func__ , ##arg)
It'd be more or less similar to use:
#define DRM_ERROR(fmt, ...) \
pr_err("%s: " fmt, __func__, ##__VA_ARGS__)
or just convert DRM_ERROR to pr_err and DRM_INFO to pr_info.
[PATCH] drm: Add a driver for kvm emulated Cirrus
ROR("cirrus_encoder_init failed\n");
+ return -1;
+ }
+
+ connector = cirrus_vga_init(cdev->ddev);
+ if (!connector) {
+ CIRRUS_ERROR("cirrus_vga_init failed\n");
+ return -1;
+ }
+
+ drm_mode_connector_attach_encoder(connector, encoder);
+
+ ret = cirrus_fbdev_init(cdev);
+ if (ret) {
+ CIRRUS_ERROR("cirrus_fbdev_init failed\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+void cirrus_modeset_fini(struct cirrus_device *cdev)
+{
+ cirrus_fbdev_fini(cdev);
+
+ if (cdev->mode_info.mode_config_initialized) {
+ drm_mode_config_cleanup(cdev->ddev);
+ cdev->mode_info.mode_config_initialized = false;
+ }
+}
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
new file mode 100644
index 000..ecc8e8d
--- /dev/null
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright 2010 Matt Turner.
+ * Copyright 2011 Red Hat
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * Authors: Matthew Garrett
+ * Matt Turner
+ */
+#include "drmP.h"
+#include "drm.h"
+
+#include "cirrus_drv.h"
+
+#include "drm_pciids.h"
+
+/*
+ * This is the generic driver code. This binds the driver to the drm core,
+ * which then performs further device association and calls our graphics init
+ * functions
+ */
+
+static struct drm_driver driver;
+
+static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
+ { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, 0x1af4, 0x1100, 0,
+ 0, 0 },
+ {0,}
+};
+
+static int __devinit
+cirrus_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+ return drm_get_pci_dev(pdev, ent, &driver);
+}
+
+static void cirrus_pci_remove(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+
+ drm_put_dev(dev);
+}
+
+static struct drm_driver driver = {
+ .driver_features = DRIVER_MODESET,
+ .load = cirrus_driver_load,
+ .unload = cirrus_driver_unload,
+ .reclaim_buffers = drm_core_reclaim_buffers,
+ .fops = {
+.owner = THIS_MODULE,
+.open = drm_open,
+.release = drm_release,
+.unlocked_ioctl = drm_ioctl,
+.mmap = drm_mmap,
+.poll = drm_poll,
+.fasync = drm_fasync,
+},
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+ .patchlevel = DRIVER_PATCHLEVEL,
+};
+
+static struct pci_driver cirrus_pci_driver = {
+ .name = DRIVER_NAME,
+ .id_table = pciidlist,
+ .probe = cirrus_pci_probe,
+ .remove = cirrus_pci_remove,
+};
+
+static int __init cirrus_init(void)
+{
+ return drm_pci_init(&driver, &cirrus_pci_driver);
+}
+
+static void __exit cirrus_exit(void)
+{
+ drm_pci_exit(&driver, &cirrus_pci_driver);
+}
+
+module_init(cirrus_init);
+module_exit(cirrus_exit);
+
+MODULE_DEVICE_TABLE(pci, pciidlist);
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
new file mode 100644
index 000..7a93f3e
--- /dev/null
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -0,0 +1,127 @@
+/*
+ * Copyright 2010 Matt Turner.
+ * Copyright 2011 Red Hat
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * Authors: Matthew Garrett
+ * Matt Turner
+ */
+#ifndef __CIRRUS_DRV_H__
+#define __CIRRUS_DRV_H__
+
+#include
+
+#define DRIVER_AUTHOR "Matthew Garrett"
+
+#define DRIVER_NAME"cirrus"
+#define DRIVER_DESC"qemu Cirrus emulation"
+#define DRIVER_DATE"20110418"
+
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+#define DRIVER_PATCHLEVEL 0
+
+#define CIRRUS_INFO(fmt, arg...) DRM_INFO(DRIVER_NAME ": " fmt, ##arg)
+#define CIRRUS_ERROR(fmt, arg...) DRM_ERROR(DRIVER_NAME ": " fmt, ##arg)
+
+#define CIRRUSFB_CONN_LIMIT 4
+
+#define RREG8(reg) ioread8(((void __iomem *)cdev->rmmio) + (reg))
+#define WREG8(reg, v) iowrite8(v, ((void __iomem *)cdev->rmmio) + (reg))
+#define RREG32(reg) ioread32(((void __iomem *)cdev->rmmio) + (reg))
+#define WREG32(reg, v) iowrite32(v, ((void __iomem *)cdev->rmmio) + (reg))
+
+#define SEQ_INDEX 4
+#define SEQ_DATA 5
+
+#define WREG_S
Re: [PATCH 2/2] drm: Verify debug message arguments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2011 08:35 PM, Joe Perches wrote:
> Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
> and fix fallout.
>
> Signed-off-by: Joe Perches
Aside from the comment below about intel_bios.c,
Reviewed-by: Ian Romanick
especially the changes in intel_display.c. yikes...
> ---
> drivers/gpu/drm/drm_irq.c |9 +
> drivers/gpu/drm/i915/intel_bios.c |6 +++---
> drivers/gpu/drm/i915/intel_display.c|8
> drivers/gpu/drm/radeon/radeon_display.c |5 +++--
> include/drm/drmP.h |3 ++-
> 5 files changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 741457b..62ced75 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -684,10 +684,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct
> drm_device *dev, int crtc,
>*/
> *vblank_time = ns_to_timeval(timeval_to_ns(&raw_time) - delta_ns);
>
> - DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %d.%d -> %d.%d [e %d us, %d rep]\n",
> - crtc, (int) vbl_status, hpos, vpos, raw_time.tv_sec,
> - raw_time.tv_usec, vblank_time->tv_sec, vblank_time->tv_usec,
> - (int) duration_ns/1000, i);
> + DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d
> rep]\n",
> + crtc, (int)vbl_status, hpos, vpos,
> + (long)raw_time.tv_sec, (long)raw_time.tv_usec,
> + (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
> + (int)duration_ns/1000, i);
>
> vbl_status = DRM_VBLANKTIME_SCANOUTPOS_METHOD;
> if (invbl)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index fb5b4d4..927442a 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -214,9 +214,9 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
> i915_lvds_downclock) {
> dev_priv->lvds_downclock_avail = 1;
> dev_priv->lvds_downclock = temp_downclock;
> - DRM_DEBUG_KMS("LVDS downclock is found in VBT. ",
> - "Normal Clock %dKHz, downclock %dKHz\n",
> - temp_downclock, panel_fixed_mode->clock);
> + DRM_DEBUG_KMS("LVDS downclock is found in VBT. "
> + "Normal Clock %dKHz, downclock %dKHz\n",
> + temp_downclock, panel_fixed_mode->clock);
> }
> return;
> }
Does this hunk only change white space, or am I missing something?
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 432fc04..63bc2af 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3497,11 +3497,11 @@ static unsigned long intel_calculate_wm(unsigned long
> clock_in_khz,
> 1000;
> entries_required = DIV_ROUND_UP(entries_required, wm->cacheline_size);
>
> - DRM_DEBUG_KMS("FIFO entries required for mode: %d\n", entries_required);
> + DRM_DEBUG_KMS("FIFO entries required for mode: %ld\n",
> entries_required);
>
> wm_size = fifo_size - (entries_required + wm->guard_size);
>
> - DRM_DEBUG_KMS("FIFO watermark level: %d\n", wm_size);
> + DRM_DEBUG_KMS("FIFO watermark level: %ld\n", wm_size);
>
> /* Don't promote wm_size to unsigned... */
> if (wm_size > (long)wm->max_wm)
> @@ -3820,13 +3820,13 @@ static bool g4x_check_srwm(struct drm_device *dev,
> display_wm, cursor_wm);
>
> if (display_wm > display->max_wm) {
> - DRM_DEBUG_KMS("display watermark is too large(%d), disabling\n",
> + DRM_DEBUG_KMS("display watermark is too large(%d/%ld),
> disabling\n",
> display_wm, display->max_wm);
> return false;
> }
>
> if (cursor_wm > cursor->max_wm) {
> - DRM_DEBUG_KMS("cursor watermark is too large(%d), disabling\n",
> + DRM_DEBUG_KMS("cursor watermark is too large(%d/%ld),
> disabling\n",
> cursor_wm, cursor->max_wm);
> return false;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index bdbab5c..0671934 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1087,8 +1087,9 @@ void radeon_compute_pll_legacy(struct radeon_pll *pll,
> *frac_fb_div_p = best_frac_feedback_div;
> *ref_div_p = best_ref_div;
> *post_div_p = best_post_div;
> - DRM_DEBUG_KMS("%d %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
> - freq, best_freq / 1000, best_feedback_div,
> best_frac_feedback_div,
> + DRM_DEBUG_KMS("%lld %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
> +
Re: [PATCH 1/2] drm: Create and use drm_err
On Mon, 2011-04-18 at 15:56 -0700, Ian Romanick wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/17/2011 08:35 PM, Joe Perches wrote:
> > Reduce drm text size ~1% by using drm_err and
> > printf extension %pV to emit error messages.
> >
> > Remove unused macro DRM_MEM_ERROR.
> >
> > $ size drivers/gpu/drm/built-in.o*
> >textdata bss dec hex filename
> > 3611599663 256 371078 5a986 drivers/gpu/drm/built-in.o.new
> > 3654169663 256 375335 5ba27 drivers/gpu/drm/built-in.o.old
> >
> > Signed-off-by: Joe Perches
> > ---
> > drivers/gpu/drm/drm_stub.c | 21 +
> > include/drm/drmP.h | 21 +++--
> > 2 files changed, 28 insertions(+), 14 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> > index 001273d..6d7b083 100644
> > --- a/drivers/gpu/drm/drm_stub.c
> > +++ b/drivers/gpu/drm/drm_stub.c
> > @@ -62,6 +62,26 @@ struct idr drm_minors_idr;
> > struct class *drm_class;
> > struct proc_dir_entry *drm_proc_root;
> > struct dentry *drm_debugfs_root;
> > +
> > +int drm_err(const char *func, const char *format, ...)
> > +{
> > + struct va_format vaf;
> > + va_list args;
> > + int r;
> > +
> > + va_start(args, format);
> > +
> > + vaf.fmt = format;
> > + vaf.va = &args;
> > +
> > + r = printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* %pV", func, &vaf);
>
> This code has ben reorganized a lot over the years, so this comment may
> be bogus. However...
>
> I believe that DRM_NAME is a define, and drm_stub.c is in common code.
> As a result, won't this change cause something different to get logged?
No I think we hacked that out a long time past thankfully, so its always
"drm" now.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: Verify debug message arguments
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2011 08:35 PM, Joe Perches wrote:
> Add __attribute__((format (printf, 4, 5))) to drm_ut_debug_printk
> and fix fallout.
>
> Signed-off-by: Joe Perches
Aside from the comment below about intel_bios.c,
Reviewed-by: Ian Romanick
especially the changes in intel_display.c. yikes...
> ---
> drivers/gpu/drm/drm_irq.c |9 +
> drivers/gpu/drm/i915/intel_bios.c |6 +++---
> drivers/gpu/drm/i915/intel_display.c|8
> drivers/gpu/drm/radeon/radeon_display.c |5 +++--
> include/drm/drmP.h |3 ++-
> 5 files changed, 17 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 741457b..62ced75 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -684,10 +684,11 @@ int drm_calc_vbltimestamp_from_scanoutpos(struct
> drm_device *dev, int crtc,
>*/
> *vblank_time = ns_to_timeval(timeval_to_ns(&raw_time) - delta_ns);
>
> - DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %d.%d -> %d.%d [e %d us, %d rep]\n",
> - crtc, (int) vbl_status, hpos, vpos, raw_time.tv_sec,
> - raw_time.tv_usec, vblank_time->tv_sec, vblank_time->tv_usec,
> - (int) duration_ns/1000, i);
> + DRM_DEBUG("crtc %d : v %d p(%d,%d)@ %ld.%ld -> %ld.%ld [e %d us, %d
> rep]\n",
> + crtc, (int)vbl_status, hpos, vpos,
> + (long)raw_time.tv_sec, (long)raw_time.tv_usec,
> + (long)vblank_time->tv_sec, (long)vblank_time->tv_usec,
> + (int)duration_ns/1000, i);
>
> vbl_status = DRM_VBLANKTIME_SCANOUTPOS_METHOD;
> if (invbl)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index fb5b4d4..927442a 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -214,9 +214,9 @@ parse_lfp_panel_data(struct drm_i915_private *dev_priv,
> i915_lvds_downclock) {
> dev_priv->lvds_downclock_avail = 1;
> dev_priv->lvds_downclock = temp_downclock;
> - DRM_DEBUG_KMS("LVDS downclock is found in VBT. ",
> - "Normal Clock %dKHz, downclock %dKHz\n",
> - temp_downclock, panel_fixed_mode->clock);
> + DRM_DEBUG_KMS("LVDS downclock is found in VBT. "
> + "Normal Clock %dKHz, downclock %dKHz\n",
> + temp_downclock, panel_fixed_mode->clock);
> }
> return;
> }
Does this hunk only change white space, or am I missing something?
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 432fc04..63bc2af 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3497,11 +3497,11 @@ static unsigned long intel_calculate_wm(unsigned long
> clock_in_khz,
> 1000;
> entries_required = DIV_ROUND_UP(entries_required, wm->cacheline_size);
>
> - DRM_DEBUG_KMS("FIFO entries required for mode: %d\n", entries_required);
> + DRM_DEBUG_KMS("FIFO entries required for mode: %ld\n",
> entries_required);
>
> wm_size = fifo_size - (entries_required + wm->guard_size);
>
> - DRM_DEBUG_KMS("FIFO watermark level: %d\n", wm_size);
> + DRM_DEBUG_KMS("FIFO watermark level: %ld\n", wm_size);
>
> /* Don't promote wm_size to unsigned... */
> if (wm_size > (long)wm->max_wm)
> @@ -3820,13 +3820,13 @@ static bool g4x_check_srwm(struct drm_device *dev,
> display_wm, cursor_wm);
>
> if (display_wm > display->max_wm) {
> - DRM_DEBUG_KMS("display watermark is too large(%d), disabling\n",
> + DRM_DEBUG_KMS("display watermark is too large(%d/%ld),
> disabling\n",
> display_wm, display->max_wm);
> return false;
> }
>
> if (cursor_wm > cursor->max_wm) {
> - DRM_DEBUG_KMS("cursor watermark is too large(%d), disabling\n",
> + DRM_DEBUG_KMS("cursor watermark is too large(%d/%ld),
> disabling\n",
> cursor_wm, cursor->max_wm);
> return false;
> }
> diff --git a/drivers/gpu/drm/radeon/radeon_display.c
> b/drivers/gpu/drm/radeon/radeon_display.c
> index bdbab5c..0671934 100644
> --- a/drivers/gpu/drm/radeon/radeon_display.c
> +++ b/drivers/gpu/drm/radeon/radeon_display.c
> @@ -1087,8 +1087,9 @@ void radeon_compute_pll_legacy(struct radeon_pll *pll,
> *frac_fb_div_p = best_frac_feedback_div;
> *ref_div_p = best_ref_div;
> *post_div_p = best_post_div;
> - DRM_DEBUG_KMS("%d %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
> - freq, best_freq / 1000, best_feedback_div,
> best_frac_feedback_div,
> + DRM_DEBUG_KMS("%lld %d, pll dividers - fb: %d.%d ref: %d, post %d\n",
> +
Re: [PATCH 1/2] drm: Create and use drm_err
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2011 08:35 PM, Joe Perches wrote:
> Reduce drm text size ~1% by using drm_err and
> printf extension %pV to emit error messages.
>
> Remove unused macro DRM_MEM_ERROR.
>
> $ size drivers/gpu/drm/built-in.o*
>text data bss dec hex filename
> 361159 9663 256 371078 5a986 drivers/gpu/drm/built-in.o.new
> 365416 9663 256 375335 5ba27 drivers/gpu/drm/built-in.o.old
>
> Signed-off-by: Joe Perches
> ---
> drivers/gpu/drm/drm_stub.c | 21 +
> include/drm/drmP.h | 21 +++--
> 2 files changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 001273d..6d7b083 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -62,6 +62,26 @@ struct idr drm_minors_idr;
> struct class *drm_class;
> struct proc_dir_entry *drm_proc_root;
> struct dentry *drm_debugfs_root;
> +
> +int drm_err(const char *func, const char *format, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> + int r;
> +
> + va_start(args, format);
> +
> + vaf.fmt = format;
> + vaf.va = &args;
> +
> + r = printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* %pV", func, &vaf);
This code has ben reorganized a lot over the years, so this comment may
be bogus. However...
I believe that DRM_NAME is a define, and drm_stub.c is in common code.
As a result, won't this change cause something different to get logged?
> +
> + va_end(args);
> +
> + return r;
> +}
> +EXPORT_SYMBOL(drm_err);
> +
> void drm_ut_debug_printk(unsigned int request_level,
>const char *prefix,
>const char *function_name,
> @@ -78,6 +98,7 @@ void drm_ut_debug_printk(unsigned int request_level,
> }
> }
> EXPORT_SYMBOL(drm_ut_debug_printk);
> +
> static int drm_minor_get_id(struct drm_device *dev, int type)
> {
> int new_id;
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 202424d..22db51d 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -126,6 +126,9 @@ extern void drm_ut_debug_printk(unsigned int
> request_level,
> const char *prefix,
> const char *function_name,
> const char *format, ...);
> +extern __attribute__((format (printf, 2, 3)))
> +int drm_err(const char *func, const char *format, ...);
> +
> /***/
> /** \name DRM template customization defaults */
> /*@{*/
> @@ -181,21 +184,11 @@ extern void drm_ut_debug_printk(unsigned int
> request_level,
> * \param fmt printf() like format string.
> * \param arg arguments
> */
> -#define DRM_ERROR(fmt, arg...) \
> - printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __func__ , ##arg)
> -
> -/**
> - * Memory error output.
> - *
> - * \param area memory area where the error occurred.
> - * \param fmt printf() like format string.
> - * \param arg arguments
> - */
> -#define DRM_MEM_ERROR(area, fmt, arg...) \
> - printk(KERN_ERR "[" DRM_NAME ":%s:%s] *ERROR* " fmt , __func__, \
> -drm_mem_stats[area].name , ##arg)
> +#define DRM_ERROR(fmt, ...) \
> + drm_err(__func__, fmt, ##__VA_ARGS__)
>
> -#define DRM_INFO(fmt, arg...) printk(KERN_INFO "[" DRM_NAME "] " fmt ,
> ##arg)
> +#define DRM_INFO(fmt, ...) \
> + printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
>
> /**
> * Debug output.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2swbEACgkQX1gOwKyEAw+w/ACfd2QMJWOQU5f9sgavPXkfPPfW
GygAn2D8bjKkIV8wOXYC1fOI9w4DPWHj
=q3FM
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Create and use drm_err
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/17/2011 08:35 PM, Joe Perches wrote:
> Reduce drm text size ~1% by using drm_err and
> printf extension %pV to emit error messages.
>
> Remove unused macro DRM_MEM_ERROR.
>
> $ size drivers/gpu/drm/built-in.o*
>text data bss dec hex filename
> 361159 9663 256 371078 5a986 drivers/gpu/drm/built-in.o.new
> 365416 9663 256 375335 5ba27 drivers/gpu/drm/built-in.o.old
>
> Signed-off-by: Joe Perches
> ---
> drivers/gpu/drm/drm_stub.c | 21 +
> include/drm/drmP.h | 21 +++--
> 2 files changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_stub.c b/drivers/gpu/drm/drm_stub.c
> index 001273d..6d7b083 100644
> --- a/drivers/gpu/drm/drm_stub.c
> +++ b/drivers/gpu/drm/drm_stub.c
> @@ -62,6 +62,26 @@ struct idr drm_minors_idr;
> struct class *drm_class;
> struct proc_dir_entry *drm_proc_root;
> struct dentry *drm_debugfs_root;
> +
> +int drm_err(const char *func, const char *format, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> + int r;
> +
> + va_start(args, format);
> +
> + vaf.fmt = format;
> + vaf.va = &args;
> +
> + r = printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* %pV", func, &vaf);
This code has ben reorganized a lot over the years, so this comment may
be bogus. However...
I believe that DRM_NAME is a define, and drm_stub.c is in common code.
As a result, won't this change cause something different to get logged?
> +
> + va_end(args);
> +
> + return r;
> +}
> +EXPORT_SYMBOL(drm_err);
> +
> void drm_ut_debug_printk(unsigned int request_level,
>const char *prefix,
>const char *function_name,
> @@ -78,6 +98,7 @@ void drm_ut_debug_printk(unsigned int request_level,
> }
> }
> EXPORT_SYMBOL(drm_ut_debug_printk);
> +
> static int drm_minor_get_id(struct drm_device *dev, int type)
> {
> int new_id;
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index 202424d..22db51d 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -126,6 +126,9 @@ extern void drm_ut_debug_printk(unsigned int
> request_level,
> const char *prefix,
> const char *function_name,
> const char *format, ...);
> +extern __attribute__((format (printf, 2, 3)))
> +int drm_err(const char *func, const char *format, ...);
> +
> /***/
> /** \name DRM template customization defaults */
> /*@{*/
> @@ -181,21 +184,11 @@ extern void drm_ut_debug_printk(unsigned int
> request_level,
> * \param fmt printf() like format string.
> * \param arg arguments
> */
> -#define DRM_ERROR(fmt, arg...) \
> - printk(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __func__ , ##arg)
> -
> -/**
> - * Memory error output.
> - *
> - * \param area memory area where the error occurred.
> - * \param fmt printf() like format string.
> - * \param arg arguments
> - */
> -#define DRM_MEM_ERROR(area, fmt, arg...) \
> - printk(KERN_ERR "[" DRM_NAME ":%s:%s] *ERROR* " fmt , __func__, \
> -drm_mem_stats[area].name , ##arg)
> +#define DRM_ERROR(fmt, ...) \
> + drm_err(__func__, fmt, ##__VA_ARGS__)
>
> -#define DRM_INFO(fmt, arg...) printk(KERN_INFO "[" DRM_NAME "] " fmt ,
> ##arg)
> +#define DRM_INFO(fmt, ...) \
> + printk(KERN_INFO "[" DRM_NAME "] " fmt, ##__VA_ARGS__)
>
> /**
> * Debug output.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk2swbEACgkQX1gOwKyEAw+w/ACfd2QMJWOQU5f9sgavPXkfPPfW
GygAn2D8bjKkIV8wOXYC1fOI9w4DPWHj
=q3FM
-END PGP SIGNATURE-
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 Nicolas Kaiser changed: What|Removed |Added Attachment #45790|45789: readPixSanity|readPixSanity git-699ecec description|git-699ecec #3 |#3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 Nicolas Kaiser changed: What|Removed |Added Attachment #45790|45789: readPixSanity|readPixSanity git-699ecec description|git-699ecec #3 |#3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #5 from Nicolas Kaiser 2011-04-18 15:46:14 PDT --- Created an attachment (id=45790) --> (https://bugs.freedesktop.org/attachment.cgi?id=45790) 45789: readPixSanity git-699ecec #3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #5 from Nicolas Kaiser 2011-04-18 15:46:14 PDT --- Created an attachment (id=45790) --> (https://bugs.freedesktop.org/attachment.cgi?id=45790) 45789: readPixSanity git-699ecec #3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #4 from Nicolas Kaiser 2011-04-18 15:45:28 PDT --- Created an attachment (id=45789) --> (https://bugs.freedesktop.org/attachment.cgi?id=45789) readPixSanity git-699ecec #2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #4 from Nicolas Kaiser 2011-04-18 15:45:28 PDT --- Created an attachment (id=45789) --> (https://bugs.freedesktop.org/attachment.cgi?id=45789) readPixSanity git-699ecec #2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #3 from Nicolas Kaiser 2011-04-18 15:44:31 PDT --- Created an attachment (id=45788) --> (https://bugs.freedesktop.org/attachment.cgi?id=45788) readPixSanity git-699ecec #1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #3 from Nicolas Kaiser 2011-04-18 15:44:31 PDT --- Created an attachment (id=45788) --> (https://bugs.freedesktop.org/attachment.cgi?id=45788) readPixSanity git-699ecec #1 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #2 from Nicolas Kaiser 2011-04-18 15:43:08 PDT --- Created an attachment (id=45787) --> (https://bugs.freedesktop.org/attachment.cgi?id=45787) readPixSanity 7.9.2 #3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #2 from Nicolas Kaiser 2011-04-18 15:43:08 PDT --- Created an attachment (id=45787) --> (https://bugs.freedesktop.org/attachment.cgi?id=45787) readPixSanity 7.9.2 #3 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #1 from Nicolas Kaiser 2011-04-18 15:42:20 PDT --- Created an attachment (id=45786) --> (https://bugs.freedesktop.org/attachment.cgi?id=45786) readPixSanity 7.9.2 #2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36371] r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 --- Comment #1 from Nicolas Kaiser 2011-04-18 15:42:20 PDT --- Created an attachment (id=45786) --> (https://bugs.freedesktop.org/attachment.cgi?id=45786) readPixSanity 7.9.2 #2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36371] New: r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 Summary: r200: piglit readPixSanity failure Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: ni...@nikai.net Created an attachment (id=45785) --> (https://bugs.freedesktop.org/attachment.cgi?id=45785) readPixSanity 7.9.2 #1 For presumably quite some time the piglit readPixSanity test fails here. I'll attach tests with mesa-7.9.2 as well as git-699ecec. I did three runs each, because I noticed that the readbacks differ from run to run. System environment: -- system architecture: i686 -- Linux distribution: Gentoo -- GPU: R200 514D -- Model: ATI Radeon 9100 QM (AGP) -- Display connector: VGA -- xf86-video-ati: 982c22f16c89be81779fbfe17d8d3f9b6897 -- xserver: 1.9.4 -- mesa: 699ecec58c6925fb174ecf925158df6cce59be59 and -- mesa: 7.9.2 -- drm: 2.4.25 -- kernel: 2.6.38.2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36371] New: r200: piglit readPixSanity failure
https://bugs.freedesktop.org/show_bug.cgi?id=36371 Summary: r200: piglit readPixSanity failure Product: Mesa Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r200 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: nikai at nikai.net Created an attachment (id=45785) --> (https://bugs.freedesktop.org/attachment.cgi?id=45785) readPixSanity 7.9.2 #1 For presumably quite some time the piglit readPixSanity test fails here. I'll attach tests with mesa-7.9.2 as well as git-699ecec. I did three runs each, because I noticed that the readbacks differ from run to run. System environment: -- system architecture: i686 -- Linux distribution: Gentoo -- GPU: R200 514D -- Model: ATI Radeon 9100 QM (AGP) -- Display connector: VGA -- xf86-video-ati: 982c22f16c89be81779fbfe17d8d3f9b6897 -- xserver: 1.9.4 -- mesa: 699ecec58c6925fb174ecf925158df6cce59be59 and -- mesa: 7.9.2 -- drm: 2.4.25 -- kernel: 2.6.38.2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 26999] _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed
https://bugs.freedesktop.org/show_bug.cgi?id=26999 --- Comment #11 from Julien Viard de Galbert 2011-04-18 14:50:47 PDT --- Unfortunately, I didn't get time to work on that yet... I still plan too, but I really don't know when ;) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26999] _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed
https://bugs.freedesktop.org/show_bug.cgi?id=26999 --- Comment #11 from Julien Viard de Galbert 2011-04-18 14:50:47 PDT --- Unfortunately, I didn't get time to work on that yet... I still plan too, but I really don't know when ;) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: [PATCH] drm: Add a driver for kvm emulated Cirrus
On Mon, Apr 18, 2011 at 10:03:06PM +0100, Alan Cox wrote:
> So has this been benchmarked - intuitively I'd agree and expect that a
> shadowfb driver ought to give best performance.
No, but it's noticably nicer to use under virt-manager. I'll try to come
up with some numbers.
> > +/* Map the framebuffer from the card and configure the core */
> > +static int cirrus_vram_init(struct cirrus_device *cdev)
> > +{
> > + int ret;
> > +
> > + /* BAR 0 is VRAM */
> > + cdev->mc.vram_base = pci_resource_start(cdev->ddev->pdev, 0);
> > + /* We have 4MB of VRAM */
> > + cdev->mc.vram_size = 4 * 1024 * 1024;
>
> For real hardware at least you should check that the pci resource is at
> least 4Mb long before doing this, otherwise the resulting progression in
> the fail case is that you map some other device into user address space,
> which isn't good!
True. The PCI table is restrictive enough that it won't bind to real
hardware, so I don't know if it's worth it to be paranoid.
> > +static void cirrus_encoder_mode_set(struct drm_encoder *encoder,
> > + struct drm_display_mode *mode,
> > + struct drm_display_mode *adjusted_mode)
> > +{
> > + struct drm_device *dev = encoder->dev;
> > + struct cirrus_device *cdev = dev->dev_private;
> > +
> > + unsigned char tmp;
> > +
> > + switch (encoder->crtc->fb->bits_per_pixel) {
> > + case 8:
> > + tmp = 0x0;
> > + break;
> > + case 16:
> > + /* Enable 16 bit mode */
> > + WREG_HDR(0x01);
>
> If you switch back from 16 does this not need clearing ?
Nope. qemu just looks at this to distinguish between 15 and 16 bit, and
I've no intention of supporting 15 bit...
--
Matthew Garrett | mj...@srcf.ucam.org
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add a driver for kvm emulated Cirrus
So has this been benchmarked - intuitively I'd agree and expect that a
shadowfb driver ought to give best performance.
> +/* Map the framebuffer from the card and configure the core */
> +static int cirrus_vram_init(struct cirrus_device *cdev)
> +{
> + int ret;
> +
> + /* BAR 0 is VRAM */
> + cdev->mc.vram_base = pci_resource_start(cdev->ddev->pdev, 0);
> + /* We have 4MB of VRAM */
> + cdev->mc.vram_size = 4 * 1024 * 1024;
For real hardware at least you should check that the pci resource is at
least 4Mb long before doing this, otherwise the resulting progression in
the fail case is that you map some other device into user address space,
which isn't good!
> +static void cirrus_encoder_mode_set(struct drm_encoder *encoder,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct drm_device *dev = encoder->dev;
> + struct cirrus_device *cdev = dev->dev_private;
> +
> + unsigned char tmp;
> +
> + switch (encoder->crtc->fb->bits_per_pixel) {
> + case 8:
> + tmp = 0x0;
> + break;
> + case 16:
> + /* Enable 16 bit mode */
> + WREG_HDR(0x01);
If you switch back from 16 does this not need clearing ?
Alan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 --- Comment #4 from Sergey Senozhatsky 2011-04-18 13:34:24 --- On (04/17/11 18:08), bugzilla-daemon at bugzilla.kernel.org wrote: > Also please try the current Linus' tree in case the underlying bug has been > fixed already. > Hello, Had some time for testing, and it looks like the problem sits on the X server side. Even .38 (built with gcc-4.5 and gcc-4.6) failed. Sergey -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.39-rc1 nouveau(?) regression (bisected)
On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz wrote: > > It's some nasty corruption: Looks like something wrote 0x to free'd memory. Enabling DEBUG_PAGEALLOC *might* show where it happens. > > [ 6.523867] > = > [ 6.523916] BUG sysfs_dir_cache: Poison overwritten > [ 6.523949] > - > [ 6.523950] > [ 6.524016] INFO: 0x8801bb47df4c-0x8801bb47df4f. First byte 0xff > instead of 0x6b > [ 6.524061] INFO: Slab 0xea00060f7b58 objects=22 used=21 > fp=0x8801bb47df18 flags=0x80c1 > [ 6.524110] INFO: Object 0x8801bb47df18 @offset=3864 fp=0x > (null) > [ 6.524111] > [ 6.524170] Bytes b4 0x8801bb47df08: 00 00 00 00 00 00 00 00 5a 5a 5a > 5a 5a 5a 5a 5a > [ 6.524516] Object 0x8801bb47df18: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b > [ 6.524862] Object 0x8801bb47df28: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b > [ 6.525208] Object 0x8801bb47df38: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b > [ 6.525556] Object 0x8801bb47df48: 6b 6b 6b 6b ff ff ff ff 6b 6b 6b > 6b 6b 6b 6b 6b So here the 0x is pretty obvious. > and in another boot: > > [ 6.704786] BUG: unable to handle kernel paging request at bc70b058 Here it is less obvious, but it was _probably_ a regular kernel pointer of the type 0x8801bc70b058 before the high bits were overwritten by a 0x. So then sysfs_refresh_inode() follows that pointer, and crashes. Just a guess, obviously, but it looks rather likely. Linus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Add a driver for kvm emulated Cirrus
On Mon, Apr 18, 2011 at 4:04 PM, Matthew Garrett wrote: > qemu-kvm emulates a Cirrus GPU, including its acceleration engine. We > typically then run a Cirrus-specific X driver on top of this, which > turns requests into commands and sends them to the emulated accelerator. > This all seems to be unnecessary overhead given that we're just going > to end up writing to memory from the host instead, and performance is > almost certainly going to be better using an unaccelerated framebuffer > and a guest-side shadow. > > This patch provides a simple modesetting-only KMS driver for the hardware > emulated in qemu-kvm. It's stripped down to the point where it's able to > program the emulation, but would almost certainly fail miserably if asked > to run on real hardware. It's intended to reduce virt overhead slightly, > but also to serve as a template to writing a basic KMS driver. > > The code and structure are heavily derived from Matt Turner's glint > driver, with the modesetting code cribbed from cirrusfb (hence the > license). Nice! > +#define CIRRUS_DPMS_CLEARED (-1) I wanted to add a DPMS_CLEARED to DRM, since it's duplicated in at least Nouveau, glint, and now cirrusfb. I guess we should fix that at some point. The only other nit-pick I've got is that I named variables gfb and gfbdev because I'm uncreative with variable names and because glint started with a 'g'. Not important though. Thanks, I'll have to give it a try. Please have a Reviewed-by: Matt Turner Matt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.39-rc1 nouveau(?) regression (bisected)
On Mon, Apr 18, 2011 at 1:02 PM, Marcin Slusarz wrote: > > It's some nasty corruption: Looks like something wrote 0x to free'd memory. Enabling DEBUG_PAGEALLOC *might* show where it happens. > > [ ? ?6.523867] > = > [ ? ?6.523916] BUG sysfs_dir_cache: Poison overwritten > [ ? ?6.523949] > - > [ ? ?6.523950] > [ ? ?6.524016] INFO: 0x8801bb47df4c-0x8801bb47df4f. First byte 0xff > instead of 0x6b > [ ? ?6.524061] INFO: Slab 0xea00060f7b58 objects=22 used=21 > fp=0x8801bb47df18 flags=0x80c1 > [ ? ?6.524110] INFO: Object 0x8801bb47df18 @offset=3864 fp=0x ? ? ? ? > ?(null) > [ ? ?6.524111] > [ ? ?6.524170] Bytes b4 0x8801bb47df08: ?00 00 00 00 00 00 00 00 5a 5a 5a > 5a 5a 5a 5a 5a > [ ? ?6.524516] ? Object 0x8801bb47df18: ?6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b > [ ? ?6.524862] ? Object 0x8801bb47df28: ?6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b > [ ? ?6.525208] ? Object 0x8801bb47df38: ?6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b > 6b 6b 6b 6b 6b > [ ? ?6.525556] ? Object 0x8801bb47df48: ?6b 6b 6b 6b ff ff ff ff 6b 6b 6b > 6b 6b 6b 6b 6b So here the 0x is pretty obvious. > and in another boot: > > [ ? ?6.704786] BUG: unable to handle kernel paging request at bc70b058 Here it is less obvious, but it was _probably_ a regular kernel pointer of the type 0x8801bc70b058 before the high bits were overwritten by a 0x. So then sysfs_refresh_inode() follows that pointer, and crashes. Just a guess, obviously, but it looks rather likely. Linus
[PATCH] drm: Add a driver for kvm emulated Cirrus
ROR("cirrus_encoder_init failed\n");
+ return -1;
+ }
+
+ connector = cirrus_vga_init(cdev->ddev);
+ if (!connector) {
+ CIRRUS_ERROR("cirrus_vga_init failed\n");
+ return -1;
+ }
+
+ drm_mode_connector_attach_encoder(connector, encoder);
+
+ ret = cirrus_fbdev_init(cdev);
+ if (ret) {
+ CIRRUS_ERROR("cirrus_fbdev_init failed\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+void cirrus_modeset_fini(struct cirrus_device *cdev)
+{
+ cirrus_fbdev_fini(cdev);
+
+ if (cdev->mode_info.mode_config_initialized) {
+ drm_mode_config_cleanup(cdev->ddev);
+ cdev->mode_info.mode_config_initialized = false;
+ }
+}
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.c
b/drivers/gpu/drm/cirrus/cirrus_drv.c
new file mode 100644
index 000..ecc8e8d
--- /dev/null
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.c
@@ -0,0 +1,91 @@
+/*
+ * Copyright 2010 Matt Turner.
+ * Copyright 2011 Red Hat
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * Authors: Matthew Garrett
+ * Matt Turner
+ */
+#include "drmP.h"
+#include "drm.h"
+
+#include "cirrus_drv.h"
+
+#include "drm_pciids.h"
+
+/*
+ * This is the generic driver code. This binds the driver to the drm core,
+ * which then performs further device association and calls our graphics init
+ * functions
+ */
+
+static struct drm_driver driver;
+
+static DEFINE_PCI_DEVICE_TABLE(pciidlist) = {
+ { PCI_VENDOR_ID_CIRRUS, PCI_DEVICE_ID_CIRRUS_5446, 0x1af4, 0x1100, 0,
+ 0, 0 },
+ {0,}
+};
+
+static int __devinit
+cirrus_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+ return drm_get_pci_dev(pdev, ent, &driver);
+}
+
+static void cirrus_pci_remove(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+
+ drm_put_dev(dev);
+}
+
+static struct drm_driver driver = {
+ .driver_features = DRIVER_MODESET,
+ .load = cirrus_driver_load,
+ .unload = cirrus_driver_unload,
+ .reclaim_buffers = drm_core_reclaim_buffers,
+ .fops = {
+.owner = THIS_MODULE,
+.open = drm_open,
+.release = drm_release,
+.unlocked_ioctl = drm_ioctl,
+.mmap = drm_mmap,
+.poll = drm_poll,
+.fasync = drm_fasync,
+},
+ .name = DRIVER_NAME,
+ .desc = DRIVER_DESC,
+ .date = DRIVER_DATE,
+ .major = DRIVER_MAJOR,
+ .minor = DRIVER_MINOR,
+ .patchlevel = DRIVER_PATCHLEVEL,
+};
+
+static struct pci_driver cirrus_pci_driver = {
+ .name = DRIVER_NAME,
+ .id_table = pciidlist,
+ .probe = cirrus_pci_probe,
+ .remove = cirrus_pci_remove,
+};
+
+static int __init cirrus_init(void)
+{
+ return drm_pci_init(&driver, &cirrus_pci_driver);
+}
+
+static void __exit cirrus_exit(void)
+{
+ drm_pci_exit(&driver, &cirrus_pci_driver);
+}
+
+module_init(cirrus_init);
+module_exit(cirrus_exit);
+
+MODULE_DEVICE_TABLE(pci, pciidlist);
+MODULE_AUTHOR(DRIVER_AUTHOR);
+MODULE_DESCRIPTION(DRIVER_DESC);
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
new file mode 100644
index 000..7a93f3e
--- /dev/null
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -0,0 +1,127 @@
+/*
+ * Copyright 2010 Matt Turner.
+ * Copyright 2011 Red Hat
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License version 2. See the file COPYING in the main
+ * directory of this archive for more details.
+ *
+ * Authors: Matthew Garrett
+ * Matt Turner
+ */
+#ifndef __CIRRUS_DRV_H__
+#define __CIRRUS_DRV_H__
+
+#include
+
+#define DRIVER_AUTHOR "Matthew Garrett"
+
+#define DRIVER_NAME"cirrus"
+#define DRIVER_DESC"qemu Cirrus emulation"
+#define DRIVER_DATE"20110418"
+
+#define DRIVER_MAJOR 1
+#define DRIVER_MINOR 0
+#define DRIVER_PATCHLEVEL 0
+
+#define CIRRUS_INFO(fmt, arg...) DRM_INFO(DRIVER_NAME ": " fmt, ##arg)
+#define CIRRUS_ERROR(fmt, arg...) DRM_ERROR(DRIVER_NAME ": " fmt, ##arg)
+
+#define CIRRUSFB_CONN_LIMIT 4
+
+#define RREG8(reg) ioread8(((void __iomem *)cdev->rmmio) + (reg))
+#define WREG8(reg, v) iowrite8(v, ((void __iomem *)cdev->rmmio) + (reg))
+#define RREG32(reg) ioread32(((void __iomem *)cdev->rmmio) + (reg))
+#define WREG32(reg, v) iowrite32(v, ((void __iomem *)cdev->rmmio) + (reg))
+
+#define SEQ_INDEX 4
+#define SEQ_DATA 5
+
+#define WREG_S
Re: 2.6.39-rc1 nouveau(?) regression (bisected)
On Sun, Apr 17, 2011 at 06:49:20PM +0200, Marcin Slusarz wrote: > On Sun, Apr 17, 2011 at 12:24:27PM -0400, Kyle Spaans wrote: > > On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote: > > > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > > > > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > > > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski > > > > > > >> wrote: > > > > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as > > > > > > >>> "calm" > > > > > > >>> to everyone, but then chose to CC Maciej instead: Would you be > > > > > > >>> so kind and > > > > > > >>> add this to your regression list? Thanks! > > > > > > >>> > > > > > > >>> Since commit 38f1cff > > > > > > >>> > > > > > > >>> From: Dave Airlie > > > > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > > > > >>> Subject: [PATCH] Merge commit > > > > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > > > > >>> > > > > > > >>> This commit changed an internal radeon structure, that > > > > > > >>> meant a new driver > > > > > > >>> in -next had to be fixed up, merge in the commit and fix up > > > > > > >>> the driver. > > > > > > >>> > > > > > > >>> Also fixes a trivial nouveau merge. > > > > > > >>> > > > > > > >>> Conflicts: > > > > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > > > > >>> > > > > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, > > > > > > >>> right after > > > > > > >>> blanking the screen, and before the initramfs gets loaded. I > > > > > > >>> just > > > > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do > > > > > > >>> indeed work > > > > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip > > > > > > >>> ( 85f2e68 ). > > > > > > >> Can you activate netconsole and check whether kernel spits > > > > > > >> anything interesting? > > > > > > >> You might try to load nouveau module after boot - maybe > > > > > > >> something will be saved > > > > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > > > > Compiling it as a module seems to work fine. When I do so, no > > > > > > > regression is > > > > > > > obvious from what gets reported in "dmesg". However, somehow I > > > > > > > now do get > > > > > > > some output: The last message I see is > > > > > > > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > > > > > > > > > > > > > > > > > > > Then, nothing more. However, it really is quite strange why this > > > > > > > error only > > > > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that > > > > > > it is > > > > > > causing me an oops at boot, but my bug has been ignored there so > > > > > > far - > > > > > > perhaps I should have posted it here instead. > > > > > > > > > > I'm getting the exact same symptoms on my Atom + ION hardware. > > > > > Crashes before it > > > > > can write any logs if it's compiled in and the logo is selected, but > > > > > boots fine > > > > > if compiled as a module or the logo is removed. > > > > > > > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > > > > mm/vmalloc.c) > > > > > to be the first bad one in 2.6.38+. This makes me think that it's not > > > > > a bug in > > > > > nouveau, but maybe a bug in the order that things are initialized? > > > > > > > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on > > > > 2.6.39-rc3+ > > > > makes my system boot just fine with the nouveau drivers compiled into > > > > the > > > > kernel. I've seen some similar looking bugs on LKML that this > > > > regression may or > > > > may not be related to? It works fine on 2.6.38. > > > > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > > > > http://lkml.org/lkml/2011/4/15/194 > > > > > > > > I'm still trying to figure out exactly where the kernel is crashing > > > > after > > > > printing > > > > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 > > > > f4cf7600 > > > > > > > > Any thoughts on what else I should look for? > > > > > > I reproduced this bug today, and reverting > > > 89699605fe7cfd8611900346f61cb6cbf179b10a > > > does not fix it for me. Here's the backtrace: > > > > > > Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: > > > (null) > > > due to oops @ 0x81255081 > > > CPU 6 Modules linked in: > > > > > > Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System > > > manufacturer System Product Name/P6T SE > > > RIP: 0010:[] [] > > > iowrite32+0x12/0x34 > > > RSP: :8801becab4b0 EFLAGS: 00010296 > >
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #9 from Karesz L. 2011-04-18 12:51:22 PDT --- I've made a custom kernel, and applied this (I modified the nx6125's patch a bit): --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -3171,6 +3171,14 @@ void radeon_combios_asic_init(struct drm_device *dev) rdev->pdev->subsystem_device == 0x30a4) return; +/* quirk for rs4xx FSC Amilo Li1718 laptop to make it resume + * - it hangs on resume inside the dynclk 1 table. + */ +if (rdev->family == CHIP_RS480 && +rdev->pdev->subsystem_vendor == 0x103c && +rdev->pdev->subsystem_device == 0x10fb) +return; + /* DYN CLK 1 */ table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE); if (table) I haven't been able to resume with it correctly, but, in some cases, the system froze a little bit after, than before. These times, the lcd got backlit, and some broken images, lines, colours, dots appeared. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36327] fujitsu siemens amilo li1718: ati radeon x200m does not resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=36327 --- Comment #9 from Karesz L. 2011-04-18 12:51:22 PDT --- I've made a custom kernel, and applied this (I modified the nx6125's patch a bit): --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -3171,6 +3171,14 @@ void radeon_combios_asic_init(struct drm_device *dev) rdev->pdev->subsystem_device == 0x30a4) return; +/* quirk for rs4xx FSC Amilo Li1718 laptop to make it resume + * - it hangs on resume inside the dynclk 1 table. + */ +if (rdev->family == CHIP_RS480 && +rdev->pdev->subsystem_vendor == 0x103c && +rdev->pdev->subsystem_device == 0x10fb) +return; + /* DYN CLK 1 */ table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE); if (table) I haven't been able to resume with it correctly, but, in some cases, the system froze a little bit after, than before. These times, the lcd got backlit, and some broken images, lines, colours, dots appeared. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 --- Comment #8 from Johannes Berg 2011-04-18 12:50:17 --- Actually, that was wrong -- I wasn't booting the kernel I was compiling, 2.6.39-rc3 doesn't work at all, I only get a garbled screen :-( -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Linux 2.6.39-rc3
On Mon, Apr 18, 2011 at 11:59 AM, Jerome Glisse wrote: > On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher > wrote: >> On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse >> wrote: >>> On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher >>> wrote: On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: > On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > >> If you want to go the printk way you can add printk before each test >> ring_test, ib_test in r600.c this 2 functions are the own that might >> trigger the first GPU gart activities. > > Okay, I found the place in source that triggers this. It happens in the > function r600_ib_test. The interesting thing is that not the ib-command > itself is responsible but the fence that is emitted afterwards (proved > by removing the fence command, where the problem went away). > I don't know enough about the command semantics to make a guess what > goes wrong there. But maybe you GPU folks have an idea? > I can't think of anything off hand. ?It might be worth disabling the call to r600_ib_test() in r600_init() and then seeing if you get any errors when the fences are used later on when X starts or just at that point in the module load sequence. ?What's odd is that when you tested radeon.no_wb=1 you got the same behavior as that disables shadowing of fence writes to gpu gart mem, so it wouldn't be writing to memory in that case. Alex >>> >>> It might be the irq ring write that is faulty. >> >> That's disabled with no_wb=1 as well. >> >> Alex >> > > I mean the irq interrupt ring, i don't see this being disabled when no_wb=1 I meant the IH ring pointer writeback. The ih ring itself is still in gart memory. Alex > > Cheers, > Jerome >
Linux 2.6.39-rc3
On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher wrote: > On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse wrote: >> On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher >> wrote: >>> On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > If you want to go the printk way you can add printk before each test > ring_test, ib_test in r600.c this 2 functions are the own that might > trigger the first GPU gart activities. Okay, I found the place in source that triggers this. It happens in the function r600_ib_test. The interesting thing is that not the ib-command itself is responsible but the fence that is emitted afterwards (proved by removing the fence command, where the problem went away). I don't know enough about the command semantics to make a guess what goes wrong there. But maybe you GPU folks have an idea? >>> >>> I can't think of anything off hand. ?It might be worth disabling the >>> call to r600_ib_test() in r600_init() and then seeing if you get any >>> errors when the fences are used later on when X starts or just at that >>> point in the module load sequence. ?What's odd is that when you tested >>> radeon.no_wb=1 you got the same behavior as that disables shadowing of >>> fence writes to gpu gart mem, so it wouldn't be writing to memory in >>> that case. >>> >>> Alex >>> >> >> It might be the irq ring write that is faulty. > > That's disabled with no_wb=1 as well. > > Alex > I mean the irq interrupt ring, i don't see this being disabled when no_wb=1 Cheers, Jerome
Linux 2.6.39-rc3
On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse wrote: > On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher > wrote: >> On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: >>> On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: >>> If you want to go the printk way you can add printk before each test ring_test, ib_test in r600.c this 2 functions are the own that might trigger the first GPU gart activities. >>> >>> Okay, I found the place in source that triggers this. It happens in the >>> function r600_ib_test. The interesting thing is that not the ib-command >>> itself is responsible but the fence that is emitted afterwards (proved >>> by removing the fence command, where the problem went away). >>> I don't know enough about the command semantics to make a guess what >>> goes wrong there. But maybe you GPU folks have an idea? >>> >> >> I can't think of anything off hand. ?It might be worth disabling the >> call to r600_ib_test() in r600_init() and then seeing if you get any >> errors when the fences are used later on when X starts or just at that >> point in the module load sequence. ?What's odd is that when you tested >> radeon.no_wb=1 you got the same behavior as that disables shadowing of >> fence writes to gpu gart mem, so it wouldn't be writing to memory in >> that case. >> >> Alex >> > > It might be the irq ring write that is faulty. That's disabled with no_wb=1 as well. Alex > > Cheers, > Jerome >
Linux 2.6.39-rc3
On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher wrote: > On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: >> On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: >> >>> If you want to go the printk way you can add printk before each test >>> ring_test, ib_test in r600.c this 2 functions are the own that might >>> trigger the first GPU gart activities. >> >> Okay, I found the place in source that triggers this. It happens in the >> function r600_ib_test. The interesting thing is that not the ib-command >> itself is responsible but the fence that is emitted afterwards (proved >> by removing the fence command, where the problem went away). >> I don't know enough about the command semantics to make a guess what >> goes wrong there. But maybe you GPU folks have an idea? >> > > I can't think of anything off hand. ?It might be worth disabling the > call to r600_ib_test() in r600_init() and then seeing if you get any > errors when the fences are used later on when X starts or just at that > point in the module load sequence. ?What's odd is that when you tested > radeon.no_wb=1 you got the same behavior as that disables shadowing of > fence writes to gpu gart mem, so it wouldn't be writing to memory in > that case. > > Alex > It might be the irq ring write that is faulty. Cheers, Jerome
Linux 2.6.39-rc3
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: > On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > >> If you want to go the printk way you can add printk before each test >> ring_test, ib_test in r600.c this 2 functions are the own that might >> trigger the first GPU gart activities. > > Okay, I found the place in source that triggers this. It happens in the > function r600_ib_test. The interesting thing is that not the ib-command > itself is responsible but the fence that is emitted afterwards (proved > by removing the fence command, where the problem went away). > I don't know enough about the command semantics to make a guess what > goes wrong there. But maybe you GPU folks have an idea? > I can't think of anything off hand. It might be worth disabling the call to r600_ib_test() in r600_init() and then seeing if you get any errors when the fences are used later on when X starts or just at that point in the module load sequence. What's odd is that when you tested radeon.no_wb=1 you got the same behavior as that disables shadowing of fence writes to gpu gart mem, so it wouldn't be writing to memory in that case. Alex > ? ? ? ?Joerg > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >
[PATCH] drm: Recover DPMS properly after XRandr re-enablement
At Sun, 17 Apr 2011 18:26:54 +0200, Florian Mickler wrote: > > On Wed, 22 Dec 2010 12:53:07 + > Chris Wilson wrote: > > > On Wed, 22 Dec 2010 12:42:32 +, Chris Wilson > chris-wilson.co.uk> wrote: > > > From: Takashi Iwai > > > > > This patch adds a new helper function to manage the drm_connector > > > DPMS so that it can be called commonly in both places. > > > > > > Signed-off-by: Takashi Iwai > > > > FWIW, > > > > Reviewed-by: Chris Wilson > > > > -Chris > > > > Is this patch still necessary for 2.6.39? Yes, I think so. Takashi > It was needed to fix a regression from 2.6.36 (at least in February). > ( https://bugzilla.kernel.org/show_bug.cgi?id=24982 ) > > Regards, > Flo >
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 --- Comment #7 from Johannes Berg 2011-04-18 09:56:16 --- I'm now on 2.6.39-rc3 and while the issue persists, the patch doesn't apply. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Mon, Apr 18, 2011 at 11:59 AM, Jerome Glisse wrote: > On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher wrote: >> On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse wrote: >>> On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher >>> wrote: On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: > On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > >> If you want to go the printk way you can add printk before each test >> ring_test, ib_test in r600.c this 2 functions are the own that might >> trigger the first GPU gart activities. > > Okay, I found the place in source that triggers this. It happens in the > function r600_ib_test. The interesting thing is that not the ib-command > itself is responsible but the fence that is emitted afterwards (proved > by removing the fence command, where the problem went away). > I don't know enough about the command semantics to make a guess what > goes wrong there. But maybe you GPU folks have an idea? > I can't think of anything off hand. It might be worth disabling the call to r600_ib_test() in r600_init() and then seeing if you get any errors when the fences are used later on when X starts or just at that point in the module load sequence. What's odd is that when you tested radeon.no_wb=1 you got the same behavior as that disables shadowing of fence writes to gpu gart mem, so it wouldn't be writing to memory in that case. Alex >>> >>> It might be the irq ring write that is faulty. >> >> That's disabled with no_wb=1 as well. >> >> Alex >> > > I mean the irq interrupt ring, i don't see this being disabled when no_wb=1 I meant the IH ring pointer writeback. The ih ring itself is still in gart memory. Alex > > Cheers, > Jerome > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
On Sun, 2011-04-17 at 15:40 -0400, Bob Gleitsmann wrote: > Good day, night, or whatever, Hey, I've pushed a fix for this (solution 2 that you mentioned) to nouveau's git tree. I'll get it to Dave with the next batch of fixes for .39-rc. Ben. > > The above mentioned commit which changed the flags passed to nouveau_gem_new > to > domain creates a problem in nouveau_notifier_init_channel (in > nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That > function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier > allocation during channel allocation goes awry the kernel thinks that the gpu > is locked up and switches to software fbcon, and X is gone. The solution is > obvious. However, I am not clear on what the original purpose of the patch > was > nor why the TTM placement flags and the NOUVEAU placement flags are reversed > for > GART and VRAM. I'm not saying there isn't a good reason, I just don't know > what it is. The choices are: > 1. Revert the patch > 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to > nouveau_bo_pin. > 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix > every place that nouveau_bo_pin is called (not all that many) to give it the > flags it will then expect. > 4. None of the above > > Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's > hard to believe that no one else noticed it for a month as it's pretty > difficult > to ignore. > > Best Wishes, > > Bob Gleitsmann > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33582] New: unable to hibernate with nouveau and NV11
https://bugzilla.kernel.org/show_bug.cgi?id=33582 Summary: unable to hibernate with nouveau and NV11 Product: Drivers Version: 2.5 Kernel Version: 2.6. 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: csig...@fastmail.fm Regression: Yes Hi, I'm able to successfully hibernate while using nouveau with kernel version 2.6.35 (and before) but unable to hibernate in 2.6.36 (and after up to 2.6.39-rc$YESTERDAY). I am not using X. From the console I test whether hibernate is possible using "pm-hibernate". I've bisected this and located a range of possible commits which changed this behavior. last known good: d17f395cdcec39033a481f96d75e8b3d3c41d43a first known bad: 816544b21b020bdb9dcb9a5003fe3e1f109e8698 Between these commits the kernel would not compile. This is the nVidia card in the machine. 02:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) (prog-if 00 [VGA controller]) Subsystem: nVidia Corporation Device 0054 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 11 Memory at dc00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (32-bit, prefetchable) [size=128M] [virtual] Expansion ROM at dd00 [disabled] [size=64K] Capabilities: [60] Power Management version 2 Capabilities: [44] AGP version 2.0 Let me know if I can provide more info or test patches! Thanks, Chad. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Mon, Apr 18, 2011 at 11:33 AM, Alex Deucher wrote: > On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse wrote: >> On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher wrote: >>> On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > If you want to go the printk way you can add printk before each test > ring_test, ib_test in r600.c this 2 functions are the own that might > trigger the first GPU gart activities. Okay, I found the place in source that triggers this. It happens in the function r600_ib_test. The interesting thing is that not the ib-command itself is responsible but the fence that is emitted afterwards (proved by removing the fence command, where the problem went away). I don't know enough about the command semantics to make a guess what goes wrong there. But maybe you GPU folks have an idea? >>> >>> I can't think of anything off hand. It might be worth disabling the >>> call to r600_ib_test() in r600_init() and then seeing if you get any >>> errors when the fences are used later on when X starts or just at that >>> point in the module load sequence. What's odd is that when you tested >>> radeon.no_wb=1 you got the same behavior as that disables shadowing of >>> fence writes to gpu gart mem, so it wouldn't be writing to memory in >>> that case. >>> >>> Alex >>> >> >> It might be the irq ring write that is faulty. > > That's disabled with no_wb=1 as well. > > Alex > I mean the irq interrupt ring, i don't see this being disabled when no_wb=1 Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Mon, Apr 18, 2011 at 11:29 AM, Jerome Glisse wrote: > On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher wrote: >> On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: >>> On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: >>> If you want to go the printk way you can add printk before each test ring_test, ib_test in r600.c this 2 functions are the own that might trigger the first GPU gart activities. >>> >>> Okay, I found the place in source that triggers this. It happens in the >>> function r600_ib_test. The interesting thing is that not the ib-command >>> itself is responsible but the fence that is emitted afterwards (proved >>> by removing the fence command, where the problem went away). >>> I don't know enough about the command semantics to make a guess what >>> goes wrong there. But maybe you GPU folks have an idea? >>> >> >> I can't think of anything off hand. It might be worth disabling the >> call to r600_ib_test() in r600_init() and then seeing if you get any >> errors when the fences are used later on when X starts or just at that >> point in the module load sequence. What's odd is that when you tested >> radeon.no_wb=1 you got the same behavior as that disables shadowing of >> fence writes to gpu gart mem, so it wouldn't be writing to memory in >> that case. >> >> Alex >> > > It might be the irq ring write that is faulty. That's disabled with no_wb=1 as well. Alex > > Cheers, > Jerome > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Mon, Apr 18, 2011 at 11:23 AM, Alex Deucher wrote: > On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: >> On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: >> >>> If you want to go the printk way you can add printk before each test >>> ring_test, ib_test in r600.c this 2 functions are the own that might >>> trigger the first GPU gart activities. >> >> Okay, I found the place in source that triggers this. It happens in the >> function r600_ib_test. The interesting thing is that not the ib-command >> itself is responsible but the fence that is emitted afterwards (proved >> by removing the fence command, where the problem went away). >> I don't know enough about the command semantics to make a guess what >> goes wrong there. But maybe you GPU folks have an idea? >> > > I can't think of anything off hand. It might be worth disabling the > call to r600_ib_test() in r600_init() and then seeing if you get any > errors when the fences are used later on when X starts or just at that > point in the module load sequence. What's odd is that when you tested > radeon.no_wb=1 you got the same behavior as that disables shadowing of > fence writes to gpu gart mem, so it wouldn't be writing to memory in > that case. > > Alex > It might be the irq ring write that is faulty. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Linux 2.6.39-rc3
On Sun, Apr 17, 2011 at 10:09 AM, Joerg Roedel wrote: > On Sat, Apr 16, 2011 at 02:54:04PM -0400, Jerome Glisse wrote: > >> If you want to go the printk way you can add printk before each test >> ring_test, ib_test in r600.c this 2 functions are the own that might >> trigger the first GPU gart activities. > > Okay, I found the place in source that triggers this. It happens in the > function r600_ib_test. The interesting thing is that not the ib-command > itself is responsible but the fence that is emitted afterwards (proved > by removing the fence command, where the problem went away). > I don't know enough about the command semantics to make a guess what > goes wrong there. But maybe you GPU folks have an idea? > I can't think of anything off hand. It might be worth disabling the call to r600_ib_test() in r600_init() and then seeing if you get any errors when the fences are used later on when X starts or just at that point in the module load sequence. What's odd is that when you tested radeon.no_wb=1 you got the same behavior as that disables shadowing of fence writes to gpu gart mem, so it wouldn't be writing to memory in that case. Alex > Joerg > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Embedded Linux memory management interest group list
Hi all, One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics I am working on getting the key technical decision makers to provide input and participate in the requirements collection and design for a unified solution. We had an initial birds-of-a-feather discussion at the Embedded Linux Conference in San Francisco this past week to kick off the effort in preparation for the first embedded-memory-management mini-sprint in Budapest week of May 9th at Linaro@UDS. One of the outcomes of the BoF was the need for a mailing list to coordinate ideas, planning, etc. The subscription management for the list is located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig. The mini-summit in Budapest will have live audio and an IRC channel for those that want to participate (details to go out on the list). We expect to have additional summits over the course of the cycle, with the next one likely at Linux Plumbers in September (though, I would like to try for one more before then). cheers, Jesse ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Embedded Linux memory management interest group list
Hi all, One of the big issues we've been faced with at Linaro is around GPU and multimedia device integration, in particular the memory management requirements for supporting them on ARM. ?This next cycle, we'll be focusing on driving consensus around a unified memory management solution for embedded systems that support multiple architectures and SoCs. ?This is listed as part of our working set of requirements for the next six-month cycle (in spite of the URL, this is not being treated as a graphics-specific topic - we also have participation from multimedia and kernel working group folks): ? https://wiki.linaro.org/Cycles//TechnicalTopics/Graphics I am working on getting the key technical decision makers to provide input and participate in the requirements collection and design for a unified solution. We had an initial birds-of-a-feather discussion at the Embedded Linux Conference in San Francisco this past week to kick off the effort in preparation for the first embedded-memory-management mini-sprint in Budapest week of May 9th at Linaro at UDS. ?One of the outcomes of the BoF was the need for a mailing list to coordinate ideas, planning, etc. ?The subscription management for the list is located at http://lists.linaro.org/mailman/listinfo/linaro-mm-sig. The mini-summit in Budapest will have live audio and an IRC channel for those that want to participate (details to go out on the list). We expect to have additional summits over the course of the cycle, with the next one likely at Linux Plumbers in September (though, I would like to try for one more before then). cheers, Jesse
[Bug 36318] r600g segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=36318 --- Comment #4 from Ian Milligan 2011-04-18 07:33:20 PDT --- Interesting, I'm using LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH I don't think that is the problem. It's only glxgears having this problem, however, so that problem may be with it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36318] r600g segfaults
https://bugs.freedesktop.org/show_bug.cgi?id=36318 --- Comment #4 from Ian Milligan 2011-04-18 07:33:20 PDT --- Interesting, I'm using LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH I don't think that is the problem. It's only glxgears having this problem, however, so that problem may be with it. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33542] radeon: Don't read BIOS in VRAM on SPARC64
https://bugzilla.kernel.org/show_bug.cgi?id=33542 Jason Detring changed: What|Removed |Added Status|NEW |RESOLVED Resolution||OBSOLETE --- Comment #1 from Jason Detring 2011-04-18 06:47:24 --- Wow, I really messed this report up. I mistakenly copy-and-pasted the wrong kernel version from another Radeon bug I'm toying with. This particular dmesg block and patch was from the drm-2.6 tree, on the master branch (2.6.36-rc6, aka drm-2.6-899611e), which is neither current for the main linux-2.6 tree nor the sundry drm-2.6 staging branches. Oops. The current drm-2.6-e001978 tree seems to bring up a framebuffer console with no patching necessary. There's something wrong with the command processor, so all acceleration is disabled, but that's a topic for another ticket. Closing this ticket, sorry for the noise. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 33392] suspend/resume stopped working
https://bugzilla.kernel.org/show_bug.cgi?id=33392 --- Comment #4 from Sergey Senozhatsky 2011-04-18 13:34:24 --- On (04/17/11 18:08), bugzilla-dae...@bugzilla.kernel.org wrote: > Also please try the current Linus' tree in case the underlying bug has been > fixed already. > Hello, Had some time for testing, and it looks like the problem sits on the X server side. Even .38 (built with gcc-4.5 and gcc-4.6) failed. Sergey -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 --- Comment #8 from Johannes Berg 2011-04-18 12:50:17 --- Actually, that was wrong -- I wasn't booting the kernel I was compiling, 2.6.39-rc3 doesn't work at all, I only get a garbled screen :-( -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26999] _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed
https://bugs.freedesktop.org/show_bug.cgi?id=26999 --- Comment #10 from Peter 2011-04-18 04:11:47 PDT --- Julien, I'm unable to build mesa with provided patch too. Any pointers? Thank you! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26999] _mesa_reference_renderbuffer: Assertion `oldRb->Magic == 0xaabbccdd' failed
https://bugs.freedesktop.org/show_bug.cgi?id=26999 --- Comment #10 from Peter 2011-04-18 04:11:47 PDT --- Julien, I'm unable to build mesa with provided patch too. Any pointers? Thank you! -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 31782] nouveau: lockdep spew
https://bugzilla.kernel.org/show_bug.cgi?id=31782 --- Comment #7 from Johannes Berg 2011-04-18 09:56:16 --- I'm now on 2.6.39-rc3 and while the issue persists, the patch doesn't apply. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Recover DPMS properly after XRandr re-enablement
At Sun, 17 Apr 2011 18:26:54 +0200, Florian Mickler wrote: > > On Wed, 22 Dec 2010 12:53:07 + > Chris Wilson wrote: > > > On Wed, 22 Dec 2010 12:42:32 +, Chris Wilson > > wrote: > > > From: Takashi Iwai > > > > > This patch adds a new helper function to manage the drm_connector > > > DPMS so that it can be called commonly in both places. > > > > > > Signed-off-by: Takashi Iwai > > > > FWIW, > > > > Reviewed-by: Chris Wilson > > > > -Chris > > > > Is this patch still necessary for 2.6.39? Yes, I think so. Takashi > It was needed to fix a regression from 2.6.36 (at least in February). > ( https://bugzilla.kernel.org/show_bug.cgi?id=24982 ) > > Regards, > Flo > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.39-rc1 nouveau regression (bisected)
On Sun, Apr 17, 2011 at 05:45:57PM +0200, Marcin Slusarz wrote: > On Sun, Apr 17, 2011 at 11:12:04AM -0400, Kyle Spaans wrote: > > On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > > > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as > > > > >>> "calm" > > > > >>> to everyone, but then chose to CC Maciej instead: Would you be so > > > > >>> kind and > > > > >>> add this to your regression list? Thanks! > > > > >>> > > > > >>> Since commit 38f1cff > > > > >>> > > > > >>> From: Dave Airlie > > > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > > > >>> Subject: [PATCH] Merge commit > > > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > > > >>> > > > > >>> This commit changed an internal radeon structure, that meant a > > > > >>> new driver > > > > >>> in -next had to be fixed up, merge in the commit and fix up the > > > > >>> driver. > > > > >>> > > > > >>> Also fixes a trivial nouveau merge. > > > > >>> > > > > >>> Conflicts: > > > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > > > >>> > > > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right > > > > >>> after > > > > >>> blanking the screen, and before the initramfs gets loaded. I just > > > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed > > > > >>> work > > > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > > > >>> 85f2e68 ). > > > > >> Can you activate netconsole and check whether kernel spits anything > > > > >> interesting? > > > > >> You might try to load nouveau module after boot - maybe something > > > > >> will be saved > > > > >> to /var/log or you could even ssh into the box and check dmesg... > > > > > Compiling it as a module seems to work fine. When I do so, no > > > > > regression is > > > > > obvious from what gets reported in "dmesg". However, somehow I now do > > > > > get > > > > > some output: The last message I see is > > > > > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > > > pointer value> > > > > > > > > > > Then, nothing more. However, it really is quite strange why this > > > > > error only > > > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > > > causing me an oops at boot, but my bug has been ignored there so far - > > > > perhaps I should have posted it here instead. > > > > > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes > > > before it > > > can write any logs if it's compiled in and the logo is selected, but > > > boots fine > > > if compiled as a module or the logo is removed. > > > > > > In my case I bisected and found 8969960 by Nick Piggin (change to > > > mm/vmalloc.c) > > > to be the first bad one in 2.6.38+. This makes me think that it's not a > > > bug in > > > nouveau, but maybe a bug in the order that things are initialized? > > > > FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on > > 2.6.39-rc3+ > > makes my system boot just fine with the nouveau drivers compiled into the > > kernel. I've seen some similar looking bugs on LKML that this regression > > may or > > may not be related to? It works fine on 2.6.38. > > > > https://bugzilla.kernel.org/show_bug.cgi?id=33272 > > http://lkml.org/lkml/2011/4/15/194 > > > > I'm still trying to figure out exactly where the kernel is crashing after > > printing > > [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 > > > > Any thoughts on what else I should look for? > > I reproduced this bug today, and reverting > 89699605fe7cfd8611900346f61cb6cbf179b10a > does not fix it for me. Here's the backtrace: > > Entering kdb (current=0x8801becb, pid 1) on processor 6 Oops: (null) > due to oops @ 0x81255081 > CPU 6 Modules linked in: > > Pid: 1, comm: swapper Not tainted 2.6.39-rc2-nv+ #640 System > manufacturer System Product Name/P6T SE > RIP: 0010:[] [] iowrite32+0x12/0x34 > RSP: :8801becab4b0 EFLAGS: 00010296 > RAX: RBX: 8801bd334800 RCX: 16fc > RDX: RSI: c900100bbf4c RDI: c900100bbf4c > RBP: 8801becab4b0 R08: 0002 R09: 0001 > R10: 00bb R11: 8801becab540 R12: 8801bd336000 > R13: 8801bd334818 R14: 8801bd60 R15: 0020 > FS: () GS:8801bfd8() > knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: c900100bbf4c CR3: 01a2b000 CR4: 06e0 > DR0: DR1: DR2:
Re: 2.6.39-rc1 nouveau regression (bisected)
On Sat, Apr 16, 2011 at 07:50:28PM -0400, Kyle Spaans wrote: > On Sun, Apr 17, 2011 at 08:12:35AM +1000, Nigel Cunningham wrote: > > On 15/04/11 16:11, Dominik Brodowski wrote: > > > On Thu, Apr 14, 2011 at 09:02:01PM +0200, Marcin Slusarz wrote: > > >> On Thu, Apr 14, 2011 at 07:05:59PM +0200, Dominik Brodowski wrote: > > >>> Thought about CCing Linus to show him that 2.6.39-rcX isn't as "calm" > > >>> to everyone, but then chose to CC Maciej instead: Would you be so kind > > >>> and > > >>> add this to your regression list? Thanks! > > >>> > > >>> Since commit 38f1cff > > >>> > > >>> From: Dave Airlie > > >>> Date: Wed, 16 Mar 2011 11:34:41 +1000 > > >>> Subject: [PATCH] Merge commit > > >>> '5359533801e3dd3abca5b7d3d985b0b33fd9fe8b' into dr > > >>> > > >>> This commit changed an internal radeon structure, that meant a new > > >>> driver > > >>> in -next had to be fixed up, merge in the commit and fix up the > > >>> driver. > > >>> > > >>> Also fixes a trivial nouveau merge. > > >>> > > >>> Conflicts: > > >>> drivers/gpu/drm/nouveau/nouveau_mem.c > > >>> > > >>> booting my atom/NM10/ION2 system crashes hard during boot, right after > > >>> blanking the screen, and before the initramfs gets loaded. I just > > >>> re-checked: both parent commits ( 5359533 and 4819d2e ) do indeed work > > >>> just fine, but the merge commit ( 38f1cff ) fails, same as tip ( > > >>> 85f2e68 ). > > >> Can you activate netconsole and check whether kernel spits anything > > >> interesting? > > >> You might try to load nouveau module after boot - maybe something will > > >> be saved > > >> to /var/log or you could even ssh into the box and check dmesg... > > > Compiling it as a module seems to work fine. When I do so, no regression > > > is > > > obvious from what gets reported in "dmesg". However, somehow I now do get > > > some output: The last message I see is > > > > > > [drm] nouveau :01:00.0: allocated 1680x1050, fb 0x40 b0 > > pointer value> > > > > > > Then, nothing more. However, it really is quite strange why this error > > > only > > > appears in the CONFIG_NOUVEAU=y case, not in the =m case... > > Try disabling CONFIG_BOOT_LOGO. I reported on freedesktop.org that it is > > causing me an oops at boot, but my bug has been ignored there so far - > > perhaps I should have posted it here instead. > > I'm getting the exact same symptoms on my Atom + ION hardware. Crashes before > it > can write any logs if it's compiled in and the logo is selected, but boots > fine > if compiled as a module or the logo is removed. > > In my case I bisected and found 8969960 by Nick Piggin (change to > mm/vmalloc.c) > to be the first bad one in 2.6.38+. This makes me think that it's not a bug in > nouveau, but maybe a bug in the order that things are initialized? FWIW, reverting commit 89699605fe7cfd8611900346f61cb6cbf179b10a on 2.6.39-rc3+ makes my system boot just fine with the nouveau drivers compiled into the kernel. I've seen some similar looking bugs on LKML that this regression may or may not be related to? It works fine on 2.6.38. https://bugzilla.kernel.org/show_bug.cgi?id=33272 http://lkml.org/lkml/2011/4/15/194 I'm still trying to figure out exactly where the kernel is crashing after printing [drm] nouveau :03:00.0: allocated 1280x1024 fb: 0x4000, b0 f4cf7600 Any thoughts on what else I should look for? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33755] System hangs with x-testing and gtkperf tests
https://bugs.freedesktop.org/show_bug.cgi?id=33755 KavithaReddy changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from KavithaReddy 2011-04-18 01:49:24 PDT --- (In reply to comment #3) > Please make sure your kernel has this patch: > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=1e644d6dce366a7bae22484f60133b61ba322911 fixed with the latest build -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33755] System hangs with x-testing and gtkperf tests
https://bugs.freedesktop.org/show_bug.cgi?id=33755 KavithaReddy changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from KavithaReddy 2011-04-18 01:49:24 PDT --- (In reply to comment #3) > Please make sure your kernel has this patch: > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=1e644d6dce366a7bae22484f60133b61ba322911 fixed with the latest build -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] fix mesa tarball creation again
Pushed, thanks. Marek On Sat, Apr 16, 2011 at 10:11 AM, Thierry Vignaud wrote: > Hi > > The following patch fixes mesa tarball creation again > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110418/4510f525/attachment.html>
[Bug 33542] New: radeon: Don't read BIOS in VRAM on SPARC64
https://bugzilla.kernel.org/show_bug.cgi?id=33542
Summary: radeon: Don't read BIOS in VRAM on SPARC64
Product: Drivers
Version: 2.5
Kernel Version: 2.6.39-rc3
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Video(DRI - non Intel)
AssignedTo: drivers_video-dri at kernel-bugs.osdl.org
ReportedBy: detringj at gmail.com
Regression: No
Created an attachment (id=54572)
--> (https://bugzilla.kernel.org/attachment.cgi?id=54572)
DRM and Radeon dmesg block containing kernel panic.
Hi!
Hurray! Radeon KMS works again on SPARC64! Almost.
Test platform is a Sun Ultra 45. Test board is a Sun XVR-300 (RV380
0x1002:0x5B64) on a PCI-e bus.
There's a kernel panic when calling igp_read_bios_from_vram() from
radeon_get_bios(). See attached dmesg capture.
Patching around it with
--- a/drivers/gpu/drm/radeon/radeon_bios.c 2011-04-17 19:31:04.0
-0500
+++ b/drivers/gpu/drm/radeon/radeon_bios.c 2010-09-28 20:01:22.0
-0500
@@ -432,8 +432,10 @@
uint16_t tmp;
r = radeon_atrm_get_bios(rdev);
+#if !defined(__sparc__)
if (r == false)
r = igp_read_bios_from_vram(rdev);
+#endif /* !__sparc__ */
if (r == false)
r = radeon_read_bios(rdev);
if (r == false) {
gives me a framebuffer console again. After which, the usual desktop stack
works as well (X11, mesa, textured video).
I'm not sure this is the correct way to code the fix, stylistically speaking.
Although I don't know of any sparc64 machines sporting a Radeon IGP, I'm sure
it could happen someday. It also seems other architectures might run into this
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.
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
--
___
Dri-devel mailing list
Dri-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
