Re: [PATCH v3 0/2] Enhanced EDID quirk functionality
Dear Ian, thank you a million for doing that. Am Samstag, den 11.08.2012, 23:30 -0500 schrieb Ian Pilcher: > Updated patch set, based on Paul's feedback. > > * Separate user-defined quirks stuff from new HDMI-related quirks > * (Hopefully) improve documentation Yeah, maybe somebody else can chime in. > Also continuing to explore the wonders of git format-patch and git > send-email. Just for my interest, was it very hard or in the end it took “just” half(?) an hour? I found another typo and forgot to ask you to also add `CC: sta...@kernel.org` to the patches to get them backported to older Linux releases. But I will reply to the individual patches. 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
Re: [ANNOUNCE] libdrm 2.4.38
Am Sat, 11 Aug 2012 21:25:04 +0200 schrieb Marek Olšák : > git tag: libdrm-2.4.38 > > http://dri.freedesktop.org/www/libdrm/libdrm-2.4.38.tar.bz2 > MD5: 8018e0bce5059cee05d855503d262cce libdrm-2.4.38.tar.bz2 > SHA1: 21718ddb8be71bc74845a33c2b4fbda1de942e16 libdrm-2.4.38.tar.bz2 > SHA256: > a7caec55c945f7f8dec55fea9200391a168298bcdc4cb9a93c976e748193171a > libdrm-2.4.38.tar.bz2 This is what I get here: [andyrtr@workstation64 trunk]$ sha256sum libdrm-2.4.38.tar.bz2 && md5sum libdrm-2.4.38.tar.bz2 3e5a2f318edaf1eef41e7e6c85aa9596d6f9f8b083ec4d7d6710ffbb8921e7e9 libdrm-2.4.38.tar.bz2 a910d1305adcaa6561a7450899949105 libdrm-2.4.38.tar.bz2 Can you confirm this? -Andy ArchLinux ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A dma-fence is transient, one-shot deal. It is allocated and attached
> to one or more dma-buf's. When the one that attached it is done, with
> the pending operation, it can signal the fence.
>
> + dma_fence_signal()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> TODO maybe need some helper fxn for simple devices, like a display-
> only drm/kms device which simply wants to wait for exclusive fence to
> be signaled, and then attach a non-exclusive fence while scanout is in
> progress.
>
> The one pending on the fence can add an async callback:
> + dma_fence_add_callback()
> The callback can optionally be cancelled with remove_wait_queue()
>
> Or wait synchronously (optionally with timeout or interruptible):
> + dma_fence_wait()
>
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync. But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization. For example:
>
> fence = dma_buf_get_fence(dmabuf);
> if (fence->ops == &bikeshed_fence_ops) {
> dma_buf *fence_buf;
> dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
> ... tell the hw the memory location to wait on ...
> } else {
> /* fall-back to sw sync * /
> dma_fence_add_callback(fence, my_cb);
> }
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> To facilitate other non-sw implementations, the enable_signaling callback
> can be used to keep track if a device not supporting hw sync is waiting
> on the fence, and in this case should arrange to call dma_fence_signal()
> at some point after the condition has changed, to notify other devices
> waiting on the fence. If there are no sw waiters, this can be skipped to
> avoid waking the CPU unnecessarily. The handler of the enable_signaling
> op should take a refcount until the fence is signaled, then release its ref.
>
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
>
> v1: Original
> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> that dma-fence didn't need to care about the sw->hw signaling path
> (it can be handled same as sw->sw case), and therefore the fence->ops
> can be simplified and more handled in the core. So remove the signal,
> add_callback, cancel_callback, and wait ops, and replace with a simple
> enable_signaling() op which can be used to inform a fence supporting
> hw->hw signaling that one or more devices which do not support hw
> signaling are waiting (and therefore it should enable an irq or do
> whatever is necessary in order that the CPU is notified when the
> fence is passed).
> v3: Fix locking fail in attach_fence() and get_fence()
> v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
> we decided that we need to be able to attach one fence to N dma-buf's,
> so using the list_head in dma-fence struct would be problematic.
> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
> comments
> about checking if fence fired or not. This is broken by design.
> waitqueue_active during destruction is now fatal, since the signaller
> should be holding a reference in enable_signalling until it signalled
> the fence. Pass the original dma_fence_cb along, and call __remove_wait
> in the dma_fence_callback handler, so that no cleanup needs to be
> performed.
> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
> fence wasn't signaled yet, for example for hardware fences that may
> choose to signal blindly.
> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
> header and fixed include mess. dma-fence.h now includes dma-buf.h
> All members are now initialized, so kmalloc can be used for
> allocating a dma
Re: [ANNOUNCE] libdrm 2.4.38
The thing is I didn't have the permission to upload the files, so another core developer did it for me (Jerome Glisse). It's probably just a different version of gcc between his machine and mine that caused this issue. The files should be okay and the announcement is wrong. Sorry about that. Marek On Sun, Aug 12, 2012 at 10:09 AM, Andreas Radke wrote: > Am Sat, 11 Aug 2012 21:25:04 +0200 > schrieb Marek Olšák : > >> git tag: libdrm-2.4.38 >> >> http://dri.freedesktop.org/www/libdrm/libdrm-2.4.38.tar.bz2 >> MD5: 8018e0bce5059cee05d855503d262cce libdrm-2.4.38.tar.bz2 >> SHA1: 21718ddb8be71bc74845a33c2b4fbda1de942e16 libdrm-2.4.38.tar.bz2 >> SHA256: >> a7caec55c945f7f8dec55fea9200391a168298bcdc4cb9a93c976e748193171a >> libdrm-2.4.38.tar.bz2 > > This is what I get here: > > [andyrtr@workstation64 trunk]$ sha256sum libdrm-2.4.38.tar.bz2 > && md5sum libdrm-2.4.38.tar.bz2 > 3e5a2f318edaf1eef41e7e6c85aa9596d6f9f8b083ec4d7d6710ffbb8921e7e9 > libdrm-2.4.38.tar.bz2 > a910d1305adcaa6561a7450899949105 libdrm-2.4.38.tar.bz2 > > Can you confirm this? > > -Andy > ArchLinux ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
FOSDEM2013: DevRoom or not?
Hi, The FOSDEM organizers have sent out a call for devrooms. FOSDEM this year is on the weekend of the 2nd and 3rd of February 2013. After the success of this formula last year, where, for the first time ever, we had a properly filled devroom schedule when the deadline hit, i am going to re-apply the same formula: * By the 28th of september, i need 6 committed speakers, otherwise i will not apply for a DevRoom. 6 people need to apply for a talk slot who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. This "definitely" means: * Don't knowingly plan anything else for this weekend. * Come to FOSDEM even if your corporation does not fund you (though feel free to contact the board individually for funding) * Make sure that you are allowed to travel to the shengen area in february. * Catastrophies excluded of course. Such catastrophies include things like train-derailments and such, but explicitely excludes hangovers :p * Scheduling based on timeliness of application: the earlier you apply, the better slot you get. * FOSDEMs final deadline for the full schedule is likely around 15th of january 2013. But do not count on that deadline, we will only do hourly slots, to keep people from running around between devrooms like headless chickens. Only 12-16 slots will be available, first come, first serve. I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 I hope we get a nice devroom like we had last time. That new building we were in was really amazing, even though it took a while before all FOSDEM visitors found it. Thanks, Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag.
Hi, > Subject: Re: [PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag. So obviously this should have read "gma500: ..." Let me know if I should resend. Thanks, Forest -- Forest Bond http://www.alittletooquiet.net http://www.rapidrollout.com signature.asc Description: Digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #16 from ojab 2012-08-12 14:43:34 UTC --- Still the same with latest libdrm/mesa/xf86-video-ati & kernel-3.5.1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
How to find out modeline without attaching actual device?
Dear Linux folks, regarding modelines problems with some TVs [1] and EDID quirks, Ian sent nice patches for [2], is there a way to test what modeline the DRM subsystem would choose without actually attaching the device? The problem is, the TV is at a different place and I rarely have access to it. So it would be great if I could just use some kind of simulator and pass the EDID to it, what connector it is on (though this should not matter) and I get the calculated modeline as a result. This should be enough since I already know what modeline works. Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=26294 [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026264.html 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
Re: [PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag.
On Sun, 12 Aug 2012 10:04:47 -0400 Forest Bond wrote: > Hi, > > > Subject: Re: [PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag. > > So obviously this should have read "gma500: ..." Let me know if I should > resend. No need. I'll pick these up and test them on the problem board here as well. Alan ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm: Add user-defined EDID quirks capability
Dear Ian,
Am Samstag, den 11.08.2012, 23:30 -0500 schrieb Ian Pilcher:
> Add the ability for users to define their own EDID quirks via a
> module parameter or sysfs attribute.
>
> Signed-off-by: Ian Pilcher
> Acked-by: Paul Menzel
please also add
Cc:
as documented in [1] so that users of older Linux versions can also
profit from your work.
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/stable_kernel_rules.txt;h=b0714d8f678ac51d0c280a4f5f2980196052421f;hb=HEAD
> ---
> Documentation/EDID/edid_quirks.txt | 126 ++
> drivers/gpu/drm/drm_drv.c | 2 +
> drivers/gpu/drm/drm_edid.c | 500
> -
> drivers/gpu/drm/drm_stub.c | 6 +
> drivers/gpu/drm/drm_sysfs.c| 19 ++
> include/drm/drmP.h | 10 +
> include/drm/drm_edid.h | 13 +-
> 7 files changed, 615 insertions(+), 61 deletions(-)
> create mode 100644 Documentation/EDID/edid_quirks.txt
[…]
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 9238de4..7fe39e0 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
[…]
> +/**
> + * drm_edid_quirks_store - parse and process EDID quirkl list changes written
s/quirkl/quirk/
> + * to sysfs attribute
> + */
> +ssize_t drm_edid_quirks_store(struct class *class, struct class_attribute
> *attr,
> + const char *buf, size_t count)
> +{
> + int res;
> +
> + res = drm_edid_quirks_process(buf, 1);
> + if (res != 0)
> + return res;
> +
> + return count;
> +}
> +
> /*** DDC fetch and block validation ***/
[…]
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 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #29 from Alexander E. Patrakov 2012-08-12 15:40:48 UTC --- Under Windows 7 Professional x64, I tried to use the "RW-Everything" tool to get information about the ROM of the AMD card. It failed, however, I don't know if it really means "you should not read this ROM" or just an incompatibility with Windows x64. Just for the record, it shows 0x as the expansion ROM base address for all PCI-like devices in the system. However, in the "Option ROM information", it shows the PnP header and three option ROMs correctly. However, they are for the following vendor id / device id pairs, none of which seems relevant: 0x8086/0x0126 (the Intel graphics chip), 0x11ab/0x6121 (the Marvell IDE controller) and 0x8086/0x282a (the Intel fakeraid). -- 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 v3 2/2] drm: Add EDID quirks to disable HDMI audio and InfoFrames
Am Samstag, den 11.08.2012, 23:30 -0500 schrieb Ian Pilcher: > Add EDID quirk flags to disable HDMI audio and HDMI InfoFrames. > Add quirk for LG L246WP. I know, in commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 Author: Adam Jackson Date: Wed May 23 16:26:54 2012 -0400 drm/edid/quirks: ViewSonic VA2026w it also was committed together, but I would prefer to first add the quirks and then the actual monitor. In my opinion the advantage is that then it is more visible because it is mentioned in the commit summary and therefore can be found more easily. So it would be great if you could split this patch up too although it is quite small too. Could you also mention in the commit message of the patch adding the LG monitor on what system you tested this just for the record. > Signed-off-by: Ian Pilcher > Acked-by: Paul Menzel > --- > drivers/gpu/drm/drm_edid.c | 24 > 1 file changed, 24 insertions(+) […] 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
Re: How to find out modeline without attaching actual device?
Hi Paul, On Sun, 12 August 2012 Paul Menzel wrote: > Dear Linux folks, > > regarding modelines problems with some TVs [1] and EDID quirks, Ian sent > nice patches for [2], is there a way to test what modeline the DRM > subsystem would choose without actually attaching the device? > > The problem is, the TV is at a different place and I rarely have access > to it. So it would be great if I could just use some kind of simulator > and pass the EDID to it, what connector it is on (though this should not > matter) and I get the calculated modeline as a result. > > This should be enough since I already know what modeline works. I think you can, by plugging a monitor of your choice and injecting the EDID you want to test with drm_kms_helper's edid_firmware parameter. It will then load the EDID from /lib/firmware/ instead of asking the monitor. Select CONFIG_DRM_LOAD_EDID_FIRMWARE, then when loading drm_kms_helper.ko set edid_firmware=VGA1:edid/myedid.bin module option to load EDID from /lib/firmware/edid/myedid.bin. See also Documentation/EDID/HOWTO.txt Bruno > Thanks, > > Paul > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=26294 > [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026264.html ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: FOSDEM2013: DevRoom or not?
On 08/12/12 06:50 AM, Luc Verhaegen wrote: > * By the 28th of september, i need 6 committed speakers, otherwise i > will not apply for a DevRoom. 6 people need to apply for a talk slot > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. > This "definitely" means: > * Don't knowingly plan anything else for this weekend. Which unfortunately due to scheduling this year, means not attending the end of linux.conf.au, since that runs January 28 to February 2nd, on the other end of the planet (a very long flight away from Brussels). > * Come to FOSDEM even if your corporation does not fund you (though > feel free to contact the board individually for funding) Yes, as always, the X.Org Foundation Board is willing to fund travel & lodging expenses for those who don't have other funding (including those working for companies who have declined to pay for travel). Contact bo...@foundation.x.org with requests. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/fb-helper: don't clobber output routing in setup_crtcs
Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the new drm/i915 code depends upon to be
absolutely correct.
The crtc helper itself doesn't really care about that, since it
disables unused encoders in a rather roundabout way anyway.
Two places call drm_setup_crts:
- For the initial fb config. I've auditted all current drivers, and
they all allocate their encoders with kzalloc. So there's no need to
clear encoder->crtc once more.
- When processing hotplug events while showing the fb console. This
one is a bit more tricky, but both the crtc helper code and the new
drm/i915 modeset code disable encoders if their crtc is changed and
that encoder isn't part of the new config. Also, both disable any
disconnected outputs, too.
Which only leaves encoders that are on, connected, but for some odd
reason the fb helper code doesn't want to use. That would be a bug
in the fb configuration selector, since it tries to light up as many
outputs as possible.
v2: Kill the now unused encoders variable.
Signed-Off-by: Daniel Vetter
---
Hi Dave,
This patch here is blocking the modeset-rework series, and I'd like to merge
that as soon as possible. You've merged the other two prep patches already for
3.6, but this one here popped up later on in testing.
Can you please merge this into drm-next for 3.7 so that I can backmerge it, or
smash your maintainer-ack onto it for merging through the intel tree?
Thanks, Daniel
---
drivers/gpu/drm/drm_fb_helper.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f546d1e..4ecc869 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1230,7 +1230,6 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper)
struct drm_device *dev = fb_helper->dev;
struct drm_fb_helper_crtc **crtcs;
struct drm_display_mode **modes;
- struct drm_encoder *encoder;
struct drm_mode_set *modeset;
bool *enabled;
int width, height;
@@ -1241,11 +1240,6 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper)
width = dev->mode_config.max_width;
height = dev->mode_config.max_height;
- /* clean out all the encoder/crtc combos */
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- encoder->crtc = NULL;
- }
-
crtcs = kcalloc(dev->mode_config.num_connector,
sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
modes = kcalloc(dev->mode_config.num_connector,
--
1.7.11.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 headwall changed: What|Removed |Added CC||hedv...@gmail.com --- Comment #33 from headwall 2012-08-12 17:52:10 UTC --- I tried the VFCT patch on a Mac Pro 1,1, and it gives me a kernel panic. I can't really give any details on it because the screen output is garbled. The previous patch with adding the video ROM to the kernel works, but without X support. Should the VFCT table show up in /sys/firmware/acpi/tables? If so, the Mac doesn't support this method. Does anyone know what Darwin/OSX does to get the 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
Re: 3.6-rc1 breaks my laptop graphics (intel)
On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote: > Hi Daniel. > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the > i915 driver initializes itself. I bisected this down to commit > 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the > blc controller on the right pipe), and when I revert that, and also > a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH > backlight registers) which depended on the first patch, my laptop works > just fine. > > Below is the combined revert. > > Any thoughts? Any patch I can try out? http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=770c12312ad617172b1a65b911d3e6564fc5aca8 which is already merged to drm-intel-fixes. 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: [Intel-gfx] 3.6-rc1 breaks my laptop graphics (intel)
On Sun, Aug 12, 2012 at 11:48:02AM -0700, Greg KH wrote: > On Sun, Aug 12, 2012 at 11:33:05AM -0700, Greg KH wrote: > > On Sun, Aug 12, 2012 at 08:25:31PM +0200, Daniel Vetter wrote: > > > On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote: > > > > Hi Daniel. > > > > > > > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the > > > > i915 driver initializes itself. I bisected this down to commit > > > > 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the > > > > blc controller on the right pipe), and when I revert that, and also > > > > a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH > > > > backlight registers) which depended on the first patch, my laptop works > > > > just fine. > > > > > > > > Below is the combined revert. > > > > > > > > Any thoughts? Any patch I can try out? > > > > > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=770c12312ad617172b1a65b911d3e6564fc5aca8 > > > > > > which is already merged to drm-intel-fixes. > > > > Ah, thanks, I'll go try that out, the Subject: line didn't draw my > > attention to it being the same problem as mine :) > > Yes, that works, many thanks. > > I'm guessing this is going to be going to Linus soon, right? Yeah, I'm stalling a bit for test results on an edp regression fixer that affects the new macbook air, but I'll send current -fixes to Dave in a few days. Thanks for reporting this regression, 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
[PATCH v4 0/3] Enhanced EDID quirk functionality
Another rev. I figured out how to use git reset --hard and --soft to make regenerating the patch series a bit easier. (It helped a ton that all of the later changes are isolated in a single file.) I still feel like I'm probably missing an easier way to go back a fix a simple type, however. * Fix typo * Split adding new quirk flags and adding new quirk into separate patches After reveiwing stable_kernel_rules.txt, I don't think that these patches are appropriate for -stable. I don't consider it to be "obviously correct," and it certainly isn't less than 100 lines. Thus, I'm not going to submit this for inclusion in -stable. Ian Pilcher (3): drm: Add user-defined EDID quirks capability drm: Add EDID quirks to disable HDMI audio and InfoFrames drm: Add EDID quirk for LG L246WP Documentation/EDID/edid_quirks.txt | 126 + drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_edid.c | 524 + drivers/gpu/drm/drm_stub.c | 6 + drivers/gpu/drm/drm_sysfs.c| 19 ++ include/drm/drmP.h | 10 + include/drm/drm_edid.h | 13 +- 7 files changed, 639 insertions(+), 61 deletions(-) create mode 100644 Documentation/EDID/edid_quirks.txt -- 1.7.11.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] drm: Add user-defined EDID quirks capability
Add the ability for users to define their own EDID quirks via a
module parameter or sysfs attribute.
Signed-off-by: Ian Pilcher
Acked-by: Paul Menzel
---
Documentation/EDID/edid_quirks.txt | 126 ++
drivers/gpu/drm/drm_drv.c | 2 +
drivers/gpu/drm/drm_edid.c | 500 -
drivers/gpu/drm/drm_stub.c | 6 +
drivers/gpu/drm/drm_sysfs.c| 19 ++
include/drm/drmP.h | 10 +
include/drm/drm_edid.h | 13 +-
7 files changed, 615 insertions(+), 61 deletions(-)
create mode 100644 Documentation/EDID/edid_quirks.txt
diff --git a/Documentation/EDID/edid_quirks.txt
b/Documentation/EDID/edid_quirks.txt
new file mode 100644
index 000..0c9c746
--- /dev/null
+++ b/Documentation/EDID/edid_quirks.txt
@@ -0,0 +1,126 @@
+ EDID Quirks
+ =
+ Ian Pilcher
+August 11, 2012
+
+
+"EDID blocks out in the wild have a variety of bugs"
+-- from drivers/gpu/drm/drm_edid.c
+
+
+Overview
+
+
+EDID quirks provide a mechanism for working around display hardware with buggy
+EDID data.
+
+An individual EDID quirk maps a display type (identified by its EDID
+manufacturer ID and product code[1]) to a set of "quirk flags." The kernel
+includes a variety of built-in quirks. (They are stored in the edid_quirk_list
+array in drivers/gpu/drm/drm_edid.c.)
+
+An example of a built-in EDID quirk is:
+
+ACR:0xad46:0x0001
+
+The first field is the manufacturer ID (Acer, Inc.), the second field is the
+manufacturer's product code, and the third field contains the quirk flags for
+that display type.
+
+The quirk flags are defined in drivers/gpu/drm/drm_edid.c. Each flag has a
+symbolic name beginning with EDID_QUIRK_, along with a numerical value. Each
+flag should also have an associated comment which provides an idea of its
+effect. Note that the values in the source file are expressed as bit
shifts[2]:
+
+* 1 << 0: 0x0001
+* 1 << 1: 0x0002
+* 1 << 2: 0x0004
+* etc.
+
+
+sysfs interface
+===
+
+The current EDID quirk list can be read from /sys/class/drm/edid_quirks:
+
+# cat /sys/class/drm/edid_quirks
+ ACR:0xad46:0x0001
+ API:0x7602:0x0001
+ ACR:0x0977:0x0020
+0x9e6a:0x077e:0x0080
+...
+
+("Nonconformant" manufacturer IDs are displayed as hexadecimal values.)
+
+The number of total "slots" in the list can be read from
+/sys/class/drm/edid_quirks_size. This total includes both occupied slots (i.e.
+the current list) and any slots available for additional quirks. The number of
+available slots can be calculated by subtracting the number of quirks in the
+current list from the total number of slots.
+
+If a slot is available, an additional quirk can be added to the list by writing
+it to /sys/class/drm/edid_quirks:
+
+# echo FOO:0x:0x100 > /sys/class/drm/edid_quirks
+
+Manufacturer IDs can also be specified numerically. (This is the only way to
+specify a nonconformant ID.) This command is equivalent to the previous one:
+
+# echo 0x19ef:0x:0x100 > /sys/class/drm/edid_quirks
+
+Numeric values can also be specified in decimal or octal formats; a number that
+begins with a 0 is assumed to be octal:
+
+# echo FOO:65535:0400 > /sys/class/drm/edid_quirks
+
+An existing quirk can be replaced by writing a new set of flags:
+
+# echo FOO:0x:0x200 > /sys/class/drm/edid_quirks
+
+A quirk can be deleted from the list by writing an empty flag set (0). This
+makes the slot occupied by that quirk available.
+
+# echo FOO:0x:0 > /sys/class/drm/edid_quirks
+
+Writing an "at symbol" (@) clears the entire quirk list:
+
+# echo @ > /sys/class/drm/edid_quirks
+
+Multiple changes to the list can be specified in a comma (or newline) separated
+list. For example, the following command clears all of the existing quirks in
+the list and adds 3 new quirks:
+
+# echo @,FOO:0x:0x100,BAR:0x:0x001,BAZ:0x:0x002 > \
+/sys/class/drm/edid_quirks
+
+Note however, that any error (an incorrectly formatted quirk or an attempt to
+add a quirk when no slot is available) will abort processing of any further
+changes, potentially making it difficult to determine exactly which change
+caused the error and what changes were made. For this reason, making changes
+one at a time is recommended, particularly if the changes are being made by a
+script or program.
+
+
+Module parameter
+
+
+The EDID quirk list can also be modified via the edid_quirks module parameter
+(drm.edid_quirks on the kernel command line). The effect of setting this
+parameter is identical to the effect of writing its value to
+/sys/class/drm/edid_quirks, with one important difference. When an error is
+encountered during module parameter parsing or processing, any remaining quirks
+in the paramet
[PATCH v4 2/3] drm: Add EDID quirks to disable HDMI audio and InfoFrames
Add 2 new EDID quirk flags:
- EDID_QUIRK_DISABLE_INFOFRAMES turns off all HDMI-specific
functionality (audio, HDCP, etc.). Intended for displays that
are confused by *any* InfoFrames.
- EDID_QUIRK_NO_AUDIO disables HDMI audio. Intended for displays
that incorrectely report audio capabilities in their EDID data.
Signed-off-by: Ian Pilcher
Acked-by: Paul Menzel
---
drivers/gpu/drm/drm_edid.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ea535f6..61586b4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -70,6 +70,10 @@
#define EDID_QUIRK_DETAILED_SYNC_PP(1 << 6)
/* Force reduced-blanking timings for detailed modes */
#define EDID_QUIRK_FORCE_REDUCED_BLANKING (1 << 7)
+/* Display is confused by InfoFrames; don't sent any */
+#define EDID_QUIRK_DISABLE_INFOFRAMES (1 << 8)
+/* Display doesn't have any audio output */
+#define EDID_QUIRK_NO_AUDIO(1 << 9)
struct detailed_mode_closure {
struct drm_connector *connector;
@@ -2109,6 +2113,14 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
int i, hdmi_id;
int start_offset, end_offset;
bool is_hdmi = false;
+ char buf[EDID_DISPLAY_ID_BUF_SIZE];
+
+ if (edid_get_quirks(edid) & EDID_QUIRK_DISABLE_INFOFRAMES) {
+ DRM_INFO("Disabling HDMI InfoFrames on display %s "
+"due to EDID quirk\n",
+drm_edid_display_id_format(edid->display_id, buf, 1));
+ goto end;
+ }
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
@@ -2157,6 +2169,14 @@ bool drm_detect_monitor_audio(struct edid *edid)
int i, j;
bool has_audio = false;
int start_offset, end_offset;
+ char buf[EDID_DISPLAY_ID_BUF_SIZE];
+
+ if (edid_get_quirks(edid) & EDID_QUIRK_NO_AUDIO) {
+ DRM_INFO("Disabling HDMI audio on display %s "
+"due to EDID quirk\n",
+drm_edid_display_id_format(edid->display_id, buf, 1));
+ goto end;
+ }
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
--
1.7.11.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm: Add EDID quirk for LG L246WP
This display is apparently confused by any InfoFrames (see
https://bugzilla.redhat.com/show_bug.cgi?id=806091).
Tested on a ThinkPad T510 (nVidia GT218 [NVS 3100M]) and a co-
workers ThinkPad X220 with Intel graphics. EDID_QUIRK_NO_AUDIO
makes this display work with the Intel driver; nouveau requires
EDID_QUIRK_DISABLE_INFOFRAMES.
Signed-off-by: Ian Pilcher
Acked-by: Paul Menzel
---
drivers/gpu/drm/drm_edid.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 61586b4..1f50e09 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -160,6 +160,10 @@ union edid_quirk edid_quirk_list[EDID_QUIRK_LIST_SIZE] = {
{ { { { EDID_MFG_ID('V', 'S', 'C'), cpu_to_le16(5020) } },
EDID_QUIRK_FORCE_REDUCED_BLANKING } },
+ /* LG L246WP */
+ { { { { EDID_MFG_ID('G', 'S', 'M'), cpu_to_le16(0x563f) } },
+ EDID_QUIRK_DISABLE_INFOFRAMES | EDID_QUIRK_NO_AUDIO } },
+
/*
* When adding built-in quirks, please adjust EDID_QUIRK_LIST_SIZE to
* provide some room for user-supplied quirks.
--
1.7.11.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #17 from ojab 2012-08-12 20:38:55 UTC --- The same issue on OpenGL renderer string: Gallium 0.4 on AMD RS780 OpenGL version string: 2.1 Mesa 7.11.2 (git-ea72e3c) OpenGL shading language version string: 1.20 -- 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: [UDL] general protection fault in fb_deferred_io_mkwrite()
On Sun, Aug 12, 2012 at 3:34 AM, Thomas Meyer wrote: > guilty driver is probably udl_fb.c > any ideas? > Hi Thomas, We were seeing similar issues in udlfb (the original fbdev version of this driver), which were fixed earlier this year by getting all rendering operations out of probe/disconnect -- those which might trigger fb_defio page faults in an inappropriate context, or be long-running. Here's some more detail: http://plugable.com/2012/06/21/displaylink-usb-devices-on-linux-kernel-3-4-0/comment-page-1/#comment-5896 Unfortunately, I haven't had time to get going with udl myself, so haven't been able to port and confirm. Thanks for raising and staying on this. Best wishes, Bernie [ 45.66] RIP [] fb_deferred_io_mkwrite+0xdc/0xf0 > [ 45.66] RSP > [ 45.711547] ---[ end trace d4732d5a0bf375fb ]--- > [ 45.720961] released /dev/fb1 user=1 count=0 > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] Enhanced EDID quirk functionality
On 12.08.2012 22:07, Ian Pilcher wrote: Another rev. I figured out how to use git reset --hard and --soft to make regenerating the patch series a bit easier. (It helped a ton that all of the later changes are isolated in a single file.) I still feel like I'm probably missing an easier way to go back a fix a simple type, however. Sounds like you should give interactive rebasing a try: git rebase -i It fires up an editor allowing you to make changes to you individual patches. I hope that helps, Christian. * Fix typo * Split adding new quirk flags and adding new quirk into separate patches After reveiwing stable_kernel_rules.txt, I don't think that these patches are appropriate for -stable. I don't consider it to be "obviously correct," and it certainly isn't less than 100 lines. Thus, I'm not going to submit this for inclusion in -stable. Ian Pilcher (3): drm: Add user-defined EDID quirks capability drm: Add EDID quirks to disable HDMI audio and InfoFrames drm: Add EDID quirk for LG L246WP Documentation/EDID/edid_quirks.txt | 126 + drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_edid.c | 524 + drivers/gpu/drm/drm_stub.c | 6 + drivers/gpu/drm/drm_sysfs.c| 19 ++ include/drm/drmP.h | 10 + include/drm/drm_edid.h | 13 +- 7 files changed, 639 insertions(+), 61 deletions(-) create mode 100644 Documentation/EDID/edid_quirks.txt ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 0/3] Enhanced EDID quirk functionality
Dear Ian, thank you very much for your quick iterations. Hopefully the developers will review this on Monday. Am Sonntag, den 12.08.2012, 15:07 -0500 schrieb Ian Pilcher: > Another rev. I figured out how to use git reset --hard and --soft to > make regenerating the patch series a bit easier. (It helped a ton > that all of the later changes are isolated in a single file.) Definitely. Wasn’t `git add -p` helpful? > I still feel like I'm probably missing an easier way to go back a fix > a simple type, however. Have you heard of `git rebase` already. That is the more complex version of `git commit --amend`. If the typo is in the last commit just do make the change and do `git commit --amend -a`. If you want to change some earlier commit (like 2 ahead), either do the fix, commit it and do `git rebase -i HEAD~3` and reorder the commits to put the fix at the correct place and change `pick` to `f` for fix up. Or do `git rebase -i HEAD~3` and choose the commits you need to edit and then commit these changes with `git commit -a --amend`. > * Fix typo > > * Split adding new quirk flags and adding new quirk into separate > patches > > After reveiwing stable_kernel_rules.txt, I don't think that these > patches are appropriate for -stable. I don't consider it to be > "obviously correct," and it certainly isn't less than 100 lines. > Thus, I'm not going to submit this for inclusion in -stable. Hmm, three things. 1. I would try anyway. The stable maintainer will reject it if they think it is not appropriate. 2. Your last quirk should be back ported. One solution would be, you first submit patches to add the quirks and the monitor and then add the functionality. 3. I also need to add two monitors to the quirk list which need to be backported. If I try to get them in before yours, you would have to rebase your patches again. Also likely future quirks would need to be backported in a complicated way. So I vote for getting this into stable and hopefully the maintainers agree. 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
3.4.0 -> 3.5.0 bad rendering effects on radeon
Hi, I use Fedora 17 and as soon as kernel 3.5 has been distributed, I get very bad rendering artifacts on my laptop. The laptop is a Thinkpad R50 with a radeon graphics card 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02) It is not a new laptop, about 8 years old. I've opened a bug at Fedora where you can see 2 pictures of what happens. https://bugzilla.redhat.com/show_bug.cgi?id=845639 Reading the mailing list, I cannot understand if this problem has already been reported. I've tried to bisect but I've hit a series of unbootable kernels. "git bisect visualize" currently shows the log between BAD:be122ab Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6 GOOD: c10e408 i915: Add option to bypass vbt table. where I can see a lot of drm related changes. Regards ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
On 2012-08-08 21:50, George Spelvin wrote: I'm trying to run a v3.5 kernel (plus some -stable patches from Ted Ts'o) on an Ubuntu system. Things are generally working except for the following Oops on each boot, which prevents the graphics system from loading. [ 36.187972] [drm] Initialized drm 1.1.0 20060810 [ 36.230306] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround [ 36.487606] i915 :00:02.0: setting latency timer to 64 [ 36.555464] [drm] GMBUS [i915 gmbus ssc] timed out, falling back to bit banging on pin 0 [ 36.555490] BUG: unable to handle kernel NULL pointer dereference at 0028 [ 36.555626] IP: [] bit_xfer+0x23/0x870 [i2c_algo_bit] [ 36.555701] PGD 212cb0067 PUD 212caf067 PMD 0 [ 36.555803] Oops: [#1] SMP [ 36.555885] CPU 3 [ 36.555907] Modules linked in: snd_seq_midi joydev i915(+) snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer snd_seq_device kvm_intel drm kvm snd serio_raw soundcore i2c_algo_bit snd_page_alloc lpc_ich video mei microcode mac_hid eeprom it87 hwmon_vid coretemp lp parport raid10 raid456 async_pq async_xor firewire_ohci firewire_core xor async_memcpy async_raid6_recov hid_microsoft floppy crc_itu_t r8169 pata_jmicron usbhid hid mptsas mptscsih mptbase scsi_transport_sas raid6_pq async_tx raid1 raid0 multipath linear [ 36.557232] [ 36.557271] Pid: 623, comm: modprobe Not tainted 3.5.0 #3 Gigabyte Technology Co., Ltd. H57M-USB3/H57M-USB3 [ 36.557398] RIP: 0010:[] [] bit_xfer+0x23/0x870 [i2c_algo_bit] [ 36.557493] RSP: :880212c6d648 EFLAGS: 00010296 [ 36.557544] RAX: 88021222c030 RBX: 880212c6d7e8 RCX: [ 36.557599] RDX: 0001 RSI: 880212c6d7e8 RDI: 88021222c030 [ 36.557655] RBP: 880212c6d6c8 R08: 0402 R09: [ 36.557710] R10: R11: 0006 R12: 0001 [ 36.557766] R13: 880212c6dfd8 R14: 0001 R15: 88021222c030 [ 36.557822] FS: 7f5a7b85b700() GS:88021fcc() knlGS: [ 36.557899] CS: 0010 DS: ES: CR0: 8005003b [ 36.557950] CR2: 0028 CR3: 000212cad000 CR4: 07e0 [ 36.558006] DR0: DR1: DR2: [ 36.558062] DR3: DR6: 0ff0 DR7: 0400 [ 36.558119] Process modprobe (pid: 623, threadinfo 880212c6c000, task 88020fdf5b80) [ 36.558197] Stack: [ 36.558239] 0001 880212c6dfd8 0001 00011222c000 [ 36.558380] 880212c6d6c8 8166341e 88020ff6ca72 000c510c0018 [ 36.558523] 880212c6d6d8 880212c6d698 0082 880212c6d7e8 [ 36.558671] Call Trace: [ 36.558719] [] ? printk+0x61/0x63 [ 36.558790] [] gmbus_xfer+0x56b/0x6f0 [i915] [ 36.558847] [] i2c_transfer+0x9c/0xe0 [ 36.558899] [] ? ep_poll_callback+0x10b/0x150 [ 36.558953] [] i2c_smbus_xfer_emulated+0x156/0x5d0 [ 36.559010] [] ? idr_get_empty_slot+0x115/0x320 [ 36.559064] [] i2c_smbus_xfer+0x113/0x130 [ 36.559118] [] ? _raw_spin_lock+0xe/0x20 [ 36.559173] [] ? klist_next+0x89/0x110 [ 36.559225] [] i2c_default_probe+0xeb/0x130 [ 36.559279] [] ? i2c_check_addr_busy+0x3b/0x60 [ 36.559332] [] i2c_do_add_adapter+0x1bb/0x290 [ 36.559382] [] ? sysfs_do_create_link+0xeb/0x200 [ 36.559433] [] ? put_device+0x17/0x20 [ 36.559482] [] ? __process_new_driver+0x30/0x30 [ 36.559535] [] __process_new_adapter+0x12/0x20 [ 36.559590] [] bus_for_each_drv+0x4e/0xa0 [ 36.559642] [] i2c_register_adapter+0x16d/0x270 [ 36.559696] [] i2c_add_adapter+0xa3/0xb0 [ 36.559759] [] intel_setup_gmbus+0xcc/0x1f0 [i915] [ 36.559821] [] i915_driver_load+0x2ac/0xb90 [i915] [ 36.559882] [] ? drm_get_minor+0x261/0x300 [drm] [ 36.559940] [] drm_get_pci_dev+0x186/0x2d0 [drm] [ 36.559995] [] ? default_spin_lock_flags+0x9/0x10 [ 36.560060] [] i915_pci_probe+0x16/0x20 [i915] [ 36.560115] [] local_pci_probe+0x5c/0xd0 [ 36.560168] [] pci_device_probe+0x111/0x120 [ 36.560221] [] driver_probe_device+0x7e/0x220 [ 36.560274] [] __driver_attach+0xab/0xb0 [ 36.560327] [] ? driver_probe_device+0x220/0x220 [ 36.560375] [] bus_for_each_dev+0x55/0x90 [ 36.560421] [] ? 0xa0322fff [ 36.560470] [] driver_attach+0x1e/0x20 [ 36.560522] [] bus_add_driver+0x198/0x270 [ 36.560573] [] ? 0xa0322fff [ 36.560625] [] driver_register+0x77/0x150 [ 36.560677] [] ? 0xa0322fff [ 36.560729] [] __pci_register_driver+0x5e/0xe0 [ 36.560784] [] ? 0xa0322fff [ 36.560839] [] drm_pci_init+0x11a/0x130 [drm] [ 36.560892] [] ? 0xa0322fff [ 36.560949] [] i915_init+0x8b/0x8d [i915] [ 36.561004] [] do_one_initcall+0x12a/0x180 [ 36.561057] [] sys_init_module+0x10b0/0x1f40 [ 36.56] [] ? free_notes_attrs+0x60/0x60 [ 36.561165] [] system_call_
[PATCH] drm/radeon: Include swiotlb.h if SWIOTLB configured.
When SWIOTLB is configured, if without this patch kernel compilation fails. Signed-off-by: Huacai Chen Signed-off-by: Hongliang Tao Signed-off-by: Hua Yan Cc: dri-devel@lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_ttm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index 5b71c71..fc3ac22 100644 --- a/drivers/gpu/drm/radeon/radeon_ttm.c +++ b/drivers/gpu/drm/radeon/radeon_ttm.c @@ -41,6 +41,10 @@ #include "radeon_reg.h" #include "radeon.h" +#ifdef CONFIG_SWIOTLB +#include +#endif + #define DRM_FILE_PAGE_OFFSET (0x1ULL >> PAGE_SHIFT) static int radeon_ttm_debugfs_init(struct radeon_device *rdev); -- 1.7.7.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 62/62] drivers/gpu/drm/i915/i915_debugfs.c:1959:6: warning: unused variable 'ret'
Hi Daniel,
FYI, there are new compile warnings show up in
tree: git://people.freedesktop.org/~danvet/drm-intel.git drm-intel-next-queued
head: ffedf4590c151968e7881e0bbf340da648dfd072
commit: ffedf4590c151968e7881e0bbf340da648dfd072 [62/62] drm/i915: don't grab
dev->struct_mutex for userspace forcewak
config: x86_64-allmodconfig (attached as .config)
All error/warnings:
drivers/gpu/drm/i915/i915_debugfs.c: In function 'i915_forcewake_open':
drivers/gpu/drm/i915/i915_debugfs.c:1959:6: warning: unused variable 'ret'
[-Wunused-variable]
vim +1959 drivers/gpu/drm/i915/i915_debugfs.c
1956 {
1957 struct drm_device *dev = inode->i_private;
1958 struct drm_i915_private *dev_priv = dev->dev_private;
> 1959 int ret;
1960
1961 if (INTEL_INFO(dev)->gen < 6)
1962 return 0;
---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu Intel Corporation
-- next part --
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 3.5.0-rc4 Kernel Configuration
#
CONFIG_64BIT=y
# CONFIG_X86_32 is not set
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_GPIO=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx
-fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10
-fcall-saved-r11"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_CONSTRUCTORS=y
CONFIG_HAVE_IRQ_WORK=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_FHANDLE=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_DEBUG=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_RCU_FANOUT=64
CONFIG_RCU_FANOUT_LEAF=16
CONFIG_RCU_FANOUT_EXACT=y
CONFIG_RCU_FAST_NO_HZ=y
CONFIG_TREE_RCU_TRACE=y
CONFIG_IKCONFIG=m
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUPS=y
CONFIG_CGROUP_DEBUG=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_CGROUP_MEM_RES_CTLR is not set
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_DEBUG_BLK_CGROUP=y
CONFIG_CHECKPOINT_RESTORE=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="
[PATCH v3 0/2] Enhanced EDID quirk functionality
Dear Ian, thank you a million for doing that. Am Samstag, den 11.08.2012, 23:30 -0500 schrieb Ian Pilcher: > Updated patch set, based on Paul's feedback. > > * Separate user-defined quirks stuff from new HDMI-related quirks > * (Hopefully) improve documentation Yeah, maybe somebody else can chime in. > Also continuing to explore the wonders of git format-patch and git > send-email. Just for my interest, was it very hard or in the end it took ?just? half(?) an hour? I found another typo and forgot to ask you to also add `CC: stable at kernel.org` to the patches to get them backported to older Linux releases. But I will reply to the individual patches. Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120812/bf42e33b/attachment.pgp>
[ANNOUNCE] libdrm 2.4.38
Am Sat, 11 Aug 2012 21:25:04 +0200 schrieb Marek Ol??k : > git tag: libdrm-2.4.38 > > http://dri.freedesktop.org/www/libdrm/libdrm-2.4.38.tar.bz2 > MD5: 8018e0bce5059cee05d855503d262cce libdrm-2.4.38.tar.bz2 > SHA1: 21718ddb8be71bc74845a33c2b4fbda1de942e16 libdrm-2.4.38.tar.bz2 > SHA256: > a7caec55c945f7f8dec55fea9200391a168298bcdc4cb9a93c976e748193171a > libdrm-2.4.38.tar.bz2 This is what I get here: [andyrtr at workstation64 trunk]$ sha256sum libdrm-2.4.38.tar.bz2 && md5sum libdrm-2.4.38.tar.bz2 3e5a2f318edaf1eef41e7e6c85aa9596d6f9f8b083ec4d7d6710ffbb8921e7e9 libdrm-2.4.38.tar.bz2 a910d1305adcaa6561a7450899949105 libdrm-2.4.38.tar.bz2 Can you confirm this? -Andy ArchLinux
[drm-intel:drm-intel-next-queued 62/62] drivers/gpu/drm/i915/i915_debugfs.c:1959:6: warning: unused variable 'ret'
On Sun, Aug 12, 2012 at 07:45:11AM +0800, Fengguang Wu wrote:
> Hi Daniel,
>
> FYI, there are new compile warnings show up in
Thanks for catching this, I've (once again) forgotten to git add before
sending out the final patch :(
-Daniel
>
> tree: git://people.freedesktop.org/~danvet/drm-intel.git
> drm-intel-next-queued
> head: ffedf4590c151968e7881e0bbf340da648dfd072
> commit: ffedf4590c151968e7881e0bbf340da648dfd072 [62/62] drm/i915: don't grab
> dev->struct_mutex for userspace forcewak
> config: x86_64-allmodconfig (attached as .config)
>
> All error/warnings:
>
> drivers/gpu/drm/i915/i915_debugfs.c: In function 'i915_forcewake_open':
> drivers/gpu/drm/i915/i915_debugfs.c:1959:6: warning: unused variable 'ret'
> [-Wunused-variable]
>
> vim +1959 drivers/gpu/drm/i915/i915_debugfs.c
> 1956{
> 1957struct drm_device *dev = inode->i_private;
> 1958struct drm_i915_private *dev_priv = dev->dev_private;
> > 1959int ret;
> 1960
> 1961if (INTEL_INFO(dev)->gen < 6)
> 1962return 0;
>
> ---
> 0-DAY kernel build testing backend Open Source Technology Centre
> Fengguang Wu Intel Corporation
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 3.5.0-rc4 Kernel Configuration
> #
> CONFIG_64BIT=y
> # CONFIG_X86_32 is not set
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_HAVE_LATENCYTOP_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_GENERIC_GPIO=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> # CONFIG_RWSEM_GENERIC_SPINLOCK is not set
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_DEFAULT_IDLE=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_HAVE_INTEL_TXT=y
> CONFIG_X86_64_SMP=y
> CONFIG_X86_HT=y
> CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi
> -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9
> -fcall-saved-r10 -fcall-saved-r11"
> CONFIG_ARCH_CPU_PROBE_RELEASE=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_CONSTRUCTORS=y
> CONFIG_HAVE_IRQ_WORK=y
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
>
> #
> # General setup
> #
> CONFIG_EXPERIMENTAL=y
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> CONFIG_LOCALVERSION=""
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> CONFIG_DEFAULT_HOSTNAME="(none)"
> CONFIG_SWAP=y
> CONFIG_SYSVIPC=y
> CONFIG_SYSVIPC_SYSCTL=y
> CONFIG_POSIX_MQUEUE=y
> CONFIG_POSIX_MQUEUE_SYSCTL=y
> CONFIG_BSD_PROCESS_ACCT=y
> CONFIG_BSD_PROCESS_ACCT_V3=y
> CONFIG_FHANDLE=y
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> CONFIG_AUDIT=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_WATCH=y
> CONFIG_AUDIT_TREE=y
> CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
> CONFIG_HAVE_GENERIC_HARDIRQS=y
>
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_HARDIRQS=y
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_DEBUG=y
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
>
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
>
> #
> # RCU Subsystem
> #
> CONFIG_TREE_RCU=y
> # CONFIG_PREEMPT_RCU is not set
> CONFIG_RCU_FANOUT=64
> CONFIG_RCU_FANOUT_LEAF=16
> CONFIG_RCU_FANOUT_EXACT=y
> CONFIG_RCU_FAST_NO_HZ=y
> CONFIG_TREE_RCU_TRACE=y
> CONFIG_IKCONFIG=m
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=17
> CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
> CONFIG_CGROUPS=y
> CONFIG_CGROUP_DEBUG=y
> CONFIG_CGROUP_FREEZER=y
> CONFIG_CGROUP_DEVICE=y
> CONFIG_CPUSETS=y
> CONFIG_PROC_PID_CPUS
[Linaro-mm-sig] [PATCH 2/4] dma-fence: dma-buf synchronization (v8 )
On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
> A dma-fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device. For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering. The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
>
> A dma-fence is transient, one-shot deal. It is allocated and attached
> to one or more dma-buf's. When the one that attached it is done, with
> the pending operation, it can signal the fence.
>
> + dma_fence_signal()
>
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
>
> TODO maybe need some helper fxn for simple devices, like a display-
> only drm/kms device which simply wants to wait for exclusive fence to
> be signaled, and then attach a non-exclusive fence while scanout is in
> progress.
>
> The one pending on the fence can add an async callback:
> + dma_fence_add_callback()
> The callback can optionally be cancelled with remove_wait_queue()
>
> Or wait synchronously (optionally with timeout or interruptible):
> + dma_fence_wait()
>
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync. But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization. For example:
>
> fence = dma_buf_get_fence(dmabuf);
> if (fence->ops == &bikeshed_fence_ops) {
> dma_buf *fence_buf;
> dma_bikeshed_fence_get_buf(fence, &fence_buf, &offset);
> ... tell the hw the memory location to wait on ...
> } else {
> /* fall-back to sw sync * /
> dma_fence_add_callback(fence, my_cb);
> }
>
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
>
> To facilitate other non-sw implementations, the enable_signaling callback
> can be used to keep track if a device not supporting hw sync is waiting
> on the fence, and in this case should arrange to call dma_fence_signal()
> at some point after the condition has changed, to notify other devices
> waiting on the fence. If there are no sw waiters, this can be skipped to
> avoid waking the CPU unnecessarily. The handler of the enable_signaling
> op should take a refcount until the fence is signaled, then release its ref.
>
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
>
> v1: Original
> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> that dma-fence didn't need to care about the sw->hw signaling path
> (it can be handled same as sw->sw case), and therefore the fence->ops
> can be simplified and more handled in the core. So remove the signal,
> add_callback, cancel_callback, and wait ops, and replace with a simple
> enable_signaling() op which can be used to inform a fence supporting
> hw->hw signaling that one or more devices which do not support hw
> signaling are waiting (and therefore it should enable an irq or do
> whatever is necessary in order that the CPU is notified when the
> fence is passed).
> v3: Fix locking fail in attach_fence() and get_fence()
> v4: Remove tie-in w/ dma-buf.. after discussion w/ danvet and mlankorst
> we decided that we need to be able to attach one fence to N dma-buf's,
> so using the list_head in dma-fence struct would be problematic.
> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some
> comments
> about checking if fence fired or not. This is broken by design.
> waitqueue_active during destruction is now fatal, since the signaller
> should be holding a reference in enable_signalling until it signalled
> the fence. Pass the original dma_fence_cb along, and call __remove_wait
> in the dma_fence_callback handler, so that no cleanup needs to be
> performed.
> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
> fence wasn't signaled yet, for example for hardware fences that may
> choose to signal blindly.
> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
> header and fixed include mess. dma-fence.h now includes dma-buf.h
> All members are now initialized, so kmalloc can be used for
> allocating a dma
[ANNOUNCE] libdrm 2.4.38
The thing is I didn't have the permission to upload the files, so another core developer did it for me (Jerome Glisse). It's probably just a different version of gcc between his machine and mine that caused this issue. The files should be okay and the announcement is wrong. Sorry about that. Marek On Sun, Aug 12, 2012 at 10:09 AM, Andreas Radke wrote: > Am Sat, 11 Aug 2012 21:25:04 +0200 > schrieb Marek Ol??k : > >> git tag: libdrm-2.4.38 >> >> http://dri.freedesktop.org/www/libdrm/libdrm-2.4.38.tar.bz2 >> MD5: 8018e0bce5059cee05d855503d262cce libdrm-2.4.38.tar.bz2 >> SHA1: 21718ddb8be71bc74845a33c2b4fbda1de942e16 libdrm-2.4.38.tar.bz2 >> SHA256: >> a7caec55c945f7f8dec55fea9200391a168298bcdc4cb9a93c976e748193171a >> libdrm-2.4.38.tar.bz2 > > This is what I get here: > > [andyrtr at workstation64 trunk]$ sha256sum libdrm-2.4.38.tar.bz2 > && md5sum libdrm-2.4.38.tar.bz2 > 3e5a2f318edaf1eef41e7e6c85aa9596d6f9f8b083ec4d7d6710ffbb8921e7e9 > libdrm-2.4.38.tar.bz2 > a910d1305adcaa6561a7450899949105 libdrm-2.4.38.tar.bz2 > > Can you confirm this? > > -Andy > ArchLinux
FOSDEM2013: DevRoom or not?
Hi, The FOSDEM organizers have sent out a call for devrooms. FOSDEM this year is on the weekend of the 2nd and 3rd of February 2013. After the success of this formula last year, where, for the first time ever, we had a properly filled devroom schedule when the deadline hit, i am going to re-apply the same formula: * By the 28th of september, i need 6 committed speakers, otherwise i will not apply for a DevRoom. 6 people need to apply for a talk slot who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. This "definitely" means: * Don't knowingly plan anything else for this weekend. * Come to FOSDEM even if your corporation does not fund you (though feel free to contact the board individually for funding) * Make sure that you are allowed to travel to the shengen area in february. * Catastrophies excluded of course. Such catastrophies include things like train-derailments and such, but explicitely excludes hangovers :p * Scheduling based on timeliness of application: the earlier you apply, the better slot you get. * FOSDEMs final deadline for the full schedule is likely around 15th of january 2013. But do not count on that deadline, we will only do hourly slots, to keep people from running around between devrooms like headless chickens. Only 12-16 slots will be available, first come, first serve. I will set up a wiki page tonight, at http://wiki.x.org/wiki/fosdem2013 I hope we get a nice devroom like we had last time. That new building we were in was really amazing, even though it took a while before all FOSDEM visitors found it. Thanks, Luc Verhaegen.
[PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag.
Hi, > Subject: Re: [PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag. So obviously this should have read "gma500: ..." Let me know if I should resend. Thanks, Forest -- Forest Bond http://www.alittletooquiet.net http://www.rapidrollout.com -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120812/ee540612/attachment.pgp>
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #16 from ojab 2012-08-12 14:43:34 UTC --- Still the same with latest libdrm/mesa/xf86-video-ati & kernel-3.5.1. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
How to find out modeline without attaching actual device?
Dear Linux folks, regarding modelines problems with some TVs [1] and EDID quirks, Ian sent nice patches for [2], is there a way to test what modeline the DRM subsystem would choose without actually attaching the device? The problem is, the TV is at a different place and I rarely have access to it. So it would be great if I could just use some kind of simulator and pass the EDID to it, what connector it is on (though this should not matter) and I get the calculated modeline as a result. This should be enough since I already know what modeline works. Thanks, Paul [1] https://bugs.freedesktop.org/show_bug.cgi?id=26294 [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026264.html -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120812/eac0c8ce/attachment.pgp>
[PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag.
On Sun, 12 Aug 2012 10:04:47 -0400 Forest Bond wrote: > Hi, > > > Subject: Re: [PATCH 2/3] gma: psb_intel_crtc: Drop crtc_enable flag. > > So obviously this should have read "gma500: ..." Let me know if I should > resend. No need. I'll pick these up and test them on the problem board here as well. Alan
[PATCH v3 1/2] drm: Add user-defined EDID quirks capability
Dear Ian,
Am Samstag, den 11.08.2012, 23:30 -0500 schrieb Ian Pilcher:
> Add the ability for users to define their own EDID quirks via a
> module parameter or sysfs attribute.
>
> Signed-off-by: Ian Pilcher
> Acked-by: Paul Menzel
please also add
Cc:
as documented in [1] so that users of older Linux versions can also
profit from your work.
[1]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/stable_kernel_rules.txt;h=b0714d8f678ac51d0c280a4f5f2980196052421f;hb=HEAD
> ---
> Documentation/EDID/edid_quirks.txt | 126 ++
> drivers/gpu/drm/drm_drv.c | 2 +
> drivers/gpu/drm/drm_edid.c | 500
> -
> drivers/gpu/drm/drm_stub.c | 6 +
> drivers/gpu/drm/drm_sysfs.c| 19 ++
> include/drm/drmP.h | 10 +
> include/drm/drm_edid.h | 13 +-
> 7 files changed, 615 insertions(+), 61 deletions(-)
> create mode 100644 Documentation/EDID/edid_quirks.txt
[?]
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 9238de4..7fe39e0 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
[?]
> +/**
> + * drm_edid_quirks_store - parse and process EDID quirkl list changes written
s/quirkl/quirk/
> + * to sysfs attribute
> + */
> +ssize_t drm_edid_quirks_store(struct class *class, struct class_attribute
> *attr,
> + const char *buf, size_t count)
> +{
> + int res;
> +
> + res = drm_edid_quirks_process(buf, 1);
> + if (res != 0)
> + return res;
> +
> + return count;
> +}
> +
> /*** DDC fetch and block validation ***/
[?]
Thanks,
Paul
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120812/267d1552/attachment.pgp>
[Bug 41265] Radeon KMS does not work on thunderbolt media dock
https://bugs.freedesktop.org/show_bug.cgi?id=41265 --- Comment #29 from Alexander E. Patrakov 2012-08-12 15:40:48 UTC --- Under Windows 7 Professional x64, I tried to use the "RW-Everything" tool to get information about the ROM of the AMD card. It failed, however, I don't know if it really means "you should not read this ROM" or just an incompatibility with Windows x64. Just for the record, it shows 0x as the expansion ROM base address for all PCI-like devices in the system. However, in the "Option ROM information", it shows the PnP header and three option ROMs correctly. However, they are for the following vendor id / device id pairs, none of which seems relevant: 0x8086/0x0126 (the Intel graphics chip), 0x11ab/0x6121 (the Marvell IDE controller) and 0x8086/0x282a (the Intel fakeraid). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH v3 2/2] drm: Add EDID quirks to disable HDMI audio and InfoFrames
Am Samstag, den 11.08.2012, 23:30 -0500 schrieb Ian Pilcher: > Add EDID quirk flags to disable HDMI audio and HDMI InfoFrames. > Add quirk for LG L246WP. I know, in commit bc42aabc6a01b92b0f961d65671564e0e1cd7592 Author: Adam Jackson Date: Wed May 23 16:26:54 2012 -0400 drm/edid/quirks: ViewSonic VA2026w it also was committed together, but I would prefer to first add the quirks and then the actual monitor. In my opinion the advantage is that then it is more visible because it is mentioned in the commit summary and therefore can be found more easily. So it would be great if you could split this patch up too although it is quite small too. Could you also mention in the commit message of the patch adding the LG monitor on what system you tested this just for the record. > Signed-off-by: Ian Pilcher > Acked-by: Paul Menzel > --- > drivers/gpu/drm/drm_edid.c | 24 > 1 file changed, 24 insertions(+) [?] Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120812/386aa2de/attachment.pgp>
How to find out modeline without attaching actual device?
Hi Paul, On Sun, 12 August 2012 Paul Menzel wrote: > Dear Linux folks, > > regarding modelines problems with some TVs [1] and EDID quirks, Ian sent > nice patches for [2], is there a way to test what modeline the DRM > subsystem would choose without actually attaching the device? > > The problem is, the TV is at a different place and I rarely have access > to it. So it would be great if I could just use some kind of simulator > and pass the EDID to it, what connector it is on (though this should not > matter) and I get the calculated modeline as a result. > > This should be enough since I already know what modeline works. I think you can, by plugging a monitor of your choice and injecting the EDID you want to test with drm_kms_helper's edid_firmware parameter. It will then load the EDID from /lib/firmware/ instead of asking the monitor. Select CONFIG_DRM_LOAD_EDID_FIRMWARE, then when loading drm_kms_helper.ko set edid_firmware=VGA1:edid/myedid.bin module option to load EDID from /lib/firmware/edid/myedid.bin. See also Documentation/EDID/HOWTO.txt Bruno > Thanks, > > Paul > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=26294 > [2] http://lists.freedesktop.org/archives/dri-devel/2012-August/026264.html
FOSDEM2013: DevRoom or not?
On 08/12/12 06:50 AM, Luc Verhaegen wrote: > * By the 28th of september, i need 6 committed speakers, otherwise i > will not apply for a DevRoom. 6 people need to apply for a talk slot > who _definitely_ will come to FOSDEM on February 2nd and/or 3rd 2013. > This "definitely" means: > * Don't knowingly plan anything else for this weekend. Which unfortunately due to scheduling this year, means not attending the end of linux.conf.au, since that runs January 28 to February 2nd, on the other end of the planet (a very long flight away from Brussels). > * Come to FOSDEM even if your corporation does not fund you (though > feel free to contact the board individually for funding) Yes, as always, the X.Org Foundation Board is willing to fund travel & lodging expenses for those who don't have other funding (including those working for companies who have declined to pay for travel). Contact board at foundation.x.org with requests. -- -Alan Coopersmith- alan.coopersmith at oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc
[PATCH] drm/fb-helper: don't clobber output routing in setup_crtcs
Yet again the too close relationship between the fb helper and the
crtc helper code strikes. This time around the fb helper resets all
encoder->crtc pointers to NULL before starting to set up it's own
mode. Which is total bullocks, because this will clobber the existing
output routing, which the new drm/i915 code depends upon to be
absolutely correct.
The crtc helper itself doesn't really care about that, since it
disables unused encoders in a rather roundabout way anyway.
Two places call drm_setup_crts:
- For the initial fb config. I've auditted all current drivers, and
they all allocate their encoders with kzalloc. So there's no need to
clear encoder->crtc once more.
- When processing hotplug events while showing the fb console. This
one is a bit more tricky, but both the crtc helper code and the new
drm/i915 modeset code disable encoders if their crtc is changed and
that encoder isn't part of the new config. Also, both disable any
disconnected outputs, too.
Which only leaves encoders that are on, connected, but for some odd
reason the fb helper code doesn't want to use. That would be a bug
in the fb configuration selector, since it tries to light up as many
outputs as possible.
v2: Kill the now unused encoders variable.
Signed-Off-by: Daniel Vetter
---
Hi Dave,
This patch here is blocking the modeset-rework series, and I'd like to merge
that as soon as possible. You've merged the other two prep patches already for
3.6, but this one here popped up later on in testing.
Can you please merge this into drm-next for 3.7 so that I can backmerge it, or
smash your maintainer-ack onto it for merging through the intel tree?
Thanks, Daniel
---
drivers/gpu/drm/drm_fb_helper.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index f546d1e..4ecc869 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -1230,7 +1230,6 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper)
struct drm_device *dev = fb_helper->dev;
struct drm_fb_helper_crtc **crtcs;
struct drm_display_mode **modes;
- struct drm_encoder *encoder;
struct drm_mode_set *modeset;
bool *enabled;
int width, height;
@@ -1241,11 +1240,6 @@ static void drm_setup_crtcs(struct drm_fb_helper
*fb_helper)
width = dev->mode_config.max_width;
height = dev->mode_config.max_height;
- /* clean out all the encoder/crtc combos */
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- encoder->crtc = NULL;
- }
-
crtcs = kcalloc(dev->mode_config.num_connector,
sizeof(struct drm_fb_helper_crtc *), GFP_KERNEL);
modes = kcalloc(dev->mode_config.num_connector,
--
1.7.11.2
[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot
https://bugs.freedesktop.org/show_bug.cgi?id=26891 headwall changed: What|Removed |Added CC||hedvall at gmail.com --- Comment #33 from headwall 2012-08-12 17:52:10 UTC --- I tried the VFCT patch on a Mac Pro 1,1, and it gives me a kernel panic. I can't really give any details on it because the screen output is garbled. The previous patch with adding the video ROM to the kernel works, but without X support. Should the VFCT table show up in /sys/firmware/acpi/tables? If so, the Mac doesn't support this method. Does anyone know what Darwin/OSX does to get the ROM? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
3.6-rc1 breaks my laptop graphics (intel)
On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote: > Hi Daniel. > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the > i915 driver initializes itself. I bisected this down to commit > 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the > blc controller on the right pipe), and when I revert that, and also > a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH > backlight registers) which depended on the first patch, my laptop works > just fine. > > Below is the combined revert. > > Any thoughts? Any patch I can try out? http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=770c12312ad617172b1a65b911d3e6564fc5aca8 which is already merged to drm-intel-fixes. Thanks, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[Intel-gfx] 3.6-rc1 breaks my laptop graphics (intel)
On Sun, Aug 12, 2012 at 11:48:02AM -0700, Greg KH wrote: > On Sun, Aug 12, 2012 at 11:33:05AM -0700, Greg KH wrote: > > On Sun, Aug 12, 2012 at 08:25:31PM +0200, Daniel Vetter wrote: > > > On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote: > > > > Hi Daniel. > > > > > > > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the > > > > i915 driver initializes itself. I bisected this down to commit > > > > 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the > > > > blc controller on the right pipe), and when I revert that, and also > > > > a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH > > > > backlight registers) which depended on the first patch, my laptop works > > > > just fine. > > > > > > > > Below is the combined revert. > > > > > > > > Any thoughts? Any patch I can try out? > > > > > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=770c12312ad617172b1a65b911d3e6564fc5aca8 > > > > > > which is already merged to drm-intel-fixes. > > > > Ah, thanks, I'll go try that out, the Subject: line didn't draw my > > attention to it being the same problem as mine :) > > Yes, that works, many thanks. > > I'm guessing this is going to be going to Linus soon, right? Yeah, I'm stalling a bit for test results on an edp regression fixer that affects the new macbook air, but I'll send current -fixes to Dave in a few days. Thanks for reporting this regression, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH v4 0/3] Enhanced EDID quirk functionality
Another rev. I figured out how to use git reset --hard and --soft to make regenerating the patch series a bit easier. (It helped a ton that all of the later changes are isolated in a single file.) I still feel like I'm probably missing an easier way to go back a fix a simple type, however. * Fix typo * Split adding new quirk flags and adding new quirk into separate patches After reveiwing stable_kernel_rules.txt, I don't think that these patches are appropriate for -stable. I don't consider it to be "obviously correct," and it certainly isn't less than 100 lines. Thus, I'm not going to submit this for inclusion in -stable. Ian Pilcher (3): drm: Add user-defined EDID quirks capability drm: Add EDID quirks to disable HDMI audio and InfoFrames drm: Add EDID quirk for LG L246WP Documentation/EDID/edid_quirks.txt | 126 + drivers/gpu/drm/drm_drv.c | 2 + drivers/gpu/drm/drm_edid.c | 524 + drivers/gpu/drm/drm_stub.c | 6 + drivers/gpu/drm/drm_sysfs.c| 19 ++ include/drm/drmP.h | 10 + include/drm/drm_edid.h | 13 +- 7 files changed, 639 insertions(+), 61 deletions(-) create mode 100644 Documentation/EDID/edid_quirks.txt -- 1.7.11.2
[PATCH v4 1/3] drm: Add user-defined EDID quirks capability
Add the ability for users to define their own EDID quirks via a
module parameter or sysfs attribute.
Signed-off-by: Ian Pilcher
Acked-by: Paul Menzel
---
Documentation/EDID/edid_quirks.txt | 126 ++
drivers/gpu/drm/drm_drv.c | 2 +
drivers/gpu/drm/drm_edid.c | 500 -
drivers/gpu/drm/drm_stub.c | 6 +
drivers/gpu/drm/drm_sysfs.c| 19 ++
include/drm/drmP.h | 10 +
include/drm/drm_edid.h | 13 +-
7 files changed, 615 insertions(+), 61 deletions(-)
create mode 100644 Documentation/EDID/edid_quirks.txt
diff --git a/Documentation/EDID/edid_quirks.txt
b/Documentation/EDID/edid_quirks.txt
new file mode 100644
index 000..0c9c746
--- /dev/null
+++ b/Documentation/EDID/edid_quirks.txt
@@ -0,0 +1,126 @@
+ EDID Quirks
+ =
+ Ian Pilcher
+August 11, 2012
+
+
+"EDID blocks out in the wild have a variety of bugs"
+-- from drivers/gpu/drm/drm_edid.c
+
+
+Overview
+
+
+EDID quirks provide a mechanism for working around display hardware with buggy
+EDID data.
+
+An individual EDID quirk maps a display type (identified by its EDID
+manufacturer ID and product code[1]) to a set of "quirk flags." The kernel
+includes a variety of built-in quirks. (They are stored in the edid_quirk_list
+array in drivers/gpu/drm/drm_edid.c.)
+
+An example of a built-in EDID quirk is:
+
+ACR:0xad46:0x0001
+
+The first field is the manufacturer ID (Acer, Inc.), the second field is the
+manufacturer's product code, and the third field contains the quirk flags for
+that display type.
+
+The quirk flags are defined in drivers/gpu/drm/drm_edid.c. Each flag has a
+symbolic name beginning with EDID_QUIRK_, along with a numerical value. Each
+flag should also have an associated comment which provides an idea of its
+effect. Note that the values in the source file are expressed as bit
shifts[2]:
+
+* 1 << 0: 0x0001
+* 1 << 1: 0x0002
+* 1 << 2: 0x0004
+* etc.
+
+
+sysfs interface
+===
+
+The current EDID quirk list can be read from /sys/class/drm/edid_quirks:
+
+# cat /sys/class/drm/edid_quirks
+ ACR:0xad46:0x0001
+ API:0x7602:0x0001
+ ACR:0x0977:0x0020
+0x9e6a:0x077e:0x0080
+...
+
+("Nonconformant" manufacturer IDs are displayed as hexadecimal values.)
+
+The number of total "slots" in the list can be read from
+/sys/class/drm/edid_quirks_size. This total includes both occupied slots (i.e.
+the current list) and any slots available for additional quirks. The number of
+available slots can be calculated by subtracting the number of quirks in the
+current list from the total number of slots.
+
+If a slot is available, an additional quirk can be added to the list by writing
+it to /sys/class/drm/edid_quirks:
+
+# echo FOO:0x:0x100 > /sys/class/drm/edid_quirks
+
+Manufacturer IDs can also be specified numerically. (This is the only way to
+specify a nonconformant ID.) This command is equivalent to the previous one:
+
+# echo 0x19ef:0x:0x100 > /sys/class/drm/edid_quirks
+
+Numeric values can also be specified in decimal or octal formats; a number that
+begins with a 0 is assumed to be octal:
+
+# echo FOO:65535:0400 > /sys/class/drm/edid_quirks
+
+An existing quirk can be replaced by writing a new set of flags:
+
+# echo FOO:0x:0x200 > /sys/class/drm/edid_quirks
+
+A quirk can be deleted from the list by writing an empty flag set (0). This
+makes the slot occupied by that quirk available.
+
+# echo FOO:0x:0 > /sys/class/drm/edid_quirks
+
+Writing an "at symbol" (@) clears the entire quirk list:
+
+# echo @ > /sys/class/drm/edid_quirks
+
+Multiple changes to the list can be specified in a comma (or newline) separated
+list. For example, the following command clears all of the existing quirks in
+the list and adds 3 new quirks:
+
+# echo @,FOO:0x:0x100,BAR:0x:0x001,BAZ:0x:0x002 > \
+/sys/class/drm/edid_quirks
+
+Note however, that any error (an incorrectly formatted quirk or an attempt to
+add a quirk when no slot is available) will abort processing of any further
+changes, potentially making it difficult to determine exactly which change
+caused the error and what changes were made. For this reason, making changes
+one at a time is recommended, particularly if the changes are being made by a
+script or program.
+
+
+Module parameter
+
+
+The EDID quirk list can also be modified via the edid_quirks module parameter
+(drm.edid_quirks on the kernel command line). The effect of setting this
+parameter is identical to the effect of writing its value to
+/sys/class/drm/edid_quirks, with one important difference. When an error is
+encountered during module parameter parsing or processing, any remaining quirks
+in the paramet
[PATCH v4 2/3] drm: Add EDID quirks to disable HDMI audio and InfoFrames
Add 2 new EDID quirk flags:
- EDID_QUIRK_DISABLE_INFOFRAMES turns off all HDMI-specific
functionality (audio, HDCP, etc.). Intended for displays that
are confused by *any* InfoFrames.
- EDID_QUIRK_NO_AUDIO disables HDMI audio. Intended for displays
that incorrectely report audio capabilities in their EDID data.
Signed-off-by: Ian Pilcher
Acked-by: Paul Menzel
---
drivers/gpu/drm/drm_edid.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index ea535f6..61586b4 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -70,6 +70,10 @@
#define EDID_QUIRK_DETAILED_SYNC_PP(1 << 6)
/* Force reduced-blanking timings for detailed modes */
#define EDID_QUIRK_FORCE_REDUCED_BLANKING (1 << 7)
+/* Display is confused by InfoFrames; don't sent any */
+#define EDID_QUIRK_DISABLE_INFOFRAMES (1 << 8)
+/* Display doesn't have any audio output */
+#define EDID_QUIRK_NO_AUDIO(1 << 9)
struct detailed_mode_closure {
struct drm_connector *connector;
@@ -2109,6 +2113,14 @@ bool drm_detect_hdmi_monitor(struct edid *edid)
int i, hdmi_id;
int start_offset, end_offset;
bool is_hdmi = false;
+ char buf[EDID_DISPLAY_ID_BUF_SIZE];
+
+ if (edid_get_quirks(edid) & EDID_QUIRK_DISABLE_INFOFRAMES) {
+ DRM_INFO("Disabling HDMI InfoFrames on display %s "
+"due to EDID quirk\n",
+drm_edid_display_id_format(edid->display_id, buf, 1));
+ goto end;
+ }
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
@@ -2157,6 +2169,14 @@ bool drm_detect_monitor_audio(struct edid *edid)
int i, j;
bool has_audio = false;
int start_offset, end_offset;
+ char buf[EDID_DISPLAY_ID_BUF_SIZE];
+
+ if (edid_get_quirks(edid) & EDID_QUIRK_NO_AUDIO) {
+ DRM_INFO("Disabling HDMI audio on display %s "
+"due to EDID quirk\n",
+drm_edid_display_id_format(edid->display_id, buf, 1));
+ goto end;
+ }
edid_ext = drm_find_cea_extension(edid);
if (!edid_ext)
--
1.7.11.2
[PATCH v4 3/3] drm: Add EDID quirk for LG L246WP
This display is apparently confused by any InfoFrames (see
https://bugzilla.redhat.com/show_bug.cgi?id=806091).
Tested on a ThinkPad T510 (nVidia GT218 [NVS 3100M]) and a co-
workers ThinkPad X220 with Intel graphics. EDID_QUIRK_NO_AUDIO
makes this display work with the Intel driver; nouveau requires
EDID_QUIRK_DISABLE_INFOFRAMES.
Signed-off-by: Ian Pilcher
Acked-by: Paul Menzel
---
drivers/gpu/drm/drm_edid.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 61586b4..1f50e09 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -160,6 +160,10 @@ union edid_quirk edid_quirk_list[EDID_QUIRK_LIST_SIZE] = {
{ { { { EDID_MFG_ID('V', 'S', 'C'), cpu_to_le16(5020) } },
EDID_QUIRK_FORCE_REDUCED_BLANKING } },
+ /* LG L246WP */
+ { { { { EDID_MFG_ID('G', 'S', 'M'), cpu_to_le16(0x563f) } },
+ EDID_QUIRK_DISABLE_INFOFRAMES | EDID_QUIRK_NO_AUDIO } },
+
/*
* When adding built-in quirks, please adjust EDID_QUIRK_LIST_SIZE to
* provide some room for user-supplied quirks.
--
1.7.11.2
[Bug 40790] r600g readPixSanity failure on RS880 Radeon HD 4250
https://bugs.freedesktop.org/show_bug.cgi?id=40790 --- Comment #17 from ojab 2012-08-12 20:38:55 UTC --- The same issue on OpenGL renderer string: Gallium 0.4 on AMD RS780 OpenGL version string: 2.1 Mesa 7.11.2 (git-ea72e3c) OpenGL shading language version string: 1.20 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[UDL] general protection fault in fb_deferred_io_mkwrite()
On Sun, Aug 12, 2012 at 3:34 AM, Thomas Meyer wrote: > guilty driver is probably udl_fb.c > any ideas? > Hi Thomas, We were seeing similar issues in udlfb (the original fbdev version of this driver), which were fixed earlier this year by getting all rendering operations out of probe/disconnect -- those which might trigger fb_defio page faults in an inappropriate context, or be long-running. Here's some more detail: http://plugable.com/2012/06/21/displaylink-usb-devices-on-linux-kernel-3-4-0/comment-page-1/#comment-5896 Unfortunately, I haven't had time to get going with udl myself, so haven't been able to port and confirm. Thanks for raising and staying on this. Best wishes, Bernie [ 45.66] RIP [] fb_deferred_io_mkwrite+0xdc/0xf0 > [ 45.66] RSP > [ 45.711547] ---[ end trace d4732d5a0bf375fb ]--- > [ 45.720961] released /dev/fb1 user=1 count=0 > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120812/b0095a33/attachment.html>
[PATCH v4 0/3] Enhanced EDID quirk functionality
On 12.08.2012 22:07, Ian Pilcher wrote: > Another rev. I figured out how to use git reset --hard and --soft to > make regenerating the patch series a bit easier. (It helped a ton > that all of the later changes are isolated in a single file.) I still > feel like I'm probably missing an easier way to go back a fix a simple > type, however. Sounds like you should give interactive rebasing a try: git rebase -i It fires up an editor allowing you to make changes to you individual patches. I hope that helps, Christian. > > * Fix typo > > * Split adding new quirk flags and adding new quirk into separate >patches > > After reveiwing stable_kernel_rules.txt, I don't think that these > patches are appropriate for -stable. I don't consider it to be > "obviously correct," and it certainly isn't less than 100 lines. > Thus, I'm not going to submit this for inclusion in -stable. > > Ian Pilcher (3): >drm: Add user-defined EDID quirks capability >drm: Add EDID quirks to disable HDMI audio and InfoFrames >drm: Add EDID quirk for LG L246WP > > Documentation/EDID/edid_quirks.txt | 126 + > drivers/gpu/drm/drm_drv.c | 2 + > drivers/gpu/drm/drm_edid.c | 524 > + > drivers/gpu/drm/drm_stub.c | 6 + > drivers/gpu/drm/drm_sysfs.c| 19 ++ > include/drm/drmP.h | 10 + > include/drm/drm_edid.h | 13 +- > 7 files changed, 639 insertions(+), 61 deletions(-) > create mode 100644 Documentation/EDID/edid_quirks.txt >
[PATCH v4 0/3] Enhanced EDID quirk functionality
Dear Ian, thank you very much for your quick iterations. Hopefully the developers will review this on Monday. Am Sonntag, den 12.08.2012, 15:07 -0500 schrieb Ian Pilcher: > Another rev. I figured out how to use git reset --hard and --soft to > make regenerating the patch series a bit easier. (It helped a ton > that all of the later changes are isolated in a single file.) Definitely. Wasn?t `git add -p` helpful? > I still feel like I'm probably missing an easier way to go back a fix > a simple type, however. Have you heard of `git rebase` already. That is the more complex version of `git commit --amend`. If the typo is in the last commit just do make the change and do `git commit --amend -a`. If you want to change some earlier commit (like 2 ahead), either do the fix, commit it and do `git rebase -i HEAD~3` and reorder the commits to put the fix at the correct place and change `pick` to `f` for fix up. Or do `git rebase -i HEAD~3` and choose the commits you need to edit and then commit these changes with `git commit -a --amend`. > * Fix typo > > * Split adding new quirk flags and adding new quirk into separate > patches > > After reveiwing stable_kernel_rules.txt, I don't think that these > patches are appropriate for -stable. I don't consider it to be > "obviously correct," and it certainly isn't less than 100 lines. > Thus, I'm not going to submit this for inclusion in -stable. Hmm, three things. 1. I would try anyway. The stable maintainer will reject it if they think it is not appropriate. 2. Your last quirk should be back ported. One solution would be, you first submit patches to add the quirks and the monitor and then add the functionality. 3. I also need to add two monitors to the quirk list which need to be backported. If I try to get them in before yours, you would have to rebase your patches again. Also likely future quirks would need to be backported in a complicated way. So I vote for getting this into stable and hopefully the maintainers agree. Thanks, Paul -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20120812/d7c74bad/attachment.pgp>
3.4.0 -> 3.5.0 bad rendering effects on radeon
Hi, I use Fedora 17 and as soon as kernel 3.5 has been distributed, I get very bad rendering artifacts on my laptop. The laptop is a Thinkpad R50 with a radeon graphics card 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 [Mobility FireGL 9000] (rev 02) It is not a new laptop, about 8 years old. I've opened a bug at Fedora where you can see 2 pictures of what happens. https://bugzilla.redhat.com/show_bug.cgi?id=845639 Reading the mailing list, I cannot understand if this problem has already been reported. I've tried to bisect but I've hit a series of unbootable kernels. "git bisect visualize" currently shows the log between BAD:be122ab Merge tag 'spi-for-linus' of git://git.secretlab.ca/git/linux-2.6 GOOD: c10e408 i915: Add option to bypass vbt table. where I can see a lot of drm related changes. Regards
v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
On 2012-08-08 21:50, George Spelvin wrote: > I'm trying to run a v3.5 kernel (plus some -stable patches from Ted > Ts'o) on > an Ubuntu system. Things are generally working except for the > following > Oops on each boot, which prevents the graphics system from loading. > > [ 36.187972] [drm] Initialized drm 1.1.0 20060810 > [ 36.230306] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work > properly. Using workaround > [ 36.487606] i915 :00:02.0: setting latency timer to 64 > [ 36.555464] [drm] GMBUS [i915 gmbus ssc] timed out, falling back > to bit banging on pin 0 > [ 36.555490] BUG: unable to handle kernel NULL pointer dereference > at 0028 > [ 36.555626] IP: [] bit_xfer+0x23/0x870 > [i2c_algo_bit] > [ 36.555701] PGD 212cb0067 PUD 212caf067 PMD 0 > [ 36.555803] Oops: [#1] SMP > [ 36.555885] CPU 3 > [ 36.555907] Modules linked in: snd_seq_midi joydev i915(+) > snd_rawmidi snd_seq_midi_event snd_seq drm_kms_helper snd_timer > snd_seq_device kvm_intel drm kvm snd serio_raw soundcore i2c_algo_bit > snd_page_alloc lpc_ich video mei microcode mac_hid eeprom it87 > hwmon_vid coretemp lp parport raid10 raid456 async_pq async_xor > firewire_ohci firewire_core xor async_memcpy async_raid6_recov > hid_microsoft floppy crc_itu_t r8169 pata_jmicron usbhid hid mptsas > mptscsih mptbase scsi_transport_sas raid6_pq async_tx raid1 raid0 > multipath linear > [ 36.557232] > [ 36.557271] Pid: 623, comm: modprobe Not tainted 3.5.0 #3 Gigabyte > Technology Co., Ltd. H57M-USB3/H57M-USB3 > [ 36.557398] RIP: 0010:[] [] > bit_xfer+0x23/0x870 [i2c_algo_bit] > [ 36.557493] RSP: :880212c6d648 EFLAGS: 00010296 > [ 36.557544] RAX: 88021222c030 RBX: 880212c6d7e8 RCX: > > [ 36.557599] RDX: 0001 RSI: 880212c6d7e8 RDI: > 88021222c030 > [ 36.557655] RBP: 880212c6d6c8 R08: 0402 R09: > > [ 36.557710] R10: R11: 0006 R12: > 0001 > [ 36.557766] R13: 880212c6dfd8 R14: 0001 R15: > 88021222c030 > [ 36.557822] FS: 7f5a7b85b700() GS:88021fcc() > knlGS: > [ 36.557899] CS: 0010 DS: ES: CR0: 8005003b > [ 36.557950] CR2: 0028 CR3: 000212cad000 CR4: > 07e0 > [ 36.558006] DR0: DR1: DR2: > > [ 36.558062] DR3: DR6: 0ff0 DR7: > 0400 > [ 36.558119] Process modprobe (pid: 623, threadinfo > 880212c6c000, task 88020fdf5b80) > [ 36.558197] Stack: > [ 36.558239] 0001 880212c6dfd8 0001 > 00011222c000 > [ 36.558380] 880212c6d6c8 8166341e 88020ff6ca72 > 000c510c0018 > [ 36.558523] 880212c6d6d8 880212c6d698 0082 > 880212c6d7e8 > [ 36.558671] Call Trace: > [ 36.558719] [] ? printk+0x61/0x63 > [ 36.558790] [] gmbus_xfer+0x56b/0x6f0 [i915] > [ 36.558847] [] i2c_transfer+0x9c/0xe0 > [ 36.558899] [] ? ep_poll_callback+0x10b/0x150 > [ 36.558953] [] > i2c_smbus_xfer_emulated+0x156/0x5d0 > [ 36.559010] [] ? idr_get_empty_slot+0x115/0x320 > [ 36.559064] [] i2c_smbus_xfer+0x113/0x130 > [ 36.559118] [] ? _raw_spin_lock+0xe/0x20 > [ 36.559173] [] ? klist_next+0x89/0x110 > [ 36.559225] [] i2c_default_probe+0xeb/0x130 > [ 36.559279] [] ? i2c_check_addr_busy+0x3b/0x60 > [ 36.559332] [] i2c_do_add_adapter+0x1bb/0x290 > [ 36.559382] [] ? > sysfs_do_create_link+0xeb/0x200 > [ 36.559433] [] ? put_device+0x17/0x20 > [ 36.559482] [] ? __process_new_driver+0x30/0x30 > [ 36.559535] [] __process_new_adapter+0x12/0x20 > [ 36.559590] [] bus_for_each_drv+0x4e/0xa0 > [ 36.559642] [] i2c_register_adapter+0x16d/0x270 > [ 36.559696] [] i2c_add_adapter+0xa3/0xb0 > [ 36.559759] [] intel_setup_gmbus+0xcc/0x1f0 > [i915] > [ 36.559821] [] i915_driver_load+0x2ac/0xb90 > [i915] > [ 36.559882] [] ? drm_get_minor+0x261/0x300 > [drm] > [ 36.559940] [] drm_get_pci_dev+0x186/0x2d0 > [drm] > [ 36.559995] [] ? > default_spin_lock_flags+0x9/0x10 > [ 36.560060] [] i915_pci_probe+0x16/0x20 [i915] > [ 36.560115] [] local_pci_probe+0x5c/0xd0 > [ 36.560168] [] pci_device_probe+0x111/0x120 > [ 36.560221] [] driver_probe_device+0x7e/0x220 > [ 36.560274] [] __driver_attach+0xab/0xb0 > [ 36.560327] [] ? > driver_probe_device+0x220/0x220 > [ 36.560375] [] bus_for_each_dev+0x55/0x90 > [ 36.560421] [] ? 0xa0322fff > [ 36.560470] [] driver_attach+0x1e/0x20 > [ 36.560522] [] bus_add_driver+0x198/0x270 > [ 36.560573] [] ? 0xa0322fff > [ 36.560625] [] driver_register+0x77/0x150 > [ 36.560677] [] ? 0xa0322fff > [ 36.560729] [] __pci_register_driver+0x5e/0xe0 > [ 36.560784] [] ? 0xa0322fff > [ 36.560839] [] drm_pci_init+0x11a/0x130 [drm] > [ 36.560892] [] ? 0xa0322fff > [
[BUG] Intel xorg driver 2.20.2 overlay off-by-one bug
While reading through the Intel driver code, I spotted this in
I830SetPortAttributeOverlay:
} else if (attribute == xvPipe) {
xf86CrtcConfigPtr xf86_config = XF86_CRTC_CONFIG_PTR(scrn);
if ((value < -1) || (value > xf86_config->num_crtc))
return BadValue;
if (value < 0)
adaptor_priv->desired_crtc = NULL;
else
adaptor_priv->desired_crtc = xf86_config->crtc[value];
This allows value == xf86_config->num_crtc to be valid, which would be
the CRTC number _after_ the last one in the array. Presumably this is
not desired, and the test should be ">=".
[UDL] general protection fault in fb_deferred_io_mkwrite()
Hi,
guilty driver is probably udl_fb.c
any ideas?
[ 42.890551] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 42.890585] released /dev/fb1 user=1 count=0
[ 42.890702] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 43.053034] type=1400 audit(1344698343.496:9): avc: denied { execmem } for
pid=631 comm="java" scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:system_r:httpd_t:s0 tclass=process
[ 43.093084] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 43.140051] [drm] write mode info 144
[ 43.140786] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 43.164482] asix 2-1.3:1.0: eth1: link down
[ 44.791884] asix 2-1.3:1.0: eth1: link up, 100Mbps, full-duplex, lpa 0x41E1
[ 45.289464] general protection fault: [#1]
[ 45.289512] CPU 0
[ 45.289529] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables snd_usb_audio snd_usbmidi_lib snd_rawmidi udl
syscopyarea sysfillrect sysimgblt asix uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_core videodev usbnet snd_seq_device drm_usb arc4
btusb iwlwifi bluetooth snd_hda_codec_hdmi acer_wmi joydev mac80211
snd_hda_codec_realtek cfg80211 acerhdf atl1c snd_hda_intel sparse_keymap pcspkr
snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd rfkill soundcore
wmi kvm_intel kvm ipv6 [last unloaded: scsi_wait_scan]
[ 45.290003]
[ 45.290003] Pid: 629, comm: X Not tainted 3.5.1 #3 Acer Aspire 1810T/JM11-MS
[ 45.290003] RIP: 0010:[] []
fb_deferred_io_mkwrite+0xdc/0xf0
[ 45.290003] RSP: :880138e93c98 EFLAGS: 00010246
[ 45.290003] RAX: 7672645f6e6f6564 RBX: ea0004bd6180 RCX: 0036
[ 45.290003] RDX: 88013369b460 RSI: 880138e93cf8 RDI: 880130e0a800
[ 45.290003] RBP: 880138e93cb8 R08: 0c00 R09: a80012f58600
[ 45.290003] R10: 57ffd70a7ebd6180 R11: 003ccd37a850 R12: 880130e0a800
[ 45.290003] R13: 88013369b448 R14: 88013369b440 R15:
[ 45.290003] FS: 7f981237a8c0() GS:8168a000()
knlGS:
[ 45.290003] CS: 0010 DS: ES: CR0: 80050033
[ 45.290003] CR2: 7f9810821010 CR3: 00012f191000 CR4: 000407f0
[ 45.290003] DR0: DR1: DR2:
[ 45.290003] DR3: DR6: 0ff0 DR7: 0400
[ 45.290003] Process X (pid: 629, threadinfo 880138e92000, task
880130c16b50)
[ 45.290003] Stack:
[ 45.290003] 880130f37dc8 0001 88013b2049c0
ea0004bd6180
[ 45.290003] 880138e93d48 810b658c 880138e93d48
810b740a
[ 45.290003] 88012f183210 7f9810821010 880127c23420
30c16b50
[ 45.290003] Call Trace:
[ 45.290003] [] __do_fault+0xbc/0x420
[ 45.290003] [] ? do_wp_page.isra.77+0x2aa/0x640
[ 45.290003] [] handle_pte_fault+0x8c/0x7f0
[ 45.290003] [] ? __send_signal.part.24+0x130/0x300
[ 45.290003] [] ? pte_alloc_one+0x1a/0x40
[ 45.290003] [] handle_mm_fault+0x208/0x2c0
[ 45.290003] [] do_page_fault+0x143/0x490
[ 45.290003] [] ? check_preempt_curr+0x85/0xa0
[ 45.290003] [] ? __dequeue_entity+0x2a/0x50
[ 45.290003] [] ? pick_next_task_fair+0x6e/0x180
[ 45.290003] [] ? __schedule+0x22d/0x500
[ 45.290003] [] page_fault+0x1f/0x30
[ 45.290003] Code: 89 0a 4c 89 ef e8 35 fd 27 00 49 8b 36 49 8d bc 24 90 02
00 00 e8 95 66 e0 ff 5b b8 00 02 00 00 41 5c 41 5d 41 5e 5d c3 4c 89 e7 d0
e9 5e ff ff ff 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 55
[ 45.290003] RIP [] fb_deferred_io_mkwrite+0xdc/0xf0
[ 45.290003] RSP
[ 45.316388] ---[ end trace d4732d5a0bf375fa ]---
[ 45.347642] released /dev/fb1 user=1 count=0
[ 45.454869] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 45.454903] released /dev/fb1 user=1 count=0
[ 45.455020] open /dev/fb1 user=1 fb_info=880130e0a800 count=1
[ 45.456389] [drm] write mode info 144
[ 45.631358] [drm] write mode info 144
[ 45.632075] general protection fault: [#2]
[ 45.632121] CPU 0
[ 45.632139] Modules linked in: ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6
ip6table_filter ip6_tables snd_usb_audio snd_usbmidi_lib snd_rawmidi udl
syscopyarea sysfillrect sysimgblt asix uvcvideo videobuf2_vmalloc
videobuf2_memops videobuf2_core videodev usbnet snd_seq_device drm_usb arc4
btusb iwlwifi bluetooth snd_hda_codec_hdmi acer_wmi joydev mac80211
snd_hda_codec_realtek cfg80211 acerhdf atl1c snd_hda_intel sparse_keymap pcspkr
snd_hda_codec snd_hwdep snd_pcm snd_page_alloc snd_timer snd rfkill soundcore
wmi kvm_intel kvm ipv6 [last unloaded: scsi_wait_scan]
[ 45.66]
[ 45.66] Pid: 836, comm: X Tainted: G D 3.5.1 #3 Acer Aspire
1810T/JM11-MS
[ 45.66] RIP: 0010:[] []
fb_deferred_io_mkwrite+0xdc/0xf0
[ 45.66] RSP: :880126559c98 EFLAGS: 00010246
[ 45.66] RAX: 006f732e61786562 RBX: ea0004bd6180 RCX: 000
3.6-rc1 breaks my laptop graphics (intel)
Hi Daniel.
The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the
i915 driver initializes itself. I bisected this down to commit
24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the
blc controller on the right pipe), and when I revert that, and also
a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH
backlight registers) which depended on the first patch, my laptop works
just fine.
Below is the combined revert.
Any thoughts? Any patch I can try out?
thanks,
greg k-h
--
Subject: drm/i915: revert 24ded204429fa0f5501d37c63ee35c555c0b75ee and
a4f32fc3a37e982fffce8ec583643990ff288419
24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the
blc controller on the right pipe) breaks the boot for my laptop, so
revert it, and a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't
forget the PCH backlight registers) which depended on it.
Signed-off-by: Greg Kroah-Hartman
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8435355..4e786f2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -383,8 +383,7 @@ extern u32 intel_panel_get_max_backlight(struct drm_device
*dev);
extern u32 intel_panel_get_backlight(struct drm_device *dev);
extern void intel_panel_set_backlight(struct drm_device *dev, u32 level);
extern int intel_panel_setup_backlight(struct drm_device *dev);
-extern void intel_panel_enable_backlight(struct drm_device *dev,
-enum pipe pipe);
+extern void intel_panel_enable_backlight(struct drm_device *dev);
extern void intel_panel_disable_backlight(struct drm_device *dev);
extern void intel_panel_destroy_backlight(struct drm_device *dev);
extern enum drm_connector_status intel_panel_detect(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index e05c0d3..6547904 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -71,7 +71,6 @@ static struct intel_lvds *intel_attached_lvds(struct
drm_connector *connector)
static void intel_lvds_enable(struct intel_lvds *intel_lvds)
{
struct drm_device *dev = intel_lvds->base.base.dev;
- struct intel_crtc *intel_crtc =
to_intel_crtc(intel_lvds->base.base.crtc);
struct drm_i915_private *dev_priv = dev->dev_private;
u32 ctl_reg, lvds_reg, stat_reg;
@@ -108,7 +107,7 @@ static void intel_lvds_enable(struct intel_lvds *intel_lvds)
if (wait_for((I915_READ(stat_reg) & PP_ON) != 0, 1000))
DRM_ERROR("timed out waiting for panel to power on\n");
- intel_panel_enable_backlight(dev, intel_crtc->pipe);
+ intel_panel_enable_backlight(dev);
}
static void intel_lvds_disable(struct intel_lvds *intel_lvds)
@@ -1079,14 +1078,35 @@ bool intel_lvds_init(struct drm_device *dev)
goto failed;
out:
- /*
-* Unlock registers and just
-* leave them unlocked
-*/
if (HAS_PCH_SPLIT(dev)) {
+ u32 pwm;
+
+ pipe = (I915_READ(PCH_LVDS) & LVDS_PIPEB_SELECT) ? 1 : 0;
+
+ /* make sure PWM is enabled and locked to the LVDS pipe */
+ pwm = I915_READ(BLC_PWM_CPU_CTL2);
+ if (pipe == 0 && (pwm & BLM_PIPE_B))
+ I915_WRITE(BLC_PWM_CPU_CTL2, pwm & ~BLM_PWM_ENABLE);
+ if (pipe)
+ pwm |= BLM_PIPE_B;
+ else
+ pwm &= ~BLM_PIPE_B;
+ I915_WRITE(BLC_PWM_CPU_CTL2, pwm | BLM_PWM_ENABLE);
+
+ pwm = I915_READ(BLC_PWM_PCH_CTL1);
+ pwm |= BLM_PCH_PWM_ENABLE;
+ I915_WRITE(BLC_PWM_PCH_CTL1, pwm);
+ /*
+* Unlock registers and just
+* leave them unlocked
+*/
I915_WRITE(PCH_PP_CONTROL,
I915_READ(PCH_PP_CONTROL) | PANEL_UNLOCK_REGS);
} else {
+ /*
+* Unlock registers and just
+* leave them unlocked
+*/
I915_WRITE(PP_CONTROL,
I915_READ(PP_CONTROL) | PANEL_UNLOCK_REGS);
}
diff --git a/drivers/gpu/drm/i915/intel_panel.c
b/drivers/gpu/drm/i915/intel_panel.c
index 10c7d39..7180cc8 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -287,24 +287,9 @@ void intel_panel_disable_backlight(struct drm_device *dev)
dev_priv->backlight_enabled = false;
intel_panel_actually_set_backlight(dev, 0);
-
- if (INTEL_INFO(dev)->gen >= 4) {
- uint32_t reg, tmp;
-
- reg = HAS_PCH_SPLIT(dev) ? BLC_PWM_CPU_CTL2 : BLC_PWM_CTL2;
-
- I915_WRITE(reg, I915_READ(reg) & ~BLM_PWM_ENABLE);
-
- if (HAS_PCH_SPLIT(dev)) {
- tmp = I915_READ(BLC_PWM_PCH_CTL1);
-
3.6-rc1 breaks my laptop graphics (intel)
On Sun, Aug 12, 2012 at 08:25:31PM +0200, Daniel Vetter wrote: > On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote: > > Hi Daniel. > > > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the > > i915 driver initializes itself. I bisected this down to commit > > 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the > > blc controller on the right pipe), and when I revert that, and also > > a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH > > backlight registers) which depended on the first patch, my laptop works > > just fine. > > > > Below is the combined revert. > > > > Any thoughts? Any patch I can try out? > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=770c12312ad617172b1a65b911d3e6564fc5aca8 > > which is already merged to drm-intel-fixes. Ah, thanks, I'll go try that out, the Subject: line didn't draw my attention to it being the same problem as mine :) greg k-h
3.6-rc1 breaks my laptop graphics (intel)
On Sun, Aug 12, 2012 at 11:33:05AM -0700, Greg KH wrote: > On Sun, Aug 12, 2012 at 08:25:31PM +0200, Daniel Vetter wrote: > > On Sun, Aug 12, 2012 at 11:21:57AM -0700, Greg KH wrote: > > > Hi Daniel. > > > > > > The 3.6-rc1 kernel breaks my laptop, booting to a black screen when the > > > i915 driver initializes itself. I bisected this down to commit > > > 24ded204429fa0f5501d37c63ee35c555c0b75ee (drm/i915: properly enable the > > > blc controller on the right pipe), and when I revert that, and also > > > a4f32fc3a37e982fffce8ec583643990ff288419 (drm/i915: don't forget the PCH > > > backlight registers) which depended on the first patch, my laptop works > > > just fine. > > > > > > Below is the combined revert. > > > > > > Any thoughts? Any patch I can try out? > > > > http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=770c12312ad617172b1a65b911d3e6564fc5aca8 > > > > which is already merged to drm-intel-fixes. > > Ah, thanks, I'll go try that out, the Subject: line didn't draw my > attention to it being the same problem as mine :) Yes, that works, many thanks. I'm guessing this is going to be going to Linus soon, right? greg k-h
v3.5 Oops in i2c_algo_bit.c:bit_xfer+0x23/0x870: i915 or i2c?
(Bringing this back to the mailing lists after a bit of uninteresting private conversation.) > Honestly, I think we need a way to force disable gmbus with a module > parameter or something anyway. It's not the first time gmbus has been > implicated with an issue. Maybe it even exists already, but I couldn't > find this. So if you confirm that fixes the problem for you on the ml, > at least maybe such a patch will be the result. > > If you feel it's a software bug (which I agree it seems likely), a > bisect is always much appreciated. Personally, I'll usually step back > major releases until something works, or I hit 3.2ish. Even knowing it > never worked through 3.2 is helpful. It's a friend's machine, which I normally only have remote access to, so it's a bit pf a pain, but I can manage. I just thought a basic i3 motherboard was so common I couldn't possibly be the only one with this problem. Here's the 3.2 dmesg showing the fallback working, but this is an Ubuntu-patched kernel (linux-image-3.2.0-29-generic) that may be a fair distance from stock: [ 44.401124] [drm] Initialized drm 1.1.0 20060810 [ 44.471549] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 44.471553] i915 :00:02.0: setting latency timer to 64 [ 44.555865] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.611882] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.667876] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.723831] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.779841] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.835854] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.895843] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 44.951836] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus disabled] [ 45.007798] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.063716] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.119776] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.175716] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.231689] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.287696] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.343704] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.399667] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus ssc] [ 45.455651] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.511629] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.567581] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.623645] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.679546] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.735614] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.791596] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.847533] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus vga] [ 45.903517] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 45.959547] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.015492] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.071473] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.127430] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.183447] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.239425] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.295407] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus panel] [ 46.351401] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.407382] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.463363] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.519347] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.575302] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.631320] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.687360] [drm] GMBUS timed out, falling back to bit banging on pin 0 [i915 gmbus dpc] [ 46.743300] [drm] GMBUS timed out, falling back
