[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #3 from Eugene Shalygin --- With "glamor" as acceleration method, these crashes are much more rare -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130224/a8e03a7f/attachment.html>
[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 --- Comment #3 from Alex Deucher 2013-02-24 23:14:49 --- (In reply to comment #2) > That explains why the 3 monitor setup works, but 2 monitors plus a projector > don't: two of the monitors are the same. Interestingly enough, it works > completely fine for any kernel < 3.7.0. I have been using this setup since at > least a year or so and never had any problems with 3 different display units > (until 3.7.0). Considering what you said that confuses me, since it shouldn't > have worked as problem-free as it did, should it? It probably worked by accident previously. Presumably the pixel clocks on the two monitors that were sharing a PLL were close enough that the monitors were ok with it. What modes are you running on the two monitors and projector? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
Re: [PATCH v4 6/9] drm/tegra: Implement page-flipping support
On Fri, Feb 22, 2013 at 05:13:47PM +0100, Mario Kleiner wrote:
> On 02/21/2013 03:35 PM, Thierry Reding wrote:
> >All the necessary support bits like .mode_set_base() and VBLANK are now
> >available, so page-flipping case easily be implemented on top.
> >
> >Signed-off-by: Thierry Reding
> >---
> >Changes in v3:
> >- use drm_send_vblank_event()
> >- set crtc->fb field
> >
> >Changes in v4:
> >- fix a potential race by checking that a framebuffer base has been
> > latched when completing a page-flip
> >
> > drivers/gpu/drm/tegra/dc.c | 66
> > +
> > drivers/gpu/drm/tegra/dc.h | 2 ++
> > drivers/gpu/drm/tegra/drm.c | 9 +++
> > drivers/gpu/drm/tegra/drm.h | 5
> > 4 files changed, 82 insertions(+)
> >
> >diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
> >index 5f55a25..c5d825f 100644
> >--- a/drivers/gpu/drm/tegra/dc.c
> >+++ b/drivers/gpu/drm/tegra/dc.c
> >@@ -183,7 +183,72 @@ void tegra_dc_disable_vblank(struct tegra_dc *dc)
> > spin_unlock_irqrestore(&dc->lock, flags);
> > }
> >+static void tegra_dc_finish_page_flip(struct tegra_dc *dc)
> >+{
> >+struct drm_device *drm = dc->base.dev;
> >+struct drm_crtc *crtc = &dc->base;
> >+struct drm_gem_cma_object *gem;
> >+unsigned long flags, base;
> >+
>
> The checks for properly latched scanout look good to me and should
> fix the race between software and hardware. But shouldn't you
> already spin_lock_irqsave() here, before checking dc->event and
> performing write access on the DC_CMD_STATE_ACCESS registers? And
> lock around most of the tegra_dc_page_flip() code below, like in
> your previous iteration of the patch, to prevent a race between
> pageflip ioctl and the vblank irq handler?
Currently there's nothing else that touches the DC_CMD_STATE_ACCESS
register, so that part should be safe.
As to the locking that I removed since the previous patch, I looked at
it more closely and didn't think it was necessary. Also nothing in my
tests seemed to point to any race here, though I probably didn't cover
everything.
> >+if (!dc->event)
>
> -> !dc->event may exit prematurely because the irq handler on one
> core doesn't notice the new setup of dc->event by
> tegra_dc_page_flip() on a different core? Don't know if that can
> happen, don't know the memory ordering of arm, but could imagine
> that this or the compiler reordering instructions could cause
> trouble without lock protection.
I'm not sure I follow here. If the handler sees a NULL here, why would
it want to continue? It can safely assume that the page flip wasn't
setup for this interval, can't it?
If indeed the VBLANK interrupt happens exactly around the assignment to
dc->event, then we'll just schedule the page-flip for the next VBLANK.
> >+return;
> >+
> >+gem = drm_fb_cma_get_gem_obj(crtc->fb, 0);
> -> crtc->fb gets updated in tegra_dc_page_flip() after
> tegra_dc_set_base() without lock -> possibly stale fb here?
Good point. That may indeed require a lock. I'll need to look more
closely.
> >+/* check if new start address has been latched */
> >+tegra_dc_writel(dc, READ_MUX, DC_CMD_STATE_ACCESS);
> >+base = tegra_dc_readl(dc, DC_WINBUF_START_ADDR);
> >+tegra_dc_writel(dc, 0, DC_CMD_STATE_ACCESS);
> >+
>
> -> Can other code in the driver write to DC_CMD_STATE_ACCESS,
> simultaneously to tegra_dc_page_flip writing->reading->writing and
> cause trouble?
This is the only location where the DC_CMD_STATE_ACCESS register is
actually used in the driver so we should be safe for now.
> >+static int tegra_dc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer
> >*fb,
> >+ struct drm_pending_vblank_event *event)
> >+{
> >+struct tegra_dc *dc = to_tegra_dc(crtc);
> >+struct drm_device *drm = crtc->dev;
> >+
> >+if (dc->event)
> >+return -EBUSY;
> >+
>
> -> Lock already here?
>
> >+if (event) {
> >+event->pipe = dc->pipe;
> >+dc->event = event;
> >+drm_vblank_get(drm, dc->pipe);
> >+}
> >+
> >+tegra_dc_set_base(dc, 0, 0, fb);
> >+crtc->fb = fb;
> >+
>
> -> Unlock here?
I tried to expand the lock after we discussed this previously but it
caused the code to deadlock. While in the process of tracking it down I
decided that the lock wasn't actually required at all.
But I hadn't thought about the stale FB issue, so I'll check again. I
notice that Dave has already merged this series, so if nobody objects
I'll fix it up in a follow-up patch.
Thierry
pgpbwC8VcJ2XU.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: resume fails to light display on Macbook Pro Retina on 3.8-rc1
On Mon, Feb 25, 2013 at 4:06 PM, Dave Airlie wrote: > On Mon, Feb 25, 2013 at 3:52 PM, Greg KH wrote: >> Hi Ben, >> >> My Macbook Pro Retina fails to resume properly on 3.8. I tracked this >> down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp: >> move link training helpers into core as display methods) >> >> Anything I can try to help solve this? >> >> Note, I'm using the Intel driver as the main controller for this laptop, >> well, I think I am, my xorg log is attached. > > No you are using the nvidia, the efi always boots nvidia enabled now. > > Cool, might have to lend Ben my retina to see if he can reproduce. btw I just tested my drm-next tree on mine and it resumed the display fine, something oopsed a few seconds later that I haven't tracked down git://git.freedesktop.org/~airlied/linux drm-next I'll be sending it to Linus this evening or tomorrow morning, once I fix my tree. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: resume fails to light display on Macbook Pro Retina on 3.8-rc1
On Mon, Feb 25, 2013 at 3:52 PM, Greg KH wrote: > Hi Ben, > > My Macbook Pro Retina fails to resume properly on 3.8. I tracked this > down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp: > move link training helpers into core as display methods) > > Anything I can try to help solve this? > > Note, I'm using the Intel driver as the main controller for this laptop, > well, I think I am, my xorg log is attached. No you are using the nvidia, the efi always boots nvidia enabled now. Cool, might have to lend Ben my retina to see if he can reproduce. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
resume fails to light display on Macbook Pro Retina on 3.8-rc1
Hi Ben,
My Macbook Pro Retina fails to resume properly on 3.8. I tracked this
down to commit 6c5a04249d7afeea3e0ed971e7813f84e29a1706 (drm/nvd0/disp:
move link training helpers into core as display methods)
Anything I can try to help solve this?
Note, I'm using the Intel driver as the main controller for this laptop,
well, I think I am, my xorg log is attached.
And sorry for not reporting this sooner, it took me a long time to
bisect down, there were other resume and boot issues on the bisect trail
leading to this, the full log is below.
thanks,
greg k-h
git bisect start
# good: [29594404d7fe73cd80eaa4ee8c43dcc53970c60e] Linux 3.7
git bisect good 29594404d7fe73cd80eaa4ee8c43dcc53970c60e
# bad: [19f949f52599ba7c3f67a5897ac6be14bfcb1200] Linux 3.8
git bisect bad 19f949f52599ba7c3f67a5897ac6be14bfcb1200
# good: [dadfab4873256d2145640c0ce468fcbfb48977fe] Merge tag 'firewire-updates'
of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394
git bisect good dadfab4873256d2145640c0ce468fcbfb48977fe
# bad: [992956189de58cae9f2be40585bc25105cd7c5ad] efi: Fix the build with user
namespaces enabled.
git bisect bad 992956189de58cae9f2be40585bc25105cd7c5ad
# skip: [2b8318881ddbcb67c5e8d2178b4228474944] Merge tag 'fbdev-for-3.8' of
git://gitorious.org/linux-omap-dss2/linux
git bisect skip 2b8318881ddbcb67c5e8d2178b4228474944
# good: [da22f22e91f0d14d996c7258101575a5a06ddf85] ssb: add
ssb_chipco_gpio_pull{up,down}
git bisect good da22f22e91f0d14d996c7258101575a5a06ddf85
# good: [bb523fc08d4a4a726c7555be7800735685888b3c] drm/i915: convert
PIPE_CLK_SEL to transcoder
git bisect good bb523fc08d4a4a726c7555be7800735685888b3c
# good: [d3e4ea017a414a19ab11a10b52e80a0c8b3f1670] [media] em28xx-cards: fix a
warning
git bisect good d3e4ea017a414a19ab11a10b52e80a0c8b3f1670
# good: [3fcb6eb4063ab4eef05601c266afa2af667c8e1f] video: exynos_dp: remove
redundant parameters
git bisect good 3fcb6eb4063ab4eef05601c266afa2af667c8e1f
# good: [c5b005ab7091c9ef4ca9b47569a8e27e54588933] drbd: use bitmap_parse
instead of __bitmap_parse
git bisect good c5b005ab7091c9ef4ca9b47569a8e27e54588933
# skip: [c13e69b2f0e1e2da41a175c7e9215659842cbef9] Merge tag 'upstream-linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev
git bisect skip c13e69b2f0e1e2da41a175c7e9215659842cbef9
# good: [c8241969b44438c9335b59d375b627214bc36483] drm/i915: pass adjusted_mode
to intel_choose_pipe_bpp_dither(), again
git bisect good c8241969b44438c9335b59d375b627214bc36483
# skip: [c5258190c2ae664cdf367417a2a25e5fa4104322] Merge branch 'next' of
git://git.monstr.eu/linux-2.6-microblaze
git bisect skip c5258190c2ae664cdf367417a2a25e5fa4104322
# good: [24ebb37e6515d999bb27f5f8de6ff30faa7479f5] HID: i2c-hid: change I2C name
git bisect good 24ebb37e6515d999bb27f5f8de6ff30faa7479f5
# good: [189e11731aa858597095fbe1e6d243bad26bd96b] x86: pvclock: add note about
rdtsc barriers
git bisect good 189e11731aa858597095fbe1e6d243bad26bd96b
# skip: [75e300c8ba5864367634d946c729d8fd05c1cbc2] Merge tag 'for-v3.8' of
git://git.infradead.org/users/cbou/linux-pstore
git bisect skip 75e300c8ba5864367634d946c729d8fd05c1cbc2
# good: [08ff32352d6ff7083533dc1c25618d42f92ec28e] mlx4: 64-byte CQE/EQE support
git bisect good 08ff32352d6ff7083533dc1c25618d42f92ec28e
# skip: [e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f] Merge branch 'for-next' of
git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds
git bisect skip e81d372ff9f694e13fa46e8b5aaed505c7fd2a1f
# good: [fc8d7547b1e19e1bb8f3206837ee0c7c6538e2e5] RDMA/nes: Fix for sending
fpdus in order to hardware
git bisect good fc8d7547b1e19e1bb8f3206837ee0c7c6538e2e5
# good: [4247bfe20ab1cb8cf1874b811c0dc60bcd0249e8] Merge remote-tracking branch
'regulator/topic/stub' into regulator-next
git bisect good 4247bfe20ab1cb8cf1874b811c0dc60bcd0249e8
# good: [5028ea04c8a8a67fe73f18f5f34386730c9c1bf2] OMAPDSS: Remove acb and acbi
fields from omap_dss_device
git bisect good 5028ea04c8a8a67fe73f18f5f34386730c9c1bf2
# good: [986836503e49ccf7e84b813715d344964ec93566] Merge branch 'drbd-8.4_ed6'
into for-3.8-drivers-drbd-8.4_ed6
git bisect good 986836503e49ccf7e84b813715d344964ec93566
# bad: [9add1ac3dd256ad12e266f8403daf928be19953f] Merge branch 'drm-next-3.8'
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect bad 9add1ac3dd256ad12e266f8403daf928be19953f
# good: [1f2285d462c02ef9b82ee9c553a31884c23994f0] drm/nouveau/clk: fix crystal
frequency retrieval on nv25
git bisect good 1f2285d462c02ef9b82ee9c553a31884c23994f0
# bad: [bd3b49f25a3eae2d91432247b7565489120b6bcf] drm: tegra: Add maintainers
entry
git bisect bad bd3b49f25a3eae2d91432247b7565489120b6bcf
# bad: [6c8e4633d351f6f794c8a5c03f19e8d5a25f9639] drm/nouveau/dp: move core
link training calls to common code
git bisect bad 6c8e4633d351f6f794c8a5c03f19e8d5a25f9639
# good: [b6caea505879c4a606cf364442fd1f06f6c40e30] drm/nouveau/bios: implement
BIT 'U' table (and subtable) parsing in core
git bisect good b6caea505879c4a606
[Bug 61386] i855 GPU hang with AoE2 under Wine
https://bugs.freedesktop.org/show_bug.cgi?id=61386 --- Comment #3 from Bruno --- Created attachment 75452 --> https://bugs.freedesktop.org/attachment.cgi?id=75452&action=edit Second error_state Sole console output from wine: fixme:system:SystemParametersInfoW Unimplemented action: 110 (SPI_GETSHOWIMEUI) intel_do_flush_locked failed: Input/output error -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130224/ef212c60/attachment.html>
[Bug 61419] r600g: No OpenGL Core 3.1 available on Cayman
https://bugs.freedesktop.org/show_bug.cgi?id=61419 Alexandre Demers changed: What|Removed |Added Hardware|Other |All -- 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 61419] New: r600g: No OpenGL Core 3.1 available on Cayman
https://bugs.freedesktop.org/show_bug.cgi?id=61419 Priority: medium Bug ID: 61419 Assignee: dri-devel@lists.freedesktop.org Summary: r600g: No OpenGL Core 3.1 available on Cayman Severity: normal Classification: Unclassified OS: All Reporter: alexandre.f.dem...@gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 75469 --> https://bugs.freedesktop.org/attachment.cgi?id=75469&action=edit glxinfo, no OpenGL Core 3.1 According to docs/GL3.txt, it should be possible to create an OpenGL Core 3.1. Latest glxinfo doesn't report it. GL_ARB_texture_buffer_object is not reported. GL_ARB_uniform_buffer_object is reported. If I understand correctly, without TBO extension, there is no GLSL 1.40 and thus no OpenGL Core 3.1. -- 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 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #49 from Alexandre Demers --- What if the problem is not from this code, but underneath? I'll try to suspend and resume without having Xorg running. Would that help in any way? -- 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 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 Sebastian Rose changed: What|Removed |Added Kernel Version|3.7.2 and up|3.7.0 and up -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 --- Comment #2 from Sebastian Rose 2013-02-24 16:57:38 --- That explains why the 3 monitor setup works, but 2 monitors plus a projector don't: two of the monitors are the same. Interestingly enough, it works completely fine for any kernel < 3.7.0. I have been using this setup since at least a year or so and never had any problems with 3 different display units (until 3.7.0). Considering what you said that confuses me, since it shouldn't have worked as problem-free as it did, should it? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130224/20697152/attachment.html>
[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher 2013-02-24 16:27:18 --- This is a hardware limitation. The hardware only has 2 PLLs for non-DisplayPort monitors. As such, the driver only supports 2 independent pixel clocks on non-DisplayPort monitors. If you have more than 2 non-DP monitors, it will only work if several of them share the same pixel clock (i.e., the monitors sharing a PLL have to display the same mode with the same pixel clock). Older kernels did not properly warn about exceeding these limitations. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #3 from Eugene Shalygin --- With "glamor" as acceleration method, these crashes are much more rare -- 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 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 --- Comment #3 from Alex Deucher 2013-02-24 23:14:49 --- (In reply to comment #2) > That explains why the 3 monitor setup works, but 2 monitors plus a projector > don't: two of the monitors are the same. Interestingly enough, it works > completely fine for any kernel < 3.7.0. I have been using this setup since at > least a year or so and never had any problems with 3 different display units > (until 3.7.0). Considering what you said that confuses me, since it shouldn't > have worked as problem-free as it did, should it? It probably worked by accident previously. Presumably the pixel clocks on the two monitors that were sharing a PLL were close enough that the monitors were ok with it. What modes are you running on the two monitors and projector? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54381] New: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 Summary: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL Product: Drivers Version: 2.5 Kernel Version: 3.7.2 and up 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: rose at semkath.de Regression: No I'm running a 3 monitor setup with a Radeon HD graphics card [Radeon HD 6000 Series]. I'm not using the proprietary drivers. Connectors are: 2 DVI and 1 HDMI. When I change the second DVI connection from a monitor to a projector and try to set the correct resolution (1920x1080) it fails with the following error message: [15189.014994] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL [15189.015008] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:12] It changes the resolution but there are black areas at the sides and at the bottom of the displayed picture. It only happens if I connect the projector, not when the usual monitor is connected. This problem does not exist with kernel version 3.6.11. $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux semkath-desktop 3.8.0 #1 SMP PREEMPT Wed Feb 20 18:31:08 CET 2013 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux Gnu C 4.7.2 Gnu make 3.82 binutils 2.23.1 util-linux 2.22.2 mount debug module-init-tools 12 e2fsprogs 1.42.6 Linux C Library2.16 Dynamic linker (ldd) 2.16 Procps UNKNOWN Net-tools 1.60_p20120127084908 Kbd1.15.5 Sh-utils 8.21 Modules Loaded snd_aloop kvm_amd firewire_ohci k10temp i2c_piix4 firewire_core -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH 1/2] drivers/gpu/drm/tilcdc/tilcdc_drv.c: adjust duplicate test
From: Julia Lawall
Delete successive tests to the same location.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@s exists@
local idexpression y;
expression x,e;
@@
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
... when != \(y = e\|y += e\|y -= e\|y |= e\|y &= e\|y++\|y--\|&y\)
*if ( \(x == NULL\|IS_ERR(x)\|y != 0\) )
{ ... when forall
return ...; }
//
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index c5b592d..3ad0a63 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -192,7 +192,7 @@ static int tilcdc_load(struct drm_device *dev, unsigned
long flags)
}
priv->disp_clk = clk_get(dev->dev, "dpll_disp_ck");
- if (IS_ERR(priv->clk)) {
+ if (IS_ERR(priv->disp_clk)) {
dev_err(dev->dev, "failed to get display clock\n");
ret = -ENODEV;
goto fail;
[Bug 61386] i855 GPU hang with AoE2 under Wine
https://bugs.freedesktop.org/show_bug.cgi?id=61386 --- Comment #3 from Bruno --- Created attachment 75452 --> https://bugs.freedesktop.org/attachment.cgi?id=75452&action=edit Second error_state Sole console output from wine: fixme:system:SystemParametersInfoW Unimplemented action: 110 (SPI_GETSHOWIMEUI) intel_do_flush_locked failed: Input/output error -- 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 61386] i855 GPU hang with AoE2 under Wine
https://bugs.freedesktop.org/show_bug.cgi?id=61386 Chris Wilson changed: What|Removed |Added Assignee|chris at chris-wilson.co.uk|dri-devel at lists.freedesktop ||.org QA Contact|intel-gfx-bugs at lists.freede | |sktop.org | Product|xorg|Mesa Component|Driver/intel|Drivers/DRI/i830 --- Comment #2 from Chris Wilson --- Slightly puzzling. Is the hang always the same? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130224/c701c83f/attachment-0001.html>
[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 Sebastian Rose changed: What|Removed |Added Kernel Version|3.7.2 and up|3.7.0 and up -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 --- Comment #2 from Sebastian Rose 2013-02-24 16:57:38 --- That explains why the 3 monitor setup works, but 2 monitors plus a projector don't: two of the monitors are the same. Interestingly enough, it works completely fine for any kernel < 3.7.0. I have been using this setup since at least a year or so and never had any problems with 3 different display units (until 3.7.0). Considering what you said that confuses me, since it shouldn't have worked as problem-free as it did, should it? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 58354] [bisected] r600g: use DMA engine for VM page table updates on cayman locks in Unigine Tropics
https://bugs.freedesktop.org/show_bug.cgi?id=58354 Alex Deucher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- 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 54381] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher 2013-02-24 16:27:18 --- This is a hardware limitation. The hardware only has 2 PLLs for non-DisplayPort monitors. As such, the driver only supports 2 independent pixel clocks on non-DisplayPort monitors. If you have more than 2 non-DP monitors, it will only work if several of them share the same pixel clock (i.e., the monitors sharing a PLL have to display the same mode with the same pixel clock). Older kernels did not properly warn about exceeding these limitations. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #75 from Myckel Habets --- (In reply to comment #72) > (In reply to comment #71) > > (In reply to comment #69) > > > I went ahead and pushed a split up version of attachment 75373 [details] > > > [review] [review] > > > [review] to mesa: > > > http://cgit.freedesktop.org/mesa/mesa/commit/ > > > ?id=7ebf83f109db9dde89830d5844107c936cf42e4d > > > http://cgit.freedesktop.org/mesa/mesa/commit/ > > > ?id=8442b67f5f3aedbfdb4446164dd09d4eaeda4888 > > > 9.1 is supposed to be released today and even if the patch isn't perfect > > > for > > > everyone yet, it's a lot better than it was before. I'll keep this bug > > > open > > > and we can continue to work on this until we get it nailed. > > > > That was quick - I've only just got to try with etqw and with v5 it quickly > > causes a GPU reset. > > On vanilla master now. Can still get etqw to provoke a gpu reset but it > seems like it's the initial use of the text console when on the main screen > that provokes it. If I avoid using it then I can run without locks. I'm also on vanilla master now, just got a lock up on open arena (after ~40 min). I'm trying Eriks patch again, because I yet have to get it to lock up with that one (after ~2h of playing). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130224/c5f85bca/attachment.html>
[Bug 54381] New: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL
https://bugzilla.kernel.org/show_bug.cgi?id=54381 Summary: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL Product: Drivers Version: 2.5 Kernel Version: 3.7.2 and up 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: r...@semkath.de Regression: No I'm running a 3 monitor setup with a Radeon HD graphics card [Radeon HD 6000 Series]. I'm not using the proprietary drivers. Connectors are: 2 DVI and 1 HDMI. When I change the second DVI connection from a monitor to a projector and try to set the correct resolution (1920x1080) it fails with the following error message: [15189.014994] [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL [15189.015008] [drm:drm_crtc_helper_set_config] *ERROR* failed to set mode on [CRTC:12] It changes the resolution but there are black areas at the sides and at the bottom of the displayed picture. It only happens if I connect the projector, not when the usual monitor is connected. This problem does not exist with kernel version 3.6.11. $ scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux semkath-desktop 3.8.0 #1 SMP PREEMPT Wed Feb 20 18:31:08 CET 2013 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux Gnu C 4.7.2 Gnu make 3.82 binutils 2.23.1 util-linux 2.22.2 mount debug module-init-tools 12 e2fsprogs 1.42.6 Linux C Library2.16 Dynamic linker (ldd) 2.16 Procps UNKNOWN Net-tools 1.60_p20120127084908 Kbd1.15.5 Sh-utils 8.21 Modules Loaded snd_aloop kvm_amd firewire_ohci k10temp i2c_piix4 firewire_core -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (boot/grub2 and suspend/resume) (CAYMAN)
https://bugs.freedesktop.org/show_bug.cgi?id=56139 --- Comment #48 from Alexandre Demers --- (In reply to comment #47) > A patch referencing this bug report has been merged in Linux v3.8-rc7: > > commit ed39fadd6df01095378e499fac3674883f16b853 > Author: Alex Deucher > Date: Thu Jan 31 09:00:52 2013 -0500 > > drm/radeon/evergreen+: wait for the MC to settle after MC blackout Still not fixed with 3.8.0 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130224/8aeae970/attachment.html>
[Bug 61386] i855 GPU hang with AoE2 under Wine
https://bugs.freedesktop.org/show_bug.cgi?id=61386 Chris Wilson changed: What|Removed |Added Assignee|ch...@chris-wilson.co.uk|dri-devel@lists.freedesktop ||.org QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Product|xorg|Mesa Component|Driver/intel|Drivers/DRI/i830 --- Comment #2 from Chris Wilson --- Slightly puzzling. Is the hang always the same? -- 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 50655] ATI RV670 [Radeon HD 3870] Ioquake games causes GPU lockup (waiting for 0x00003039 last fence id 0x00003030)
https://bugs.freedesktop.org/show_bug.cgi?id=50655 --- Comment #75 from Myckel Habets --- (In reply to comment #72) > (In reply to comment #71) > > (In reply to comment #69) > > > I went ahead and pushed a split up version of attachment 75373 [details] > > > [review] [review] > > > [review] to mesa: > > > http://cgit.freedesktop.org/mesa/mesa/commit/ > > > ?id=7ebf83f109db9dde89830d5844107c936cf42e4d > > > http://cgit.freedesktop.org/mesa/mesa/commit/ > > > ?id=8442b67f5f3aedbfdb4446164dd09d4eaeda4888 > > > 9.1 is supposed to be released today and even if the patch isn't perfect > > > for > > > everyone yet, it's a lot better than it was before. I'll keep this bug > > > open > > > and we can continue to work on this until we get it nailed. > > > > That was quick - I've only just got to try with etqw and with v5 it quickly > > causes a GPU reset. > > On vanilla master now. Can still get etqw to provoke a gpu reset but it > seems like it's the initial use of the text console when on the main screen > that provokes it. If I avoid using it then I can run without locks. I'm also on vanilla master now, just got a lock up on open arena (after ~40 min). I'm trying Eriks patch again, because I yet have to get it to lock up with that one (after ~2h of playing). -- 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
