Re: [Intel-gfx] [PATCH] drm/i915: fix up readout of the lvds dither bit on gen2/3
On Mon, Jul 22, 2013 at 06:55:55AM +0200, Knut Petersen wrote: On 11.07.2013 19:22, Daniel Vetter wrote: On Thu, Jul 11, 2013 at 06:29:15PM +0200, Knut Petersen wrote: On 11.07.2013 13:49, Chris Wilson wrote: On Thu, Jul 11, 2013 at 01:35:40PM +0200, Daniel Vetter wrote: It's in the PFIT_CONTROL register, but very much associated with the lvds encoder. So move the readout for it (in the case of an otherwise disabled pfit) from the pipe to the lvds encoder's get_config function. Otherwise we get a pipe state mismatch if we use pipe B for a non-lvds output and we've left the dither bit enabled behind us. This can happen if the BIOS has set the bit (some seem to unconditionally do that, even in the complete absence of an lvds port), but not enabled pipe B at boot-up. Then we won't clear the pfit control register since we can only touch that if the pfit is associated with our pipe in the crtc configuration - we could trample over the pfit state of the other pipe otherwise since it's shared. Once pipe B is enabled we notice that the 6to8 dither bit is set and complain about the mismatch. Note that testing indicates that we don't actually need to set this bit when the pfit is disabled, dithering on 18bpp panels seems to work regardless. But ripping that code out is not something for a bugfix meant for -rc kernels. v2: While at it clarify the logic in i9xx_get_pfit_config, spurred by comments from Chris on irc. v3: Use Chris suggestion to make the control flow in i9xx_get_pfit_config easier to understand. v4: Kill the extra line, spotted by Chris. Reported-by: Knut Petersen knut_peter...@t-online.de Cc: Knut Petersen knut_peter...@t-online.de Cc: Chris Wilson ch...@chris-wilson.co.uk References: http://lists.freedesktop.org/archives/intel-gfx/2013-July/030092.html Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris Tested-by: Knut Petersen knut_peter...@t-online.de Thanks, that patch cures both inital boot and suspend/resume problems. Attached find dmesg (inital boot) and dmesg2 (suspend/resume cycle). Thanks for testing and reporting this issue, patch is merged into my -fixes queue now. Thanks, Daniel We have -rc2, but this patch is still missing ... I'm flushing out my current -fixes to with a pull request to Dave today. I've had a bit a hold-up with other regressions unfortunately. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix hdmi portclock limits
In
commit 325b9d048810f7689ec644595061c0b700e64bce
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri Apr 19 11:24:33 2013 +0200
drm/i915: fixup 12bpc hdmi dotclock handling
I've errornously claimed that we don't yet support the hdmi 1.4
dotclocks 225 MHz on Haswell. But a bug report and a closer look at
the wrpll table showed that we've supported port clocks up to 300MHz.
With the new code to dynamically compute wrpll limits we should have
no issues going up to the full 340 MHz range of hdmi 1.4, so let's
just use that to fix this regression. That'll allow 4k over hdmi for
free!
v2: Drop the random hunk that somehow slipped in.
v3: Cantiga has the original HDMI dotclock limit of 165MHz. And also
patch up the mode filtering. To do so extract the dotclock limits into
a little helper function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67048
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
Tested-by: Andreas Reis andreas.r...@gmail.com (v2)
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_hdmi.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 98df2a0..23874a3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -785,10 +785,22 @@ static void intel_disable_hdmi(struct intel_encoder
*encoder)
}
}
+static int hdmi_portclock_limit(struct intel_hdmi *hdmi)
+{
+ struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+
+ if (IS_G4X(dev))
+ return 165000;
+ else if (IS_HASWELL(dev))
+ return 34;
+ else
+ return 225000;
+}
+
static int intel_hdmi_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- if (mode-clock 165000)
+ if (mode-clock hdmi_portclock_limit(intel_attached_hdmi(connector)))
return MODE_CLOCK_HIGH;
if (mode-clock 2)
return MODE_CLOCK_LOW;
@@ -806,6 +818,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
struct drm_device *dev = encoder-base.dev;
struct drm_display_mode *adjusted_mode = pipe_config-adjusted_mode;
int clock_12bpc = pipe_config-requested_mode.clock * 3 / 2;
+ int portclock_limit = hdmi_portclock_limit(intel_hdmi);
int desired_bpp;
if (intel_hdmi-color_range_auto) {
@@ -829,7 +842,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
* outputs. We also need to check that the higher clock still fits
* within limits.
*/
- if (pipe_config-pipe_bpp 8*3 clock_12bpc = 225000
+ if (pipe_config-pipe_bpp 8*3 clock_12bpc = portclock_limit
HAS_PCH_SPLIT(dev)) {
DRM_DEBUG_KMS(picking bpc to 12 for HDMI output\n);
desired_bpp = 12*3;
@@ -846,7 +859,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
pipe_config-pipe_bpp = desired_bpp;
}
- if (adjusted_mode-clock 225000) {
+ if (adjusted_mode-clock portclock_limit) {
DRM_DEBUG_KMS(too high HDMI clock, rejecting mode\n);
return false;
}
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Like I've said yesterday I've originally wanted to include a hdmi regression fix for modes with dotclocks 165MHz, but this morning (after reading the test result from QA) I've noticed that I've fumbled something. So that patch has to take another round. So that regression is still open, but otherwise this pull request here resolves everything else outstanding: - fixup panel fitter readout for gen2/3 (just quitens dmesg noise) - fix pft computations for non-autoscaled resolutions (i.e. letter/pillar boxing on gen2/3) - preserve the DDI A/E lane sharing bit (Stéphane Marchesin) - fix the rc6 fails to work after resume regression, big thanks to Konstantin Khlebnikov for the patch and debug insight about what actually might be going on here - fix Oops in is_crtc_connector_off (Chris) - sanitize shared dpll state - our new paranoid state checker tripped up over dirt left behind by the BIOS - correctly restore fences, fixes the my screen is all messed up after resume regression introduced in the final 3.10 pull request - quirk backlights harder, this time for Dell XPS13 machines to fix a regression (patch from Kamal Mostafa) - 90% fix for some haswell hangs when accessing registers concurrently, the 100% solution is simply too invasive for -fixes and what we have here seems to be good enough (Chris) Cheers, Daniel The following changes since commit 46a0b638f35b45fc13d3dc0deb6a7e17988170b2: Revert drm/i915: Workaround incoherence between fences and LLC across multiple CPUs (2013-07-10 15:31:12 +0200) are available in the git repository at: git://people.freedesktop.org/~danvet/drm-intel tags/drm-intel-fixes-2013-07-22 for you to fetch changes up to 181d1b9e31c668259d3798c521672afb8edd355c: drm/i915: fix up gt init sequence fallout (2013-07-21 15:37:02 +0200) Chris Wilson (2): drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() drm/i915: Serialize almost all register access Daniel Vetter (6): drm/i915: fix up readout of the lvds dither bit on gen2/3 drm/i915: fix pfit regression for non-autoscaled resolutions drm/i915: Sanitize shared dpll state Merge tag 'v3.10' into drm-intel-fixes drm/i915: correctly restore fences with objects attached drm/i915: fix up gt init sequence fallout Kamal Mostafa (1): drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight Konstantin Khlebnikov (1): drm/i915: fix long-standing SNB regression in power consumption after resume v2 Stéphane Marchesin (1): drm/i915: Preserve the DDI_A_4_LANES bit from the bios Documentation/networking/ip-sysctl.txt |4 +- MAINTAINERS|2 +- Makefile |2 +- arch/arm/Kconfig | 14 + arch/arm/include/asm/cputype.h |2 + arch/arm/include/asm/glue-proc.h |9 + arch/arm/include/asm/smp_plat.h|2 +- arch/arm/kernel/devtree.c | 10 +- arch/arm/kernel/setup.c|2 +- arch/arm/mm/nommu.c|6 + arch/arm/mm/proc-fa526.S |1 - arch/arm/mm/proc-macros.S |5 + arch/arm/mm/proc-v7.S | 34 +- arch/mn10300/include/asm/uaccess.h |2 +- arch/mn10300/kernel/setup.c| 54 +- arch/powerpc/kernel/pci-common.c | 17 +- arch/powerpc/platforms/pseries/eeh_cache.c |4 +- arch/powerpc/platforms/pseries/eeh_pe.c|3 +- arch/x86/kernel/kprobes/core.c | 14 +- crypto/algboss.c | 15 +- crypto/api.c |6 - crypto/internal.h |6 + drivers/acpi/dock.c| 179 ++- drivers/acpi/internal.h|5 + drivers/acpi/scan.c|1 + drivers/ata/libata-acpi.c | 37 +- drivers/ata/libata-core.c |2 + drivers/ata/libata.h |2 + drivers/block/rbd.c| 14 +- drivers/bluetooth/btmrvl_main.c|9 +- drivers/cpufreq/cpufreq_ondemand.c | 17 +- drivers/gpio/gpio-omap.c | 22 +- drivers/gpu/drm/i915/i915_dma.c| 18 +- drivers/gpu/drm/i915/i915_drv.c| 13 +- drivers/gpu/drm/i915/i915_drv.h|5 +- drivers/gpu/drm/i915/i915_gem.c| 36 +- drivers/gpu/drm/i915/i915_suspend.c|1 + drivers/gpu/drm/i915/intel_ddi.c
Re: [Intel-gfx] i915 irq storm mitigation in 3.10
On Mon, Jul 22, 2013 at 8:14 AM, Jan Niggemann j...@hz6.de wrote: Am 21.07.2013 22:43, schrieb Daniel Vetter: Can you please boot with drm.debug=0xe added to your kernel cmdline, do a cold boot (so that we get a storm) and then once everything is quiet grab the full kernel log (you probably have to grab it from the disk, dmesg has likely overflown) and upload it somewhere (since it's probably too big for the mailing lists)? Please also enable printk timestamps for your kernel so that we can create a timeline of everything going on. I hope I did it correctly, apending both printk.time=1 and drm.debug=0xe to my kernel command line: http://files.hz6.de/kern_20130722.log That log should give us a starting point, but I guess we need to run some debug patches past you to figure out what's going on in your system exactly. Did the drm.debug option work, it's not very chatty? Nope, that didn't work out somehow, it should be _much_ more chatty, even without a hpd irq storm. Usually the kernel prints the commandline in the log, but I didn't see that here either ... Can you please try to figure out what's going on here? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] sna: Call EnterVT from sna_screen_init.
From: Christopher James Halse Rogers r...@ubuntu.com
It's documented to do so. It might as well.
---
src/sna/sna_driver.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/sna/sna_driver.c b/src/sna/sna_driver.c
index b48ab30..de1384d 100644
--- a/src/sna/sna_driver.c
+++ b/src/sna/sna_driver.c
@@ -936,6 +936,8 @@ agp_aperture_size(struct pci_device *dev, int gen)
return dev-regions[gen 030 ? 0 : 2].size;
}
+static Bool sna_enter_vt(VT_FUNC_ARGS_DECL);
+
static Bool
sna_screen_init(SCREEN_INIT_ARGS_DECL)
{
@@ -1072,7 +1074,7 @@ sna_screen_init(SCREEN_INIT_ARGS_DECL)
sna_uevent_init(scrn);
- return TRUE;
+ return sna_enter_vt(VT_FUNC_ARGS(0));
}
static void sna_adjust_frame(ADJUST_FRAME_ARGS_DECL)
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 2/2] sna: Support running nested in Mir
From: Christopher James Halse Rogers r...@ubuntu.com
This is pretty much functional for both SNA and UXA, but can't reasonably
be applied until the Xserver patch has landed, and that needs more work.
This demonstrates the approach, however.
There's probably some code to be shared with XWayland support, around the
output handling (or lack thereof) and possibly integration with the underlying
compositor for SwapBuffers etc.
---
src/intel.h | 7 ++
src/intel_display.c | 18 +
src/intel_dri.c | 23 +++
src/intel_driver.c | 191 ---
src/intel_module.c | 30 +++-
src/sna/sna.h| 12
src/sna/sna_accel.c | 28
src/sna/sna_dri.c| 5 ++
src/sna/sna_driver.c | 140 +++--
9 files changed, 406 insertions(+), 48 deletions(-)
diff --git a/src/intel.h b/src/intel.h
index d4c9aff..01011f5 100644
--- a/src/intel.h
+++ b/src/intel.h
@@ -76,6 +76,12 @@ SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
#include libudev.h
#endif
+#if XMIR
+#include xmir.h
+#else
+typedef struct xmir_screen xmir_screen;
+#endif
+
/* remain compatible to xorg-server 1.6 */
#ifndef MONITOR_EDID_COMPLETE_RAWDATA
#define MONITOR_EDID_COMPLETE_RAWDATA EDID_COMPLETE_RAWDATA
@@ -350,6 +356,7 @@ typedef struct intel_screen_private {
InputHandlerProc uevent_handler;
#endif
Bool has_prime_vmap_flush;
+ xmir_screen *xmir;
} intel_screen_private;
#ifndef I915_PARAM_HAS_PRIME_VMAP_FLUSH
diff --git a/src/intel_display.c b/src/intel_display.c
index 17168e5..d84a367 100644
--- a/src/intel_display.c
+++ b/src/intel_display.c
@@ -1872,6 +1872,17 @@ intel_mode_init(struct intel_screen_private *intel)
{
struct intel_mode *mode = intel-modes;
+ if (intel-modes == NULL) {
+ mode = calloc (sizeof *mode, 1);
+ mode-fd = intel-drmSubFD;
+
+ mode-event_context.version = DRM_EVENT_CONTEXT_VERSION;
+ mode-event_context.vblank_handler = intel_vblank_handler;
+ mode-event_context.page_flip_handler = intel_page_flip_handler;
+
+ intel-modes = mode;
+ }
+
/* We need to re-register the mode-fd for the synchronisation
* feedback on every server generation, so perform the
* registration within ScreenInit and not PreInit.
@@ -1967,6 +1978,13 @@ Bool intel_crtc_on(xf86CrtcPtr crtc)
Bool ret;
int i;
+ /* We're not in control of this crtc, probably because we're running
nested.
+* We can't say anything useful about whether the CRTC's on or not, so
say
+* off.
+*/
+ if (!intel_crtc)
+ return FALSE;
+
if (!crtc-enabled)
return FALSE;
diff --git a/src/intel_dri.c b/src/intel_dri.c
index 0370034..e382e5e 100644
--- a/src/intel_dri.c
+++ b/src/intel_dri.c
@@ -68,6 +68,11 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#include intel_glamor.h
#include uxa.h
+#ifdef XMIR
+#include xmir.h
+#include xf86Priv.h
+#endif
+
typedef struct {
int refcnt;
PixmapPtr pixmap;
@@ -1545,6 +1550,19 @@ static const char *dri_driver_name(intel_screen_private
*intel)
return s;
}
+#if DRI2INFOREC_VERSION = 8 defined(XMIR)
+static int I830DRI2AuthMagic(ScreenPtr screen, uint32_t magic)
+{
+ ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
+ intel_screen_private *intel = intel_get_screen_private(scrn);
+
+ if (xorgMir)
+ return xmir_auth_drm_magic(intel-xmir, magic);
+ else
+ return drmAuthMagic(intel-drmSubFD, magic);
+}
+#endif
+
Bool I830DRI2ScreenInit(ScreenPtr screen)
{
ScrnInfoPtr scrn = xf86ScreenToScrn(screen);
@@ -1625,6 +1643,11 @@ Bool I830DRI2ScreenInit(ScreenPtr screen)
driverNames[0] = info.driverName;
#endif
+#if DRI2INFOREC_VERSION = 8 XMIR
+ info.version = 8;
+ info.AuthMagic2 = I830DRI2AuthMagic;
+#endif
+
return DRI2ScreenInit(screen, info);
}
diff --git a/src/intel_driver.c b/src/intel_driver.c
index ae2e31e..e960d89 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -64,6 +64,12 @@ USE OR OTHER DEALINGS IN THE SOFTWARE.
#include intel.h
#include intel_video.h
+#ifdef XMIR
+#include xmir.h
+#include dix.h
+#include xf86Priv.h
+#endif
+
#ifdef INTEL_XVMC
#define _INTEL_XVMC_SERVER_
#include intel_hwmc.h
@@ -169,7 +175,8 @@ static Bool i830CreateScreenResources(ScreenPtr screen)
if (!intel_uxa_create_screen_resources(screen))
return FALSE;
- intel_copy_fb(scrn);
+ if (!xorgMir)
+ intel_copy_fb(scrn);
return TRUE;
}
@@ -246,41 +253,51 @@ static void intel_check_dri_option(ScrnInfoPtr scrn)
static Bool intel_open_drm_master(ScrnInfoPtr scrn)
{
- intel_screen_private *intel = intel_get_screen_private(scrn);
- struct pci_device *dev = intel-PciInfo;
- drmSetVersion
Re: [Intel-gfx] [RFC PATCH 2/2] sna: Support running nested in Mir
With xorgMir this is not going to fly. Make sure the compatibility cruft, first of all, exists and is out of line in a header. And expose the driving heartbeat of when to refresh the screen pixmap from Xmir. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 irq storm mitigation in 3.10
Daniel Vetter writes: On Sun, Jul 21, 2013 at 10:23 PM, Jan Niggemann j...@hz6.de wrote: But every time this happens we only let through a few interrupts, so this shouldn't affect you badly. Can you please check whether those slowdowns line up with 2 minute intervalls? I observed these slowdowns for a couple of weeks now. On my machine, they only happen once, some minutes after a cold boot. They last for a minute or two, and then they are gone. I'd have guessed that the storm detection kicks in pretty quickly after a storm is detected and that it would go unnoticed. Hm, that sounds like something doesn't quite work as expected. We should kill things once we get 5 interrupts or so in 1 second. So if it's bad enough that it slows your machine down it really should only be barely noticeable. The logs show that the disable mechanism got triggered, so there was a storm that got detected. The respective message is generated by the worker, everything up to there (detection and marking disabled) seems to be fine. I bet we are still getting interrupts but the respective bit in hpd_event_bits doesn't get set any more. Since we unconditionally queue the worker on interrupt there is surprise it is so busy. Then this points to the call to hpd_irq_setup() in intel_hpd_irq_handler() not doing what is expected, ie masking out the stormy interrupt. Could it be that we can't mask/disable an interrupt before ACKing it? @Jan, could you also specify what hardware you are using (ie give us an output of lspci -n)? Cheers, Egbert. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/2] sna: Support running nested in Mir
On Mon, 22 Jul, 2013 at 5:53 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: With xorgMir this is not going to fly. Make sure the compatibility cruft, first of all, exists and is out of line in a header. Do you mean remove the various #ifdef XMIR bits, or *all* the bits gated on xorgMir? Some of that's not going to be trivial to hide away in a header. And expose the driving heartbeat of when to refresh the screen pixmap from Xmir. I'm not sure what you mean here - Xmir exposes the on-buffer-available callback, which gets triggered when swap_buffers has returned the next buffer to render to. This is what I'd think of as the refresh heartbeat. Is this not what you mean? If you're rendering as fast as possible, this will be a once-per-compositor-vblank event. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/2] sna: Support running nested in Mir
On Mon, Jul 22, 2013 at 08:20:49AM +0010, Christopher James Halse Rogers wrote: On Mon, 22 Jul, 2013 at 5:53 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: With xorgMir this is not going to fly. Make sure the compatibility cruft, first of all, exists and is out of line in a header. Do you mean remove the various #ifdef XMIR bits, or *all* the bits gated on xorgMir? Some of that's not going to be trivial to hide away in a header. It looked like it could be done quite simply. The most important part is to avoid the extern xorgMir - as that will be a major nuisance. And expose the driving heartbeat of when to refresh the screen pixmap from Xmir. I'm not sure what you mean here - Xmir exposes the on-buffer-available callback, which gets triggered when swap_buffers has returned the next buffer to render to. This is what I'd think of as the refresh heartbeat. Is this not what you mean? Yes, that's what it looked like. But I didn't see how that was being coupled into how fast we updated. If you're rendering as fast as possible, this will be a once-per-compositor-vblank event. That's what I would expect, so I am just missing the logic between that and us sending updates. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/2] sna: Support running nested in Mir
On Mon, Jul 22, 2013 at 04:44:40PM +1000, christopher.halse.rog...@canonical.com wrote: From: Christopher James Halse Rogers r...@ubuntu.com This is pretty much functional for both SNA and UXA, but can't reasonably be applied until the Xserver patch has landed, and that needs more work. This demonstrates the approach, however. There's probably some code to be shared with XWayland support, around the output handling (or lack thereof) and possibly integration with the underlying compositor for SwapBuffers etc. git-am doesn't like the base sha1, can you point me to a branch? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH 2/2] sna: Support running nested in Mir
On Mon, 22 Jul, 2013 at 6:41 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, Jul 22, 2013 at 04:44:40PM +1000, christopher.halse.rog...@canonical.com wrote: From: Christopher James Halse Rogers r...@ubuntu.com This is pretty much functional for both SNA and UXA, but can't reasonably be applied until the Xserver patch has landed, and that needs more work. This demonstrates the approach, however. There's probably some code to be shared with XWayland support, around the output handling (or lack thereof) and possibly integration with the underlying compositor for SwapBuffers etc. git-am doesn't like the base sha1, can you point me to a branch? Oh. Well, doesn't that make me look rather stupid. It's based on sha 2770655371, ie: 2.21.9, because that's what my master branch was up to, and I didn't notice that it wasn't set to track origin/master. Git fail! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
This has been broken in
commit 2f63315692b1d3c055972ad33fc7168ae908b97b
Author: Ben Widawsky b...@bwidawsk.net
Date: Wed Jul 17 12:19:03 2013 -0700
drm/i915: Create VMAs
which resulted in an OOPS the first time around we've hit -ENOSPC.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67156
Cc: Imre Deak imre.d...@intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Tested-by: meng mengmeng.m...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cfa6588..c87a6ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3121,8 +3121,8 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object
*obj,
vma = i915_gem_vma_create(obj, dev_priv-gtt.base);
if (IS_ERR(vma)) {
- i915_gem_object_unpin_pages(obj);
- return PTR_ERR(vma);
+ ret = PTR_ERR(vma);
+ goto err_unpin;
}
search_free:
@@ -3138,17 +3138,17 @@ search_free:
if (ret == 0)
goto search_free;
- goto err_out;
+ goto err_free_vma;
}
if (WARN_ON(!i915_gem_valid_gtt_space(dev, vma-node,
obj-cache_level))) {
ret = -EINVAL;
- goto err_out;
+ goto err_remove_node;
}
ret = i915_gem_gtt_prepare_object(obj);
if (ret)
- goto err_out;
+ goto err_remove_node;
list_move_tail(obj-global_list, dev_priv-mm.bound_list);
list_add_tail(obj-mm_list, vm-inactive_list);
@@ -3167,9 +3167,11 @@ search_free:
i915_gem_verify_gtt(dev);
return 0;
-err_out:
+err_remove_node:
drm_mm_remove_node(vma-node);
+err_free_vma:
i915_gem_vma_destroy(vma);
+err_unpin:
i915_gem_object_unpin_pages(obj);
return ret;
}
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
On Mon, Jul 22, 2013 at 12:12:38PM +0200, Daniel Vetter wrote: This has been broken in commit 2f63315692b1d3c055972ad33fc7168ae908b97b Author: Ben Widawsky b...@bwidawsk.net Date: Wed Jul 17 12:19:03 2013 -0700 drm/i915: Create VMAs which resulted in an OOPS the first time around we've hit -ENOSPC. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67156 Cc: Imre Deak imre.d...@intel.com Cc: Ben Widawsky b...@bwidawsk.net Tested-by: meng mengmeng.m...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch I tried and failed to demonstrate that this was overkill. Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Completion of i915 VMAs
On Sun, Jul 21, 2013 at 07:08:07PM -0700, Ben Widawsky wrote: Map, and unmap are logical functionalities to add for an address space. They do more or less what you'd think: take an object and create a mapping via the GPU's page tables to that object. Of course, without the rest of the patches from [3], there will only ever be 1 address space, with the weird aliasing ppgtt behind it. One thing which I toyed with, but opted not to include was to directly pass obj,vm to map/unmap instead of doing the slightly less pretty way as I've done in execbuf and bind. In the future I think I may just do this, but for now it's not a big win as the end result wasn't much better (and I didn't get it to immediately work). That's annoying. Currently we use map to refer to the process of making a CPU mapping to the objects and bind for doing it from the GPU's perspective. And since the CPU map may well require a GPU map, keeping the nomenclature distinct helps easily confused me. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix hdmi portclock limits
On Mon, Jul 22, 2013 at 08:05:10AM +0200, Daniel Vetter wrote:
In
commit 325b9d048810f7689ec644595061c0b700e64bce
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri Apr 19 11:24:33 2013 +0200
drm/i915: fixup 12bpc hdmi dotclock handling
I've errornously claimed that we don't yet support the hdmi 1.4
dotclocks 225 MHz on Haswell. But a bug report and a closer look at
the wrpll table showed that we've supported port clocks up to 300MHz.
With the new code to dynamically compute wrpll limits we should have
no issues going up to the full 340 MHz range of hdmi 1.4, so let's
just use that to fix this regression. That'll allow 4k over hdmi for
free!
v2: Drop the random hunk that somehow slipped in.
v3: Cantiga has the original HDMI dotclock limit of 165MHz. And also
patch up the mode filtering. To do so extract the dotclock limits into
a little helper function.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67048
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
Tested-by: Andreas Reis andreas.r...@gmail.com (v2)
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Andreas Reis just upgrade his tested-by to v3.
-Daniel
---
drivers/gpu/drm/i915/intel_hdmi.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 98df2a0..23874a3 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -785,10 +785,22 @@ static void intel_disable_hdmi(struct intel_encoder
*encoder)
}
}
+static int hdmi_portclock_limit(struct intel_hdmi *hdmi)
+{
+ struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+
+ if (IS_G4X(dev))
+ return 165000;
+ else if (IS_HASWELL(dev))
+ return 34;
+ else
+ return 225000;
+}
+
static int intel_hdmi_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- if (mode-clock 165000)
+ if (mode-clock hdmi_portclock_limit(intel_attached_hdmi(connector)))
return MODE_CLOCK_HIGH;
if (mode-clock 2)
return MODE_CLOCK_LOW;
@@ -806,6 +818,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
struct drm_device *dev = encoder-base.dev;
struct drm_display_mode *adjusted_mode = pipe_config-adjusted_mode;
int clock_12bpc = pipe_config-requested_mode.clock * 3 / 2;
+ int portclock_limit = hdmi_portclock_limit(intel_hdmi);
int desired_bpp;
if (intel_hdmi-color_range_auto) {
@@ -829,7 +842,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
* outputs. We also need to check that the higher clock still fits
* within limits.
*/
- if (pipe_config-pipe_bpp 8*3 clock_12bpc = 225000
+ if (pipe_config-pipe_bpp 8*3 clock_12bpc = portclock_limit
HAS_PCH_SPLIT(dev)) {
DRM_DEBUG_KMS(picking bpc to 12 for HDMI output\n);
desired_bpp = 12*3;
@@ -846,7 +859,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
pipe_config-pipe_bpp = desired_bpp;
}
- if (adjusted_mode-clock 225000) {
+ if (adjusted_mode-clock portclock_limit) {
DRM_DEBUG_KMS(too high HDMI clock, rejecting mode\n);
return false;
}
--
1.8.3.2
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix hdmi portclock limits
On Mon, Jul 22, 2013 at 08:05:10AM +0200, Daniel Vetter wrote:
+static int hdmi_portclock_limit(struct intel_hdmi *hdmi)
+{
+ struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+
+ if (IS_G4X(dev))
+ return 165000;
+ else if (IS_HASWELL(dev))
+ return 34;
I read 300MHz in the BSpec?
+ else
+ return 225000;
+}
+
static int intel_hdmi_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- if (mode-clock 165000)
+ if (mode-clock hdmi_portclock_limit(intel_attached_hdmi(connector)))
return MODE_CLOCK_HIGH;
if (mode-clock 2)
return MODE_CLOCK_LOW;
@@ -806,6 +818,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
struct drm_device *dev = encoder-base.dev;
struct drm_display_mode *adjusted_mode = pipe_config-adjusted_mode;
int clock_12bpc = pipe_config-requested_mode.clock * 3 / 2;
+ int portclock_limit = hdmi_portclock_limit(intel_hdmi);
int desired_bpp;
if (intel_hdmi-color_range_auto) {
@@ -829,7 +842,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
* outputs. We also need to check that the higher clock still fits
* within limits.
*/
- if (pipe_config-pipe_bpp 8*3 clock_12bpc = 225000
+ if (pipe_config-pipe_bpp 8*3 clock_12bpc = portclock_limit
HAS_PCH_SPLIT(dev)) {
DRM_DEBUG_KMS(picking bpc to 12 for HDMI output\n);
desired_bpp = 12*3;
@@ -846,7 +859,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
pipe_config-pipe_bpp = desired_bpp;
}
- if (adjusted_mode-clock 225000) {
+ if (adjusted_mode-clock portclock_limit) {
DRM_DEBUG_KMS(too high HDMI clock, rejecting mode\n);
return false;
}
--
1.8.3.2
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915: create vmas at execbuf
On Sun, Jul 21, 2013 at 07:08:16PM -0700, Ben Widawsky wrote:
@@ -4054,7 +4051,7 @@ void i915_gem_free_object(struct drm_gem_object
*gem_obj)
struct i915_vma *i915_gem_vma_create(struct drm_i915_gem_object *obj,
struct i915_address_space *vm)
{
- struct i915_vma *vma = kzalloc(sizeof(*vma), GFP_KERNEL);
+ struct i915_vma *vma = kzalloc(sizeof(*vma), GFP_ATOMIC);
Hmm, possibly best to erradicate the allocations from underneath the
spinlock as the number may be rather large.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix hdmi portclock limits
On Mon, Jul 22, 2013 at 06:02:39PM +0200, Daniel Vetter wrote:
In
commit 325b9d048810f7689ec644595061c0b700e64bce
Author: Daniel Vetter daniel.vet...@ffwll.ch
Date: Fri Apr 19 11:24:33 2013 +0200
drm/i915: fixup 12bpc hdmi dotclock handling
I've errornously claimed that we don't yet support the hdmi 1.4
dotclocks 225 MHz on Haswell. But a bug report and a closer look at
the wrpll table showed that we've supported port clocks up to 300MHz.
With the new code to dynamically compute wrpll limits we should have
no issues going up to the full 340 MHz range of hdmi 1.4, so let's
just use that to fix this regression. That'll allow 4k over hdmi for
free!
v2: Drop the random hunk that somehow slipped in.
v3: Cantiga has the original HDMI dotclock limit of 165MHz. And also
patch up the mode filtering. To do so extract the dotclock limits into
a little helper function.
v4: Use 300MHz (from Bspec) instead of 340MHz (upper limit for hdmi
1.3), apparently hw is not required to be able to drive the highest
dotclocks. Suggested by Damien.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67048
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030
Tested-by: Andreas Reis andreas.r...@gmail.com (v2)
Cc: Damien Lespiau damien.lesp...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Reviewed-by: Damien Lespiau damien.lesp...@intel.com
--
Damien
---
drivers/gpu/drm/i915/intel_hdmi.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 98df2a0..2fd3fd5 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -785,10 +785,22 @@ static void intel_disable_hdmi(struct intel_encoder
*encoder)
}
}
+static int hdmi_portclock_limit(struct intel_hdmi *hdmi)
+{
+ struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+
+ if (IS_G4X(dev))
+ return 165000;
+ else if (IS_HASWELL(dev))
+ return 30;
+ else
+ return 225000;
+}
+
static int intel_hdmi_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- if (mode-clock 165000)
+ if (mode-clock hdmi_portclock_limit(intel_attached_hdmi(connector)))
return MODE_CLOCK_HIGH;
if (mode-clock 2)
return MODE_CLOCK_LOW;
@@ -806,6 +818,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
struct drm_device *dev = encoder-base.dev;
struct drm_display_mode *adjusted_mode = pipe_config-adjusted_mode;
int clock_12bpc = pipe_config-requested_mode.clock * 3 / 2;
+ int portclock_limit = hdmi_portclock_limit(intel_hdmi);
int desired_bpp;
if (intel_hdmi-color_range_auto) {
@@ -829,7 +842,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
* outputs. We also need to check that the higher clock still fits
* within limits.
*/
- if (pipe_config-pipe_bpp 8*3 clock_12bpc = 225000
+ if (pipe_config-pipe_bpp 8*3 clock_12bpc = portclock_limit
HAS_PCH_SPLIT(dev)) {
DRM_DEBUG_KMS(picking bpc to 12 for HDMI output\n);
desired_bpp = 12*3;
@@ -846,7 +859,7 @@ bool intel_hdmi_compute_config(struct intel_encoder
*encoder,
pipe_config-pipe_bpp = desired_bpp;
}
- if (adjusted_mode-clock 225000) {
+ if (adjusted_mode-clock portclock_limit) {
DRM_DEBUG_KMS(too high HDMI clock, rejecting mode\n);
return false;
}
--
1.8.3.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915 irq storm mitigation in 3.10
Hi all, Am 21.07.2013 22:43, schrieb Daniel Vetter: Can you please boot with drm.debug=0xe added to your kernel cmdline, do a cold boot (so that we get a storm) and then once everything is quiet grab the full kernel log (you probably have to grab it from the disk, dmesg has likely overflown) and upload it somewhere (since it's probably too big for the mailing lists)? Please also enable printk timestamps for your kernel so that we can create a timeline of everything going on. I hope I did it correctly, apending both printk.time=1 and drm.debug=0xe to my kernel command line: http://files.hz6.de/kern_20130722.log That log should give us a starting point, but I guess we need to run some debug patches past you to figure out what's going on in your system exactly. Did the drm.debug option work, it's not very chatty? Another thing I have noticed: All storm-related messages are about DP-3 and HDMI-A-1, but my T400 doesn't have either a HDMI out nor a DisplayPort connector... We'll only enable ports (and interrupts for them) if we think they're there. Could it be that there's a docking station for your machine available which would have these ports? Hmm, yes, I think so. Thank you all for helping diagnosing this issue! Regards jan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/12] Completion of i915 VMAs
On Mon, Jul 22, 2013 at 11:42:40AM +0100, Chris Wilson wrote: On Sun, Jul 21, 2013 at 07:08:07PM -0700, Ben Widawsky wrote: Map, and unmap are logical functionalities to add for an address space. They do more or less what you'd think: take an object and create a mapping via the GPU's page tables to that object. Of course, without the rest of the patches from [3], there will only ever be 1 address space, with the weird aliasing ppgtt behind it. One thing which I toyed with, but opted not to include was to directly pass obj,vm to map/unmap instead of doing the slightly less pretty way as I've done in execbuf and bind. In the future I think I may just do this, but for now it's not a big win as the end result wasn't much better (and I didn't get it to immediately work). That's annoying. Currently we use map to refer to the process of making a CPU mapping to the objects and bind for doing it from the GPU's perspective. And since the CPU map may well require a GPU map, keeping the nomenclature distinct helps easily confused me. -Chris -- Chris Wilson, Intel Open Source Technology Centre I can rename it, I expect you will review it. -- Ben Widawsky, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix hdmi portclock limits
On Mon, Jul 22, 2013 at 05:24:34PM +0100, Damien Lespiau wrote: On Mon, Jul 22, 2013 at 06:02:39PM +0200, Daniel Vetter wrote: In commit 325b9d048810f7689ec644595061c0b700e64bce Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Apr 19 11:24:33 2013 +0200 drm/i915: fixup 12bpc hdmi dotclock handling I've errornously claimed that we don't yet support the hdmi 1.4 dotclocks 225 MHz on Haswell. But a bug report and a closer look at the wrpll table showed that we've supported port clocks up to 300MHz. With the new code to dynamically compute wrpll limits we should have no issues going up to the full 340 MHz range of hdmi 1.4, so let's just use that to fix this regression. That'll allow 4k over hdmi for free! v2: Drop the random hunk that somehow slipped in. v3: Cantiga has the original HDMI dotclock limit of 165MHz. And also patch up the mode filtering. To do so extract the dotclock limits into a little helper function. v4: Use 300MHz (from Bspec) instead of 340MHz (upper limit for hdmi 1.3), apparently hw is not required to be able to drive the highest dotclocks. Suggested by Damien. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67048 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67030 Tested-by: Andreas Reis andreas.r...@gmail.com (v2) Cc: Damien Lespiau damien.lesp...@intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch Reviewed-by: Damien Lespiau damien.lesp...@intel.com Picked up for -fixes, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix hdmi portclock limits
On Mon, Jul 22, 2013 at 12:17:12PM +0100, Damien Lespiau wrote:
On Mon, Jul 22, 2013 at 08:05:10AM +0200, Daniel Vetter wrote:
+static int hdmi_portclock_limit(struct intel_hdmi *hdmi)
+{
+ struct drm_device *dev = intel_hdmi_to_dev(hdmi);
+
+ if (IS_G4X(dev))
+ return 165000;
+ else if (IS_HASWELL(dev))
+ return 34;
I read 300MHz in the BSpec?
To expand a bit here, HDMI 1.3 and 1.4 have their upper limit defined to
340MHz, but not every piece of hardware is able to achieve that. In our
case the limit seems to be 300MHz for HSW (which apparently is already
enough for some 4k resolutions).
HDMI 1.x and QHD is not that interesting, it can only up to 30Hz. DP
seems the way to go there until HDMI 2.0
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: add HAS_LP_PCH check
On Fri, Jul 19, 2013 at 06:58:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We have 2 possible LPT PCHs: the normal version, which contains the
pixel path (FDI, transcoders, VGA, etc), and the LP version, which
comes with ULT machines and doesn't contain the pixel path. Both
models return true for HAS_PCH_LPT.
We already have a few places where we explicitly check for LPT-LP, so
add a HAS_LP_PCH check to simplify the code.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
1-4 is:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
This patch I believe should have come first in the series (we discussed
on IRC), but meh.
Also, I think the name HAS_LP_PCH is no good since the LP is Low
Power. It really should be HAS_PCH_LPT_LP. I realize that's redundant
within the functions since they are lpt only, but this is defined in the
primary header file...
With that this too is:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 9 +++--
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 2885265..262c3d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1578,6 +1578,8 @@ struct drm_i915_file_private {
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
#define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
#define HAS_PCH_SPLIT(dev) (INTEL_PCH_TYPE(dev) != PCH_NONE)
+#define HAS_LP_PCH(dev_priv) ((dev_priv)-pch_id == \
+ INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
#define HAS_FORCE_WAKE(dev) (INTEL_INFO(dev)-has_force_wake)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c35a613..1d3c805 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5274,8 +5274,7 @@ static void lpt_enable_clkout_dp(struct drm_device
*dev, bool with_spread,
if (WARN(with_fdi !with_spread, FDI requires downspread\n))
with_spread = true;
- if (WARN(dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE
- with_fdi, LP PCH doesn't have FDI\n))
+ if (WARN(HAS_LP_PCH(dev_priv) with_fdi, LP PCH doesn't have FDI\n))
with_fdi = false;
mutex_lock(dev_priv-dpio_lock);
@@ -5298,8 +5297,7 @@ static void lpt_enable_clkout_dp(struct drm_device
*dev, bool with_spread,
}
}
- reg = (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
-SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_LP_PCH(dev_priv) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp |= SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
@@ -5315,8 +5313,7 @@ static void lpt_disable_clkout_dp(struct drm_device
*dev)
mutex_lock(dev_priv-dpio_lock);
- reg = (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
-SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_LP_PCH(dev_priv) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp = ~SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 43031ec..7643b16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4650,7 +4650,7 @@ static void lpt_init_clock_gating(struct drm_device
*dev)
* TODO: this bit should only be enabled when really needed, then
* disabled when not needed anymore in order to save power.
*/
- if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
+ if (HAS_LP_PCH(dev_priv))
I915_WRITE(SOUTH_DSPCLK_GATE_D,
I915_READ(SOUTH_DSPCLK_GATE_D) |
PCH_LP_PARTITION_LEVEL_DISABLE);
@@ -4665,7 +4665,7 @@ static void lpt_suspend_hw(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_LP_PCH(dev_priv)) {
uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
val = ~PCH_LP_PARTITION_LEVEL_DISABLE;
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
On Mon, Jul 22, 2013 at 12:12:38PM +0200, Daniel Vetter wrote:
This has been broken in
commit 2f63315692b1d3c055972ad33fc7168ae908b97b
Author: Ben Widawsky b...@bwidawsk.net
Date: Wed Jul 17 12:19:03 2013 -0700
drm/i915: Create VMAs
which resulted in an OOPS the first time around we've hit -ENOSPC.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67156
Cc: Imre Deak imre.d...@intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Tested-by: meng mengmeng.m...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index cfa6588..c87a6ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3121,8 +3121,8 @@ i915_gem_object_bind_to_gtt(struct drm_i915_gem_object
*obj,
vma = i915_gem_vma_create(obj, dev_priv-gtt.base);
if (IS_ERR(vma)) {
- i915_gem_object_unpin_pages(obj);
- return PTR_ERR(vma);
+ ret = PTR_ERR(vma);
+ goto err_unpin;
}
Adding the extra goto here seems pointless to me.
search_free:
@@ -3138,17 +3138,17 @@ search_free:
if (ret == 0)
goto search_free;
- goto err_out;
+ goto err_free_vma;
}
My preference would be to exit early in drm_mm_remove_node() if the node
isn't allocated. I think at least we should add a WARN to
drm_mm_remove_node if the node-allocated == 0.
if (WARN_ON(!i915_gem_valid_gtt_space(dev, vma-node,
obj-cache_level))) {
ret = -EINVAL;
- goto err_out;
+ goto err_remove_node;
}
ret = i915_gem_gtt_prepare_object(obj);
if (ret)
- goto err_out;
+ goto err_remove_node;
list_move_tail(obj-global_list, dev_priv-mm.bound_list);
list_add_tail(obj-mm_list, vm-inactive_list);
@@ -3167,9 +3167,11 @@ search_free:
i915_gem_verify_gtt(dev);
return 0;
-err_out:
+err_remove_node:
drm_mm_remove_node(vma-node);
+err_free_vma:
i915_gem_vma_destroy(vma);
+err_unpin:
i915_gem_object_unpin_pages(obj);
return ret;
}
Reviewed-by: Ben Widawsky b...@bwidawsk.net
--
Ben Widawsky, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fix up error cleanup in i915_gem_object_bind_to_gtt
On Mon, Jul 22, 2013 at 01:12:30PM -0700, Ben Widawsky wrote:
On Mon, Jul 22, 2013 at 12:12:38PM +0200, Daniel Vetter wrote:
This has been broken in
commit 2f63315692b1d3c055972ad33fc7168ae908b97b
Author: Ben Widawsky b...@bwidawsk.net
Date: Wed Jul 17 12:19:03 2013 -0700
drm/i915: Create VMAs
which resulted in an OOPS the first time around we've hit -ENOSPC.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67156
Cc: Imre Deak imre.d...@intel.com
Cc: Ben Widawsky b...@bwidawsk.net
Tested-by: meng mengmeng.m...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_gem.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index cfa6588..c87a6ec 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3121,8 +3121,8 @@ i915_gem_object_bind_to_gtt(struct
drm_i915_gem_object *obj,
vma = i915_gem_vma_create(obj, dev_priv-gtt.base);
if (IS_ERR(vma)) {
- i915_gem_object_unpin_pages(obj);
- return PTR_ERR(vma);
+ ret = PTR_ERR(vma);
+ goto err_unpin;
}
Adding the extra goto here seems pointless to me.
Like explained on irc, that's just to have a nice OCD reverse err_foo:
label stacking at the end of the function.
search_free:
@@ -3138,17 +3138,17 @@ search_free:
if (ret == 0)
goto search_free;
- goto err_out;
+ goto err_free_vma;
}
My preference would be to exit early in drm_mm_remove_node() if the node
isn't allocated. I think at least we should add a WARN to
drm_mm_remove_node if the node-allocated == 0.
Hm, good idea. I'll create a quick patch.
if (WARN_ON(!i915_gem_valid_gtt_space(dev, vma-node,
obj-cache_level))) {
ret = -EINVAL;
- goto err_out;
+ goto err_remove_node;
}
ret = i915_gem_gtt_prepare_object(obj);
if (ret)
- goto err_out;
+ goto err_remove_node;
list_move_tail(obj-global_list, dev_priv-mm.bound_list);
list_add_tail(obj-mm_list, vm-inactive_list);
@@ -3167,9 +3167,11 @@ search_free:
i915_gem_verify_gtt(dev);
return 0;
-err_out:
+err_remove_node:
drm_mm_remove_node(vma-node);
+err_free_vma:
i915_gem_vma_destroy(vma);
+err_unpin:
i915_gem_object_unpin_pages(obj);
return ret;
}
Reviewed-by: Ben Widawsky b...@bwidawsk.net
Queued for -next, thanks for the review.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm/i915: correctly restore fences with objects attached
Aside: When sending a mail to your maintainer please _always_ cc the relevant mailing list. On Tue, Jul 23, 2013 at 12:07 AM, member graysky gray...@archlinux.us wrote: Hello Daniel. I believe you patch has introduced at minimum an ERROR message to my dmesg. I applied to to 3.10.2 and whenever my screen wakes up from going to sleep, I get the following in my dmesg: [ 7114.087816] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [ 7174.521130] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting [11591.343093] [drm:intel_dp_complete_link_train] *ERROR* failed to train DP, aborting Should be unrelated. Have you tested the 3.10-rc7 kernel? That shouldn't have the resume corruption bug yet but is otherwise the same drm/i915 code as 3.10. Most likely the bug is there already. If that's the case can you please file a bug report on bugs.freedesktop.org against DRI - DRM (Intel)? Tahnks, Daniel Here is the link to the patch I applied: http://cgit.freedesktop.org/~danvet/drm-intel/commit/?id=94a335dba34ff47cad3d6d0c29b452d43a1be3c8 Also, I have commented on this in an Arch Linux bug report wherein your patch is mentioned. It might be more fruitful if you comment on the Arch Bug report. https://bugs.archlinux.org/task/36107 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: add HAS_LP_PCH check
2013/7/22 Ben Widawsky b...@bwidawsk.net:
On Fri, Jul 19, 2013 at 06:58:57PM -0300, Paulo Zanoni wrote:
From: Paulo Zanoni paulo.r.zan...@intel.com
We have 2 possible LPT PCHs: the normal version, which contains the
pixel path (FDI, transcoders, VGA, etc), and the LP version, which
comes with ULT machines and doesn't contain the pixel path. Both
models return true for HAS_PCH_LPT.
We already have a few places where we explicitly check for LPT-LP, so
add a HAS_LP_PCH check to simplify the code.
Signed-off-by: Paulo Zanoni paulo.r.zan...@intel.com
1-4 is:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
This patch I believe should have come first in the series (we discussed
on IRC), but meh.
Also, I think the name HAS_LP_PCH is no good since the LP is Low
Power. It really should be HAS_PCH_LPT_LP. I realize that's redundant
within the functions since they are lpt only, but this is defined in the
primary header file...
I was thinking in the future where other PCHs may also have this
LP/non-LP difference, so we'd use the HAS_LP_PCH macro for them. If we
want the macro to be PCH-specific we should probably even drop the
macro and keep using dev_priv-pch_id (drop this patch).
With that this too is:
Reviewed-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_display.c | 9 +++--
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 2885265..262c3d4 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1578,6 +1578,8 @@ struct drm_i915_file_private {
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
#define HAS_PCH_NOP(dev) (INTEL_PCH_TYPE(dev) == PCH_NOP)
#define HAS_PCH_SPLIT(dev) (INTEL_PCH_TYPE(dev) != PCH_NONE)
+#define HAS_LP_PCH(dev_priv) ((dev_priv)-pch_id == \
+ INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
#define HAS_FORCE_WAKE(dev) (INTEL_INFO(dev)-has_force_wake)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c35a613..1d3c805 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5274,8 +5274,7 @@ static void lpt_enable_clkout_dp(struct drm_device
*dev, bool with_spread,
if (WARN(with_fdi !with_spread, FDI requires downspread\n))
with_spread = true;
- if (WARN(dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE
- with_fdi, LP PCH doesn't have FDI\n))
+ if (WARN(HAS_LP_PCH(dev_priv) with_fdi, LP PCH doesn't have
FDI\n))
with_fdi = false;
mutex_lock(dev_priv-dpio_lock);
@@ -5298,8 +5297,7 @@ static void lpt_enable_clkout_dp(struct drm_device
*dev, bool with_spread,
}
}
- reg = (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
-SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_LP_PCH(dev_priv) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp |= SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
@@ -5315,8 +5313,7 @@ static void lpt_disable_clkout_dp(struct drm_device
*dev)
mutex_lock(dev_priv-dpio_lock);
- reg = (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) ?
-SBI_GEN0 : SBI_DBUFF0;
+ reg = HAS_LP_PCH(dev_priv) ? SBI_GEN0 : SBI_DBUFF0;
tmp = intel_sbi_read(dev_priv, reg, SBI_ICLK);
tmp = ~SBI_GEN0_CFG_BUFFENABLE_DISABLE;
intel_sbi_write(dev_priv, reg, tmp, SBI_ICLK);
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 43031ec..7643b16 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4650,7 +4650,7 @@ static void lpt_init_clock_gating(struct drm_device
*dev)
* TODO: this bit should only be enabled when really needed, then
* disabled when not needed anymore in order to save power.
*/
- if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE)
+ if (HAS_LP_PCH(dev_priv))
I915_WRITE(SOUTH_DSPCLK_GATE_D,
I915_READ(SOUTH_DSPCLK_GATE_D) |
PCH_LP_PARTITION_LEVEL_DISABLE);
@@ -4665,7 +4665,7 @@ static void lpt_suspend_hw(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- if (dev_priv-pch_id == INTEL_PCH_LPT_LP_DEVICE_ID_TYPE) {
+ if (HAS_LP_PCH(dev_priv)) {
uint32_t val = I915_READ(SOUTH_DSPCLK_GATE_D);
val = ~PCH_LP_PARTITION_LEVEL_DISABLE;
--
1.8.1.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
--
Paulo Zanoni
