[PATCH] i915: don't map imported dma-bufs for dmar.
On Tue, Jul 31, 2012 at 03:58:13PM +1000, Dave Airlie wrote: > From: Dave Airlie > > The exporter should have given us pages in the correct place, avoid > the prepare object mapping phase on dmar systems. > > This fixes an oops on a GM45/R600 machine, when running the intel/radeon > tests. > > Signed-off-by: Dave Airlie Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH 1/3] drm/i915: implement dma buf begin_cpu_access
On Mon, Jul 30, 2012 at 02:06:54PM +1000, Dave Airlie wrote: > From: Dave Airlie > > In order for udl vmap to work properly, we need to push the object > into the CPU domain before we start copying the data to the USB device. > > question: what is direction here in terms of read/write to the device. > > This along with the udl change avoids userspace explicit mapping to > be used. > > Signed-off-by: Dave Airlie In my understanding TO_DEVICE means cpu writes, devices reads. FROM is devices writes, cpu reads. So your patch looks correct. One thing I wonder is how much lockdep likes this one here ... But I guess it's not the first one ;-) Also, do we have a simple testcase that clears the bo with the intel igd and then tells udl the updated damage, just to exercise the code a bit? -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[PATCH] drm/i915: remove unused variable
On Sat, Jul 28, 2012 at 06:46:35PM +0545, Devendra Naga wrote: > the following warning was produced, > > drivers/gpu/drm/i915/i915_gem_context.c: In function ?i915_switch_context?: > drivers/gpu/drm/i915/i915_gem_context.c:454:6: warning: unused variable ?ret? > [-Wunused-variable] > > fix up by removing it > > Signed-off-by: Devendra Naga Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
Massive power regression going 3.4->3.5
On Wed, Aug 01, 2012 at 11:08:19AM +0100, James Bottomley wrote: > On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: > > On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley > HansenPartnership.com> wrote: > > > On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: > > > > On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley > > > HansenPartnership.com> wrote: > > > > > I got the attached to apply and it doesn't really improve the idle > > > > > power > > > > > much (12.5W). > > > > > > > > That's good to know. Next step is to try overriding i915.semaphores. > > > > Can you please test with i915.semaphores=0 and i915.semaphores=1? > > > > > > There's not much point doing i915_semaphores=1 since that's the default > > > on gen 6 hardware, but i915_semaphores=0 recovers and idle power of > > > ~6.5W > > > > It is only the default if iommu is off, and changing the default > > was one of the side-effects of the patch you bisected. > > > > Can you please login to the desktop, let it idle, record > > /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > > Then trace-cmd record -e i915 sleep 10s, and follow up with a new pair > > of /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. > > > > This will let us see whether the pm counters are truly advancing and > > what activity the driver is performing whilst idle. > > OK, so here it is > > James Hm, if I haven't botched the math, you have a rc6 residency of about 320 seconds between the two cats of drpc_info. Can you please script this so that we have exactly 10s in between? (Aside: 3.6 has a neat interface for rc6 residency in sysfs ...) Also, you need to attach the output of trace-cmd report (like with perf), so that we see the tracepoints in detail. Another quick thing to confirm: What is the power consumption on the old kernel when booting with i915.i915_semaphores=1? Thanks, Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote: > I like this approach more - the only other solution I see is to ask the > currently active driver (i.e. radeon) at bootime for the right mode. Which > sounds much more hellish and fragile ... The "correct" approach is clearly to just have the drm core change the i2c mux before requesting edid, but that's made difficult because of the absence of ordering guarantees in initialisation. I don't like quirking this, since we're then back to the situation of potentially having to add every new piece of related hardware to the quirk list. -- Matthew Garrett | mjg59 at srcf.ucam.org
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #9 from Christian Casteyde 2012-08-05 21:28:16 --- Update: Still present in 3.6-rc1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[PATCH] gpu/mfd/usb: Fix USB randconfig problems
Fix config warning: warning: ( ... && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD) by adding the missing dependency on USB_ARCH_HAS_HCD to DRM_UDL and DRM_USB. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:16: symbol USB_ARCH_HAS_OHCI depends on I2C drivers/i2c/Kconfig:5: symbol I2C is selected by FB_DDC drivers/video/Kconfig:86: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/Kconfig:385: symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/Kconfig:373: symbol FB_CYBER2000 depends on FB which is due to drivers/usb/Kconfig: config USB_ARCH_HAS_OHCI ... default y if ARCH_PNX4008 && I2C Fix by dropping I2C from the above dependency; logic is that this is not a platform dependency but a configuration dependency: the _architecture_ still supports USB even is I2C is not selected. This exposes: drivers/video/Kconfig:36:error: recursive dependency detected! drivers/video/Kconfig:36: symbol FB is selected by DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_UDL drivers/gpu/drm/udl/Kconfig:1: symbol DRM_UDL depends on USB_ARCH_HAS_HCD drivers/usb/Kconfig:78: symbol USB_ARCH_HAS_HCD depends on USB_ARCH_HAS_OHCI drivers/usb/Kconfig:17: symbol USB_ARCH_HAS_OHCI depends on MFD_TC6393XB drivers/mfd/Kconfig:396:symbol MFD_TC6393XB depends on GPIOLIB drivers/gpio/Kconfig:35:symbol GPIOLIB is selected by FB_VIA drivers/video/Kconfig:1560: symbol FB_VIA depends on FB which can be fixed by having MFD_TC6393XB select GPIOLIB instead of depending on it. Signed-off-by: Guenter Roeck --- If anyone has a better idea how to fix this set of problems, please let me know. Also, I'll be happy to split the patch into three parts if that helps to get it integrated. drivers/gpu/drm/Kconfig |1 + drivers/gpu/drm/udl/Kconfig |1 + drivers/mfd/Kconfig |3 ++- drivers/usb/Kconfig |2 +- 4 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 23120c0..90e2808 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -22,6 +22,7 @@ menuconfig DRM config DRM_USB tristate depends on DRM + depends on USB_ARCH_HAS_HCD select USB config DRM_KMS_HELPER diff --git a/drivers/gpu/drm/udl/Kconfig b/drivers/gpu/drm/udl/Kconfig index 0b5e096..56e0bf3 100644 --- a/drivers/gpu/drm/udl/Kconfig +++ b/drivers/gpu/drm/udl/Kconfig @@ -1,6 +1,7 @@ config DRM_UDL tristate "DisplayLink" depends on DRM && EXPERIMENTAL + depends on USB_ARCH_HAS_HCD select DRM_USB select FB_SYS_FILLRECT select FB_SYS_COPYAREA diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index d1facef..b1a1462 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -395,7 +395,8 @@ config MFD_TC6387XB config MFD_TC6393XB bool "Support Toshiba TC6393XB" - depends on GPIOLIB && ARM && HAVE_CLK + depends on ARM && HAVE_CLK + select GPIOLIB select MFD_CORE select MFD_TMIO help diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig index a7773a3..7065df6 100644 --- a/drivers/usb/Kconfig +++ b/drivers/usb/Kconfig @@ -13,7 +13,7 @@ config USB_ARCH_HAS_OHCI default y if PXA3xx default y if ARCH_EP93XX default y if ARCH_AT91 - default y if ARCH_PNX4008 && I2C + default y if ARCH_PNX4008 default y if MFD_TC6393XB default y if ARCH_W90X900 default y if ARCH_DAVINCI_DA8XX -- 1.7.9.7
[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Sun, Aug 5, 2012 at 5:44 PM, Dave Airlie wrote: > On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter wrote: >> On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote: >>> On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote: >>> >>> > I like this approach more - the only other solution I see is to ask the >>> > currently active driver (i.e. radeon) at bootime for the right mode. Which >>> > sounds much more hellish and fragile ... >>> >>> The "correct" approach is clearly to just have the drm core change the >>> i2c mux before requesting edid, but that's made difficult because of the >>> absence of ordering guarantees in initialisation. I don't like quirking >>> this, since we're then back to the situation of potentially having to >>> add every new piece of related hardware to the quirk list. >> >> The "correct" approach of switching the mux before we fetch the edid is >> actualy the one I fear will result in fragile code: Only run on few >> machines, and as you say with tons of funky interactions with the init >> sequence ordering. And I guess people will bitch about the flickering >> this will cause ;-) >> >> As long as it's only apple shipping multi-gpu machines with >> broken/non-existing vbt, I'll happily stomach the quirk list entries. >> They're bad, but imo the lesser evil. > > Well in theory you can switch the ddc lines without switching the other lines, > so we could do a mutex protected mux switch around edid retrival, > Depends on the system. On non-Macs, some systems have a single mux, others have a separate mux for i2c and display as specified in the ATPX ACPI methods. Not sure how the Macs do it. I've started cleaning up the PX radeon code along with a bunch of other radeon ralated ACPI fixes: http://cgit.freedesktop.org/~agd5f/linux/log/?h=acpi_patches Alex
[Bug 53122] X lockups /
https://bugs.freedesktop.org/show_bug.cgi?id=53122 --- Comment #2 from #Paul <201208bugzillaz at moo.uklinux.net> 2012-08-05 15:41:41 UTC --- (In reply to comment #1) > Please attach your dmesg output. Isn't that what appears in the syslog? (which I already quoted). I've got the old syslog, but I've since rebooted and dmesg now reports something else. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Nouveau] [PATCH] nouveau: Do not use nva3 engine for 0xaf chipset
On Sat, Aug 04, 2012 at 08:00:45AM +0200, Henrik Rydberg wrote: > The nva3 copy engine exhibits random memory corruption in at least one > case, the GeForce 320M (nv50, 0xaf) in the MacBookAir3,1. This patch > omits creating the engine for the specific chipset, falling back to > M2MF, which kills the symptoms. I've pushed this (with slightly modified commit message) to nouveau git. I'll get it to Linus' tree in a future -fixes merge. Thanks, Ben. > > Signed-off-by: Henrik Rydberg > --- > Hi Ben, > > this patch is still needed in 3.6-rc1, so perhaps we should apply it > after all. I have been running it without problems for a long time > now. > > Thanks, > Henrik > > drivers/gpu/drm/nouveau/nouveau_state.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c > b/drivers/gpu/drm/nouveau/nouveau_state.c > index 1cdfd6e..1866dbb 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_state.c > +++ b/drivers/gpu/drm/nouveau/nouveau_state.c > @@ -731,7 +731,6 @@ nouveau_card_init(struct drm_device *dev) > case 0xa3: > case 0xa5: > case 0xa8: > - case 0xaf: > nva3_copy_create(dev); > break; > } > -- > 1.7.11.4 > > ___ > Nouveau mailing list > Nouveau at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/nouveau
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #4 from stevenvandenbrandenstift at gmail.com 2012-08-05 11:54:10 UTC --- how to check the libdrm version? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #3 from stevenvandenbrandenstift at gmail.com 2012-08-05 11:33:51 UTC --- Created attachment 65141 --> https://bugs.freedesktop.org/attachment.cgi?id=65141 varlog from startup untill crash of game -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[XDC 2012] Conference Update #1
We are still 1 1/2 month into XDC 2012 so it's time to give a status update and beat the drums some more: - Registration Reminder: So far we have 24 registered participants: there's plenty of room for more - so if you haven't done so: register! If you are in need for travel sponsorship please consider contacting the X.Org Foundation Board of Directors: send email board at foundation.x.org. - Presentation Reminder: So far we don't have all too many proposals for presentations. Matt Dew has just announced a more formal CFP if you would like to submit a conference paper: http://lists.x.org/archives/xorg/2012-August/054967.html However you can still register as described on the conference page if you prefer a more informal process. I expect that Matt will send out a clarification on this issue. If at doubt feel free to contact me. - Hotel Reservation Reminder: We've got a number of rooms allocated for the conference which you will get for EUR 68/night for a single room (breakfast and free wifi included) at the Azimut Hotel (http://www.azimuthotels.com) Kaulbachstr 1 90408 Nuernberg tel.: +49 911 3657 0 FAX.: +49 911 3657 448 email: reservierung.nuernberg at azimuthotels.com This deal will expire on April 18th, so please make your reservation! There are still a number of rooms available - first come first serve. For the reservation you need to state the reservation number #142733. PLEASE NOTE: The hotel has informed me that you should either place your reservation by phone or by email if you want to take advantage of this special deal. Please *don't* use the online reservation tool. - Beer Hiking thru the Franconian Countryside: We will do a beer hiking trip thru the Frankonian Countryside on Saturday after the conference: on this trip we will walk from one beer garden of a micro-brewery to the next. Please let me know if you would like to participate so that I get a rough estimate on the number of people who would like to join. - Contact Information Update: If you have any further inquiries please feel free to email me at egbert.eich _at_ gmail.com (Please note I've updated the email address at which you can reach me and replaced it by one that is not hampered by broken spam filters.) So if you have tried to contact me in the past and weren't able to, please resend! You may also contact me at freenode: my nick is 'egbert'. I'm always present - though not always physical. I will respond sometimes with a delay. So see you all in Nuernberg! Cheers, Egbert.
[Bug 39782] [r300g] XvMC playback fails with MPEG2 video and RV350
https://bugs.freedesktop.org/show_bug.cgi?id=39782 --- Comment #15 from 414N 2012-08-05 07:50:38 UTC --- Still no clue of what could be going awry? This is still happening on recent git checkouts, regardless of the previous patch. Please do tell me if you need more information to narrow down the issue. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #109 from Alexandre Demers 2012-08-05 04:34:02 UTC --- (In reply to comment #108) > Oops, I've hit a va error again. I've been using my computer all day long, > going from one window to another, using Flash on Openstreetmap and Google Map. > The error could explain some lockups I've experienced. I hit the card's > maximum > memory from what I understand of the error. Should I put collected info here > or > under bug 53111? Here is the error message without any log for now. I'll wait to see if it should be tracked here: [54804.656571] radeon :01:00.0: offset 0x40 is in reserved area 0x80 [54805.166815] radeon :01:00.0: bo 8800c227d800 va 0x02B0 conflict with (bo 880202702400 0x0244 0x0344) [54805.177976] radeon :01:00.0: bo 8800c227b000 va 0x02C38000 conflict with (bo 880202702400 0x0244 0x0344) [54805.178980] radeon :01:00.0: bo 880061241400 va 0x02C38000 conflict with (bo 880202702400 0x0244 0x0344) [54805.253953] radeon :01:00.0: bo 88021b183800 va 0x0090 conflict with (bo 880fc000 0x0090 0x00901000) [54806.900210] radeon :01:00.0: va above limit (0x00100200 > 0x0010) [54806.927121] radeon :01:00.0: va above limit (0x001000B0 > 0x0010) [54811.663812] radeon :01:00.0: bo 880223631c00 va 0x01278000 conflict with (bo 88020270b000 0x0120 0x0170) [54813.069082] radeon :01:00.0: bo 88021b183800 va 0x0090 conflict with (bo 880fc000 0x0090 0x00901000) [54813.075691] radeon :01:00.0: bo 88007f002c00 va 0x0090 conflict with (bo 880fc000 0x0090 0x00901000) [54813.075886] radeon :01:00.0: bo 88007f002000 va 0x0090 conflict with (bo 880fc000 0x0090 0x00901000) [54813.075961] gnome-shell[1025]: segfault at 50 ip 7f8af5ebe019 sp 7fff80159650 error 4 in r600_dri.so[7f8af5e53000+4b1000] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 45018] [bisected] rendering regression and va conflicts since added support for virtual address space on cayman v11
https://bugs.freedesktop.org/show_bug.cgi?id=45018 --- Comment #108 from Alexandre Demers 2012-08-05 04:29:39 UTC --- Oops, I've hit a va error again. I've been using my computer all day long, going from one window to another, using Flash on Openstreetmap and Google Map. The error could explain some lockups I've experienced. I hit the card's maximum memory from what I understand of the error. Should I put collected info here or under bug 53111? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39782] [r300g] XvMC playback fails with MPEG2 video and RV350
https://bugs.freedesktop.org/show_bug.cgi?id=39782 --- Comment #15 from 414N grsf...@tiscali.it 2012-08-05 07:50:38 UTC --- Still no clue of what could be going awry? This is still happening on recent git checkouts, regardless of the previous patch. Please do tell me if you need more information to narrow down the issue. -- 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
[XDC 2012] Conference Update #1
We are still 1 1/2 month into XDC 2012 so it's time to give a status update and beat the drums some more: - Registration Reminder: So far we have 24 registered participants: there's plenty of room for more - so if you haven't done so: register! If you are in need for travel sponsorship please consider contacting the X.Org Foundation Board of Directors: send email bo...@foundation.x.org. - Presentation Reminder: So far we don't have all too many proposals for presentations. Matt Dew has just announced a more formal CFP if you would like to submit a conference paper: http://lists.x.org/archives/xorg/2012-August/054967.html However you can still register as described on the conference page if you prefer a more informal process. I expect that Matt will send out a clarification on this issue. If at doubt feel free to contact me. - Hotel Reservation Reminder: We've got a number of rooms allocated for the conference which you will get for EUR 68/night for a single room (breakfast and free wifi included) at the Azimut Hotel (http://www.azimuthotels.com) Kaulbachstr 1 90408 Nuernberg tel.: +49 911 3657 0 FAX.: +49 911 3657 448 email: reservierung.nuernb...@azimuthotels.com This deal will expire on April 18th, so please make your reservation! There are still a number of rooms available - first come first serve. For the reservation you need to state the reservation number #142733. PLEASE NOTE: The hotel has informed me that you should either place your reservation by phone or by email if you want to take advantage of this special deal. Please *don't* use the online reservation tool. - Beer Hiking thru the Franconian Countryside: We will do a beer hiking trip thru the Frankonian Countryside on Saturday after the conference: on this trip we will walk from one beer garden of a micro-brewery to the next. Please let me know if you would like to participate so that I get a rough estimate on the number of people who would like to join. - Contact Information Update: If you have any further inquiries please feel free to email me at egbert.eich _at_ gmail.com (Please note I've updated the email address at which you can reach me and replaced it by one that is not hampered by broken spam filters.) So if you have tried to contact me in the past and weren't able to, please resend! You may also contact me at freenode: my nick is 'egbert'. I'm always present - though not always physical. I will respond sometimes with a delay. So see you all in Nuernberg! Cheers, Egbert. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 0/5] i915 changes for hybrid graphics support on Macbooks
The following patches are part of a larger series I've been working on to get vga_switcheroo working on hybrid graphics Macbooks. Some of these machines are not providing a VBT, and since the LVDS panel is connected to the discrete GPU at boot we can't get a mode for the panel during initialization. As a result the LVDS connector is not registered with DRM, and graphics switching is not possible. These patches fix this issue by registering the connector even if we can't get a mode for the panel. If we don't have an EDID we check again from the vga_switcheroo reprobe callback. This is working, except for the framebuffer console which isn't displaying when switched to the integrated GPU, which I still need to debug. I'm not entirely sure whether or not this is the correct approach though, so I wanted to go ahead and get some feedback on the patches now to make sure I'm on the right track. Thanks, Seth Andreas Heider (1): drm/i915: Add support for vga_switcheroo reprobe Seth Forshee (4): drm/i915: separate out code to get EDID from LVDS panel drm/i915: register LVDS connector even if we can't get a panel mode drm/i915: make intel_lvds_get_edid() more robust drm/i915: check LVDS for EDID on GPU switches drivers/gpu/drm/i915/i915_dma.c |9 ++- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_lvds.c | 156 + 3 files changed, 97 insertions(+), 69 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 1/5] drm/i915: Add support for vga_switcheroo reprobe
From: Andreas Heider andr...@meetr.de
Signed-off-by: Andreas Heider andr...@meetr.de
---
drivers/gpu/drm/i915/i915_dma.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 9cf7dfe..5b5176d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1263,6 +1263,12 @@ static void i915_switcheroo_set_state(struct pci_dev
*pdev, enum vga_switcheroo_
}
}
+static void i915_switcheroo_reprobe(struct pci_dev *pdev)
+{
+ struct drm_device *dev = pci_get_drvdata(pdev);
+ intel_fb_output_poll_changed(dev);
+}
+
static bool i915_switcheroo_can_switch(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
@@ -1276,7 +1282,7 @@ static bool i915_switcheroo_can_switch(struct pci_dev
*pdev)
static const struct vga_switcheroo_client_ops i915_switcheroo_ops = {
.set_gpu_state = i915_switcheroo_set_state,
- .reprobe = NULL,
+ .reprobe = i915_switcheroo_reprobe,
.can_switch = i915_switcheroo_can_switch,
};
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/5] drm/i915: separate out code to get EDID from LVDS panel
This code will be reused to support hybrid graphics on some Apple
machines that can't get a mode for the LVDS panel at boot, so move it
into a new function named intel_lvds_get_edid().
Signed-off-by: Seth Forshee seth.fors...@canonical.com
---
drivers/gpu/drm/i915/intel_lvds.c | 95 +
1 file changed, 55 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index e05c0d3..5069137 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -46,6 +46,7 @@ struct intel_lvds {
struct edid *edid;
+ u8 i2c_pin;
int fitting_mode;
u32 pfit_control;
u32 pfit_pgm_ratios;
@@ -897,6 +898,54 @@ static bool intel_lvds_supported(struct drm_device *dev)
return IS_MOBILE(dev) !IS_I830(dev);
}
+static bool intel_lvds_get_edid(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_connector *connector = dev_priv-int_lvds_connector;
+ struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
+ struct drm_display_mode *scan; /* *modes, *bios_mode; */
+
+ /*
+* Attempt to get the fixed panel mode from DDC. Assume that the
+* preferred mode is the right one.
+*/
+ intel_lvds-edid = drm_get_edid(connector,
+ intel_gmbus_get_adapter(dev_priv,
+
intel_lvds-i2c_pin));
+ if (intel_lvds-edid) {
+ if (drm_add_edid_modes(connector,
+ intel_lvds-edid)) {
+ drm_mode_connector_update_edid_property(connector,
+
intel_lvds-edid);
+ } else {
+ kfree(intel_lvds-edid);
+ intel_lvds-edid = NULL;
+ }
+ }
+ if (!intel_lvds-edid) {
+ /* Didn't get an EDID, so
+* Set wide sync ranges so we get all modes
+* handed to valid_mode for checking
+*/
+ connector-display_info.min_vfreq = 0;
+ connector-display_info.max_vfreq = 200;
+ connector-display_info.min_hfreq = 0;
+ connector-display_info.max_hfreq = 200;
+ }
+
+ list_for_each_entry(scan, connector-probed_modes, head) {
+ if (scan-type DRM_MODE_TYPE_PREFERRED) {
+ intel_lvds-fixed_mode =
+ drm_mode_duplicate(dev, scan);
+ intel_find_lvds_downclock(dev,
+ intel_lvds-fixed_mode,
+ connector);
+ return true;
+ }
+ }
+ return false;
+}
+
/**
* intel_lvds_init - setup LVDS connectors on this device
* @dev: drm device
@@ -912,7 +961,6 @@ bool intel_lvds_init(struct drm_device *dev)
struct intel_connector *intel_connector;
struct drm_connector *connector;
struct drm_encoder *encoder;
- struct drm_display_mode *scan; /* *modes, *bios_mode; */
struct drm_crtc *crtc;
u32 lvds;
int pipe;
@@ -955,9 +1003,11 @@ bool intel_lvds_init(struct drm_device *dev)
intel_lvds-pfit_control = I915_READ(PFIT_CONTROL);
}
+ intel_lvds-i2c_pin = pin;
intel_encoder = intel_lvds-base;
encoder = intel_encoder-base;
connector = intel_connector-base;
+ dev_priv-int_lvds_connector = connector;
drm_connector_init(dev, intel_connector-base,
intel_lvds_connector_funcs,
DRM_MODE_CONNECTOR_LVDS);
@@ -991,6 +1041,7 @@ bool intel_lvds_init(struct drm_device *dev)
dev-mode_config.scaling_mode_property,
DRM_MODE_SCALE_ASPECT);
intel_lvds-fitting_mode = DRM_MODE_SCALE_ASPECT;
+
/*
* LVDS discovery:
* 1) check for EDID on DDC
@@ -1001,44 +1052,8 @@ bool intel_lvds_init(struct drm_device *dev)
*if closed, act like it's not there for now
*/
- /*
-* Attempt to get the fixed panel mode from DDC. Assume that the
-* preferred mode is the right one.
-*/
- intel_lvds-edid = drm_get_edid(connector,
- intel_gmbus_get_adapter(dev_priv,
- pin));
- if (intel_lvds-edid) {
- if (drm_add_edid_modes(connector,
- intel_lvds-edid)) {
- drm_mode_connector_update_edid_property(connector,
-
intel_lvds-edid);
- } else {
-
[RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
Some Apple hybrid graphics machines do not have the LVDS panel connected
to the integrated GPU at boot and also do not supply a VBT. The LVDS
connector is not registered as a result, making it impossible to support
graphics switching.
This patch changes intel_lvds_init() to register the connector even if
we can't find any panel modes. This makes it necessary to always check
intel_lvds-fixed_mode before use, as it could now be NULL.
Signed-off-by: Seth Forshee seth.fors...@canonical.com
---
drivers/gpu/drm/i915/intel_lvds.c | 48 +++--
1 file changed, 19 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 5069137..c1ab632 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -161,6 +161,8 @@ static int intel_lvds_mode_valid(struct drm_connector
*connector,
struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
struct drm_display_mode *fixed_mode = intel_lvds-fixed_mode;
+ if (!fixed_mode)
+ return MODE_PANEL;
if (mode-hdisplay fixed_mode-hdisplay)
return MODE_PANEL;
if (mode-vdisplay fixed_mode-vdisplay)
@@ -262,7 +264,8 @@ static bool intel_lvds_mode_fixup(struct drm_encoder
*encoder,
* with the panel scaling set up to source from the H/VDisplay
* of the original mode.
*/
- intel_fixed_panel_mode(intel_lvds-fixed_mode, adjusted_mode);
+ if (intel_lvds-fixed_mode)
+ intel_fixed_panel_mode(intel_lvds-fixed_mode, adjusted_mode);
if (HAS_PCH_SPLIT(dev)) {
intel_pch_panel_fitting(dev, intel_lvds-fitting_mode,
@@ -461,12 +464,13 @@ static int intel_lvds_get_modes(struct drm_connector
*connector)
{
struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
struct drm_device *dev = connector-dev;
- struct drm_display_mode *mode;
+ struct drm_display_mode *mode = NULL;
if (intel_lvds-edid)
return drm_add_edid_modes(connector, intel_lvds-edid);
- mode = drm_mode_duplicate(dev, intel_lvds-fixed_mode);
+ if (intel_lvds-fixed_mode)
+ mode = drm_mode_duplicate(dev, intel_lvds-fixed_mode);
if (mode == NULL)
return 0;
@@ -1073,26 +1077,21 @@ bool intel_lvds_init(struct drm_device *dev)
*/
/* Ironlake: FIXME if still fail, not try pipe mode now */
- if (HAS_PCH_SPLIT(dev))
- goto failed;
-
- lvds = I915_READ(LVDS);
- pipe = (lvds LVDS_PIPEB_SELECT) ? 1 : 0;
- crtc = intel_get_crtc_for_pipe(dev, pipe);
-
- if (crtc (lvds LVDS_PORT_EN)) {
- intel_lvds-fixed_mode = intel_crtc_mode_get(dev, crtc);
- if (intel_lvds-fixed_mode) {
- intel_lvds-fixed_mode-type |=
- DRM_MODE_TYPE_PREFERRED;
- goto out;
+ if (!HAS_PCH_SPLIT(dev)) {
+ lvds = I915_READ(LVDS);
+ pipe = (lvds LVDS_PIPEB_SELECT) ? 1 : 0;
+ crtc = intel_get_crtc_for_pipe(dev, pipe);
+
+ if (crtc (lvds LVDS_PORT_EN)) {
+ intel_lvds-fixed_mode = intel_crtc_mode_get(dev, crtc);
+ if (intel_lvds-fixed_mode) {
+ intel_lvds-fixed_mode-type |=
+ DRM_MODE_TYPE_PREFERRED;
+ goto out;
+ }
}
}
- /* If we still don't have a mode after all that, give up. */
- if (!intel_lvds-fixed_mode)
- goto failed;
-
out:
/*
* Unlock registers and just
@@ -1116,13 +1115,4 @@ out:
intel_panel_setup_backlight(dev);
return true;
-
-failed:
- DRM_DEBUG_KMS(No LVDS modes found, disabling.\n);
- dev_priv-int_lvds_connector = NULL;
- drm_connector_cleanup(connector);
- drm_encoder_cleanup(encoder);
- kfree(intel_lvds);
- kfree(intel_connector);
- return false;
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 4/5] drm/i915: make intel_lvds_get_edid() more robust
intel_lvds_get_edid() needs to be called when switching GPUs, but it's
currently making assumptions that it will only be called once and that
there's always an LVDS connector present when it's called. Fix these
assumptions.
Signed-off-by: Seth Forshee seth.fors...@canonical.com
---
drivers/gpu/drm/i915/intel_lvds.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index c1ab632..9d05a90 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -906,9 +906,18 @@ static bool intel_lvds_get_edid(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_connector *connector = dev_priv-int_lvds_connector;
- struct intel_lvds *intel_lvds = intel_attached_lvds(connector);
+ struct intel_lvds *intel_lvds;
struct drm_display_mode *scan; /* *modes, *bios_mode; */
+ if (!connector)
+ return false;
+
+ intel_lvds = intel_attached_lvds(connector);
+
+ /* If we already have an EDID, no need to check again */
+ if (intel_lvds-edid)
+ return true;
+
/*
* Attempt to get the fixed panel mode from DDC. Assume that the
* preferred mode is the right one.
@@ -939,6 +948,12 @@ static bool intel_lvds_get_edid(struct drm_device *dev)
list_for_each_entry(scan, connector-probed_modes, head) {
if (scan-type DRM_MODE_TYPE_PREFERRED) {
+ /*
+* If we already have a preferred mode from another
+* source, prefer the one from the EDID.
+*/
+ if (intel_lvds-fixed_mode)
+ drm_mode_destroy(dev, intel_lvds-fixed_mode);
intel_lvds-fixed_mode =
drm_mode_duplicate(dev, scan);
intel_find_lvds_downclock(dev,
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 5/5] drm/i915: check LVDS for EDID on GPU switches
If the LVDS panel wasn't connected at boot then we won't have an EDID
for it. To fix this, call intel_lvds_get_edid() from the vga_switcheroo
reprobe callback.
Signed-off-by: Seth Forshee seth.fors...@canonical.com
---
drivers/gpu/drm/i915/i915_dma.c |1 +
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_lvds.c |2 +-
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 5b5176d..c9c942e 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1266,6 +1266,7 @@ static void i915_switcheroo_set_state(struct pci_dev
*pdev, enum vga_switcheroo_
static void i915_switcheroo_reprobe(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ intel_lvds_get_edid(dev);
intel_fb_output_poll_changed(dev);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8435355..bcc14f9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -356,6 +356,7 @@ extern void intel_dvo_init(struct drm_device *dev);
extern void intel_tv_init(struct drm_device *dev);
extern void intel_mark_busy(struct drm_device *dev,
struct drm_i915_gem_object *obj);
+extern bool intel_lvds_get_edid(struct drm_device *dev);
extern bool intel_lvds_init(struct drm_device *dev);
extern void intel_dp_init(struct drm_device *dev, int dp_reg);
void
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 9d05a90..39dbefc 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -902,7 +902,7 @@ static bool intel_lvds_supported(struct drm_device *dev)
return IS_MOBILE(dev) !IS_I830(dev);
}
-static bool intel_lvds_get_edid(struct drm_device *dev)
+bool intel_lvds_get_edid(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_connector *connector = dev_priv-int_lvds_connector;
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Fri, Aug 03, 2012 at 05:14:16PM +0100, Matthew Garrett wrote: On Fri, Aug 03, 2012 at 11:02:19AM -0500, Seth Forshee wrote: Some Apple hybrid graphics machines do not have the LVDS panel connected to the integrated GPU at boot and also do not supply a VBT. The LVDS connector is not registered as a result, making it impossible to support graphics switching. This patch changes intel_lvds_init() to register the connector even if we can't find any panel modes. This makes it necessary to always check intel_lvds-fixed_mode before use, as it could now be NULL. This one kind of sucks. I think adding a quirk for this situation would be justifiable, rather than doing it for all devices. This is one of the things I wasn't so sure about. There are various checks in intel_lvds_init() that can cause it to bail out before we try to get the EDID, and I don't fully understand all of them. If non-laptop machines are expected to bail out before the EDID check then the approach I've taken seems reasonable. Otherwise adding a quirk probably is a good idea. Seth ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] of: Add videomode helper
On 08/03/2012 01:38 AM, Sascha Hauer wrote:
Hi Stephen,
On Thu, Aug 02, 2012 at 01:35:40PM -0600, Stephen Warren wrote:
On 07/04/2012 01:56 AM, Sascha Hauer wrote:
This patch adds a helper function for parsing videomodes from the
devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
diff --git a/Documentation/devicetree/bindings/video/displaymode
b/Documentation/devicetree/bindings/video/displaymode
+Required properties:
+ - xres, yres: Display resolution
+ - left-margin, right-margin, hsync-len: Horizontal Display timing
parameters
+ in pixels
+ upper-margin, lower-margin, vsync-len: Vertical display timing
parameters in
+ lines
Perhaps bike-shedding, but...
For the margin property names, wouldn't it be better to use terminology
more commonly used for video timings rather than Linux FB naming. In
other words naming like:
hactive, hsync-len, hfront-porch, hback-porch?
Can do. Just to make sure:
hactive == xres
hsync-len == hsync-len
hfront-porch == right-margin
hback-porch == left-margin
I believe so yes.
a) They're already standardized and very common.
Indeed, that's a big plus for EDID. I have no intention of removing EDID
data from the devicetree. There are situations where EDID is handy, for
example when you get EDID data provided by your vendor.
b) They allow other information such as a display's HDMI audio
capabilities to be represented, which can then feed into an ALSA driver.
c) The few LCD panel datasheets I've seen actually quote their
specification as an EDID already, so deriving the EDID may actually be easy.
d) People familiar with displays are almost certainly familiar with
EDID's mode representation. There are many ways of representing display
modes (sync position vs. porch widths, htotal specified rather than
specifying all the components and hence htotal being calculated etc.).
Not everyone will be familiar with all representations. Conversion
errors are less likely if the target is EDID's familiar format.
You seem to think about a different class of displays for which EDID
indeed is a better way to handle. What I have to deal with here mostly
are dumb displays which:
- can only handle their native resolution
- Have no audio capabilities at all
- come with a datasheet which specify a min/typ/max triplet for
xres,hsync,..., often enough they are scanned to pdf from some previously
printed paper.
These displays are very common on embedded devices, probably that's the
reason I did not even think about the possibility that a single display
might have different modes.
That's true, but as I mentioned, there are at least some dumb panels
(both I've seen recently) whose specification provides the EDID. I don't
know how common that is though, I must admit.
e) You'll end up with exactly the same data as if you have a DDC-based
external monitor rather than an internal panel, so you end up getting to
a common path in display handling code much more quickly.
All we have in our display driver currently is:
edidp = of_get_property(np, edid, imxpd-edid_len);
if (edidp) {
imxpd-edid = kmemdup(edidp, imxpd-edid_len, GFP_KERNEL);
} else {
ret = of_get_video_mode(np, imxpd-mode, NULL);
if (!ret)
imxpd-mode_valid = 1;
}
Presumably there's more to it though; something later checks
imxpd-mode_valid and if false, parses the EDID and sets up imxpd-mode,
etc.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Virtual address need to be fenced to know when we can safely remove it. This patch also properly clear the pagetable. Previously it was serouisly broken. v2: For to update pagetable when unbinding bo (don't bailout if bo_va-valid is true). This version is for stable 3.5 only. Why? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: fence virtual address and free it once idle [3.5] v2
On Fri, Aug 03, 2012 at 04:31:22PM -0400, Jerome Glisse wrote: On Fri, Aug 3, 2012 at 4:16 PM, Greg KH gre...@linuxfoundation.org wrote: On Fri, Aug 03, 2012 at 03:57:19PM -0400, j.gli...@gmail.com wrote: From: Jerome Glisse jgli...@redhat.com Virtual address need to be fenced to know when we can safely remove it. This patch also properly clear the pagetable. Previously it was serouisly broken. v2: For to update pagetable when unbinding bo (don't bailout if bo_va-valid is true). This version is for stable 3.5 only. Why? Because 3.4 needs again a different patch and 3.6 needs a different patch. Code around this patch changed btw 3.4-3.5 and changed again btw 3.5-3.6 and in non trivial way. Then please say that in the original patch, and point to where the changes happened, and resend it so that I can apply it. I also need an ack from the maintainer(s) that this is acceptable. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] vmwgfx: add missing mutex_unlocks
we have done a proper mutex_unlock in the error cases of the vmw_fifo_reserve,
but
there are missing mutex unlocks where we return a valid pointer in
vmw_fifo_reserve.
Signed-off-by: Devendra Naga develkernel412...@gmail.com
---
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index a0c2f12..e3abd7a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -355,6 +355,7 @@ void *vmw_fifo_reserve(struct vmw_private *dev_priv,
uint32_t bytes)
if (reserveable)
iowrite32(bytes, fifo_mem +
SVGA_FIFO_RESERVED);
+ mutex_unlock(fifo_state-fifo_mutex);
return fifo_mem + (next_cmd 2);
} else {
need_bounce = true;
@@ -363,10 +364,12 @@ void *vmw_fifo_reserve(struct vmw_private *dev_priv,
uint32_t bytes)
if (need_bounce) {
fifo_state-using_bounce_buffer = true;
- if (bytes fifo_state-static_buffer_size)
+ if (bytes fifo_state-static_buffer_size) {
+ mutex_unlock(fifo_state-fifo_mutex);
return fifo_state-static_buffer;
- else {
+ } else {
fifo_state-dynamic_buffer = vmalloc(bytes);
+ mutex_unlock(fifo_state-fifo_mutex);
return fifo_state-dynamic_buffer;
}
}
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Fri, Aug 03, 2012 at 05:27:02PM +0100, Matthew Garrett wrote:
On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote:
This is one of the things I wasn't so sure about. There are various
checks in intel_lvds_init() that can cause it to bail out before we try
to get the EDID, and I don't fully understand all of them. If non-laptop
machines are expected to bail out before the EDID check then the
approach I've taken seems reasonable. Otherwise adding a quirk probably
is a good idea.
I know we've previously had problems with machines with phantom LVDS
hardware, but I'm not sure what the current state of affairs is.
It turns out that the framebuffer console issue is due to not having a
mode when initializing LVDS. As a result 1024x768 is getting used for
the framebuffer.
So quirking is going to fix this situation. In fact, with the changes
below switcheroo seems to work perfectly, without any of these patches
at all.
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 627fe35..d83e5bc 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -503,6 +503,7 @@ typedef struct drm_i915_private {
enum intel_pch pch_type;
unsigned long quirks;
+ struct drm_display_mode *lvds_quirk_mode;
/* Register state */
bool modeset_on_lid;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f615976..c810177 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7069,7 +7069,7 @@ static void intel_init_display(struct drm_device *dev)
* resume, or other times. This quirk makes sure that's the case for
* affected systems.
*/
-static void quirk_pipea_force(struct drm_device *dev)
+static void quirk_pipea_force(struct drm_device *dev, void *data)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -7080,7 +7080,7 @@ static void quirk_pipea_force(struct drm_device *dev)
/*
* Some machines (Lenovo U160) do not work with SSC on LVDS for some reason
*/
-static void quirk_ssc_force_disable(struct drm_device *dev)
+static void quirk_ssc_force_disable(struct drm_device *dev, void *data)
{
struct drm_i915_private *dev_priv = dev-dev_private;
dev_priv-quirks |= QUIRK_LVDS_SSC_DISABLE;
@@ -7091,48 +7091,74 @@ static void quirk_ssc_force_disable(struct drm_device
*dev)
* A machine (e.g. Acer Aspire 5734Z) may need to invert the panel backlight
* brightness value
*/
-static void quirk_invert_brightness(struct drm_device *dev)
+static void quirk_invert_brightness(struct drm_device *dev, void *data)
{
struct drm_i915_private *dev_priv = dev-dev_private;
dev_priv-quirks |= QUIRK_INVERT_BRIGHTNESS;
DRM_INFO(applying inverted panel brightness quirk\n);
}
+/*
+ * Some machines (e.g. certain Macbooks) may not be able to determine the
+ * LVDS mode during driver initialization
+ */
+static void quirk_lvds_panel_mode(struct drm_device *dev, void *data)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ dev_priv-lvds_quirk_mode = data;
+ DRM_INFO(applying LVDS panel mode quirk: %p\n, data);
+}
+
+/* LVDS panel mode for Macbook Pro 8,2 */
+struct drm_display_mode mbp82_panel_mode = {
+ DRM_MODE(1440x900, DRM_MODE_TYPE_DRIVER, 88750, 1440, 1488, 1520,
+1600, 0, 900, 903, 909, 926, 0,
+DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC)
+};
+
struct intel_quirk {
int device;
int subsystem_vendor;
int subsystem_device;
- void (*hook)(struct drm_device *dev);
+ void (*hook)(struct drm_device *dev, void *data);
+ void *hook_data;
};
static struct intel_quirk intel_quirks[] = {
/* HP Mini needs pipe A force quirk (LP: #322104) */
- { 0x27ae, 0x103c, 0x361a, quirk_pipea_force },
+ { 0x27ae, 0x103c, 0x361a, quirk_pipea_force, NULL },
/* Thinkpad R31 needs pipe A force quirk */
- { 0x3577, 0x1014, 0x0505, quirk_pipea_force },
+ { 0x3577, 0x1014, 0x0505, quirk_pipea_force, NULL },
/* Toshiba Protege R-205, S-209 needs pipe A force quirk */
- { 0x2592, 0x1179, 0x0001, quirk_pipea_force },
+ { 0x2592, 0x1179, 0x0001, quirk_pipea_force, NULL },
/* ThinkPad X30 needs pipe A force quirk (LP: #304614) */
- { 0x3577, 0x1014, 0x0513, quirk_pipea_force },
+ { 0x3577, 0x1014, 0x0513, quirk_pipea_force, NULL },
/* ThinkPad X40 needs pipe A force quirk */
/* ThinkPad T60 needs pipe A force quirk (bug #16494) */
- { 0x2782, 0x17aa, 0x201a, quirk_pipea_force },
+ { 0x2782, 0x17aa, 0x201a, quirk_pipea_force, NULL },
/* 855 before need to leave pipe A dpll A up */
- { 0x3582, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
- { 0x2562, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force },
+ { 0x3582, PCI_ANY_ID, PCI_ANY_ID, quirk_pipea_force, NULL },
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #3 from stevenvandenbrandenst...@gmail.com 2012-08-05 11:33:51 UTC --- Created attachment 65141 -- https://bugs.freedesktop.org/attachment.cgi?id=65141 varlog from startup untill crash of game -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 52997] evergreen_cs_track_validate_cb:477 cb[0] bo too small when launching ds2 in wine
https://bugs.freedesktop.org/show_bug.cgi?id=52997 --- Comment #4 from stevenvandenbrandenst...@gmail.com 2012-08-05 11:54:10 UTC --- how to check the libdrm version? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53122] X lockups /
https://bugs.freedesktop.org/show_bug.cgi?id=53122 --- Comment #2 from #Paul 201208bugzil...@moo.uklinux.net 2012-08-05 15:41:41 UTC --- (In reply to comment #1) Please attach your dmesg output. Isn't that what appears in the syslog? (which I already quoted). I've got the old syslog, but I've since rebooted and dmesg now reports something else. -- 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: Massive power regression going 3.4-3.5
On Wed, Aug 01, 2012 at 11:08:19AM +0100, James Bottomley wrote: On Wed, 2012-08-01 at 09:58 +0100, Chris Wilson wrote: On Wed, 01 Aug 2012 09:45:04 +0100, James Bottomley james.bottom...@hansenpartnership.com wrote: On Wed, 2012-08-01 at 09:16 +0100, Chris Wilson wrote: On Wed, 01 Aug 2012 09:06:12 +0100, James Bottomley james.bottom...@hansenpartnership.com wrote: I got the attached to apply and it doesn't really improve the idle power much (12.5W). That's good to know. Next step is to try overriding i915.semaphores. Can you please test with i915.semaphores=0 and i915.semaphores=1? There's not much point doing i915_semaphores=1 since that's the default on gen 6 hardware, but i915_semaphores=0 recovers and idle power of ~6.5W It is only the default if iommu is off, and changing the default was one of the side-effects of the patch you bisected. Can you please login to the desktop, let it idle, record /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. Then trace-cmd record -e i915 sleep 10s, and follow up with a new pair of /sys/kernel/debug/dri/0/i915_cur_delayinfo and .../i915_drpc_info. This will let us see whether the pm counters are truly advancing and what activity the driver is performing whilst idle. OK, so here it is James Hm, if I haven't botched the math, you have a rc6 residency of about 320 seconds between the two cats of drpc_info. Can you please script this so that we have exactly 10s in between? (Aside: 3.6 has a neat interface for rc6 residency in sysfs ...) Also, you need to attach the output of trace-cmd report (like with perf), so that we see the tracepoints in detail. Another quick thing to confirm: What is the power consumption on the old kernel when booting with i915.i915_semaphores=1? Thanks, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: remove unused variable
On Sat, Jul 28, 2012 at 06:46:35PM +0545, Devendra Naga wrote: the following warning was produced, drivers/gpu/drm/i915/i915_gem_context.c: In function ‘i915_switch_context’: drivers/gpu/drm/i915/i915_gem_context.c:454:6: warning: unused variable ‘ret’ [-Wunused-variable] fix up by removing it Signed-off-by: Devendra Naga devendra.a...@gmail.com Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/i915: implement dma buf begin_cpu_access
On Mon, Jul 30, 2012 at 02:06:54PM +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com In order for udl vmap to work properly, we need to push the object into the CPU domain before we start copying the data to the USB device. question: what is direction here in terms of read/write to the device. This along with the udl change avoids userspace explicit mapping to be used. Signed-off-by: Dave Airlie airl...@redhat.com In my understanding TO_DEVICE means cpu writes, devices reads. FROM is devices writes, cpu reads. So your patch looks correct. One thing I wonder is how much lockdep likes this one here ... But I guess it's not the first one ;-) Also, do we have a simple testcase that clears the bo with the intel igd and then tells udl the updated damage, just to exercise the code a bit? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] i915: don't map imported dma-bufs for dmar.
On Tue, Jul 31, 2012 at 03:58:13PM +1000, Dave Airlie wrote: From: Dave Airlie airl...@redhat.com The exporter should have given us pages in the correct place, avoid the prepare object mapping phase on dmar systems. This fixes an oops on a GM45/R600 machine, when running the intel/radeon tests. Signed-off-by: Dave Airlie airl...@redhat.com Picked up for -fixes, thanks for the patch. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix mem leak in intel_sdvo_write_cmd()
On Tue, Jul 31, 2012 at 10:31:15PM +0200, Jesper Juhl wrote: If the allocation of 'buf' succeeds but the allocation of 'msgs' fails we'll return false and leak 'buf' when it goes out of scope. Signed-off-by: Jesper Juhl j...@chaosbits.net I've already merged a similar patch from Alan Cox for -fixes, should land in 3.6 soonish. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: ignore disconnected - unknown status changes
On Fri, Aug 03, 2012 at 09:32:44AM -0400, Alex Deucher wrote: On Thu, Aug 2, 2012 at 3:21 AM, Knut Petersen knut_peter...@t-online.de wrote: On an AOpen i915GMm-hfs the hotplug events generated by transitions between connector_status_unknown and connector_status_disconnected cause screen distortions. The attached patch cures the problem by disabling the generation of hotplug events in those cases. That should be safe for everybody as the only relevant changes are those from / to connector_status_connected. Seems reasonable to me. We should just drop unknown. We (ab)use that in i915 to avoid some (more costly) load-detection tricks in the hotplug code (but only on rather ancient hw), instead returning unknown. When userspace then inquires the connector status, we flip-flop back to connected. The issue is that we need to avoid these, for the current kms locking would stall the cursor for a while, which is not acceptable to do every 10s. Until the kms locking is fixed, we hence can't drop the unknown state. Reviewed-by: Alex Deucher alexander.deuc...@amd.com Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch -- 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: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Sat, Aug 04, 2012 at 11:57:27AM -0500, Seth Forshee wrote: On Fri, Aug 03, 2012 at 05:27:02PM +0100, Matthew Garrett wrote: On Fri, Aug 03, 2012 at 11:24:51AM -0500, Seth Forshee wrote: This is one of the things I wasn't so sure about. There are various checks in intel_lvds_init() that can cause it to bail out before we try to get the EDID, and I don't fully understand all of them. If non-laptop machines are expected to bail out before the EDID check then the approach I've taken seems reasonable. Otherwise adding a quirk probably is a good idea. I know we've previously had problems with machines with phantom LVDS hardware, but I'm not sure what the current state of affairs is. It turns out that the framebuffer console issue is due to not having a mode when initializing LVDS. As a result 1024x768 is getting used for the framebuffer. So quirking is going to fix this situation. In fact, with the changes below switcheroo seems to work perfectly, without any of these patches at all. I like this approach more - the only other solution I see is to ask the currently active driver (i.e. radeon) at bootime for the right mode. Which sounds much more hellish and fragile ... -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: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote: I like this approach more - the only other solution I see is to ask the currently active driver (i.e. radeon) at bootime for the right mode. Which sounds much more hellish and fragile ... The correct approach is clearly to just have the drm core change the i2c mux before requesting edid, but that's made difficult because of the absence of ordering guarantees in initialisation. I don't like quirking this, since we're then back to the situation of potentially having to add every new piece of related hardware to the quirk list. -- Matthew Garrett | mj...@srcf.ucam.org ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Fix mem leak in intel_sdvo_write_cmd()
On Sun, 5 Aug 2012, Daniel Vetter wrote: On Tue, Jul 31, 2012 at 10:31:15PM +0200, Jesper Juhl wrote: If the allocation of 'buf' succeeds but the allocation of 'msgs' fails we'll return false and leak 'buf' when it goes out of scope. Signed-off-by: Jesper Juhl j...@chaosbits.net I've already merged a similar patch from Alan Cox for -fixes, should land in 3.6 soonish. Perfect. -- Jesper Juhl j...@chaosbits.net http://www.chaosbits.net/ Don't top-post http://www.catb.org/jargon/html/T/top-post.html Plain text mails only, please. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #9 from Christian Casteyde casteyde.christ...@free.fr 2012-08-05 21:28:16 --- Update: Still present in 3.6-rc1 -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote: On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote: I like this approach more - the only other solution I see is to ask the currently active driver (i.e. radeon) at bootime for the right mode. Which sounds much more hellish and fragile ... The correct approach is clearly to just have the drm core change the i2c mux before requesting edid, but that's made difficult because of the absence of ordering guarantees in initialisation. I don't like quirking this, since we're then back to the situation of potentially having to add every new piece of related hardware to the quirk list. The correct approach of switching the mux before we fetch the edid is actualy the one I fear will result in fragile code: Only run on few machines, and as you say with tons of funky interactions with the init sequence ordering. And I guess people will bitchmoan about the flickering this will cause ;-) As long as it's only apple shipping multi-gpu machines with broken/non-existing vbt, I'll happily stomach the quirk list entries. They're bad, but imo the lesser evil. -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: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote: On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote: I like this approach more - the only other solution I see is to ask the currently active driver (i.e. radeon) at bootime for the right mode. Which sounds much more hellish and fragile ... The correct approach is clearly to just have the drm core change the i2c mux before requesting edid, but that's made difficult because of the absence of ordering guarantees in initialisation. I don't like quirking this, since we're then back to the situation of potentially having to add every new piece of related hardware to the quirk list. The correct approach of switching the mux before we fetch the edid is actualy the one I fear will result in fragile code: Only run on few machines, and as you say with tons of funky interactions with the init sequence ordering. And I guess people will bitchmoan about the flickering this will cause ;-) As long as it's only apple shipping multi-gpu machines with broken/non-existing vbt, I'll happily stomach the quirk list entries. They're bad, but imo the lesser evil. Well in theory you can switch the ddc lines without switching the other lines, so we could do a mutex protected mux switch around edid retrival, Of course someone would have to code it up first then we could see how ugly it would be. Dave. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 53122] X lockups /
https://bugs.freedesktop.org/show_bug.cgi?id=53122 --- Comment #3 from Alex Deucher ag...@yahoo.com 2012-08-05 23:11:37 UTC --- (In reply to comment #2) Isn't that what appears in the syslog? (which I already quoted). I've got the old syslog, but I've since rebooted and dmesg now reports something else. Please attach your full dmesg so we can see more details about your hw configuration. -- 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: [RFC PATCH 3/5] drm/i915: register LVDS connector even if we can't get a panel mode
On Sun, Aug 5, 2012 at 5:44 PM, Dave Airlie airl...@gmail.com wrote: On Mon, Aug 6, 2012 at 7:40 AM, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Aug 05, 2012 at 10:18:38PM +0100, Matthew Garrett wrote: On Sun, Aug 05, 2012 at 11:14:12PM +0200, Daniel Vetter wrote: I like this approach more - the only other solution I see is to ask the currently active driver (i.e. radeon) at bootime for the right mode. Which sounds much more hellish and fragile ... The correct approach is clearly to just have the drm core change the i2c mux before requesting edid, but that's made difficult because of the absence of ordering guarantees in initialisation. I don't like quirking this, since we're then back to the situation of potentially having to add every new piece of related hardware to the quirk list. The correct approach of switching the mux before we fetch the edid is actualy the one I fear will result in fragile code: Only run on few machines, and as you say with tons of funky interactions with the init sequence ordering. And I guess people will bitchmoan about the flickering this will cause ;-) As long as it's only apple shipping multi-gpu machines with broken/non-existing vbt, I'll happily stomach the quirk list entries. They're bad, but imo the lesser evil. Well in theory you can switch the ddc lines without switching the other lines, so we could do a mutex protected mux switch around edid retrival, Depends on the system. On non-Macs, some systems have a single mux, others have a separate mux for i2c and display as specified in the ATPX ACPI methods. Not sure how the Macs do it. I've started cleaning up the PX radeon code along with a bunch of other radeon ralated ACPI fixes: http://cgit.freedesktop.org/~agd5f/linux/log/?h=acpi_patches Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
