Re: [PATCH 3.3-rc3] drm/i915: Fixes distorted external screen image on HP 2730p
On Sun, Feb 12, 2012 at 11:10:32AM +0100, p...@haerkules.de wrote: > From: Philipp Grete > > Fixes LP: #796030 by removing forced pipe A on HP 2730p. > Quirk has previously been introduced to fix a sleep mode problem that does > not exist any more. > > Signed-off-by: Philipp Grete > --- > Fix has been confirmed by at least three people (see > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030) who didn't > experience any sleep mode problems after applying the patch. Can you please supply the corresponding tested-bys for these three people? I.e. add Tested-by: Name to the sob part of your commit message. Also please add a reference to the LP as a full link (easier to handle for people outside of the ubuntu universe): Bugzilla: http://launchpad/direct/link/to/bug Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Ignore LVDS on hp t5745 and hp st5747 thin client
On Thu, Feb 09, 2012 at 09:35:21AM -0500, Marc Gariepy wrote: > Add a no_lvds quirk for the HP t5745 and HP st5747 thin clients > > dmidecode for those thin clients are attached in thoses bugs: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916 > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920 > > > Signed-off-by: Marc Gariepy Adam, can I have your ack on this? Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
On Fri, Feb 10, 2012 at 12:50:01PM -0500, Yufeng Shen wrote: > GMBUS has several ports and each has it's own corresponding > I2C adpater. When multiple I2C adapters call gmbus_xfer() at > the same time there is a race condition in using the underlying > GMBUS controller. Fixing this by adding a mutex lock when calling > gmbus_xfer(). > > Signed-off-by: Yufeng Shen I do not see the race. All the i2c transfers should be protected correctly by the i2c core, or else I think we haven't registered our device properly. Could you give an example of when/how this can happen? Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Fix spelling in comments.
Dear Kristof, Am Samstag, den 11.02.2012, 15:04 +0100 schrieb Kristof Ralovich: > Dear All, > > attached is the patch. please only send inlined patches. You can use `git send-email` for that. > From 87b2ba50ca33b85fae58e85cd51ba7515bceb81b Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?"RALOVICH,=20Krist=C3=B3f"?= > Date: Sat, 11 Feb 2012 15:00:49 +0100 > Subject: [PATCH] Fix spelling in comments. Your Signed-off-by line is missing. Please also prepend the commit summary with the subsystem. > --- > xf86drmMode.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xf86drmMode.h b/xf86drmMode.h > index 34f5fb1..febf88a 100644 > --- a/xf86drmMode.h > +++ b/xf86drmMode.h > @@ -333,7 +333,7 @@ extern int drmModeAddFB2(int fd, uint32_t width, uint32_t > height, > uint32_t pitches[4], uint32_t offsets[4], > uint32_t *buf_id, uint32_t flags); > /** > - * Destroies the given framebuffer. > + * Destroys the given framebuffer. > */ > extern int drmModeRmFB(int fd, uint32_t bufferId); > > @@ -349,7 +349,7 @@ extern int drmModeDirtyFB(int fd, uint32_t bufferId, > */ > > /** > - * Retrive information about the ctrt crtcId > + * Retrive information about the crtc crtcId Could you also change Retri*e*ve please? > */ > extern drmModeCrtcPtr drmModeGetCrtc(int fd, uint32_t crtcId); Please resend as [PATCH v2]. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45984] New: Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 Bug #: 45984 Summary: Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch. Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hysv...@gmail.com Created attachment 56951 --> https://bugs.freedesktop.org/attachment.cgi?id=56951 dmesg Driver Stack Details: = 1)Kernel-3.0.0-12-generice-pae 2)drm-2.4.31 3)Mesa-8.0-devel (git-a7750c9) 4)Xorg-server-1.11.0 5)xf86-video-ati- master System Environment: === Asic : NI SeymourXT O.S. : Ubuntu-11.10 (64 bit) Processor: AMD Athlon(tm) 64 X2 @ 1000 MHz Memory : 2 GB Steps to Reproduce: === 1) Install piglit from git clone git://anongit.freedesktop.org/git/piglit 2) Run ./piglit-run.py tests/r600.tests results/r600.results Observation : = Xserver crashes with segmentation fault after few seconds of r600.tests launch. -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #1 from samit vats 2012-02-13 02:54:21 PST --- Created attachment 56952 --> https://bugs.freedesktop.org/attachment.cgi?id=56952 r600_results -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #2 from samit vats 2012-02-13 02:55:09 PST --- Created attachment 56953 --> https://bugs.freedesktop.org/attachment.cgi?id=56953 backtrace -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #3 from samit vats 2012-02-13 02:55:58 PST --- Created attachment 56954 --> https://bugs.freedesktop.org/attachment.cgi?id=56954 Xorg.log -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #4 from samit vats 2012-02-13 02:57:07 PST --- Created attachment 56955 --> https://bugs.freedesktop.org/attachment.cgi?id=56955 glxinfo -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 samit vats changed: What|Removed |Added Priority|medium |high -- 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/radeon/kms: drop lock in return path of radeon_fence_count_emitted.
From: Dave Airlie
Reported-by: Mikko Vinni
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_fence.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 64ea3dd..4bd36a3 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -364,8 +364,10 @@ int radeon_fence_count_emitted(struct radeon_device *rdev,
int ring)
int not_processed = 0;
read_lock_irqsave(&rdev->fence_lock, irq_flags);
- if (!rdev->fence_drv[ring].initialized)
+ if (!rdev->fence_drv[ring].initialized) {
+ read_unlock_irqrestore(&rdev->fence_lock, irq_flags);
return 0;
+ }
if (!list_empty(&rdev->fence_drv[ring].emitted)) {
struct list_head *ptr;
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bisected regression] Re: scheduling while atomic on radeon rv620, kernel 3.30-rc3
On Sun, Feb 12, 2012 at 5:20 PM, Mikko Vinni wrote: > Hi again, > > I bisected this problem to: > > 47492a23a128e953bd5087b1cac909cd8124ca5e is the first bad commit > commit 47492a23a128e953bd5087b1cac909cd8124ca5e > Author: Christian König > Date: Thu Oct 20 12:38:09 2011 +0200 > > drm/radeon: add radeon_fence_count_emited function > > Split counting of emited fences out of power > management into a seperate function. > > Signed-off-by: Christian König > Reviewed-by: Jerome Glisse > Signed-off-by: Dave Airlie > > :04 04 adbb5199d8ee03a75f65b9ddf6b1d398acfca4d9 > 67b8d0bfdd5507d82b0c8d8f500f32d140520f0d M drivers > > > > That patch (part of it below) moves code into a new function and perhaps > changes > locking a bit. Is the return in the middle ok? I've just posted a patch to fix that to dri-devel, can you check it fixes your issue? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #1 from Alex Deucher 2012-02-13 05:27:57 PST --- Please attach your xorg log, dmesg output, and xrandr --verbose output. -- 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
Re: [PATCH] Fix spelling in comments.
while you are at it, "retrive" [sic] should be "retrieve" On Sat, 11 Feb 2012, Kristof Ralovich wrote: Dear All, attached is the patch. Kristof ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms/atom: bios scratch reg handling updates
From: Alex Deucher
- Add missing DFP6 connection state handling
- crtc routing bits not used on DCE4+
Noticed by sylware on phoronix.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index a9ce094..8577824 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2981,6 +2981,20 @@ radeon_atombios_connected_scratch_regs(struct
drm_connector *connector,
bios_6_scratch &= ~ATOM_S6_ACC_REQ_DFP5;
}
}
+ if ((radeon_encoder->devices & ATOM_DEVICE_DFP6_SUPPORT) &&
+ (radeon_connector->devices & ATOM_DEVICE_DFP6_SUPPORT)) {
+ if (connected) {
+ DRM_DEBUG_KMS("DFP6 connected\n");
+ bios_0_scratch |= ATOM_S0_DFP6;
+ bios_3_scratch |= ATOM_S3_DFP6_ACTIVE;
+ bios_6_scratch |= ATOM_S6_ACC_REQ_DFP6;
+ } else {
+ DRM_DEBUG_KMS("DFP6 disconnected\n");
+ bios_0_scratch &= ~ATOM_S0_DFP6;
+ bios_3_scratch &= ~ATOM_S3_DFP6_ACTIVE;
+ bios_6_scratch &= ~ATOM_S6_ACC_REQ_DFP6;
+ }
+ }
if (rdev->family >= CHIP_R600) {
WREG32(R600_BIOS_0_SCRATCH, bios_0_scratch);
@@ -3001,6 +3015,9 @@ radeon_atombios_encoder_crtc_scratch_regs(struct
drm_encoder *encoder, int crtc)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
uint32_t bios_3_scratch;
+ if (ASIC_IS_DCE4(rdev))
+ return;
+
if (rdev->family >= CHIP_R600)
bios_3_scratch = RREG32(R600_BIOS_3_SCRATCH);
else
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45993] New: r300: SIGSEGV when trying to open a WebGL page with Firefox 10
https://bugs.freedesktop.org/show_bug.cgi?id=45993 Bug #: 45993 Summary: r300: SIGSEGV when trying to open a WebGL page with Firefox 10 Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: grsf...@tiscali.it Created attachment 56967 --> https://bugs.freedesktop.org/attachment.cgi?id=56967 Backtrace of the crash When trying to open a WebGL enabled page such as http://get.webgl.org Firefox instantly crashes. When setting the LIBGL_DEBUG environment variable to "verbose", the following message is seen on the terminal: radeon: Cannot get a relocation in radeon_drm_cs_write_reloc. System specs: CPU: AMD Athlon 64 FX-55 GPU: ATI Technologies Inc R420 JP [Radeon X800XT] OS: Slackware64 13.37 kernel: 3.2.5 (vanilla) Mesa git snapshot @ 2012-02-11 libdrm-2.4.31 Mozilla Firefox 10.0.1 x86_64 -- 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 34096] r300: Cannot get a relocation in radeon_drm_cs_write_reloc.
https://bugs.freedesktop.org/show_bug.cgi?id=34096 --- Comment #6 from 414N 2012-02-13 06:06:29 PST --- (In reply to comment #5) > 414N : It's probably a better idea to open a new bug for this, it might not > be the same problem. Thanks for the advice. I just opened bug 45993 for my problem -- 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 45993] r300: SIGSEGV when trying to open a WebGL page with Firefox 10
https://bugs.freedesktop.org/show_bug.cgi?id=45993 414N changed: What|Removed |Added Attachment #56967|application/octet-stream|text/plain mime type|| -- 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 45993] r300: SIGSEGV when trying to open a WebGL page with Firefox 10
https://bugs.freedesktop.org/show_bug.cgi?id=45993 Pavel Ondračka changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Pavel Ondračka 2012-02-13 06:13:43 PST --- *** This bug has been marked as a duplicate of bug 45943 *** -- 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 45943] [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=45943 Pavel Ondračka changed: What|Removed |Added CC||grsf...@tiscali.it --- Comment #7 from Pavel Ondračka 2012-02-13 06:13:43 PST --- *** Bug 45993 has been marked as a duplicate of this bug. *** -- 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 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)
https://bugs.freedesktop.org/show_bug.cgi?id=41668 --- Comment #22 from Alex Deucher 2012-02-13 06:20:04 PST --- (In reply to comment #21) > Alex I think this is a driver or hw bug actually. > > I seem to lose MSI rearms here, if I manually poke a rearm in from userspace > over ssh the system recovers fine. > > not sure if we should disable MSI on rv515, you might be able to find some > info internally. I'll see what I can find, but r5xx is pretty old. Did reading back the rearm reg help? -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #2 from Tobias Diedrich 2012-02-13 08:12:35 PST --- Created attachment 56974 --> https://bugs.freedesktop.org/attachment.cgi?id=56974 Xorg log -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #3 from Tobias Diedrich 2012-02-13 08:13:07 UTC --- Created attachment 56975 --> https://bugs.freedesktop.org/attachment.cgi?id=56975 xrandr --verbose output -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #4 from Tobias Diedrich 2012-02-13 08:16:57 PST --- Created attachment 56977 --> https://bugs.freedesktop.org/attachment.cgi?id=56977 dmesg output -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #5 from Tobias Diedrich 2012-02-13 08:18:44 PST --- Created attachment 56979 --> https://bugs.freedesktop.org/attachment.cgi?id=56979 video bios rom -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #6 from Alex Deucher 2012-02-13 08:22:51 PST --- Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)? If so, does reverting this commit fix the issue? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295 -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #7 from Tobias Diedrich 2012-02-13 08:27:05 PST --- (In reply to comment #6) > Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)? If so, does > reverting this commit fix the issue? > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295 It didn't work with 3.2.4, which is why tried 3.3-rc. -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #8 from Tobias Diedrich 2012-02-13 08:28:23 PST --- (In reply to comment #7) > (In reply to comment #6) > > Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)? If so, does > > reverting this commit fix the issue? > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295 > > It didn't work with 3.2.4, which is why tried 3.3-rc. Looking at the mentioned patch I should actually retry HDMI, which with 3.2.4 only supported up to 1920xsomething -- 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
Re: [PATCH] drm/edid: Add support for extension blocks beyond the first
On Wed, Dec 07, 2011 at 03:11:07PM +0100, Jean Delvare wrote:
> When 2 or more EDID extension blocks are present, segment must be
> selected prior to reading the extended EDID block over the DDC
> channel. Add support for this.
>
> Signed-off-by: Jean Delvare
> Cc: Adam Jackson
> ---
> This needs testing by someone with access to such a display.
>
> drivers/gpu/drm/drm_edid.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> --- linux-3.2-rc3.orig/drivers/gpu/drm/drm_edid.c 2011-11-09
> 15:53:31.0 +0100
> +++ linux-3.2-rc3/drivers/gpu/drm/drm_edid.c 2011-12-03 10:12:47.0
> +0100
> @@ -242,7 +242,8 @@ static int
> drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
> int block, int len)
> {
> - unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned char start = (block & 0x01) * EDID_LENGTH;
> int ret, retries = 5;
>
> /* The core i2c driver will automatically retry the transfer if the
> @@ -254,6 +255,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter
> do {
> struct i2c_msg msgs[] = {
> {
> + .addr = DDC_SEGMENT_ADDR,
> + .flags = 0,
> + .len= 1,
> + .buf= &segment,
> + }, {
> .addr = DDC_ADDR,
> .flags = 0,
> .len= 1,
> @@ -265,7 +271,18 @@ drm_do_probe_ddc_edid(struct i2c_adapter
> .buf= buf,
> }
> };
> - ret = i2c_transfer(adapter, msgs, 2);
> +
> + /* Don't write segment if it is 0, for compatibility */
> + if (segment) {
> + ret = i2c_transfer(adapter, msgs, 3);
> + /* The E-DDC specification says that the first ack is
> + * optional, so retry in ignore-nak mode if we get no
> + * ack at first.
> + */
> + if (ret == -ENXIO)
> + msgs[0].flags |= I2C_M_IGNORE_NAK;
This seems a bit wrong to me. The spec says that the ack for the
segment address is "don't care", but for the segment pointer the ack is
required (when segment != 0).
With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a
non E-DDC display, if we try to read segment != 0 from it. Of course
we shouldn't do that unless the display lied to us about what extension
blocks it provides.
So I'm not sure if it would be better to trust that the display never
lies about the extension blocks, or if we should just assume all E-DDC
displays ack both segment addr and pointer. The no-ack feature seems
to there for backwards compatibility, for cases where the host always
sends the segment addr/pointer even when reading segment 0 (which your
code doesn't do).
To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split
into two flags (one for addr, other for data).
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46004] New: [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 Bug #: 46004 Summary: [r300g, bisected] piglit glsl-fs-discard-02 fails Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: v...@ovi.com Piglit glsl-fs-discard-02 fails with r300g since: 10937e651222501c0e9f4f44e6b842c261e2edfb is the first bad commit commit 10937e651222501c0e9f4f44e6b842c261e2edfb Author: Vincent Lejeune Date: Mon Jan 2 20:17:38 2012 +0100 glsl_to_tgsi: Use the GLSL compiler's new remove-output-reads pass. The existing glsl_to_tgsi::remove_output_read pass did not work properly when indirect addressing was involved; this commit replaces it with a lowering pass that occurs before TGSI code generation. Fixes varying-array related piglit tests. Signed-off-by: Vincent Lejeune Signed-off-by: Kenneth Graunke Signed-off-by: Dave Airlie GPU: RV530 Mesa: df1cd55ebf362948788c04d2fa7da55c80991605 Kernel: 3.2.3 Libdrm: 2.4.31 -- 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 46005] New: [r300g, bisected] piglit glsl-vs-loop-redundant-condition fails
https://bugs.freedesktop.org/show_bug.cgi?id=46005 Bug #: 46005 Summary: [r300g, bisected] piglit glsl-vs-loop-redundant-condition fails Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: bryancain3+...@gmail.com piglit glsl-vs-loop-redundant-condition fails with: r300 VP: Compiler error: Failed to build loop info Using a dummy shader instead. 8c31bc704826d46cad65c4d65b4b70de7144205a is the first bad commit commit 8c31bc704826d46cad65c4d65b4b70de7144205a Author: Bryan Cain Date: Wed Aug 17 10:01:30 2011 -0500 glsl_to_tgsi: implement ir_unop_logic_not using 1-x Since our logic values are 0.0 (false) and 1.0 (true), 1.0 - x accurately implements logical not. This is a port of commit 6ad08989d7c1 to glsl_to_tgsi. GPU: RV530 Mesa: df1cd55ebf362948788c04d2fa7da55c80991605 Kernel: 3.2.3 Libdrm: 2.4.31 -- 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 46006] New: [r300g, bisected] piglit glsl-max-varyings fails
https://bugs.freedesktop.org/show_bug.cgi?id=46006 Bug #: 46006 Summary: [r300g, bisected] piglit glsl-max-varyings fails Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: mar...@gmail.com This is the last r300g piglit regression from 7.11 to 8.0. I'm not sure if this is a valid bug, there is lots of errors: r300: ERROR: FS input generic 20 unassigned, not enough hardware slots (it's not a bug, do not report it). r300: ERROR: FS input generic 21 unassigned, not enough hardware slots (it's not a bug, do not report it). However since this is a regression I'm reporting it nevertheless. May also be related to bug 34201 Output: Vertical axis: Increasing numbers of varyings. Horizontal axis: Which of the varyings contains the color. GL_MAX_VARYING_FLOATS = 40 Probe at (8,98) Expected: 0.00 1.00 0.00 Observed: 0.00 0.00 0.00 Failure with 9 vec4 varyings used in varying index 0 Probe at (8,110) Expected: 0.00 1.00 0.00 Observed: 0.00 0.00 0.00 Failure with 10 vec4 varyings used in varying index 0 1ded658ce074a85bc08c989ff17840b840ff3051 is the first bad commit commit 1ded658ce074a85bc08c989ff17840b840ff3051 Author: Marek Olšák Date: Tue Nov 22 15:05:29 2011 +0100 st/mesa: add color varyings to MaxVarying The linker now adds color varyings to the number of used varyings and checks against that limit. NOTE: This is a candidate for the 7.11 branch. GPU: RV530 Mesa: df1cd55ebf362948788c04d2fa7da55c80991605 Kernel: 3.2.3 Libdrm: 2.4.31 -- 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 46004] [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 --- Comment #1 from vincent 2012-02-13 12:03:38 PST --- Hi, could you please provide the error output for this test, and the generated opcodes using RADEON_DEBUG=fp,vp envar ? RADEON_DEBUG /path/to/piglit/bin/glsl-fs-discard-02 Regards, Vincent -- 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 46004] [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 --- Comment #2 from Pavel Ondračka 2012-02-13 12:16:22 PST --- Created attachment 56987 --> https://bugs.freedesktop.org/attachment.cgi?id=56987 RADEON_DEBUG=fp,vp log -- 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
Re: [PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
On Fri, Feb 10, 2012 at 12:50:01PM -0500, Yufeng Shen wrote:
> GMBUS has several ports and each has it's own corresponding
> I2C adpater. When multiple I2C adapters call gmbus_xfer() at
> the same time there is a race condition in using the underlying
> GMBUS controller. Fixing this by adding a mutex lock when calling
> gmbus_xfer().
>
> Signed-off-by: Yufeng Shen
2 more nitpicks:
- patch doesn't apply cleanly - can you please rebase against
drm-intel-next-queued available at
http://cgit.freedesktop.org/~danvet/drm-intel/
- please move the new gmbus_mutex to the other gmbus stuff in
drm_i915_private and add a small comment to that it explains against
concurrent use (from e.g. userspace) of the single gmbus controller.
Yours, Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h |2 ++
> drivers/gpu/drm/i915/intel_i2c.c | 23 +--
> 2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 559fb6f..4ed9fd9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -722,6 +722,8 @@ typedef struct drm_i915_private {
> u8 corr;
> spinlock_t *mchdev_lock;
>
> + struct mutex gmbus_mutex;
> +
> enum no_fbc_reason no_fbc_reason;
>
> struct drm_mm_node *compressed_fb;
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index d98cee6..42569b1 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -232,11 +232,15 @@ gmbus_xfer(struct i2c_adapter *adapter,
> struct intel_gmbus,
> adapter);
> struct drm_i915_private *dev_priv = adapter->algo_data;
> - int i, reg_offset;
> + int i, reg_offset, ret;
>
> - if (bus->force_bit)
> - return intel_i2c_quirk_xfer(dev_priv,
> + mutex_lock(&dev_priv->gmbus_mutex);
> +
> + if (bus->force_bit) {
> + ret = intel_i2c_quirk_xfer(dev_priv,
> bus->force_bit, msgs, num);
> + goto out;
> + }
>
> reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0;
>
> @@ -320,7 +324,8 @@ done:
>* start of the next xfer, till then let it sleep.
>*/
> I915_WRITE(GMBUS0 + reg_offset, 0);
> - return i;
> + ret = i;
> + goto out;
>
> timeout:
> DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d
> [%s]\n",
> @@ -330,9 +335,13 @@ timeout:
> /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging
> instead. */
> bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff);
> if (!bus->force_bit)
> - return -ENOMEM;
> + ret = -ENOMEM;
> + else
> + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num);
>
> - return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num);
> +out:
> + mutex_unlock(&dev_priv->gmbus_mutex);
> + return ret;
> }
>
> static u32 gmbus_func(struct i2c_adapter *adapter)
> @@ -379,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev)
> if (dev_priv->gmbus == NULL)
> return -ENOMEM;
>
> + mutex_init(&dev_priv->gmbus_mutex);
> +
> for (i = 0; i < GMBUS_NUM_PORTS; i++) {
> struct intel_gmbus *bus = &dev_priv->gmbus[i];
>
> --
> 1.7.3.4
>
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix single msg gmbus_xfers writes
On Thu, Feb 09, 2012 at 12:03:17PM -0800, Benson Leung wrote:
> gmbus_xfer with a single message (particularly a single message write) would
> set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b,
> No Index, Stop cycle. This would not start single message i2c transactions.
>
> Also, gmbus_xfer done: will disable the interface without checking if
> it is idle. In the case of writes, there will be no wait on status or delay
> to ensure the write starts and completes before the interface is turned off.
>
> Fixed the former issue by using the same cycle selection as used in the
> I2C_M_RD for the write case.
> GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0)
> Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable.
>
> Signed-off-by: Benson Leung
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 13 +
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index d30..64bb9cd 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -249,7 +249,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> if (msgs[i].flags & I2C_M_RD) {
> I915_WRITE(GMBUS1 + reg_offset,
> -GMBUS_CYCLE_WAIT | (i + 1 == num ?
> GMBUS_CYCLE_STOP : 0) |
> +GMBUS_CYCLE_WAIT |
> +(i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
> (len << GMBUS_BYTE_COUNT_SHIFT) |
> (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_READ | GMBUS_SW_RDY);
This here looks like just a white-space change. But your commit message
sounds like it's not jsut write's that are affected by this issue and need
to be fixed. Can you please clear up this for easily confused me?
Thanks, Daniel
> @@ -278,7 +279,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> I915_WRITE(GMBUS3 + reg_offset, val);
> I915_WRITE(GMBUS1 + reg_offset,
> -(i + 1 == num ? GMBUS_CYCLE_STOP :
> GMBUS_CYCLE_WAIT) |
> +GMBUS_CYCLE_WAIT |
> +(i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
> (msgs[i].len << GMBUS_BYTE_COUNT_SHIFT) |
> (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -317,9 +319,12 @@ clear_err:
> I915_WRITE(GMBUS1 + reg_offset, 0);
>
> done:
> - /* Mark the GMBUS interface as disabled. We will re-enable it at the
> - * start of the next xfer, till then let it sleep.
> + /* Mark the GMBUS interface as disabled after waiting for idle.
> + * We will re-enable it at the start of the next xfer,
> + * till then let it sleep.
>*/
> + if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
> + DRM_INFO("GMBUS timed out waiting for idle\n");
> I915_WRITE(GMBUS0 + reg_offset, 0);
> return i;
>
> --
> 1.7.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42611] [865g] webgl enabled pages crash Firefox and mesa
https://bugs.freedesktop.org/show_bug.cgi?id=42611 Will Setc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #4 from Will Setc 2012-02-13 13:10:58 PST --- I believe this was a firefox issue that mozilla devel has fixed. The crash has not shown up on any of my newer Debian installations with firefox10 and beyond. I can still trigger the crash on an 5 year old debian installation. But after adding a new user to the 5 year old debian installation the crash disappears for the new user. I tested using firefox versions 8, 9, 10, 11 and 13 with the same results for each version. Firefox url = about:support crashes when called by the 5 year old user and firefox url = about:support displays all fields of the about:support webgl page when called by the newly added user. -- 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 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)
https://bugs.freedesktop.org/show_bug.cgi?id=41668 --- Comment #23 from Alex Deucher 2012-02-13 13:40:27 UTC --- Created attachment 56992 --> https://bugs.freedesktop.org/attachment.cgi?id=56992 possible fix Does this patch help? -- 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
Re: [PATCH] drm/i915: Fix single msg gmbus_xfers writes
On Mon, 13 Feb 2012 21:38:38 +0100, Daniel Vetter wrote: > This here looks like just a white-space change. But your commit message > sounds like it's not jsut write's that are affected by this issue and need > to be fixed. Can you please clear up this for easily confused me? It makes the write path similar to the read path. I admit to overlooking the single write message as everything I saw was always a write followed by a read. The patch looks correct, but I need to stare at it a bit more before I r-b. However, the outstanding issue is that we need to separate the gmbus i2c adapter from the gpio i2c adapter in order for the pairing to work with the expectations of the i2c core. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix single msg gmbus_xfers writes
On Mon, Feb 13, 2012 at 09:49:35PM +, Chris Wilson wrote: > On Mon, 13 Feb 2012 21:38:38 +0100, Daniel Vetter wrote: > > This here looks like just a white-space change. But your commit message > > sounds like it's not jsut write's that are affected by this issue and need > > to be fixed. Can you please clear up this for easily confused me? > > It makes the write path similar to the read path. I admit to overlooking > the single write message as everything I saw was always a write followed > by a read. The patch looks correct, but I need to stare at it a bit more > before I r-b. > > However, the outstanding issue is that we need to separate the gmbus > i2c adapter from the gpio i2c adapter in order for the pairing to work > with the expectations of the i2c core. There's another patch floating on dri-devel to add a gmbus_mutex. The issue it tries to avoid is that multiple users corrupting each anothers state when using the single gmbus controller. See "[PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS". Or have you thought of another interaction that we need to sort out? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: drop lock in return path of radeon_fence_count_emitted.
On Mon, Feb 13, 2012 at 7:18 AM, Dave Airlie wrote:
> From: Dave Airlie
>
> Reported-by: Mikko Vinni
> Signed-off-by: Dave Airlie
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/radeon/radeon_fence.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
> b/drivers/gpu/drm/radeon/radeon_fence.c
> index 64ea3dd..4bd36a3 100644
> --- a/drivers/gpu/drm/radeon/radeon_fence.c
> +++ b/drivers/gpu/drm/radeon/radeon_fence.c
> @@ -364,8 +364,10 @@ int radeon_fence_count_emitted(struct radeon_device
> *rdev, int ring)
> int not_processed = 0;
>
> read_lock_irqsave(&rdev->fence_lock, irq_flags);
> - if (!rdev->fence_drv[ring].initialized)
> + if (!rdev->fence_drv[ring].initialized) {
> + read_unlock_irqrestore(&rdev->fence_lock, irq_flags);
> return 0;
> + }
>
> if (!list_empty(&rdev->fence_drv[ring].emitted)) {
> struct list_head *ptr;
> --
> 1.7.7.6
>
> ___
> 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
[PATCH] [trivial] drm: Fix typo in exynos_mixer.c
Correct spelling "sucessful" to "successful" in drivers/gpu/drm/exynos/exynos_mixer.c Signed-off-by: Masanari Iida --- drivers/gpu/drm/exynos/exynos_mixer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index ac24cff..33afd0c 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1044,7 +1044,7 @@ static int mixer_remove(struct platform_device *pdev) platform_get_drvdata(pdev); struct mixer_context *ctx = (struct mixer_context *)drm_hdmi_ctx->ctx; - dev_info(dev, "remove sucessful\n"); + dev_info(dev, "remove successful\n"); mixer_resource_poweroff(ctx); mixer_resources_cleanup(ctx); -- 1.7.6.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bisected regression] Re: scheduling while atomic on radeon rv620, kernel 3.30-rc3
>From Dave Airlie: > > I've just posted a patch to fix that to dri-devel, can you check it > fixes your issue? "drm/radeon/kms: drop lock in return path of radeon_fence_count_emitted" fixes the problem. Tested on top of 47492a23a and 3.3.0-rc3+00188-g3ec1e88. Thanks, Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
Hi Ben, So I2C core does protect multiple access to one adapter, but I2C core does not protect the case where multiple adapters share the same underlying device. GMBUS has 7 different pin pairs and each pair is registered as an I2C adapter. I2C core can serialize the access to one pin pair, say that the LVDS port , or the DDC port. But when there are I2C transactions on both LVDS and DDC ports, since they share the same GMBUS registers, there will be race condition. Does this make sense to you ? --- Yufeng Shen On Mon, Feb 13, 2012 at 4:04 AM, Ben Widawsky wrote: > On Fri, Feb 10, 2012 at 12:50:01PM -0500, Yufeng Shen wrote: >> GMBUS has several ports and each has it's own corresponding >> I2C adpater. When multiple I2C adapters call gmbus_xfer() at >> the same time there is a race condition in using the underlying >> GMBUS controller. Fixing this by adding a mutex lock when calling >> gmbus_xfer(). >> >> Signed-off-by: Yufeng Shen > > I do not see the race. All the i2c transfers should be protected > correctly by the i2c core, or else I think we haven't registered our > device properly. Could you give an example of when/how this can happen? > > Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Fix race condition in accessing GMBUS
From: Yufeng Shen
Moved gmbus_mutex below intel_gmbus and added comments.
Rebased to drm-intel-next-queued.
GMBUS has several ports and each has it's own corresponding
I2C adpater. When multiple I2C adapters call gmbus_xfer() at
the same time there is a race condition in using the underlying
GMBUS controller. Fixing this by adding a mutex lock when calling
gmbus_xfer().
Signed-off-by: Yufeng Shen
---
drivers/gpu/drm/i915/i915_drv.h |8
drivers/gpu/drm/i915/intel_i2c.c | 24 +---
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 563d24e..40027de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -313,6 +313,14 @@ typedef struct drm_i915_private {
u32 reg0;
} *gmbus;
+ /** Multiple intel_gmbus i2c adapters are actually sharing the same
+ underlying GMBUS controller. i2c core protects concurrent use of
+ the same i2c adapter but is not aware of the concurrent use of the
+ underlying GMBUS controller. gmbus_mutex is used to prevent the race
+ condition from the perspective of GMBUS controller.
+ */
+ struct mutex gmbus_mutex;
+
struct pci_dev *bridge_dev;
struct intel_ring_buffer ring[I915_NUM_RINGS];
uint32_t next_seqno;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d30..fc75d71 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -233,11 +233,15 @@ gmbus_xfer(struct i2c_adapter *adapter,
struct intel_gmbus,
adapter);
struct drm_i915_private *dev_priv = adapter->algo_data;
- int i, reg_offset;
+ int i, reg_offset, ret;
- if (bus->force_bit)
- return intel_i2c_quirk_xfer(dev_priv,
+ mutex_lock(&dev_priv->gmbus_mutex);
+
+ if (bus->force_bit) {
+ ret = intel_i2c_quirk_xfer(dev_priv,
bus->force_bit, msgs, num);
+ goto out;
+ }
reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0;
@@ -321,7 +325,8 @@ done:
* start of the next xfer, till then let it sleep.
*/
I915_WRITE(GMBUS0 + reg_offset, 0);
- return i;
+ ret = i;
+ goto out;
timeout:
DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d
[%s]\n",
@@ -331,9 +336,12 @@ timeout:
/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging
instead. */
bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff);
if (!bus->force_bit)
- return -ENOMEM;
-
- return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num);
+ ret = -ENOMEM;
+ else
+ ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num);
+out:
+ mutex_unlock(&dev_priv->gmbus_mutex);
+ return ret;
}
static u32 gmbus_func(struct i2c_adapter *adapter)
@@ -380,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev)
if (dev_priv->gmbus == NULL)
return -ENOMEM;
+ mutex_init(&dev_priv->gmbus_mutex);
+
for (i = 0; i < GMBUS_NUM_PORTS; i++) {
struct intel_gmbus *bus = &dev_priv->gmbus[i];
--
1.7.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915: Fix race condition in accessing GMBUS
Moved gmbus_mutex below intel_gmbus and added comments.
Rebased to drm-intel-next-queued.
GMBUS has several ports and each has it's own corresponding
I2C adpater. When multiple I2C adapters call gmbus_xfer() at
the same time there is a race condition in using the underlying
GMBUS controller. Fixing this by adding a mutex lock when calling
gmbus_xfer().
Signed-off-by: Yufeng Shen
---
drivers/gpu/drm/i915/i915_drv.h |8
drivers/gpu/drm/i915/intel_i2c.c | 24 +---
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 563d24e..40027de 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -313,6 +313,14 @@ typedef struct drm_i915_private {
u32 reg0;
} *gmbus;
+ /** Multiple intel_gmbus i2c adapters are actually sharing the same
+ underlying GMBUS controller. i2c core protects concurrent use of
+ the same i2c adapter but is not aware of the concurrent use of the
+ underlying GMBUS controller. gmbus_mutex is used to prevent the race
+ condition from the perspective of GMBUS controller.
+ */
+ struct mutex gmbus_mutex;
+
struct pci_dev *bridge_dev;
struct intel_ring_buffer ring[I915_NUM_RINGS];
uint32_t next_seqno;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index d30..fc75d71 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -233,11 +233,15 @@ gmbus_xfer(struct i2c_adapter *adapter,
struct intel_gmbus,
adapter);
struct drm_i915_private *dev_priv = adapter->algo_data;
- int i, reg_offset;
+ int i, reg_offset, ret;
- if (bus->force_bit)
- return intel_i2c_quirk_xfer(dev_priv,
+ mutex_lock(&dev_priv->gmbus_mutex);
+
+ if (bus->force_bit) {
+ ret = intel_i2c_quirk_xfer(dev_priv,
bus->force_bit, msgs, num);
+ goto out;
+ }
reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0;
@@ -321,7 +325,8 @@ done:
* start of the next xfer, till then let it sleep.
*/
I915_WRITE(GMBUS0 + reg_offset, 0);
- return i;
+ ret = i;
+ goto out;
timeout:
DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d
[%s]\n",
@@ -331,9 +336,12 @@ timeout:
/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging
instead. */
bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff);
if (!bus->force_bit)
- return -ENOMEM;
-
- return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num);
+ ret = -ENOMEM;
+ else
+ ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num);
+out:
+ mutex_unlock(&dev_priv->gmbus_mutex);
+ return ret;
}
static u32 gmbus_func(struct i2c_adapter *adapter)
@@ -380,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev)
if (dev_priv->gmbus == NULL)
return -ENOMEM;
+ mutex_init(&dev_priv->gmbus_mutex);
+
for (i = 0; i < GMBUS_NUM_PORTS; i++) {
struct intel_gmbus *bus = &dev_priv->gmbus[i];
--
1.7.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFCv2 PATCH 0/5] virtual GEM provider
On 2/8/12 6:19 PM, Ben Widawsky wrote: Incorporated some of the feedback given to Adam's original patch. My intention is to use this to do some dmabuf work/testing with i915 since it seemed too difficult to get some of Dave Airlie's stuff working, and I really don't feel like learning anything about nouveau if I can avoid it. (though I plan to do that later as well). I think what's missing is a shrinker, left in size for mmap (didn't see anyone respond to Daniel Vetter's comment), munmap/remap probably won't work, do quite a bit more testing; that's all I can think of at the moment. munmap appears to work. However if you do it after the close() you segfault at at exit. That's probably suboptimal. From an API perspective this is certainly enough for llvmpipe, and I can work around munmap being quirky for now. Reviewed-by: Adam Jackson - ajax ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH] [trivial] drm: Fix typo in exynos_mixer.c
> -Original Message- > From: Masanari Iida [mailto:standby2...@gmail.com] > Sent: Monday, February 13, 2012 11:11 PM > To: inki@samsung.com; jy0922.s...@samsung.com; sw0312@samsung.com; > dri-devel@lists.freedesktop.org > Cc: triv...@kernel.org; linux-ker...@vger.kernel.org; > standby2...@gmail.com > Subject: [PATCH] [trivial] drm: Fix typo in exynos_mixer.c > > Correct spelling "sucessful" to "successful" in > drivers/gpu/drm/exynos/exynos_mixer.c > > Signed-off-by: Masanari Iida > --- > drivers/gpu/drm/exynos/exynos_mixer.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c > b/drivers/gpu/drm/exynos/exynos_mixer.c > index ac24cff..33afd0c 100644 > --- a/drivers/gpu/drm/exynos/exynos_mixer.c > +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > @@ -1044,7 +1044,7 @@ static int mixer_remove(struct platform_device *pdev) > platform_get_drvdata(pdev); > struct mixer_context *ctx = (struct mixer_context *)drm_hdmi_ctx- > >ctx; > > - dev_info(dev, "remove sucessful\n"); > + dev_info(dev, "remove successful\n"); > > mixer_resource_poweroff(ctx); > mixer_resources_cleanup(ctx); > -- > 1.7.6.5 Applied. Thanks. Inki Dae. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46004] [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 --- Comment #3 from Tom Stellard 2012-02-13 18:44:05 UTC --- Created attachment 57003 --> https://bugs.freedesktop.org/attachment.cgi?id=57003 Possible fix Can you try this patch? If it doesn't work can you get the debug output (RADEON_DEBUG=fp,vp) from when the test was passing? -- 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 46005] [r300g, bisected] piglit glsl-vs-loop-redundant-condition fails
https://bugs.freedesktop.org/show_bug.cgi?id=46005 --- Comment #1 from Tom Stellard 2012-02-13 18:51:03 PST --- This is a r300 compiler bug. Flow control doesn't work very well for vertex shaders at the moment. I have been slowly working on fixing this, but I'm not quite done yet. -- 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
Re: [PATCH 5/5] drm/vgem: properly implement mmap
On Thu, 9 Feb 2012 00:19:31 +0100, Ben Widawsky wrote: > Mostly copied from i915 gtt mmaps, this will properly fault in pages as > the user tries to use them. The only thing of note are that no > prefaulting occurs, so perhaps some kind of madvise will happen later if > needed. > > The only other thing missing right not is shrinker support, which will > come next after I figure out if locking is actually required right now. > Hmm, and now that I think about it, mremap, and munmap may not work > either. I still think the mmap ioctl should be fixed to just get the mmap offset, and you use the normal mmap() syscall later. The do_mmap-in-the-ioctl in the original GEM implementation was a bad idea. pgpEdMowt7Ayo.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
drm/radeon: white screen after X does modeswitch from KMS con
Hello, the SONY PCG U3 device has a 00:0c.0 VGA compatible controller [0300]: ATI Technologies Inc Radeon Mobility M6 LY [1002:4c59] graphics card. With linux 3.1.10, X.org server 7.6_1.10.4 and xf86-video-ati-6.14.2, switching from KMS'd console to X on tty7 yields a white screen that also stays when attempting to back to tty1. I have to boot with nomodeset to get a usable Xorg picture. Is it just that radeon_drv does not work together with KMS? = log when starting X from a KMS console = [ 837.009] X.Org X Server 1.10.4 Release Date: 2011-08-19 [ 837.012] X Protocol Version 11, Revision 0 [ 837.013] Build Operating System: openSUSE SUSE LINUX [12.1] [ 837.014] Current Operating System: Linux takeshi 3.1.10-jng3-desktop #1 SMP PREEMPT Sun Jan 22 13:04:41 UTC 2012 (479c31a) i586 [ 837.016] Kernel command line: root=/dev/mapper/root quiet 3 [ 837.018] Build Date: 10 November 2011 03:34:02PM [ 837.019] [ 837.020] Current version of pixman: 0.24.0 [ 837.021]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 837.024] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 837.031] (==) Log file: "/var/log/Xorg.0.log", Time: Tue Feb 14 04:18:10 2012 [ 837.035] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 837.037] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 837.042] (==) No Layout section. Using the first Screen section. [ 837.042] (==) No screen section available. Using defaults. [ 837.042] (**) |-->Screen "Default Screen Section" (0) [ 837.042] (**) | |-->Monitor "" [ 837.044] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 837.044] (==) Automatically adding devices [ 837.044] (==) Automatically enabling devices [ 837.046] (==) FontPath set to: /usr/share/fonts/misc:unscaled, /usr/share/fonts/Type1/, /usr/share/fonts/100dpi:unscaled, /usr/share/fonts/75dpi:unscaled, /usr/share/fonts/URW/, /usr/share/fonts/cyrillic:unscaled, /usr/share/fonts/truetype/, built-ins [ 837.046] (==) ModulePath set to "/usr/lib/xorg/modules/updates,/usr/lib/xorg/modules" [ 837.046] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 837.046] (II) Loader magic: 0x8233d40 [ 837.046] (II) Module ABI versions: [ 837.046]X.Org ANSI C Emulation: 0.4 [ 837.046]X.Org Video Driver: 10.0 [ 837.047]X.Org XInput driver : 12.2 [ 837.047]X.Org Server Extension : 5.0 [ 837.054] (--) PCI:*(0:0:12:0) 1002:4c59:104d:810f rev 0, Mem @ 0xf000/134217728, 0xe811/65536, I/O @ 0x2000/256, BIOS @ 0x/131072 [ 837.060] (II) Open ACPI successful (/var/run/acpid.socket) [ 837.061] (II) LoadModule: "extmod" [ 837.069] (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so [ 837.070] (II) Module extmod: vendor="X.Org Foundation" [ 837.071]compiled for 1.10.4, module version = 1.0.0 [ 837.071]Module class: X.Org Server Extension [ 837.071]ABI class: X.Org Server Extension, version 5.0 [ 837.071] (II) Loading extension MIT-SCREEN-SAVER [ 837.071] (II) Loading extension XFree86-VidModeExtension [ 837.071] (II) Loading extension XFree86-DGA [ 837.071] (II) Loading extension DPMS [ 837.071] (II) Loading extension XVideo [ 837.071] (II) Loading extension XVideo-MotionCompensation [ 837.071] (II) Loading extension X-Resource [ 837.072] (II) LoadModule: "dbe" [ 837.075] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [ 837.077] (II) Module dbe: vendor="X.Org Foundation" [ 837.077]compiled for 1.10.4, module version = 1.0.0 [ 837.077]Module class: X.Org Server Extension [ 837.077]ABI class: X.Org Server Extension, version 5.0 [ 837.077] (II) Loading extension DOUBLE-BUFFER [ 837.077] (II) LoadModule: "glx" [ 837.081] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 837.083] (II) Module glx: vendor="X.Org Foundation" [ 837.083]compiled for 1.10.4, module version = 1.0.0 [ 837.083]ABI class: X.Org Server Extension, version 5.0 [ 837.083] (==) AIGLX enabled [ 837.083] (II) Loading extension GLX [ 837.084] (II) LoadModule: "record" [ 837.088] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so [ 837.089] (II) Module record: vendor="X.Org Foundation" [ 837.089]compiled for 1.10.4, module version = 1.13.0 [ 837.089]Module class: X.Org Server Extension [ 837.089]ABI class: X.Org Server Extension, version 5.0 [ 837.089] (II) Loading extension RECORD [ 837.089] (II) LoadModule: "dri" [ 837.094] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so [ 837.095]
Re: [PATCH 5/5] drm/vgem: properly implement mmap
On Tue, Feb 14, 2012 at 2:18 AM, Eric Anholt wrote: > On Thu, 9 Feb 2012 00:19:31 +0100, Ben Widawsky wrote: >> Mostly copied from i915 gtt mmaps, this will properly fault in pages as >> the user tries to use them. The only thing of note are that no >> prefaulting occurs, so perhaps some kind of madvise will happen later if >> needed. >> >> The only other thing missing right not is shrinker support, which will >> come next after I figure out if locking is actually required right now. >> Hmm, and now that I think about it, mremap, and munmap may not work >> either. > > I still think the mmap ioctl should be fixed to just get the mmap > offset, and you use the normal mmap() syscall later. The > do_mmap-in-the-ioctl in the original GEM implementation was a bad idea. Yes not accepting an mmap inside things anymore, shouldn't have accepted the one in GEM. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/11] drm/exynos: fixed exynos drm driver.
this patch set fixes page flip and mode setting issues and also hdmi v1.4 support. this is based on git repository below: git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git, branch name: drm-fixes commit-id: 28a4d5675857f6386930a324317281cb8ed1e5d0 and you can refer to our working repository below: http://git.infradead.org/users/kmpark/linux-2.6-samsung, branch name: exynos-drm-fixes Thanks. Eun-Chul Kim (1): drm/exynos: added panel physical size. Inki Dae (5): drm/exynos: added possible_clones setup function. drm/exynos: fixed page flip issue. drm/exynos: removed exynos_drm_fbdev_recreate function. drm/exynos: added mode_fixup feature and code clean. drm/exynos: added postclose to release resource. Joonyoung Shim (4): drm/exynos: added hdmi version 1.4 support. drm/exynos: fixed hdmi 720p config. drm/exynos: changed priority of mixer layers. drm/exynos: removed pageflip_event_list init code when closed. Masanari Iida (1): drm/exynos: Fix typo in exynos_mixer.c drivers/gpu/drm/exynos/exynos_drm_connector.c | 41 +- drivers/gpu/drm/exynos/exynos_drm_core.c |3 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 12 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 12 +- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 51 +- drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 70 +-- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 34 +- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 28 + drivers/gpu/drm/exynos/exynos_drm_hdmi.h |5 + drivers/gpu/drm/exynos/exynos_hdmi.c | 1225 +++-- drivers/gpu/drm/exynos/exynos_hdmi.h | 10 +- drivers/gpu/drm/exynos/exynos_mixer.c | 19 +- drivers/gpu/drm/exynos/regs-hdmi.h| 306 ++- include/drm/exynos_drm.h | 19 +- 16 files changed, 1601 insertions(+), 261 deletions(-) -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 01/11] drm/exynos: Fix typo in exynos_mixer.c
From: Masanari Iida Correct spelling "sucessful" to "successful" in drivers/gpu/drm/exynos/exynos_mixer.c Signed-off-by: Masanari Iida Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_mixer.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index ac24cff..33afd0c 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -1044,7 +1044,7 @@ static int mixer_remove(struct platform_device *pdev) platform_get_drvdata(pdev); struct mixer_context *ctx = (struct mixer_context *)drm_hdmi_ctx->ctx; - dev_info(dev, "remove sucessful\n"); + dev_info(dev, "remove successful\n"); mixer_resource_poweroff(ctx); mixer_resources_cleanup(ctx); -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/11] drm/exynos: changed priority of mixer layers.
From: Joonyoung Shim Signed-off-by: Joonyoung Shim Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_mixer.c | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c b/drivers/gpu/drm/exynos/exynos_mixer.c index 33afd0c..4796167 100644 --- a/drivers/gpu/drm/exynos/exynos_mixer.c +++ b/drivers/gpu/drm/exynos/exynos_mixer.c @@ -779,15 +779,15 @@ static void mixer_win_reset(struct mixer_context *ctx) mixer_reg_writemask(res, MXR_STATUS, MXR_STATUS_16_BURST, MXR_STATUS_BURST_MASK); - /* setting default layer priority: layer1 > video > layer0 + /* setting default layer priority: layer1 > layer0 > video * because typical usage scenario would be +* layer1 - OSD * layer0 - framebuffer * video - video overlay -* layer1 - OSD */ - val = MXR_LAYER_CFG_GRP0_VAL(1); - val |= MXR_LAYER_CFG_VP_VAL(2); - val |= MXR_LAYER_CFG_GRP1_VAL(3); + val = MXR_LAYER_CFG_GRP1_VAL(3); + val |= MXR_LAYER_CFG_GRP0_VAL(2); + val |= MXR_LAYER_CFG_VP_VAL(1); mixer_reg_write(res, MXR_LAYER_CFG, val); /* setting background color */ -- 1.7.4.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 03/11] drm/exynos: fixed hdmi 720p config.
From: Joonyoung Shim
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 733b9ec..1cfe86e 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -545,9 +545,9 @@ static const struct hdmi_preset_conf hdmi_conf_720p50 = {
static const struct hdmi_preset_conf hdmi_conf_720p60 = {
.core = {
.h_blank = {0x72, 0x01},
- .v2_blank = {0xdc, 0x05},
+ .v2_blank = {0xee, 0x02},
.v1_blank = {0x1e, 0x00},
- .v_line = {0xdc, 0x05},
+ .v_line = {0xee, 0x02},
.h_line = {0x72, 0x06},
.hsync_pol = {0x00},
.vsync_pol = {0x00},
@@ -574,8 +574,8 @@ static const struct hdmi_preset_conf hdmi_conf_720p60 = {
.v_sync_line_aft_pxl_4 = {0xff, 0xff},
.v_sync_line_aft_pxl_5 = {0xff, 0xff},
.v_sync_line_aft_pxl_6 = {0xff, 0xff},
- .vact_space_1 = {0xee, 0x02},
- .vact_space_2 = {0x0c, 0x03},
+ .vact_space_1 = {0xff, 0xff},
+ .vact_space_2 = {0xff, 0xff},
.vact_space_3 = {0xff, 0xff},
.vact_space_4 = {0xff, 0xff},
.vact_space_5 = {0xff, 0xff},
@@ -586,16 +586,16 @@ static const struct hdmi_preset_conf hdmi_conf_720p60 = {
0x00, /* cmd */
0x72, 0x06, /* h_fsz */
0x72, 0x01, 0x00, 0x05, /* hact */
- 0xdc, 0x05, /* v_fsz */
+ 0xee, 0x02, /* v_fsz */
0x01, 0x00, 0x33, 0x02, /* vsync */
- 0x1e, 0x00, 0x00, 0x2d, /* vact */
+ 0x1e, 0x00, 0xd0, 0x02, /* vact */
0x33, 0x02, /* field_chg */
- 0x0c, 0x03, /* vact_st2 */
+ 0x48, 0x02, /* vact_st2 */
0x00, 0x00, /* vact_st3 */
0x00, 0x00, /* vact_st4 */
0x01, 0x00, 0x01, 0x00, /* vsync top/bot */
0x01, 0x00, 0x33, 0x02, /* field top/bot */
- 0x01, /* 3d FP */
+ 0x00, /* 3d FP */
},
};
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 05/11] drm/exynos: removed pageflip_event_list init code when closed.
From: Joonyoung Shim
if one process is terminated by ctrl-c while two processes are
using pageflip feature then for last pageflip event,
user can't get poll from kernel side so this patch fixes the problem.
Signed-off-by: Joonyoung Shim
Signed-off-by: Inki Dae
Signed-off-by: Kyoungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 35889ca..2ef12aa 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -141,16 +141,10 @@ static int exynos_drm_unload(struct drm_device *dev)
}
static void exynos_drm_preclose(struct drm_device *dev,
- struct drm_file *file_priv)
+ struct drm_file *file)
{
- struct exynos_drm_private *dev_priv = dev->dev_private;
+ DRM_DEBUG_DRIVER("%s\n", __FILE__);
- /*
-* drm framework frees all events at release time,
-* so private event list should be cleared.
-*/
- if (!list_empty(&dev_priv->pageflip_event_list))
- INIT_LIST_HEAD(&dev_priv->pageflip_event_list);
}
static void exynos_drm_lastclose(struct drm_device *dev)
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 06/11] drm/exynos: added possible_clones setup function.
basically, all crtcs are possible to clone each other.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_core.c|3 ++
drivers/gpu/drm/exynos/exynos_drm_drv.c |4 +++
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 34 +++
drivers/gpu/drm/exynos/exynos_drm_encoder.h |1 +
4 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c
b/drivers/gpu/drm/exynos/exynos_drm_core.c
index 661a035..d08a558 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_core.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_core.c
@@ -193,6 +193,9 @@ int exynos_drm_subdrv_register(struct exynos_drm_subdrv
*subdrv)
return err;
}
+ /* setup possible_clones. */
+ exynos_drm_encoder_setup(drm_dev);
+
/*
* if any specific driver such as fimd or hdmi driver called
* exynos_drm_subdrv_register() later than drm_load(),
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2ef12aa..76a111f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -33,6 +33,7 @@
#include "exynos_drm_drv.h"
#include "exynos_drm_crtc.h"
+#include "exynos_drm_encoder.h"
#include "exynos_drm_fbdev.h"
#include "exynos_drm_fb.h"
#include "exynos_drm_gem.h"
@@ -99,6 +100,9 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
if (ret)
goto err_vblank;
+ /* setup possible_clones. */
+ exynos_drm_encoder_setup(dev);
+
/*
* create and configure fb helper and also exynos specific
* fbdev object.
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 86b93dd..ef4754f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -195,6 +195,40 @@ static struct drm_encoder_funcs exynos_encoder_funcs = {
.destroy = exynos_drm_encoder_destroy,
};
+static unsigned int exynos_drm_encoder_clones(struct drm_encoder *encoder)
+{
+ struct drm_encoder *clone;
+ struct drm_device *dev = encoder->dev;
+ struct exynos_drm_encoder *exynos_encoder = to_exynos_encoder(encoder);
+ struct exynos_drm_display_ops *display_ops =
+ exynos_encoder->manager->display_ops;
+ unsigned int clone_mask = 0;
+ int cnt = 0;
+
+ list_for_each_entry(clone, &dev->mode_config.encoder_list, head) {
+ switch (display_ops->type) {
+ case EXYNOS_DISPLAY_TYPE_LCD:
+ case EXYNOS_DISPLAY_TYPE_HDMI:
+ clone_mask |= (1 << (cnt++));
+ break;
+ default:
+ continue;
+ }
+ }
+
+ return clone_mask;
+}
+
+void exynos_drm_encoder_setup(struct drm_device *dev)
+{
+ struct drm_encoder *encoder;
+
+ DRM_DEBUG_KMS("%s\n", __FILE__);
+
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, head)
+ encoder->possible_clones = exynos_drm_encoder_clones(encoder);
+}
+
struct drm_encoder *
exynos_drm_encoder_create(struct drm_device *dev,
struct exynos_drm_manager *manager,
diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
index 97b087a..eb7d231 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.h
@@ -30,6 +30,7 @@
struct exynos_drm_manager;
+void exynos_drm_encoder_setup(struct drm_device *dev);
struct drm_encoder *exynos_drm_encoder_create(struct drm_device *dev,
struct exynos_drm_manager *mgr,
unsigned int possible_crtcs);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 08/11] drm/exynos: removed exynos_drm_fbdev_recreate function.
this function ins't needed anymore.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 70 ++---
1 files changed, 4 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
index d7ae29d..3508700 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
@@ -195,66 +195,6 @@ out:
return ret;
}
-static bool
-exynos_drm_fbdev_is_samefb(struct drm_framebuffer *fb,
- struct drm_fb_helper_surface_size *sizes)
-{
- if (fb->width != sizes->surface_width)
- return false;
- if (fb->height != sizes->surface_height)
- return false;
- if (fb->bits_per_pixel != sizes->surface_bpp)
- return false;
- if (fb->depth != sizes->surface_depth)
- return false;
-
- return true;
-}
-
-static int exynos_drm_fbdev_recreate(struct drm_fb_helper *helper,
- struct drm_fb_helper_surface_size *sizes)
-{
- struct drm_device *dev = helper->dev;
- struct exynos_drm_fbdev *exynos_fbdev = to_exynos_fbdev(helper);
- struct exynos_drm_gem_obj *exynos_gem_obj;
- struct drm_framebuffer *fb = helper->fb;
- struct drm_mode_fb_cmd2 mode_cmd = { 0 };
- unsigned long size;
-
- DRM_DEBUG_KMS("%s\n", __FILE__);
-
- if (exynos_drm_fbdev_is_samefb(fb, sizes))
- return 0;
-
- mode_cmd.width = sizes->surface_width;
- mode_cmd.height = sizes->surface_height;
- mode_cmd.pitches[0] = sizes->surface_width * (sizes->surface_bpp >> 3);
- mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
- sizes->surface_depth);
-
- if (exynos_fbdev->exynos_gem_obj)
- exynos_drm_gem_destroy(exynos_fbdev->exynos_gem_obj);
-
- if (fb->funcs->destroy)
- fb->funcs->destroy(fb);
-
- size = mode_cmd.pitches[0] * mode_cmd.height;
- exynos_gem_obj = exynos_drm_gem_create(dev, size);
- if (IS_ERR(exynos_gem_obj))
- return PTR_ERR(exynos_gem_obj);
-
- exynos_fbdev->exynos_gem_obj = exynos_gem_obj;
-
- helper->fb = exynos_drm_framebuffer_init(dev, &mode_cmd,
- &exynos_gem_obj->base);
- if (IS_ERR_OR_NULL(helper->fb)) {
- DRM_ERROR("failed to create drm framebuffer.\n");
- return PTR_ERR(helper->fb);
- }
-
- return exynos_drm_fbdev_update(helper, helper->fb);
-}
-
static int exynos_drm_fbdev_probe(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes)
{
@@ -262,6 +202,10 @@ static int exynos_drm_fbdev_probe(struct drm_fb_helper
*helper,
DRM_DEBUG_KMS("%s\n", __FILE__);
+ /*
+* with !helper->fb, it means that this funcion is called first time
+* and after that, the helper->fb would be used as clone mode.
+*/
if (!helper->fb) {
ret = exynos_drm_fbdev_create(helper, sizes);
if (ret < 0) {
@@ -274,12 +218,6 @@ static int exynos_drm_fbdev_probe(struct drm_fb_helper
*helper,
* because register_framebuffer() should be called.
*/
ret = 1;
- } else {
- ret = exynos_drm_fbdev_recreate(helper, sizes);
- if (ret < 0) {
- DRM_ERROR("failed to reconfigure fbdev\n");
- return ret;
- }
}
return ret;
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/11] drm/exynos: fixed page flip issue.
with vblank_refcount = 1, there was the case that drm_vblank_put
is called by specific page flip function so this patch fixes the
issue.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c |6 +++---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |7 ++-
drivers/gpu/drm/exynos/exynos_mixer.c|7 ++-
3 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index e3861ac..de81883 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -307,9 +307,6 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
*/
event->pipe = exynos_crtc->pipe;
- list_add_tail(&event->base.link,
- &dev_priv->pageflip_event_list);
-
ret = drm_vblank_get(dev, exynos_crtc->pipe);
if (ret) {
DRM_DEBUG("failed to acquire vblank counter\n");
@@ -318,6 +315,9 @@ static int exynos_drm_crtc_page_flip(struct drm_crtc *crtc,
goto out;
}
+ list_add_tail(&event->base.link,
+ &dev_priv->pageflip_event_list);
+
crtc->fb = fb;
ret = exynos_drm_crtc_update(crtc);
if (ret) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index b6a737d..0dbb32b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -604,7 +604,12 @@ static void fimd_finish_pageflip(struct drm_device
*drm_dev, int crtc)
}
if (is_checked) {
- drm_vblank_put(drm_dev, crtc);
+ /*
+* call drm_vblank_put only in case that drm_vblank_get was
+* called.
+*/
+ if (atomic_read(&drm_dev->vblank_refcount[crtc]) > 0)
+ drm_vblank_put(drm_dev, crtc);
/*
* don't off vblank if vblank_disable_allowed is 1,
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 4796167..93846e8 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -712,7 +712,12 @@ static void mixer_finish_pageflip(struct drm_device
*drm_dev, int crtc)
}
if (is_checked)
- drm_vblank_put(drm_dev, crtc);
+ /*
+* call drm_vblank_put only in case that drm_vblank_get was
+* called.
+*/
+ if (atomic_read(&drm_dev->vblank_refcount[crtc]) > 0)
+ drm_vblank_put(drm_dev, crtc);
spin_unlock_irqrestore(&drm_dev->event_lock, flags);
}
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 10/11] drm/exynos: added postclose to release resource.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 76a111f..58820eb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -151,6 +151,17 @@ static void exynos_drm_preclose(struct drm_device *dev,
}
+static void exynos_drm_postclose(struct drm_device *dev, struct drm_file *file)
+{
+ DRM_DEBUG_DRIVER("%s\n", __FILE__);
+
+ if (!file->driver_priv)
+ return;
+
+ kfree(file->driver_priv);
+ file->driver_priv = NULL;
+}
+
static void exynos_drm_lastclose(struct drm_device *dev)
{
DRM_DEBUG_DRIVER("%s\n", __FILE__);
@@ -193,6 +204,7 @@ static struct drm_driver exynos_drm_driver = {
.unload = exynos_drm_unload,
.preclose = exynos_drm_preclose,
.lastclose = exynos_drm_lastclose,
+ .postclose = exynos_drm_postclose,
.get_vblank_counter = drm_vblank_count,
.enable_vblank = exynos_drm_crtc_enable_vblank,
.disable_vblank = exynos_drm_crtc_disable_vblank,
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3.3-rc3] drm/i915: Fixes distorted external screen image on HP 2730p
On Sun, Feb 12, 2012 at 11:10:32AM +0100, p...@haerkules.de wrote: > From: Philipp Grete > > Fixes LP: #796030 by removing forced pipe A on HP 2730p. > Quirk has previously been introduced to fix a sleep mode problem that does > not exist any more. > > Signed-off-by: Philipp Grete > --- > Fix has been confirmed by at least three people (see > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/796030) who didn't > experience any sleep mode problems after applying the patch. Can you please supply the corresponding tested-bys for these three people? I.e. add Tested-by: Name to the sob part of your commit message. Also please add a reference to the LP as a full link (easier to handle for people outside of the ubuntu universe): Bugzilla: http://launchpad/direct/link/to/bug Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Ignore LVDS on hp t5745 and hp st5747 thin client
On Thu, Feb 09, 2012 at 09:35:21AM -0500, Marc Gariepy wrote: > Add a no_lvds quirk for the HP t5745 and HP st5747 thin clients > > dmidecode for those thin clients are attached in thoses bugs: > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916 > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920 > > > Signed-off-by: Marc Gariepy Adam, can I have your ack on this? Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
On Fri, Feb 10, 2012 at 12:50:01PM -0500, Yufeng Shen wrote: > GMBUS has several ports and each has it's own corresponding > I2C adpater. When multiple I2C adapters call gmbus_xfer() at > the same time there is a race condition in using the underlying > GMBUS controller. Fixing this by adding a mutex lock when calling > gmbus_xfer(). > > Signed-off-by: Yufeng Shen I do not see the race. All the i2c transfers should be protected correctly by the i2c core, or else I think we haven't registered our device properly. Could you give an example of when/how this can happen? Ben ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Fix spelling in comments.
Dear Kristof, Am Samstag, den 11.02.2012, 15:04 +0100 schrieb Kristof Ralovich: > Dear All, > > attached is the patch. please only send inlined patches. You can use `git send-email` for that. > From 87b2ba50ca33b85fae58e85cd51ba7515bceb81b Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?"RALOVICH,=20Krist=C3=B3f"?= > Date: Sat, 11 Feb 2012 15:00:49 +0100 > Subject: [PATCH] Fix spelling in comments. Your Signed-off-by line is missing. Please also prepend the commit summary with the subsystem. > --- > xf86drmMode.h |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xf86drmMode.h b/xf86drmMode.h > index 34f5fb1..febf88a 100644 > --- a/xf86drmMode.h > +++ b/xf86drmMode.h > @@ -333,7 +333,7 @@ extern int drmModeAddFB2(int fd, uint32_t width, uint32_t > height, > uint32_t pitches[4], uint32_t offsets[4], > uint32_t *buf_id, uint32_t flags); > /** > - * Destroies the given framebuffer. > + * Destroys the given framebuffer. > */ > extern int drmModeRmFB(int fd, uint32_t bufferId); > > @@ -349,7 +349,7 @@ extern int drmModeDirtyFB(int fd, uint32_t bufferId, > */ > > /** > - * Retrive information about the ctrt crtcId > + * Retrive information about the crtc crtcId Could you also change Retri*e*ve please? > */ > extern drmModeCrtcPtr drmModeGetCrtc(int fd, uint32_t crtcId); Please resend as [PATCH v2]. Thanks, Paul signature.asc Description: This is a digitally signed message part ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45984] New: Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 Bug #: 45984 Summary: Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch. Classification: Unclassified Product: Mesa Version: 8.0 Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: hysv...@gmail.com Created attachment 56951 --> https://bugs.freedesktop.org/attachment.cgi?id=56951 dmesg Driver Stack Details: = 1)Kernel-3.0.0-12-generice-pae 2)drm-2.4.31 3)Mesa-8.0-devel (git-a7750c9) 4)Xorg-server-1.11.0 5)xf86-video-ati- master System Environment: === Asic : NI SeymourXT O.S. : Ubuntu-11.10 (64 bit) Processor: AMD Athlon(tm) 64 X2 @ 1000 MHz Memory : 2 GB Steps to Reproduce: === 1) Install piglit from git clone git://anongit.freedesktop.org/git/piglit 2) Run ./piglit-run.py tests/r600.tests results/r600.results Observation : = Xserver crashes with segmentation fault after few seconds of r600.tests launch. -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #1 from samit vats 2012-02-13 02:54:21 PST --- Created attachment 56952 --> https://bugs.freedesktop.org/attachment.cgi?id=56952 r600_results -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #2 from samit vats 2012-02-13 02:55:09 PST --- Created attachment 56953 --> https://bugs.freedesktop.org/attachment.cgi?id=56953 backtrace -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #3 from samit vats 2012-02-13 02:55:58 PST --- Created attachment 56954 --> https://bugs.freedesktop.org/attachment.cgi?id=56954 Xorg.log -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 --- Comment #4 from samit vats 2012-02-13 02:57:07 PST --- Created attachment 56955 --> https://bugs.freedesktop.org/attachment.cgi?id=56955 glxinfo -- 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 45984] Piglit:Xserver crashes with segmentation fault after few seconds of r600.tests launch.
https://bugs.freedesktop.org/show_bug.cgi?id=45984 samit vats changed: What|Removed |Added Priority|medium |high -- 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/radeon/kms: drop lock in return path of radeon_fence_count_emitted.
From: Dave Airlie
Reported-by: Mikko Vinni
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_fence.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 64ea3dd..4bd36a3 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -364,8 +364,10 @@ int radeon_fence_count_emitted(struct radeon_device *rdev,
int ring)
int not_processed = 0;
read_lock_irqsave(&rdev->fence_lock, irq_flags);
- if (!rdev->fence_drv[ring].initialized)
+ if (!rdev->fence_drv[ring].initialized) {
+ read_unlock_irqrestore(&rdev->fence_lock, irq_flags);
return 0;
+ }
if (!list_empty(&rdev->fence_drv[ring].emitted)) {
struct list_head *ptr;
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [bisected regression] Re: scheduling while atomic on radeon rv620, kernel 3.30-rc3
On Sun, Feb 12, 2012 at 5:20 PM, Mikko Vinni wrote: > Hi again, > > I bisected this problem to: > > 47492a23a128e953bd5087b1cac909cd8124ca5e is the first bad commit > commit 47492a23a128e953bd5087b1cac909cd8124ca5e > Author: Christian König > Date: Thu Oct 20 12:38:09 2011 +0200 > > drm/radeon: add radeon_fence_count_emited function > > Split counting of emited fences out of power > management into a seperate function. > > Signed-off-by: Christian König > Reviewed-by: Jerome Glisse > Signed-off-by: Dave Airlie > > :04 04 adbb5199d8ee03a75f65b9ddf6b1d398acfca4d9 > 67b8d0bfdd5507d82b0c8d8f500f32d140520f0d M drivers > > > > That patch (part of it below) moves code into a new function and perhaps > changes > locking a bit. Is the return in the middle ok? I've just posted a patch to fix that to dri-devel, can you check it fixes your issue? Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #1 from Alex Deucher 2012-02-13 05:27:57 PST --- Please attach your xorg log, dmesg output, and xrandr --verbose output. -- 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
Re: [PATCH] Fix spelling in comments.
while you are at it, "retrive" [sic] should be "retrieve" On Sat, 11 Feb 2012, Kristof Ralovich wrote: Dear All, attached is the patch. Kristof ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms/atom: bios scratch reg handling updates
From: Alex Deucher
- Add missing DFP6 connection state handling
- crtc routing bits not used on DCE4+
Noticed by sylware on phoronix.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_atombios.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index a9ce094..8577824 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -2981,6 +2981,20 @@ radeon_atombios_connected_scratch_regs(struct
drm_connector *connector,
bios_6_scratch &= ~ATOM_S6_ACC_REQ_DFP5;
}
}
+ if ((radeon_encoder->devices & ATOM_DEVICE_DFP6_SUPPORT) &&
+ (radeon_connector->devices & ATOM_DEVICE_DFP6_SUPPORT)) {
+ if (connected) {
+ DRM_DEBUG_KMS("DFP6 connected\n");
+ bios_0_scratch |= ATOM_S0_DFP6;
+ bios_3_scratch |= ATOM_S3_DFP6_ACTIVE;
+ bios_6_scratch |= ATOM_S6_ACC_REQ_DFP6;
+ } else {
+ DRM_DEBUG_KMS("DFP6 disconnected\n");
+ bios_0_scratch &= ~ATOM_S0_DFP6;
+ bios_3_scratch &= ~ATOM_S3_DFP6_ACTIVE;
+ bios_6_scratch &= ~ATOM_S6_ACC_REQ_DFP6;
+ }
+ }
if (rdev->family >= CHIP_R600) {
WREG32(R600_BIOS_0_SCRATCH, bios_0_scratch);
@@ -3001,6 +3015,9 @@ radeon_atombios_encoder_crtc_scratch_regs(struct
drm_encoder *encoder, int crtc)
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
uint32_t bios_3_scratch;
+ if (ASIC_IS_DCE4(rdev))
+ return;
+
if (rdev->family >= CHIP_R600)
bios_3_scratch = RREG32(R600_BIOS_3_SCRATCH);
else
--
1.7.7.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 45993] New: r300: SIGSEGV when trying to open a WebGL page with Firefox 10
https://bugs.freedesktop.org/show_bug.cgi?id=45993 Bug #: 45993 Summary: r300: SIGSEGV when trying to open a WebGL page with Firefox 10 Classification: Unclassified Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: grsf...@tiscali.it Created attachment 56967 --> https://bugs.freedesktop.org/attachment.cgi?id=56967 Backtrace of the crash When trying to open a WebGL enabled page such as http://get.webgl.org Firefox instantly crashes. When setting the LIBGL_DEBUG environment variable to "verbose", the following message is seen on the terminal: radeon: Cannot get a relocation in radeon_drm_cs_write_reloc. System specs: CPU: AMD Athlon 64 FX-55 GPU: ATI Technologies Inc R420 JP [Radeon X800XT] OS: Slackware64 13.37 kernel: 3.2.5 (vanilla) Mesa git snapshot @ 2012-02-11 libdrm-2.4.31 Mozilla Firefox 10.0.1 x86_64 -- 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 34096] r300: Cannot get a relocation in radeon_drm_cs_write_reloc.
https://bugs.freedesktop.org/show_bug.cgi?id=34096 --- Comment #6 from 414N 2012-02-13 06:06:29 PST --- (In reply to comment #5) > 414N : It's probably a better idea to open a new bug for this, it might not > be the same problem. Thanks for the advice. I just opened bug 45993 for my problem -- 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 45993] r300: SIGSEGV when trying to open a WebGL page with Firefox 10
https://bugs.freedesktop.org/show_bug.cgi?id=45993 414N changed: What|Removed |Added Attachment #56967|application/octet-stream|text/plain mime type|| -- 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 45993] r300: SIGSEGV when trying to open a WebGL page with Firefox 10
https://bugs.freedesktop.org/show_bug.cgi?id=45993 Pavel Ondračka changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Pavel Ondračka 2012-02-13 06:13:43 PST --- *** This bug has been marked as a duplicate of bug 45943 *** -- 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 45943] [r300g] r300_emit.c:365:r300_emit_aa_state: Assertion `(aa->dest)->cs_buf' failed.
https://bugs.freedesktop.org/show_bug.cgi?id=45943 Pavel Ondračka changed: What|Removed |Added CC||grsf...@tiscali.it --- Comment #7 from Pavel Ondračka 2012-02-13 06:13:43 PST --- *** Bug 45993 has been marked as a duplicate of this bug. *** -- 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 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)
https://bugs.freedesktop.org/show_bug.cgi?id=41668 --- Comment #22 from Alex Deucher 2012-02-13 06:20:04 PST --- (In reply to comment #21) > Alex I think this is a driver or hw bug actually. > > I seem to lose MSI rearms here, if I manually poke a rearm in from userspace > over ssh the system recovers fine. > > not sure if we should disable MSI on rv515, you might be able to find some > info internally. I'll see what I can find, but r5xx is pretty old. Did reading back the rearm reg help? -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #2 from Tobias Diedrich 2012-02-13 08:12:35 PST --- Created attachment 56974 --> https://bugs.freedesktop.org/attachment.cgi?id=56974 Xorg log -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #3 from Tobias Diedrich 2012-02-13 08:13:07 UTC --- Created attachment 56975 --> https://bugs.freedesktop.org/attachment.cgi?id=56975 xrandr --verbose output -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #4 from Tobias Diedrich 2012-02-13 08:16:57 PST --- Created attachment 56977 --> https://bugs.freedesktop.org/attachment.cgi?id=56977 dmesg output -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #5 from Tobias Diedrich 2012-02-13 08:18:44 PST --- Created attachment 56979 --> https://bugs.freedesktop.org/attachment.cgi?id=56979 video bios rom -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #6 from Alex Deucher 2012-02-13 08:22:51 PST --- Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)? If so, does reverting this commit fix the issue? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295 -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #7 from Tobias Diedrich 2012-02-13 08:27:05 PST --- (In reply to comment #6) > Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)? If so, does > reverting this commit fix the issue? > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295 It didn't work with 3.2.4, which is why tried 3.3-rc. -- 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 45968] [RADEON:KMS:RS780:HD3200] l 2560x1440 detected by monitor as 1280x1440, every second pixel missing
https://bugs.freedesktop.org/show_bug.cgi?id=45968 --- Comment #8 from Tobias Diedrich 2012-02-13 08:28:23 PST --- (In reply to comment #7) > (In reply to comment #6) > > Does it work ok with a pre3.3 kernel (e.g., 3.2, 3.1, etc.)? If so, does > > reverting this commit fix the issue? > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=9aa59993e226af94088adaee993eb8cfd33ae295 > > It didn't work with 3.2.4, which is why tried 3.3-rc. Looking at the mentioned patch I should actually retry HDMI, which with 3.2.4 only supported up to 1920xsomething -- 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
Re: [PATCH] drm/edid: Add support for extension blocks beyond the first
On Wed, Dec 07, 2011 at 03:11:07PM +0100, Jean Delvare wrote:
> When 2 or more EDID extension blocks are present, segment must be
> selected prior to reading the extended EDID block over the DDC
> channel. Add support for this.
>
> Signed-off-by: Jean Delvare
> Cc: Adam Jackson
> ---
> This needs testing by someone with access to such a display.
>
> drivers/gpu/drm/drm_edid.c | 21 +++--
> 1 file changed, 19 insertions(+), 2 deletions(-)
>
> --- linux-3.2-rc3.orig/drivers/gpu/drm/drm_edid.c 2011-11-09
> 15:53:31.0 +0100
> +++ linux-3.2-rc3/drivers/gpu/drm/drm_edid.c 2011-12-03 10:12:47.0
> +0100
> @@ -242,7 +242,8 @@ static int
> drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
> int block, int len)
> {
> - unsigned char start = block * EDID_LENGTH;
> + unsigned char segment = block >> 1;
> + unsigned char start = (block & 0x01) * EDID_LENGTH;
> int ret, retries = 5;
>
> /* The core i2c driver will automatically retry the transfer if the
> @@ -254,6 +255,11 @@ drm_do_probe_ddc_edid(struct i2c_adapter
> do {
> struct i2c_msg msgs[] = {
> {
> + .addr = DDC_SEGMENT_ADDR,
> + .flags = 0,
> + .len= 1,
> + .buf= &segment,
> + }, {
> .addr = DDC_ADDR,
> .flags = 0,
> .len= 1,
> @@ -265,7 +271,18 @@ drm_do_probe_ddc_edid(struct i2c_adapter
> .buf= buf,
> }
> };
> - ret = i2c_transfer(adapter, msgs, 2);
> +
> + /* Don't write segment if it is 0, for compatibility */
> + if (segment) {
> + ret = i2c_transfer(adapter, msgs, 3);
> + /* The E-DDC specification says that the first ack is
> + * optional, so retry in ignore-nak mode if we get no
> + * ack at first.
> + */
> + if (ret == -ENXIO)
> + msgs[0].flags |= I2C_M_IGNORE_NAK;
This seems a bit wrong to me. The spec says that the ack for the
segment address is "don't care", but for the segment pointer the ack is
required (when segment != 0).
With I2C_M_IGNORE_NAK we would in fact end up reading segment 0 from a
non E-DDC display, if we try to read segment != 0 from it. Of course
we shouldn't do that unless the display lied to us about what extension
blocks it provides.
So I'm not sure if it would be better to trust that the display never
lies about the extension blocks, or if we should just assume all E-DDC
displays ack both segment addr and pointer. The no-ack feature seems
to there for backwards compatibility, for cases where the host always
sends the segment addr/pointer even when reading segment 0 (which your
code doesn't do).
To handle it exactly as the spec says, I2C_M_IGNORE_NAK should be split
into two flags (one for addr, other for data).
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 46004] New: [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 Bug #: 46004 Summary: [r300g, bisected] piglit glsl-fs-discard-02 fails Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: v...@ovi.com Piglit glsl-fs-discard-02 fails with r300g since: 10937e651222501c0e9f4f44e6b842c261e2edfb is the first bad commit commit 10937e651222501c0e9f4f44e6b842c261e2edfb Author: Vincent Lejeune Date: Mon Jan 2 20:17:38 2012 +0100 glsl_to_tgsi: Use the GLSL compiler's new remove-output-reads pass. The existing glsl_to_tgsi::remove_output_read pass did not work properly when indirect addressing was involved; this commit replaces it with a lowering pass that occurs before TGSI code generation. Fixes varying-array related piglit tests. Signed-off-by: Vincent Lejeune Signed-off-by: Kenneth Graunke Signed-off-by: Dave Airlie GPU: RV530 Mesa: df1cd55ebf362948788c04d2fa7da55c80991605 Kernel: 3.2.3 Libdrm: 2.4.31 -- 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 46005] New: [r300g, bisected] piglit glsl-vs-loop-redundant-condition fails
https://bugs.freedesktop.org/show_bug.cgi?id=46005 Bug #: 46005 Summary: [r300g, bisected] piglit glsl-vs-loop-redundant-condition fails Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: bryancain3+...@gmail.com piglit glsl-vs-loop-redundant-condition fails with: r300 VP: Compiler error: Failed to build loop info Using a dummy shader instead. 8c31bc704826d46cad65c4d65b4b70de7144205a is the first bad commit commit 8c31bc704826d46cad65c4d65b4b70de7144205a Author: Bryan Cain Date: Wed Aug 17 10:01:30 2011 -0500 glsl_to_tgsi: implement ir_unop_logic_not using 1-x Since our logic values are 0.0 (false) and 1.0 (true), 1.0 - x accurately implements logical not. This is a port of commit 6ad08989d7c1 to glsl_to_tgsi. GPU: RV530 Mesa: df1cd55ebf362948788c04d2fa7da55c80991605 Kernel: 3.2.3 Libdrm: 2.4.31 -- 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 46006] New: [r300g, bisected] piglit glsl-max-varyings fails
https://bugs.freedesktop.org/show_bug.cgi?id=46006 Bug #: 46006 Summary: [r300g, bisected] piglit glsl-max-varyings fails Classification: Unclassified Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Keywords: regression Severity: normal Priority: medium Component: Drivers/Gallium/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: pavel.ondra...@email.cz CC: mar...@gmail.com This is the last r300g piglit regression from 7.11 to 8.0. I'm not sure if this is a valid bug, there is lots of errors: r300: ERROR: FS input generic 20 unassigned, not enough hardware slots (it's not a bug, do not report it). r300: ERROR: FS input generic 21 unassigned, not enough hardware slots (it's not a bug, do not report it). However since this is a regression I'm reporting it nevertheless. May also be related to bug 34201 Output: Vertical axis: Increasing numbers of varyings. Horizontal axis: Which of the varyings contains the color. GL_MAX_VARYING_FLOATS = 40 Probe at (8,98) Expected: 0.00 1.00 0.00 Observed: 0.00 0.00 0.00 Failure with 9 vec4 varyings used in varying index 0 Probe at (8,110) Expected: 0.00 1.00 0.00 Observed: 0.00 0.00 0.00 Failure with 10 vec4 varyings used in varying index 0 1ded658ce074a85bc08c989ff17840b840ff3051 is the first bad commit commit 1ded658ce074a85bc08c989ff17840b840ff3051 Author: Marek Olšák Date: Tue Nov 22 15:05:29 2011 +0100 st/mesa: add color varyings to MaxVarying The linker now adds color varyings to the number of used varyings and checks against that limit. NOTE: This is a candidate for the 7.11 branch. GPU: RV530 Mesa: df1cd55ebf362948788c04d2fa7da55c80991605 Kernel: 3.2.3 Libdrm: 2.4.31 -- 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 46004] [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 --- Comment #1 from vincent 2012-02-13 12:03:38 PST --- Hi, could you please provide the error output for this test, and the generated opcodes using RADEON_DEBUG=fp,vp envar ? RADEON_DEBUG /path/to/piglit/bin/glsl-fs-discard-02 Regards, Vincent -- 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 46004] [r300g, bisected] piglit glsl-fs-discard-02 fails
https://bugs.freedesktop.org/show_bug.cgi?id=46004 --- Comment #2 from Pavel Ondračka 2012-02-13 12:16:22 PST --- Created attachment 56987 --> https://bugs.freedesktop.org/attachment.cgi?id=56987 RADEON_DEBUG=fp,vp log -- 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
Re: [PATCH] [PATCH] drm/i915: Fix race condition in accessing GMBUS
On Fri, Feb 10, 2012 at 12:50:01PM -0500, Yufeng Shen wrote:
> GMBUS has several ports and each has it's own corresponding
> I2C adpater. When multiple I2C adapters call gmbus_xfer() at
> the same time there is a race condition in using the underlying
> GMBUS controller. Fixing this by adding a mutex lock when calling
> gmbus_xfer().
>
> Signed-off-by: Yufeng Shen
2 more nitpicks:
- patch doesn't apply cleanly - can you please rebase against
drm-intel-next-queued available at
http://cgit.freedesktop.org/~danvet/drm-intel/
- please move the new gmbus_mutex to the other gmbus stuff in
drm_i915_private and add a small comment to that it explains against
concurrent use (from e.g. userspace) of the single gmbus controller.
Yours, Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h |2 ++
> drivers/gpu/drm/i915/intel_i2c.c | 23 +--
> 2 files changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 559fb6f..4ed9fd9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -722,6 +722,8 @@ typedef struct drm_i915_private {
> u8 corr;
> spinlock_t *mchdev_lock;
>
> + struct mutex gmbus_mutex;
> +
> enum no_fbc_reason no_fbc_reason;
>
> struct drm_mm_node *compressed_fb;
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index d98cee6..42569b1 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -232,11 +232,15 @@ gmbus_xfer(struct i2c_adapter *adapter,
> struct intel_gmbus,
> adapter);
> struct drm_i915_private *dev_priv = adapter->algo_data;
> - int i, reg_offset;
> + int i, reg_offset, ret;
>
> - if (bus->force_bit)
> - return intel_i2c_quirk_xfer(dev_priv,
> + mutex_lock(&dev_priv->gmbus_mutex);
> +
> + if (bus->force_bit) {
> + ret = intel_i2c_quirk_xfer(dev_priv,
> bus->force_bit, msgs, num);
> + goto out;
> + }
>
> reg_offset = HAS_PCH_SPLIT(dev_priv->dev) ? PCH_GMBUS0 - GMBUS0 : 0;
>
> @@ -320,7 +324,8 @@ done:
>* start of the next xfer, till then let it sleep.
>*/
> I915_WRITE(GMBUS0 + reg_offset, 0);
> - return i;
> + ret = i;
> + goto out;
>
> timeout:
> DRM_INFO("GMBUS timed out, falling back to bit banging on pin %d
> [%s]\n",
> @@ -330,9 +335,13 @@ timeout:
> /* Hardware may not support GMBUS over these pins? Try GPIO bitbanging
> instead. */
> bus->force_bit = intel_gpio_create(dev_priv, bus->reg0 & 0xff);
> if (!bus->force_bit)
> - return -ENOMEM;
> + ret = -ENOMEM;
> + else
> + ret = intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num);
>
> - return intel_i2c_quirk_xfer(dev_priv, bus->force_bit, msgs, num);
> +out:
> + mutex_unlock(&dev_priv->gmbus_mutex);
> + return ret;
> }
>
> static u32 gmbus_func(struct i2c_adapter *adapter)
> @@ -379,6 +388,8 @@ int intel_setup_gmbus(struct drm_device *dev)
> if (dev_priv->gmbus == NULL)
> return -ENOMEM;
>
> + mutex_init(&dev_priv->gmbus_mutex);
> +
> for (i = 0; i < GMBUS_NUM_PORTS; i++) {
> struct intel_gmbus *bus = &dev_priv->gmbus[i];
>
> --
> 1.7.3.4
>
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix single msg gmbus_xfers writes
On Thu, Feb 09, 2012 at 12:03:17PM -0800, Benson Leung wrote:
> gmbus_xfer with a single message (particularly a single message write) would
> set Bus Cycle Select to 100b, the Gen Stop cycle, instead of 101b,
> No Index, Stop cycle. This would not start single message i2c transactions.
>
> Also, gmbus_xfer done: will disable the interface without checking if
> it is idle. In the case of writes, there will be no wait on status or delay
> to ensure the write starts and completes before the interface is turned off.
>
> Fixed the former issue by using the same cycle selection as used in the
> I2C_M_RD for the write case.
> GMBUS_CYCLE_WAIT | (i + 1 == num ? GMBUS_CYCLE_STOP : 0)
> Fixed the latter by waiting on GMBUS_ACTIVE to deassert before disable.
>
> Signed-off-by: Benson Leung
> ---
> drivers/gpu/drm/i915/intel_i2c.c | 13 +
> 1 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_i2c.c
> b/drivers/gpu/drm/i915/intel_i2c.c
> index d30..64bb9cd 100644
> --- a/drivers/gpu/drm/i915/intel_i2c.c
> +++ b/drivers/gpu/drm/i915/intel_i2c.c
> @@ -249,7 +249,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> if (msgs[i].flags & I2C_M_RD) {
> I915_WRITE(GMBUS1 + reg_offset,
> -GMBUS_CYCLE_WAIT | (i + 1 == num ?
> GMBUS_CYCLE_STOP : 0) |
> +GMBUS_CYCLE_WAIT |
> +(i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
> (len << GMBUS_BYTE_COUNT_SHIFT) |
> (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_READ | GMBUS_SW_RDY);
This here looks like just a white-space change. But your commit message
sounds like it's not jsut write's that are affected by this issue and need
to be fixed. Can you please clear up this for easily confused me?
Thanks, Daniel
> @@ -278,7 +279,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
>
> I915_WRITE(GMBUS3 + reg_offset, val);
> I915_WRITE(GMBUS1 + reg_offset,
> -(i + 1 == num ? GMBUS_CYCLE_STOP :
> GMBUS_CYCLE_WAIT) |
> +GMBUS_CYCLE_WAIT |
> +(i + 1 == num ? GMBUS_CYCLE_STOP : 0) |
> (msgs[i].len << GMBUS_BYTE_COUNT_SHIFT) |
> (msgs[i].addr << GMBUS_SLAVE_ADDR_SHIFT) |
> GMBUS_SLAVE_WRITE | GMBUS_SW_RDY);
> @@ -317,9 +319,12 @@ clear_err:
> I915_WRITE(GMBUS1 + reg_offset, 0);
>
> done:
> - /* Mark the GMBUS interface as disabled. We will re-enable it at the
> - * start of the next xfer, till then let it sleep.
> + /* Mark the GMBUS interface as disabled after waiting for idle.
> + * We will re-enable it at the start of the next xfer,
> + * till then let it sleep.
>*/
> + if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0, 10))
> + DRM_INFO("GMBUS timed out waiting for idle\n");
> I915_WRITE(GMBUS0 + reg_offset, 0);
> return i;
>
> --
> 1.7.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 42611] [865g] webgl enabled pages crash Firefox and mesa
https://bugs.freedesktop.org/show_bug.cgi?id=42611 Will Setc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #4 from Will Setc 2012-02-13 13:10:58 PST --- I believe this was a firefox issue that mozilla devel has fixed. The crash has not shown up on any of my newer Debian installations with firefox10 and beyond. I can still trigger the crash on an 5 year old debian installation. But after adding a new user to the 5 year old debian installation the crash disappears for the new user. I tested using firefox versions 8, 9, 10, 11 and 13 with the same results for each version. Firefox url = about:support crashes when called by the 5 year old user and firefox url = about:support displays all fields of the about:support webgl page when called by the newly added user. -- 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 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)
https://bugs.freedesktop.org/show_bug.cgi?id=41668 --- Comment #23 from Alex Deucher 2012-02-13 13:40:27 UTC --- Created attachment 56992 --> https://bugs.freedesktop.org/attachment.cgi?id=56992 possible fix Does this patch help? -- 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
