Re: [Intel-gfx] Updated -next
Hi all, We finished new round Kernel testing. We covered both mobile and desktop machines on platforms IVB, SNB, ILK, GM965 and PNV. The Kernel the latest on -testing branch Daniel's tree: commit 0028cac2e9e91961384ac15aae4196eee0faf4f6 Merge: 121d527 b250da7 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Fri Mar 23 10:44:16 2012 +0100 Merge remote-tracking branch 'keithp-kernel/drm-intel-fixes' into drm-intel-testing Conflicts: drivers/gpu/drm/i915/intel_ringbuffer.c No new bugs are filed during this circle. But some old bugs about 3 pipes or eDP on IVB platform are still open now: Bug 41976 - [IVB] screen turn to be black while switching between console and x-window with 3-pipe active. (https://bugs.freedesktop.org/show_bug.cgi?id=41976) Bug 42194 - [IVB/SNB]plug in a monitor while running testdisplay fail to make the screen come up. (https://bugs.freedesktop.org/show_bug.cgi?id=42194) Bug 44309 - [IVB eDP] 3 pipe doesn't work with eDP monitor. (https://bugs.freedesktop.org/show_bug.cgi?id=44309) Bug 45867 - [IVB 3pipe] 3 Pipe Doesn't Work with Eaglemont Card. (https://bugs.freedesktop.org/show_bug.cgi?id=45867) Thanks --Yi,Sun -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Friday, March 23, 2012 6:03 PM To: Intel Graphics Development; Sun, Yi Subject: Updated -next Hi all, I've pushed out an updated -next and -testing tree. Highlights: - more decoupling of ppgtt and global gtt. - shut up the compiler (Ben) - a bunch of minor quirks and fixlets, accompanied with quite a few module options to ease debuggin (and adding new entries to these for these new quirks). This -next tree is already targeting 3.5. Happy testing! -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/18] drm/i915: preliminary context support
On Wed, Mar 28, 2012 at 03:59:17PM -0700, Ben Widawsky wrote: On Thu, 29 Mar 2012 00:43:00 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sun, Mar 18, 2012 at 01:39:42PM -0700, Ben Widawsky wrote: Very basic code for context setup/destruction in the driver. There are 4 entry points into the contexts, load, unload, open, close. The names are self-explanatory except that load can be called during reset, and also during pm thaw/resume. As we expect our context to be preserved across these events, we do not reinitialize in this case. Also an important note, as I intend to use contexts for ILK RC6, the context initialization must always come before RC6 initialization. As Adam Jackson pointed out, I picked an arbitrary cutoff of 1MB where I decide the HW context is too big. The reason for this is even though context sizes are increasing with every generation, they are still measured in pages. If we somehow read back way more than that, it probably means BIOS has done something strange, or we're running on a platform that wasn't designed for this. The 1MB was just a nice round number. I'm open to changing it to something sensible if someone has a better idea. Signed-off-by: Ben Widawsky b...@bwidawsk.net bikeshed I see not that much precedence for _load and _unload for setup/teardown ... Also this patch is imo way too early in the series - you just add empty functions so I have no idea what they're doing. And hence can't check whether you add them at the right place. Whereas if this comes later I already know what they're doing and can check without applying whether they're all called at the right place. /bikeshed I understand that you get no greater pleasure than bikeshedding my patches until I want to cry... but seriously with the precedent, it's in our driver already. So what do you want instead, setup()/teardown() - init/fini? Anyway, here is the precedent: i915_driver_UNLOAD()-i915_gem_context_unload() i915_driver_LOAD()-i915_gem_LOAD() // which used to call my function i915_driver_LOAD()-...-i915)gem_context_load() Well, I've fixed up gem_load, that's now also called init ;-) And driver_load and _unload are remnants from the stoneage, when these two functions could essentially only be called a moduel load/unload time. Now we have hotplug and drm drivers don't use stealth attach any more ... Anyway, I've seen a few things while reading your patches yesterday that looked puzzling and strange, but I didn't really know what to do with them. So I just added some easy bikeshed comments. After a nights worth of sleep I think I'm seeing clearer, so expect some real feedback soon. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/18] drm/i915: add context information to objects
On Wed, Mar 28, 2012 at 05:20:11PM -0700, Ben Widawsky wrote: On Thu, 29 Mar 2012 00:36:21 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sun, Mar 18, 2012 at 01:39:44PM -0700, Ben Widawsky wrote: Handy mostly for assertions. Signed-off-by: Ben Widawsky b...@bwidawsk.net I don't see the point of carrying around a obj-context_id - context_id's are file_priv, so they're not that useful in the tracepoint. I suggest you just drop the contex_id arg there - the obj pointers are global and imo good enough for identification. And the few BUG_ON's don't seem really useful either. -Daniel obj-context_id was requested by Chris to clarify the trace events. I vaguely recall telling him that you won't like it. That's easily shot down on the grounds that: - we currently don't dump the id/handles of gem objects into our traces - your tracepoints dump the context_id at create/destroy time, so with a bit of python this can be re-added in userspace. I personally dislike using object pointer though I do agree it serves the same purpose. The other nice thing about having the context id is it makes it easy in debug situations to find out if a certain object is a context object. But no use case for that yet. My gripes with obj-context_id is that it smells like a layering violation. We don't have such special stuff for other special things like rings. The only exception is framebuffer when pageflipping, but I expect that we'll need to clean this up sooner or later (because we need to be able to move framebuffers sooner or later anyway, so they need better integration with the gem eviction code). -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/2] semaphorify the pageflip BO (if possible)
On Wed, Mar 28, 2012 at 05:23:08PM -0700, Ben Widawsky wrote: Daniel, how do you want to handle this? It's somewhere on my list of things to do. I'd like to play around with this on my ivb first just to see what's going on, but otherwise nothing to complain about here. Yours, Daniel On Wed, 21 Mar 2012 17:19:11 -0700 Ben Widawsky b...@bwidawsk.net wrote: I've not observed any FPS changes with my limited testing. Here is the performance data I collected with nexuiz, measuring the latency of i915_gem_object_pin_to_display_plane. Top is before, bottom is after. N Min MaxMedian Avg Stddev x 2246 0.35237.538 2.791 3.3091901 1.8631844 + 2239 0.28144.517 2.699 3.088992 1.583838 Difference at 95.0% confidence -0.220198 +/- 0.101227 -6.65414% +/- 3.05896% (Student's t, pooled s = 1.72938) Ben Widawsky (2): drm/i915: extract ring sync code drm/i915: use semaphores for the display plane drivers/gpu/drm/i915/i915_drv.h| 19 + drivers/gpu/drm/i915/i915_gem.c| 51 --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 60 +--- 3 files changed, 66 insertions(+), 64 deletions(-) -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ValleyView patches
On Wed, Mar 28, 2012 at 01:39:20PM -0700, Jesse Barnes wrote: Updated patchset addressing comments. I dropped some: - display reg offset (we're going to fix this up differently) - cache handling (not needed) along with the ones Daniel has already queued. Hopefully these ones look ok to people and we can get them queued up as well. Ok, I've picked up quite a few of these here. Three patches (the one I've sent out to the m-l) are slightly changed, just to increase the chance we don't break bisect. I've complained here or on irc about a few others. I also haven't picked up most of the output handling changes - I think we should wait until you have access to real hw again and until we have a clearer picture how we're gonna solve the mmio_base problem. I obviously also left out the device id binding patch. For further merging I'd like to have basic vlv working before applying the dev id binding patch. Now the mmio_base disaster is a bit big, so would concentrating on just one output (intel_hdmi.c looks the most mmio_base clean already) help? This way we'd only need to wrestle with getting core i9xx modesetting stuff mmio_base aware. I'd then merge the dev id binding patch right after we have support for this. Tackling the mess in intel_crt.c and intel_dp.c (and the panel stuff like the PP_ regs) would then happen in a second step. My issue here is that atm we have 2 new platforms to merge at the same time, so I'd like to get basic vlv working asap. We have intel_display.c to clean up after merging hsw and vlv, after all ... If you prefer a different plan, ideas highly welcome. Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken LVDS output at mode changes
On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote:
Hi,
we've encountered a broken LVDS output on some IVY/SNB machines when
the mode is changed (from/to native resolution). When this happens,
the whole laptop panel gets half white and half black. This doesn't
recover until the LVDS is turned off once.
And, there is no signficant difference between working and non-working
cases in the register dumps. From the software POV, all looks sane.
So, we suspect this is rather specific to some panel hardware.
However, through debugging, I found that disabling LVDS at mode change
works around the problem. A test patch is attached below.
My question now is: can this workaround have any serious drawback?
I thought of a longer blank time, but I didn't notice any difference
before and after the patch.
Or, any other suggestion as a saner fix?
No idea, I'm wondering though whether we should just accept some
flickering while modesetting unconditionally. Does anyone know what
Windows does in this case and at least on my work machine here it looks
like Windows just blanks the screen. I haven't checked with reg dumps
though how exactly they upscale stuff on lvds.
git blame says that Chris Wilson created the original PCH_SPLIT check.
Chris, any comments on this?
Yours, Daniel
thanks,
Takashi
---
---
drivers/gpu/drm/i915/intel_lvds.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -398,6 +398,26 @@ out:
return true;
}
+static int intel_disable_at_modeset_callback(const struct dmi_system_id *id)
+{
+ DRM_DEBUG_KMS(Disabling LVDS at modeset for %s\n, id-ident);
+ return 1;
+}
+
+/* Requires to disable LVDS for avoiding a broken screen at mode change */
+static const struct dmi_system_id intel_disable_at_modeset[] = {
+ {
+ .callback = intel_disable_at_modeset_callback,
+ .ident = HP ProBook,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Hewlett-Packard),
+ DMI_MATCH(DMI_PRODUCT_NAME, HP ProBook),
+ },
+ },
+
+ { } /* terminating entry */
+};
+
static void intel_lvds_prepare(struct drm_encoder *encoder)
{
struct intel_lvds *intel_lvds = to_intel_lvds(encoder);
@@ -407,7 +427,8 @@ static void intel_lvds_prepare(struct dr
* the panel fitter. However at all other times we can just reset
* the registers regardless.
*/
- if (!HAS_PCH_SPLIT(encoder-dev) intel_lvds-pfit_dirty)
+ if ((!HAS_PCH_SPLIT(encoder-dev) intel_lvds-pfit_dirty) ||
+ dmi_check_system(intel_disable_at_modeset))
intel_lvds_disable(intel_lvds);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken LVDS output at mode changes
On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote: Hi, we've encountered a broken LVDS output on some IVY/SNB machines when the mode is changed (from/to native resolution). When this happens, the whole laptop panel gets half white and half black. This doesn't recover until the LVDS is turned off once. And, there is no signficant difference between working and non-working cases in the register dumps. From the software POV, all looks sane. So, we suspect this is rather specific to some panel hardware. However, through debugging, I found that disabling LVDS at mode change works around the problem. A test patch is attached below. My question now is: can this workaround have any serious drawback? I thought of a longer blank time, but I didn't notice any difference before and after the patch. Or, any other suggestion as a saner fix? No idea, I'm wondering though whether we should just accept some flickering while modesetting unconditionally. Does anyone know what Windows does in this case and at least on my work machine here it looks like Windows just blanks the screen. I haven't checked with reg dumps though how exactly they upscale stuff on lvds. git blame says that Chris Wilson created the original PCH_SPLIT check. Chris, any comments on this? It dates back from an earlier commit that presupposes that we can modify the panel on the fly and avoid the power-cycling delays. PP_STATUS: Panel Power On Status [bit 31] In conjunction with bits Power Sequence Progress field and Power Cycle Delay Active, this bit set to a one indicates that the panel is currently powered up or is currently in the power down sequence and it is unsafe to change the timing, port, and DPLL registers for the pipe or transcoder that is assigned to the panel output. Guess that rules that out. -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] Broken LVDS output at mode changes
On Thu, Mar 29, 2012 at 01:44:28PM +0100, Chris Wilson wrote: On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote: Hi, we've encountered a broken LVDS output on some IVY/SNB machines when the mode is changed (from/to native resolution). When this happens, the whole laptop panel gets half white and half black. This doesn't recover until the LVDS is turned off once. And, there is no signficant difference between working and non-working cases in the register dumps. From the software POV, all looks sane. So, we suspect this is rather specific to some panel hardware. However, through debugging, I found that disabling LVDS at mode change works around the problem. A test patch is attached below. My question now is: can this workaround have any serious drawback? I thought of a longer blank time, but I didn't notice any difference before and after the patch. Or, any other suggestion as a saner fix? No idea, I'm wondering though whether we should just accept some flickering while modesetting unconditionally. Does anyone know what Windows does in this case and at least on my work machine here it looks like Windows just blanks the screen. I haven't checked with reg dumps though how exactly they upscale stuff on lvds. git blame says that Chris Wilson created the original PCH_SPLIT check. Chris, any comments on this? It dates back from an earlier commit that presupposes that we can modify the panel on the fly and avoid the power-cycling delays. PP_STATUS: Panel Power On Status [bit 31] In conjunction with bits Power Sequence Progress field and Power Cycle Delay Active, this bit set to a one indicates that the panel is currently powered up or is currently in the power down sequence and it is unsafe to change the timing, port, and DPLL registers for the pipe or transcoder that is assigned to the panel output. Guess that rules that out. Takashi, can you respin your patch to just unconditionally switch of the lvds also on PCH_SPLIT platforms then? -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] OpenGL Extension support on IVY Bridge
Thanks Kenneth. There isn't a specific extension that I am looking at now. I was hoping for reference list to check what the extension details on what has been accelerated, punted to fallback or like the GetGraphicResetStatus() case implemented as a noop on Ivy Bridge. Right now my best alternative would be to trace through the codes for any anything more specific and like you said IVB supports everything as Gen 6. I'll make sure the mailing list is aware if any extension needs enabling. There was another option I saw on Pixel read/write but that is hardware enable by default so that isn't a big deal. Douglas -Original Message- From: Kenneth Graunke [mailto:kenn...@whitecape.org] Sent: Thursday, March 29, 2012 1:30 PM To: Cheah, Douglas Cc: Intel-gfx@lists.freedesktop.org Subject: Re: [Intel-gfx] OpenGL Extension support on IVY Bridge On 03/28/2012 07:41 PM, Cheah, Douglas wrote: Hello folks, Hi Douglas, I like to know if there is an active list available of supported list OpenGL and OpenGLES for IVY Bridge? I am looking for a comprehensive list that include information on hardware support instead of list of supported extension just like GL_EXTENSION. Not that I'm aware of. We currently expose the same set of extensions on Ivy Bridge as we do on Sandy Bridge. If you have any specific inquiries, I'd be happy to answer them as best as I can. Also, if there are any extensions you'd like us to support, let us know. For example GL_ARB_robustness is supported but it seem like the GetGraphicResetStatus() isn't supported, is this tied down to hardware? We're planning on implementing that soon; Ian, Eric, and Ben have been working out the details. I am also interested details on extension support that can be configure such as support for s3tc texture compression which looks to be a DRI config option. Douglas For now, the two configurable extensions are: - S3TC texture compression support To enable this, you need to install the libtxc_dxtn library. Mesa will then automatically detect the library and use it. No driconf options are necessary. - Floating point texture support To enable this, you need to build Mesa with: ./configure --enable-texture-float Enabling this also makes the driver expose OpenGL 3.0 rather than 2.1. Both of these are, unfortunately, encumbered by patents. (Otherwise, we'd just enable them all the time.) We still need to consult legal about this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken LVDS output at mode changes
At Thu, 29 Mar 2012 14:51:32 +0200, Daniel Vetter wrote: On Thu, Mar 29, 2012 at 01:44:28PM +0100, Chris Wilson wrote: On Thu, 29 Mar 2012 14:16:38 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Wed, Mar 28, 2012 at 03:29:04PM +0200, Takashi Iwai wrote: Hi, we've encountered a broken LVDS output on some IVY/SNB machines when the mode is changed (from/to native resolution). When this happens, the whole laptop panel gets half white and half black. This doesn't recover until the LVDS is turned off once. And, there is no signficant difference between working and non-working cases in the register dumps. From the software POV, all looks sane. So, we suspect this is rather specific to some panel hardware. However, through debugging, I found that disabling LVDS at mode change works around the problem. A test patch is attached below. My question now is: can this workaround have any serious drawback? I thought of a longer blank time, but I didn't notice any difference before and after the patch. Or, any other suggestion as a saner fix? No idea, I'm wondering though whether we should just accept some flickering while modesetting unconditionally. Does anyone know what Windows does in this case and at least on my work machine here it looks like Windows just blanks the screen. I haven't checked with reg dumps though how exactly they upscale stuff on lvds. git blame says that Chris Wilson created the original PCH_SPLIT check. Chris, any comments on this? It dates back from an earlier commit that presupposes that we can modify the panel on the fly and avoid the power-cycling delays. PP_STATUS: Panel Power On Status [bit 31] In conjunction with bits Power Sequence Progress field and Power Cycle Delay Active, this bit set to a one indicates that the panel is currently powered up or is currently in the power down sequence and it is unsafe to change the timing, port, and DPLL registers for the pipe or transcoder that is assigned to the panel output. Guess that rules that out. Takashi, can you respin your patch to just unconditionally switch of the lvds also on PCH_SPLIT platforms then? The hardware I've tested are actually on PCH_SPLIT, IvyBridge and SandyBridge machines. I'll test IronLake and GM45 machines whether unconditonally switching will give any regressions. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken LVDS output at mode changes
#part sign=pgpmime On Thu, 29 Mar 2012 13:44:28 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: In conjunction with bits Power Sequence Progress field and Power Cycle Delay Active, this bit set to a one indicates that the panel is currently powered up or is currently in the power down sequence and it is unsafe to change the timing, port, and DPLL registers for the pipe or transcoder that is assigned to the panel output. The theory was that as we don't touch the DPLL and only modify the scaler, that the panel wouldn't care. I wonder what's confusing this one... -- keith.pack...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/41] [RFC] Haswell v2
This is an updated set of patches for Haswell enablement. I tried to address all the comments, and re-diffed the patches to simplify their inclusion into Daniel's tree. I have also split the PCI IDs definitions and their hook-up into the binding tables as well. But I think we should wait on picking up those 2 patches for now - the PCI ID allocation logic here will still receive some additional changes I think. Functionality-wise, those patches do detect digital outputs now, namely HDMI, but said outputs do not (yet) work. The digital output detection process is also different from what we had previously - we can detect the presence of a connection on a port via DDI port feedback, but we cannot say if it is HDMI or DP. So I am not quite certain on how to address this properly in the driver yet. For now, I just blindly assume that it is HDMI as I don't have any DP monitors or connectors to test :). But for all means, please consider that support for digital outputs in this series is still unfinished and will change considerable in the future. Nonetheless, any feedback on how to implement it properly is much welcome. Note that with the DDI buffers, the same port can drive DP and HDMI without any buffer configuration changes; and we can drive FDI and HDMI likewise. So I've split the DDI buffers settings into a separate patch to pre-configure the ports to their suggested connection settings at the init time, which should work for any combinations of outputs. As for other changes, there are some comments improvements, some register name changes, a new enum for DDI ports, some changes in SBI handchake handling, a couple of new clocks we need for digital outputs and a bit of changes in the DDI pipe settings handling code. So Daniel, as we talked on irc, could you check which of those patches could be early picked into your tree? This would reduce future patchbombs from my side - I'd expect to have at least a half-dozen new patches until we'll have working digital outputs in place.. Eugeni Dodonov (41): drm/i915: transform HAS_PCH_SPLIT in a feature check drm/i915: add Haswell devices and their PCI IDs drm/i915: hook Haswell devices in place drm/i915: add support for LynxPoint PCH drm/i915: add support for power wells drm/i915: add enumeration for DDI ports drm/i915: add DDI registers drm/i915: add DP_TP_CTL registers drm/i915: add DP_TP_STATUS registers drm/i915: add definitions for DDI_BUF_CTL registers drm/i915: add definition of DDI buffer translations regs drm/i915: add definition of LPT FDI port width registers drm/i915: add SBI registers drm/i915: add support for SBI ops drm/i915: add PIXCLK_GATE register drm/i915: add S PLL control drm/i915: add port clock selection support for HSW drm/i915: add SSC offsets for SBI access drm/i915: add LCPLL control registers drm/i915: add WRPLL clocks drm/i915: add WM_LINETIME registers drm/i915: add SFUSE_STRAP registers for digital port detection drm/i915: calculate same watermarks on Haswell as on Ivy Bridge drm/i915: share forcewaking code between IVB and HSW drm/i915: haswell has 3 pipes as well drm/i915: reuse Ivybridge interrupts code for Haswell drm/i915: share pipe count handling with Ivybridge drm/i915: share IVB cursor routine with Haswell drm/i915: show unknown sdvox registers on hdmi init drm/i915: enable power wells on haswell init drm/i915: disable rc6 on haswell for now drm/i915: program WM_LINETIME on Haswell drm/i915: initialize DDI buffer translations drm/i915: perform Haswell DDI link training in FDI mode drm/i915: disable pipe DDI function when disabling pipe drm/i915: do not use fdi_normal_train on haswell drm/i915: program iCLKIP on Lynx Point drm/i915: detect digital outputs on Haswell drm/i915: add support for DDI-controlled digital outputs drm/i915: prepare HDMI link for Haswell drm/i915: add debugging bits for haswell modesetting drivers/char/agp/intel-agp.c |4 + drivers/char/agp/intel-agp.h | 11 + drivers/char/agp/intel-gtt.c | 14 + drivers/gpu/drm/i915/i915_dma.c |2 +- drivers/gpu/drm/i915/i915_drv.c | 37 ++ drivers/gpu/drm/i915/i915_drv.h | 17 +- drivers/gpu/drm/i915/i915_irq.c |6 +- drivers/gpu/drm/i915/i915_reg.h | 194 + drivers/gpu/drm/i915/intel_display.c | 733 -- drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_hdmi.c| 84 +++- 11 files changed, 1064 insertions(+), 39 deletions(-) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/41] drm/i915: transform HAS_PCH_SPLIT in a feature check
The macro is becoming too complex and with VLV upon us it can lead to
confusion. So transforming this into a feature check instead.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |6 ++
drivers/gpu/drm/i915/i915_drv.h |3 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8e2c52e..9cf66e1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -211,6 +211,7 @@ static const struct intel_device_info intel_ironlake_d_info
= {
.gen = 5,
.need_gfx_hws = 1, .has_hotplug = 1,
.has_bsd_ring = 1,
+ .has_pch_split = 1,
};
static const struct intel_device_info intel_ironlake_m_info = {
@@ -218,6 +219,7 @@ static const struct intel_device_info intel_ironlake_m_info
= {
.need_gfx_hws = 1, .has_hotplug = 1,
.has_fbc = 1,
.has_bsd_ring = 1,
+ .has_pch_split = 1,
};
static const struct intel_device_info intel_sandybridge_d_info = {
@@ -226,6 +228,7 @@ static const struct intel_device_info
intel_sandybridge_d_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.has_llc = 1,
+ .has_pch_split = 1,
};
static const struct intel_device_info intel_sandybridge_m_info = {
@@ -235,6 +238,7 @@ static const struct intel_device_info
intel_sandybridge_m_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.has_llc = 1,
+ .has_pch_split = 1,
};
static const struct intel_device_info intel_ivybridge_d_info = {
@@ -243,6 +247,7 @@ static const struct intel_device_info
intel_ivybridge_d_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.has_llc = 1,
+ .has_pch_split = 1,
};
static const struct intel_device_info intel_ivybridge_m_info = {
@@ -252,6 +257,7 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
.has_bsd_ring = 1,
.has_blt_ring = 1,
.has_llc = 1,
+ .has_pch_split = 1,
};
static const struct pci_device_id pciidlist[] = { /* aka */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f2f9dd9..0443f2d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -255,6 +255,7 @@ struct intel_device_info {
u8 is_broadwater:1;
u8 is_crestline:1;
u8 is_ivybridge:1;
+ u8 has_pch_split:1;
u8 has_fbc:1;
u8 has_pipe_cxsr:1;
u8 has_hotplug:1;
@@ -1048,7 +1049,7 @@ struct drm_i915_file_private {
#define HAS_PIPE_CXSR(dev) (INTEL_INFO(dev)-has_pipe_cxsr)
#define I915_HAS_FBC(dev) (INTEL_INFO(dev)-has_fbc)
-#define HAS_PCH_SPLIT(dev) (IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev))
+#define HAS_PCH_SPLIT(dev) (INTEL_INFO(dev)-has_pch_split)
#define HAS_PIPE_CONTROL(dev) (INTEL_INFO(dev)-gen = 5)
#define INTEL_PCH_TYPE(dev) (((struct drm_i915_private
*)(dev)-dev_private)-pch_type)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/41] drm/i915: add Haswell devices and their PCI IDs
This adds product definitions for desktop, mobile and server boards.
v2: split into a separate patch, add .has_pch_split feature.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/char/agp/intel-agp.h| 11 +++
drivers/char/agp/intel-gtt.c| 14 ++
drivers/gpu/drm/i915/i915_drv.c | 18 ++
drivers/gpu/drm/i915/i915_drv.h |2 ++
4 files changed, 45 insertions(+)
diff --git a/drivers/char/agp/intel-agp.h b/drivers/char/agp/intel-agp.h
index 5da67f1..46394c11 100644
--- a/drivers/char/agp/intel-agp.h
+++ b/drivers/char/agp/intel-agp.h
@@ -234,6 +234,17 @@
#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_GT2_IG 0x0166
#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_HB 0x0158 /* Server */
#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT1_IG 0x015A
+#define PCI_DEVICE_ID_INTEL_HASWELL_HB 0x0400 /*
Desktop */
+#define PCI_DEVICE_ID_INTEL_HASWELL_D_GT1_IG 0x0402
+#define PCI_DEVICE_ID_INTEL_HASWELL_D_GT2_IG 0x0412
+#define PCI_DEVICE_ID_INTEL_HASWELL_M_HB 0x0404 /*
Mobile */
+#define PCI_DEVICE_ID_INTEL_HASWELL_M_GT1_IG 0x0406
+#define PCI_DEVICE_ID_INTEL_HASWELL_M_GT2_IG 0x0416
+#define PCI_DEVICE_ID_INTEL_HASWELL_S_HB 0x0408 /*
Server */
+#define PCI_DEVICE_ID_INTEL_HASWELL_S_GT1_IG 0x040a
+#define PCI_DEVICE_ID_INTEL_HASWELL_S_GT2_IG 0x041a
+#define PCI_DEVICE_ID_INTEL_HASWELL_SDV0x0c16 /* SDV */
+#define PCI_DEVICE_ID_INTEL_HASWELL_E_HB 0x0c04
int intel_gmch_probe(struct pci_dev *pdev,
struct agp_bridge_data *bridge);
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 5cf47ac..f494556 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1459,6 +1459,20 @@ static const struct intel_gtt_driver_description {
Ivybridge, sandybridge_gtt_driver },
{ PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT1_IG,
Ivybridge, sandybridge_gtt_driver },
+ { PCI_DEVICE_ID_INTEL_HASWELL_D_GT1_IG,
+ Haswell, sandybridge_gtt_driver },
+ { PCI_DEVICE_ID_INTEL_HASWELL_D_GT2_IG,
+ Haswell, sandybridge_gtt_driver },
+ { PCI_DEVICE_ID_INTEL_HASWELL_M_GT1_IG,
+ Haswell, sandybridge_gtt_driver },
+ { PCI_DEVICE_ID_INTEL_HASWELL_M_GT2_IG,
+ Haswell, sandybridge_gtt_driver },
+ { PCI_DEVICE_ID_INTEL_HASWELL_S_GT1_IG,
+ Haswell, sandybridge_gtt_driver },
+ { PCI_DEVICE_ID_INTEL_HASWELL_S_GT2_IG,
+ Haswell, sandybridge_gtt_driver },
+ { PCI_DEVICE_ID_INTEL_HASWELL_SDV,
+ Haswell, sandybridge_gtt_driver },
{ 0, NULL, NULL }
};
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9cf66e1..6e4d90c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -260,6 +260,24 @@ static const struct intel_device_info
intel_ivybridge_m_info = {
.has_pch_split = 1,
};
+static const struct intel_device_info intel_haswell_d_info = {
+ .is_haswell = 1, .gen = 7,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .has_bsd_ring = 1,
+ .has_blt_ring = 1,
+ .has_llc = 1,
+ .has_pch_split = 1,
+};
+
+static const struct intel_device_info intel_haswell_m_info = {
+ .is_haswell = 1, .gen = 7, .is_mobile = 1,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .has_bsd_ring = 1,
+ .has_blt_ring = 1,
+ .has_llc = 1,
+ .has_pch_split = 1,
+};
+
static const struct pci_device_id pciidlist[] = { /* aka */
INTEL_VGA_DEVICE(0x3577, intel_i830_info), /* I830_M */
INTEL_VGA_DEVICE(0x2562, intel_845g_info), /* 845_G */
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0443f2d..90681d6 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -256,6 +256,7 @@ struct intel_device_info {
u8 is_crestline:1;
u8 is_ivybridge:1;
u8 has_pch_split:1;
+ u8 is_haswell:1;
u8 has_fbc:1;
u8 has_pipe_cxsr:1;
u8 has_hotplug:1;
@@ -1006,6 +1007,7 @@ struct drm_i915_file_private {
#define IS_IRONLAKE_D(dev) ((dev)-pci_device == 0x0042)
#define IS_IRONLAKE_M(dev) ((dev)-pci_device == 0x0046)
#define IS_IVYBRIDGE(dev) (INTEL_INFO(dev)-is_ivybridge)
+#define IS_HASWELL(dev)(INTEL_INFO(dev)-is_haswell)
#define IS_MOBILE(dev) (INTEL_INFO(dev)-is_mobile)
/*
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/41] drm/i915: hook Haswell devices in place
This patch enabled i915 driver to handle Haswell devices. It should go in
last, when things are working stable enough.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/char/agp/intel-agp.c|4
drivers/gpu/drm/i915/i915_drv.c |7 +++
2 files changed, 11 insertions(+)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index 962e75d..0ad4933 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -907,6 +907,10 @@ static struct pci_device_id agp_intel_pci_table[] = {
ID(PCI_DEVICE_ID_INTEL_IVYBRIDGE_HB),
ID(PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_HB),
ID(PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_HB),
+ ID(PCI_DEVICE_ID_INTEL_HASWELL_HB),
+ ID(PCI_DEVICE_ID_INTEL_HASWELL_M_HB),
+ ID(PCI_DEVICE_ID_INTEL_HASWELL_S_HB),
+ ID(PCI_DEVICE_ID_INTEL_HASWELL_E_HB),
{ }
};
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 6e4d90c..8995165 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -322,6 +322,13 @@ static const struct pci_device_id pciidlist[] = {
/* aka */
INTEL_VGA_DEVICE(0x0152, intel_ivybridge_d_info), /* GT1 desktop */
INTEL_VGA_DEVICE(0x0162, intel_ivybridge_d_info), /* GT2 desktop */
INTEL_VGA_DEVICE(0x015a, intel_ivybridge_d_info), /* GT1 server */
+ INTEL_VGA_DEVICE(0x0402, intel_haswell_d_info), /* GT1 desktop */
+ INTEL_VGA_DEVICE(0x0412, intel_haswell_d_info), /* GT2 desktop */
+ INTEL_VGA_DEVICE(0x040a, intel_haswell_d_info), /* GT1 server */
+ INTEL_VGA_DEVICE(0x041a, intel_haswell_d_info), /* GT2 server */
+ INTEL_VGA_DEVICE(0x0406, intel_haswell_m_info), /* GT1 mobile */
+ INTEL_VGA_DEVICE(0x0416, intel_haswell_m_info), /* GT2 mobile */
+ INTEL_VGA_DEVICE(0x0c16, intel_haswell_d_info), /* SDV */
{0, 0, 0}
};
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/41] drm/i915: add support for LynxPoint PCH
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |4
drivers/gpu/drm/i915/i915_drv.h |2 ++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8995165..e4b5571 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -340,6 +340,7 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
#define INTEL_PCH_IBX_DEVICE_ID_TYPE 0x3b00
#define INTEL_PCH_CPT_DEVICE_ID_TYPE 0x1c00
#define INTEL_PCH_PPT_DEVICE_ID_TYPE 0x1e00
+#define INTEL_PCH_LPT_DEVICE_ID_TYPE 0x8c00
void intel_detect_pch(struct drm_device *dev)
{
@@ -368,6 +369,9 @@ void intel_detect_pch(struct drm_device *dev)
/* PantherPoint is CPT compatible */
dev_priv-pch_type = PCH_CPT;
DRM_DEBUG_KMS(Found PatherPoint PCH\n);
+ } else if (id == INTEL_PCH_LPT_DEVICE_ID_TYPE) {
+ dev_priv-pch_type = PCH_LPT;
+ DRM_DEBUG_KMS(Found LynxPoint PCH\n);
}
}
pci_dev_put(pch);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 90681d6..146778e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -293,6 +293,7 @@ enum no_fbc_reason {
enum intel_pch {
PCH_IBX,/* Ibexpeak PCH */
PCH_CPT,/* Cougarpoint PCH */
+ PCH_LPT,/* Lynxpoint PCH */
};
#define QUIRK_PIPEA_FORCE (10)
@@ -1055,6 +1056,7 @@ struct drm_i915_file_private {
#define HAS_PIPE_CONTROL(dev) (INTEL_INFO(dev)-gen = 5)
#define INTEL_PCH_TYPE(dev) (((struct drm_i915_private
*)(dev)-dev_private)-pch_type)
+#define HAS_PCH_LPT(dev) (INTEL_PCH_TYPE(dev) == PCH_LPT)
#define HAS_PCH_CPT(dev) (INTEL_PCH_TYPE(dev) == PCH_CPT)
#define HAS_PCH_IBX(dev) (INTEL_PCH_TYPE(dev) == PCH_IBX)
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/41] drm/i915: add support for power wells
This defines the registers used by different power wells. Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 13 + 1 file changed, 13 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 52a06be..b13ed38 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3850,4 +3850,17 @@ #define AUD_CONFIG_PIXEL_CLOCK_HDMI (0xf 16) #define AUD_CONFIG_DISABLE_NCTS (1 3) +/* HSW Power Wells */ +#define HSW_PWR_WELL_CTL1 0x45400 /* BIOS */ +#define HSW_PWR_WELL_CTL2 0x45404 /* Driver */ +#define HSW_PWR_WELL_CTL3 0x45408 /* KVMR */ +#define HSW_PWR_WELL_CTL4 0x4540C /* Debug */ +#define HSW_PWR_WELL_ENABLE (131) +#define HSW_PWR_WELL_STATE (130) +#define HSW_PWR_WELL_CTL5 0x45410 +#define HSW_PWR_WELL_ENABLE_SINGLE_STEP (131) +#define HSW_PWR_WELL_PWR_GATE_OVERRIDE (120) +#define HSW_PWR_WELL_FORCE_ON(119) +#define HSW_PWR_WELL_CTL6 0x45414 + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/41] drm/i915: add enumeration for DDI ports
There are 5 DDI ports on Haswell. Port A is always enabled, and is the one
connected to eDP, and Port E is the one that can be connected to the PCH
using FDI protocol. Ports B, C, D and E can be used for digital outputs.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 10 ++
drivers/gpu/drm/i915/i915_reg.h |2 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 146778e..a30e88f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -63,6 +63,16 @@ enum plane {
};
#define plane_name(p) ((p) + 'A')
+enum port {
+ PORT_A = 0,
+ PORT_B,
+ PORT_C,
+ PORT_D,
+ PORT_E,
+ I915_MAX_PORTS
+};
+#define port_name(p) ((p) + 'A')
+
#define I915_GEM_GPU_DOMAINS (~(I915_GEM_DOMAIN_CPU | I915_GEM_DOMAIN_GTT))
#define for_each_pipe(p) for ((p) = 0; (p) dev_priv-num_pipe; (p)++)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index b13ed38..cf7b397 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -27,6 +27,8 @@
#define _PIPE(pipe, a, b) ((a) + (pipe)*((b)-(a)))
+#define _PORT(port, a, b) ((a) + (port)*((b)-(a)))
+
/*
* The Bridge device's PCI config space has information about the
* fb aperture size and the amount of pre-reserved memory.
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/41] drm/i915: add DDI registers
There is one set of such registers for each pipe (A/B/C/EDP). v2: update to use DDI PORTS enum v1 Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index cf7b397..26c6929 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3865,4 +3865,30 @@ #define HSW_PWR_WELL_FORCE_ON(119) #define HSW_PWR_WELL_CTL6 0x45414 +/* Per-pipe DDI Function Control */ +#define PIPE_DDI_FUNC_CTL_A0x60400 +#define PIPE_DDI_FUNC_CTL_B0x61400 +#define PIPE_DDI_FUNC_CTL_C0x62400 +#define PIPE_DDI_FUNC_CTL_EDP 0x6F400 +#define DDI_FUNC_CTL(pipe) _PIPE(pipe, \ + PIPE_DDI_FUNC_CTL_A, \ + PIPE_DDI_FUNC_CTL_B) +#define PIPE_DDI_FUNC_ENABLE (131) +/* Those bits are ignored by pipe EDP since it can only connect to DDI A */ +#define PIPE_DDI_PORT_MASK(0xf28) +#define PIPE_DDI_SELECT_PORT(x) ((x)28) +#define PIPE_DDI_MODE_SELECT_HDMI (024) +#define PIPE_DDI_MODE_SELECT_DVI (124) +#define PIPE_DDI_MODE_SELECT_DP_SST (224) +#define PIPE_DDI_MODE_SELECT_DP_MST (324) +#define PIPE_DDI_MODE_SELECT_FDI (424) +#define PIPE_DDI_BPC_8(020) +#define PIPE_DDI_BPC_10 (120) +#define PIPE_DDI_BPC_6(220) +#define PIPE_DDI_BPC_12 (320) +#define PIPE_DDI_BFI_ENABLE (14) +#define PIPE_DDI_PORT_WIDTH_X1(01) +#define PIPE_DDI_PORT_WIDTH_X2(11) +#define PIPE_DDI_PORT_WIDTH_X4(31) + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/41] drm/i915: add DP_TP_CTL registers
This is one set of those registers for each pipe. v2: use port enum to access individual registers Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 16 1 file changed, 16 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 26c6929..627e52d 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3891,4 +3891,20 @@ #define PIPE_DDI_PORT_WIDTH_X2(11) #define PIPE_DDI_PORT_WIDTH_X4(31) +/* DisplayPort Transport Control */ +#define DP_TP_CTL_A0x64040 +#define DP_TP_CTL_B0x64140 +#define DP_TP_CTL(port) _PORT(port, \ + DP_TP_CTL_A, \ + DP_TP_CTL_B) +#define DP_TP_CTL_ENABLE (131) +#define DP_TP_CTL_MODE_SST(027) +#define DP_TP_CTL_MODE_MST(127) +#define DP_TP_CTL_ENHANCED_FRAME_ENABLE (118) +#define DP_TP_CTL_FDI_AUTOTRAIN (115) +#define DP_TP_CTL_LINK_TRAIN_MASK (78) +#define DP_TP_CTL_LINK_TRAIN_PAT1 (08) +#define DP_TP_CTL_LINK_TRAIN_PAT2 (18) +#define DP_TP_CTL_LINK_TRAIN_NORMAL (38) + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/41] drm/i915: add DP_TP_STATUS registers
There is one set of those registers for each port. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 627e52d..666e319 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3907,4 +3907,12 @@ #define DP_TP_CTL_LINK_TRAIN_PAT2 (18) #define DP_TP_CTL_LINK_TRAIN_NORMAL (38) +/* DisplayPort Transport Status */ +#define DP_TP_STATUS_A 0x64044 +#define DP_TP_STATUS_B 0x64144 +#define DP_TP_STATUS(port) _PORT(port, \ + DP_TP_STATUS_A, \ + DP_TP_STATUS_B) +#define DP_TP_STATUS_AUTOTRAIN_DONE (112) + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/18] drm/i915: add context information to objects
On Thu, 29 Mar 2012 10:47:56 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Wed, Mar 28, 2012 at 05:20:11PM -0700, Ben Widawsky wrote: On Thu, 29 Mar 2012 00:36:21 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sun, Mar 18, 2012 at 01:39:44PM -0700, Ben Widawsky wrote: Handy mostly for assertions. Signed-off-by: Ben Widawsky b...@bwidawsk.net I don't see the point of carrying around a obj-context_id - context_id's are file_priv, so they're not that useful in the tracepoint. I suggest you just drop the contex_id arg there - the obj pointers are global and imo good enough for identification. And the few BUG_ON's don't seem really useful either. -Daniel obj-context_id was requested by Chris to clarify the trace events. I vaguely recall telling him that you won't like it. That's easily shot down on the grounds that: - we currently don't dump the id/handles of gem objects into our traces - your tracepoints dump the context_id at create/destroy time, so with a bit of python this can be re-added in userspace. Yes, but gem handles are not specific to i915, whereas context id numbers are. Also the tracepoint that is a problem is switch, not create/destroy I personally dislike using object pointer though I do agree it serves the same purpose. The other nice thing about having the context id is it makes it easy in debug situations to find out if a certain object is a context object. But no use case for that yet. My gripes with obj-context_id is that it smells like a layering violation. We don't have such special stuff for other special things like rings. The only exception is framebuffer when pageflipping, but I expect that we'll need to clean this up sooner or later (because we need to be able to move framebuffers sooner or later anyway, so they need better integration with the gem eviction code). -Daniel I still think the pros (easy debug) outweigh the cons (not really on exactly what you don't like). I don't see any harm that can come from this. /me braces for harm Anyway, as you said in the other email, I'm expecting more serious feedback. If I end up redoing a bunch of stuff, this can go too if you really don't like it. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 26/41] drm/i915: reuse Ivybridge interrupts code for Haswell
v2: prevent possible conflicts with VLV.
v1 Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_irq.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 998116e..16e9972 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1795,7 +1795,7 @@ static void ironlake_irq_preinstall(struct drm_device
*dev)
INIT_WORK(dev_priv-hotplug_work, i915_hotplug_work_func);
INIT_WORK(dev_priv-error_work, i915_error_work_func);
- if (IS_GEN6(dev) || IS_IVYBRIDGE(dev))
+ if (IS_GEN6(dev) || IS_IVYBRIDGE(dev) || IS_HASWELL(dev))
INIT_WORK(dev_priv-rps_work, gen6_pm_rps_work);
I915_WRITE(HWSTAM, 0xeffe);
@@ -2121,7 +2121,7 @@ void intel_irq_init(struct drm_device *dev)
{
dev-driver-get_vblank_counter = i915_get_vblank_counter;
dev-max_vblank_count = 0xff; /* only 24 bits of frame count */
- if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
+ if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev) ||
IS_HASWELL(dev)) {
dev-max_vblank_count = 0x; /* full 32 bit counter */
dev-driver-get_vblank_counter = gm45_get_vblank_counter;
}
@@ -2132,7 +2132,7 @@ void intel_irq_init(struct drm_device *dev)
dev-driver-get_vblank_timestamp = NULL;
dev-driver-get_scanout_position = i915_get_crtc_scanoutpos;
- if (IS_IVYBRIDGE(dev)) {
+ if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
/* Share pre uninstall handlers with ILK/SNB */
dev-driver-irq_handler = ivybridge_irq_handler;
dev-driver-irq_preinstall = ironlake_irq_preinstall;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 24/41] drm/i915: share forcewaking code between IVB and HSW
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5e226ad..1484195 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8924,7 +8924,7 @@ static void intel_init_display(struct drm_device *dev)
dev_priv-display.force_wake_put = __gen6_gt_force_wake_put;
/* IVB configs may use multi-threaded forcewake */
- if (IS_IVYBRIDGE(dev)) {
+ if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) {
u32 ecobus;
/* A small trick here - if the bios hasn't configured
MT forcewake,
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/41] drm/i915: add support for SBI ops
With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.
v2: de-inline the function and address changes in bits names
v1 Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 44 ++
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a0e3166..8e5f5be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1220,6 +1220,50 @@ static void intel_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
POSTING_READ(reg);
}
+/* SBI access */
+static void
+intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value)
+{
+ if (wait_for((I915_READ(SBI_CTL_STAT) SBI_READY) == 0,
+ 10))
+ DRM_ERROR(timeout waiting for SBI to become ready\n);
+
+ I915_WRITE(SBI_ADDR,
+ (reg 16));
+ I915_WRITE(SBI_DATA,
+ value);
+ I915_WRITE(SBI_CTL_STAT,
+ SBI_BUSY |
+ SBI_CTL_OP_CRWR);
+
+ if (wait_for((I915_READ(SBI_CTL_STAT) (SBI_READY |
SBI_RESPONSE_SUCCESS)) == 0,
+ 10))
+ DRM_ERROR(timeout waiting for SBI to complete write
transaction\n);
+}
+
+static u32
+intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg)
+{
+ u32 value;
+ if (wait_for((I915_READ(SBI_CTL_STAT) SBI_READY) == 0,
+ 10))
+ DRM_ERROR(timeout waiting for SBI to become ready\n);
+
+ I915_WRITE(SBI_ADDR,
+ (reg 16));
+ I915_WRITE(SBI_CTL_STAT,
+ SBI_BUSY |
+ SBI_CTL_OP_CRRD);
+
+ if (wait_for((I915_READ(SBI_CTL_STAT) (SBI_READY |
SBI_RESPONSE_SUCCESS)) == 0,
+ 10))
+ DRM_ERROR(timeout waiting for SBI to complete read
transaction\n);
+
+ value = I915_READ(SBI_DATA);
+
+ return value;
+}
+
/**
* intel_enable_pch_pll - enable PCH PLL
* @dev_priv: i915 private structure
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 29/41] drm/i915: show unknown sdvox registers on hdmi init
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index cae3e5f..de54c01 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -542,6 +542,8 @@ void intel_hdmi_init(struct drm_device *dev, int sdvox_reg)
intel_encoder-clone_mask = (1 INTEL_HDMIF_CLONE_BIT);
intel_hdmi-ddc_bus = GMBUS_PORT_DPD;
dev_priv-hotplug_supported_mask |= HDMID_HOTPLUG_INT_STATUS;
+ } else {
+ DRM_DEBUG_DRIVER(Unknown sdvox register %x\n, sdvox_reg);
}
intel_hdmi-sdvox_reg = sdvox_reg;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 40/41] drm/i915: prepare HDMI link for Haswell
On Haswell, we need to properly train the DDI buffers prior to enabling
HDMI.
Note that we do enable the DDI Function for the corresponding pipe, in a
similar fashion as we do with FDI. This ensures that the pipe DDI
transport is left in a almost-ready state, and we only need to enable the
pipe afterwards to get a working modesetting.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 63 -
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 6921756..480f54b 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -324,6 +324,67 @@ static bool intel_hdmi_mode_fixup(struct drm_encoder
*encoder,
return true;
}
+static void intel_hdmi_prepare(struct drm_encoder *encoder)
+{
+ struct drm_device *dev = encoder-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_crtc *crtc = encoder-crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+ int port = intel_hdmi-ddi_port;
+ int pipe = intel_crtc-pipe;
+ u32 reg, temp;
+
+ /* On Haswell, we need to enable the clocks and prepare DDI function to
+* work in HDMI mode for this pipe.
+*/
+ if (IS_HASWELL(encoder-dev)) {
+ DRM_DEBUG_KMS(Preparing HDMI DDI mode for Haswell on port %c,
pipe %c\n, port_name(port), pipe_name(pipe));
+
+ /* Enable LCPLL if disabled */
+ reg = I915_READ(LCPLL_CTL);
+ if (reg LCPLL_PLL_DISABLE)
+ I915_WRITE(LCPLL_CTL,
+ reg ~LCPLL_PLL_DISABLE);
+
+ /* Configure CPU PLL, wait for warmup */
+ I915_WRITE(WRPLL_CTL1,
+ WRPLL_PLL_ENABLE |
+ WRPLL_PLL_SELECT_LCPLL_2700);
+
+ udelay(20);
+
+ /* Use WRPLL1 clock to drive the output to the port, and tell
the pipe to use
+* this port for connection.
+*/
+ I915_WRITE(PORT_CLK_SEL(port),
+ PORT_CLK_SEL_WRPLL1);
+ I915_WRITE(PIPE_CLK_SEL(pipe),
+ PIPE_CLK_SEL_PORT(port));
+
+ udelay(20);
+
+ /* Enable PIPE_DDI_FUNC_CTL for the pipe to work in HDMI mode */
+ temp = I915_READ(DDI_FUNC_CTL(pipe));
+ temp = ~PIPE_DDI_PORT_MASK;
+ temp |= PIPE_DDI_SELECT_PORT(port) |
+ PIPE_DDI_MODE_SELECT_HDMI |
+ PIPE_DDI_FUNC_ENABLE;
+ I915_WRITE(DDI_FUNC_CTL(pipe),
+ temp);
+
+ /* Enable DDI_BUF_CTL. In HDMI/DVI mode, the port width,
+* and swing/emphasis values are ignored so nothing special
needs
+* to be done besides enabling the port.
+*/
+ I915_WRITE(DDI_BUF_CTL(port),
+ I915_READ(DDI_BUF_CTL(port)) |
+ DDI_BUF_CTL_ENABLE);
+ }
+
+ return intel_encoder_prepare(encoder);
+}
+
static enum drm_connector_status
intel_hdmi_detect(struct drm_connector *connector, bool force)
{
@@ -457,7 +518,7 @@ static void intel_hdmi_destroy(struct drm_connector
*connector)
static const struct drm_encoder_helper_funcs intel_hdmi_helper_funcs = {
.dpms = intel_hdmi_dpms,
.mode_fixup = intel_hdmi_mode_fixup,
- .prepare = intel_encoder_prepare,
+ .prepare = intel_hdmi_prepare,
.mode_set = intel_hdmi_mode_set,
.commit = intel_encoder_commit,
};
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 35/41] drm/i915: disable pipe DDI function when disabling pipe
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 09c18f8..0324250 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1475,6 +1475,16 @@ static void intel_disable_pipe(struct drm_i915_private
*dev_priv,
I915_WRITE(reg, val ~PIPECONF_ENABLE);
intel_wait_for_pipe_off(dev_priv-dev, pipe);
+
+ /* On HSW, disable pipe DDI function the pipe */
+ if (IS_HASWELL(dev_priv-dev)) {
+ val = I915_READ(DDI_FUNC_CTL(pipe));
+ val = ~PIPE_DDI_PORT_MASK;
+ val = ~PIPE_DDI_FUNC_ENABLE;
+ I915_WRITE(DDI_FUNC_CTL(pipe),
+ val);
+ }
+
}
/*
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 39/41] drm/i915: add support for DDI-controlled digital outputs
Those are driven by DDIs on Haswell architecture, so we need to keep track
of which DDI is being used on each output.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index de54c01..6921756 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -41,6 +41,7 @@ struct intel_hdmi {
struct intel_encoder base;
u32 sdvox_reg;
int ddc_bus;
+ int ddi_port;
uint32_t color_range;
bool has_hdmi_sink;
bool has_audio;
@@ -542,6 +543,24 @@ void intel_hdmi_init(struct drm_device *dev, int sdvox_reg)
intel_encoder-clone_mask = (1 INTEL_HDMIF_CLONE_BIT);
intel_hdmi-ddc_bus = GMBUS_PORT_DPD;
dev_priv-hotplug_supported_mask |= HDMID_HOTPLUG_INT_STATUS;
+ } else if (sdvox_reg == DDI_BUF_CTL(PORT_B)) {
+ DRM_DEBUG_DRIVER(LPT: detected output on DDI B\n);
+ intel_encoder-clone_mask = (1 INTEL_HDMIB_CLONE_BIT);
+ intel_hdmi-ddc_bus = GMBUS_PORT_DPB;
+ intel_hdmi-ddi_port = PORT_B;
+ dev_priv-hotplug_supported_mask |= HDMIB_HOTPLUG_INT_STATUS;
+ } else if (sdvox_reg == DDI_BUF_CTL(PORT_C)) {
+ DRM_DEBUG_DRIVER(LPT: detected output on DDI C\n);
+ intel_encoder-clone_mask = (1 INTEL_HDMIC_CLONE_BIT);
+ intel_hdmi-ddc_bus = GMBUS_PORT_DPC;
+ intel_hdmi-ddi_port = PORT_C;
+ dev_priv-hotplug_supported_mask |= HDMIC_HOTPLUG_INT_STATUS;
+ } else if (sdvox_reg == DDI_BUF_CTL(PORT_D)) {
+ DRM_DEBUG_DRIVER(LPT: detected output on DDI A\n);
+ intel_encoder-clone_mask = (1 INTEL_HDMID_CLONE_BIT);
+ intel_hdmi-ddc_bus = GMBUS_PORT_DPD;
+ intel_hdmi-ddi_port = PORT_D;
+ dev_priv-hotplug_supported_mask |= HDMID_HOTPLUG_INT_STATUS;
} else {
DRM_DEBUG_DRIVER(Unknown sdvox register %x\n, sdvox_reg);
}
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 23/41] drm/i915: calculate same watermarks on Haswell as on Ivy Bridge
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/intel_display.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8e5f5be..5e226ad 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4679,7 +4679,7 @@ void sandybridge_update_wm(struct drm_device *dev) } /* IVB has 3 pipes */ - if (IS_IVYBRIDGE(dev) + if ((IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) g4x_compute_wm0(dev, 2, sandybridge_display_wm_info, latency, sandybridge_cursor_wm_info, latency, -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 31/41] drm/i915: disable rc6 on haswell for now
This needs proper enablement to avoid machine hangs, so let's just avoid it for now. Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/intel_display.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0e06a29..b2dc1eb 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8293,6 +8293,10 @@ static bool intel_enable_rc6(struct drm_device *dev) if (INTEL_INFO(dev)-gen == 5) return 0; + /* Sorry Haswell, no RC6 for you for now. */ + if (IS_HASWELL(dev)) + return 0; + /* * Disable rc6 on Sandybridge */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 36/41] drm/i915: do not use fdi_normal_train on haswell
This should be already configured when FDI auto-negotiation is done. Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/intel_display.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0324250..dc207e7 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -3259,7 +3259,8 @@ static void ironlake_pch_enable(struct drm_crtc *crtc) I915_WRITE(TRANS_VSYNC(pipe), I915_READ(VSYNC(pipe))); I915_WRITE(TRANS_VSYNCSHIFT(pipe), I915_READ(VSYNCSHIFT(pipe))); - intel_fdi_normal_train(crtc); + if (!IS_HASWELL(dev)) + intel_fdi_normal_train(crtc); /* For PCH DP, enable TRANS_DP_CTL */ if (HAS_PCH_CPT(dev) -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 30/41] drm/i915: enable power wells on haswell init
This attempts to enable all the available power wells during the
initialization.
Those power wells can be enabled in parallel or on-demand, and disabled
when no longer needed, but this is out of scope of this initial
enablement. Proper tracking of who uses which power well will require
a considerable rework of our display handling, so we just leave them all
enabled when the driver is loaded for now.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7daad41..0e06a29 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9173,6 +9173,34 @@ static void i915_disable_vga(struct drm_device *dev)
POSTING_READ(vga_reg);
}
+/* Starting with Haswell, we have different power wells for
+ * different parts of the GPU. This attempts to enable them all.
+ */
+static void intel_init_power_wells(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ unsigned long power_wells[] = {
+ HSW_PWR_WELL_CTL1,
+ HSW_PWR_WELL_CTL2,
+ HSW_PWR_WELL_CTL4
+ };
+ int i;
+
+ mutex_lock(dev-struct_mutex);
+
+ for (i = 0; i ARRAY_SIZE(power_wells); i++) {
+ int well = I915_READ(power_wells[i]);
+
+ if ((well HSW_PWR_WELL_STATE) == 0) {
+ I915_WRITE(power_wells[i], well HSW_PWR_WELL_ENABLE);
+ if (wait_for(I915_READ(power_wells[i]
HSW_PWR_WELL_STATE), 20))
+ DRM_ERROR(Error enabling power well %lx\n,
power_wells[i]);
+ }
+ }
+
+ mutex_unlock(dev-struct_mutex);
+}
+
void intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -9190,6 +9218,9 @@ void intel_modeset_init(struct drm_device *dev)
intel_init_quirks(dev);
+ if (IS_HASWELL(dev))
+ intel_init_power_wells(dev);
+
intel_init_display(dev);
if (IS_GEN2(dev)) {
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/41] drm/i915: add definition of LPT FDI port width registers
Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 880c4f7..58fcfae 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3475,6 +3475,9 @@ #define FDI_LINK_TRAIN_PATTERN_IDLE_CPT (28) #define FDI_LINK_TRAIN_NORMAL_CPT (38) #define FDI_LINK_TRAIN_PATTERN_MASK_CPT (38) +/* LPT */ +#define LPT_FDI_PORT_WIDTH_1X (019) +#define LPT_FDI_PORT_WIDTH_2X (119) #define _FDI_RXA_MISC0xf0010 #define _FDI_RXB_MISC0xf1010 -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 32/41] drm/i915: program WM_LINETIME on Haswell
The line time can be programmed according to the number of horizontal
pixels vs effective pixel rate ratio.
v2: improve comment as per Chris Wilson suggestion
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b2dc1eb..72f2211 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6103,6 +6103,19 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
(adjusted_mode-crtc_vsync_start - 1) |
((adjusted_mode-crtc_vsync_end - 1) 16));
+ if (IS_HASWELL(dev)) {
+ temp = I915_READ(PIPE_WM_LINETIME(pipe));
+ temp = ~PIPE_WM_LINETIME_MASK;
+
+ /* The WM are computed with base on how long it takes to fill a
single
+* row at the given clock rate
+* */
+ temp |= PIPE_WM_LINETIME_TIME(
+ adjusted_mode-crtc_hdisplay /
+ (adjusted_mode-clock / 1000));
+ I915_WRITE(PIPE_WM_LINETIME(pipe), temp);
+ }
+
/* pipesrc controls the size that is scaled from, which should
* always be the user's requested size.
*/
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 38/41] drm/i915: detect digital outputs on Haswell
Digital port detection on Haswell is indicated by the presence of a bit in
DDI_BUF_CTL for port A, and by a different register for ports B, C and D.
So we check for those bits during the initialization time and let the hdmi
function know about those.
Note that this bit does not indicates whether the output is DP or HDMI.
However, the DDI buffers can be programmed in a way that is shared between
DP/HDMI and FDI/HDMI except for PORT E.
So for now, we detect those digital outputs as being HDMI, but proper DP
support is still pending.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 50 +++---
1 file changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5aaf592..c457592 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8372,26 +8372,44 @@ static void intel_setup_outputs(struct drm_device *dev)
if (HAS_PCH_SPLIT(dev)) {
int found;
- if (I915_READ(HDMIB) PORT_DETECTED) {
- /* PCH SDVOB multiplex with HDMIB */
- found = intel_sdvo_init(dev, PCH_SDVOB);
- if (!found)
- intel_hdmi_init(dev, HDMIB);
- if (!found (I915_READ(PCH_DP_B) DP_DETECTED))
- intel_dp_init(dev, PCH_DP_B);
- }
+ if (IS_HASWELL(dev)) {
+ /* Haswell uses DDI functions to detect digital outputs
*/
+ found = I915_READ(DDI_BUF_CTL_A)
DDI_INIT_DISPLAY_DETECTED;
+ if (found)
+ intel_hdmi_init(dev, DDI_BUF_CTL_A);
+
+ /* DDI B, C and D detection is indicated by the
SFUSE_STRAP
+* register */
+ found = I915_READ(SFUSE_STRAP);
+
+ if (found SFUSE_STRAP_DDIB_DETECTED)
+ intel_hdmi_init(dev, DDI_BUF_CTL(PORT_B));
+ if (found SFUSE_STRAP_DDIC_DETECTED)
+ intel_hdmi_init(dev, DDI_BUF_CTL(PORT_C));
+ if (found SFUSE_STRAP_DDID_DETECTED)
+ intel_hdmi_init(dev, DDI_BUF_CTL(PORT_D));
+ } else {
+ if (I915_READ(HDMIB) PORT_DETECTED) {
+ /* PCH SDVOB multiplex with HDMIB */
+ found = intel_sdvo_init(dev, PCH_SDVOB);
+ if (!found)
+ intel_hdmi_init(dev, HDMIB);
+ if (!found (I915_READ(PCH_DP_B)
DP_DETECTED))
+ intel_dp_init(dev, PCH_DP_B);
+ }
- if (I915_READ(HDMIC) PORT_DETECTED)
- intel_hdmi_init(dev, HDMIC);
+ if (I915_READ(HDMIC) PORT_DETECTED)
+ intel_hdmi_init(dev, HDMIC);
- if (I915_READ(HDMID) PORT_DETECTED)
- intel_hdmi_init(dev, HDMID);
+ if (I915_READ(HDMID) PORT_DETECTED)
+ intel_hdmi_init(dev, HDMID);
- if (I915_READ(PCH_DP_C) DP_DETECTED)
- intel_dp_init(dev, PCH_DP_C);
+ if (I915_READ(PCH_DP_C) DP_DETECTED)
+ intel_dp_init(dev, PCH_DP_C);
- if (!dpd_is_edp (I915_READ(PCH_DP_D) DP_DETECTED))
- intel_dp_init(dev, PCH_DP_D);
+ if (!dpd_is_edp (I915_READ(PCH_DP_D) DP_DETECTED))
+ intel_dp_init(dev, PCH_DP_D);
+ }
} else if (SUPPORTS_DIGITAL_OUTPUTS(dev)) {
bool found = false;
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/41] drm/i915: add definition of DDI buffer translations regs
Those registers are used to train DDI buffer translations for each link type. v2: access each port registers through the DDI_BUF_TRANS macro Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index ef99df3..880c4f7 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3938,4 +3938,11 @@ #define DDI_PORT_WIDTH_X4 (31) #define DDI_INIT_DISPLAY_DETECTED (10) +/* DDI Buffer Translations */ +#define DDI_BUF_TRANS_A0x64E00 +#define DDI_BUF_TRANS_B0x64E60 +#define DDI_BUF_TRANS(port) _PORT(port, \ + DDI_BUF_TRANS_A, \ + DDI_BUF_TRANS_B) + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 25/41] drm/i915: haswell has 3 pipes as well
They work differently, but the count is the same. Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_dma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index fdff009..1fb7beb 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -2089,7 +2089,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) spin_lock_init(dev_priv-error_lock); spin_lock_init(dev_priv-rps_lock); - if (IS_IVYBRIDGE(dev)) + if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) dev_priv-num_pipe = 3; else if (IS_MOBILE(dev) || !IS_GEN2(dev)) dev_priv-num_pipe = 2; -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 21/41] drm/i915: add WM_LINETIME registers
Watermark line time registers for display low power watermark. v2: improve bit names as suggested by Chris Wilson Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 7b6754d..d9df228 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4027,4 +4027,14 @@ #define LCPLL_CD_CLOCK_DISABLE(125) #define LCPLL_CD2X_CLOCK_DISABLE (123) +/* Pipe WM_LINETIME - watermark line time */ +#define PIPE_WM_LINETIME_A 0x45270 +#define PIPE_WM_LINETIME_B 0x45274 +#define PIPE_WM_LINETIME(pipe) _PIPE(pipe, \ + PIPE_WM_LINETIME_A, \ + PIPE_WM_LINETIME_A) +#define PIPE_WM_LINETIME_MASK(0x1ff) +#define PIPE_WM_LINETIME_TIME(x) ((x)) +#define PIPE_WM_LINETIME_IPS_LINETIME_MASK (0x1ff16) +#define PIPE_WM_LINETIME_IPS_LINETIME(x) ((x)16) #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/41] drm/i915: add WRPLL clocks
The WR PLL can drive the DDI ports at fixed frequencies for HDMI, DVI, DP and FDI. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index fc24229..7b6754d 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3989,6 +3989,14 @@ #define SPLL_PLL_FREQ_810MHz (026) #define SPLL_PLL_FREQ_1350MHz (126) +/* WRPLL */ +#define WRPLL_CTL1 0x46040 +#define WRPLL_CTL2 0x46060 +#define WRPLL_PLL_ENABLE (131) +#define WRPLL_PLL_SELECT_SSC (0x0128) +#define WRPLL_PLL_SELECT_NON_SCC (0x0228) +#define WRPLL_PLL_SELECT_LCPLL_2700 (0x0328) + /* Port clock selection */ #define PORT_CLK_SEL_A 0x46100 #define PORT_CLK_SEL_B 0x46104 -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 41/41] drm/i915: add debugging bits for haswell modesetting
-- THIS PATCH IS NOT INTENDED FOR MERGING. IT IS MERELY HERE TO SIMPLIFY
THE DEBUGGING --
This patch is here for make debugging and log tracing easier, it should
go away in the future, when we'll stop hitting those code paths.
v2: cope with changes in bit names
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/i915_drv.c |2 ++
drivers/gpu/drm/i915/intel_display.c | 61 +++---
2 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e4b5571..8ef2512 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1036,6 +1036,7 @@ u##x i915_read##x(struct drm_i915_private *dev_priv, u32
reg) { \
val = read##y(dev_priv-regs + reg); \
} \
trace_i915_reg_rw(false, reg, val, sizeof(val)); \
+ DRM_DEBUG(I915_READ: 0x%x = 0x%x\n, reg, val); \
return val; \
}
@@ -1048,6 +1049,7 @@ __i915_read(64, q)
#define __i915_write(x, y) \
void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x val) { \
u32 __fifo_ret = 0; \
+ DRM_DEBUG(I915_WRITE: 0x%x = 0x%x\n, reg, val); \
trace_i915_reg_rw(true, reg, val, sizeof(val)); \
if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \
__fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c457592..82afc8a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -869,9 +869,16 @@ static void assert_fdi_tx(struct drm_i915_private
*dev_priv,
u32 val;
bool cur_state;
- reg = FDI_TX_CTL(pipe);
- val = I915_READ(reg);
- cur_state = !!(val FDI_TX_ENABLE);
+ if (IS_HASWELL(dev_priv-dev)) {
+ DRM_ERROR(Attempting to check FDI_TX_CTL on Haswell, using DDI
instead\n);
+ reg = DDI_FUNC_CTL(pipe);
+ val = I915_READ(reg);
+ cur_state = !!(val PIPE_DDI_FUNC_ENABLE);
+ } else {
+ reg = FDI_TX_CTL(pipe);
+ val = I915_READ(reg);
+ cur_state = !!(val FDI_TX_ENABLE);
+ }
WARN(cur_state != state,
FDI TX state assertion failure (expected %s, current %s)\n,
state_string(state), state_string(cur_state));
@@ -886,9 +893,14 @@ static void assert_fdi_rx(struct drm_i915_private
*dev_priv,
u32 val;
bool cur_state;
- reg = FDI_RX_CTL(pipe);
- val = I915_READ(reg);
- cur_state = !!(val FDI_RX_ENABLE);
+ if (IS_HASWELL(dev_priv-dev) pipe 0) {
+ DRM_ERROR(Attempting to enable FDI_RX on Haswell pipe
0\n);
+ return;
+ } else {
+ reg = FDI_RX_CTL(pipe);
+ val = I915_READ(reg);
+ cur_state = !!(val FDI_RX_ENABLE);
+ }
WARN(cur_state != state,
FDI RX state assertion failure (expected %s, current %s)\n,
state_string(state), state_string(cur_state));
@@ -906,6 +918,11 @@ static void assert_fdi_tx_pll_enabled(struct
drm_i915_private *dev_priv,
if (dev_priv-info-gen == 5)
return;
+ if (IS_HASWELL(dev_priv-dev)) {
+ DRM_ERROR(Attempting to check FDI_TX_PLL on Haswell,
aborting\n);
+ return;
+ }
+
reg = FDI_TX_CTL(pipe);
val = I915_READ(reg);
WARN(!(val FDI_TX_PLL_ENABLE), FDI TX PLL assertion failure, should
be active but is disabled\n);
@@ -917,6 +934,10 @@ static void assert_fdi_rx_pll_enabled(struct
drm_i915_private *dev_priv,
int reg;
u32 val;
+ if (IS_HASWELL(dev_priv-dev) pipe 0) {
+ DRM_ERROR(Attempting to enable FDI on Haswell with pipe
0\n);
+ return;
+ }
reg = FDI_RX_CTL(pipe);
val = I915_READ(reg);
WARN(!(val FDI_RX_PLL_ENABLE), FDI RX PLL assertion failure, should
be active but is disabled\n);
@@ -1022,6 +1043,11 @@ static void assert_pch_refclk_enabled(struct
drm_i915_private *dev_priv)
u32 val;
bool enabled;
+ if (HAS_PCH_LPT(dev_priv-dev)) {
+ DRM_ERROR(LPT does not has PCH refclk, skipping check\n);
+ return;
+ }
+
val = I915_READ(PCH_DREF_CONTROL);
enabled = !!(val (DREF_SSC_SOURCE_MASK | DREF_NONSPREAD_SOURCE_MASK |
DREF_SUPERSPREAD_SOURCE_MASK));
@@ -1236,6 +1262,7 @@ intel_sbi_write(struct drm_i915_private *dev_priv, u16
reg, u32 value)
SBI_BUSY |
SBI_CTL_OP_CRWR);
+ DRM_DEBUG(SBI_WRITE: 0x%x = 0x%x\n, reg, value);
if (wait_for((I915_READ(SBI_CTL_STAT) (SBI_READY |
SBI_RESPONSE_SUCCESS)) == 0,
10))
DRM_ERROR(timeout waiting for SBI to complete
[Intel-gfx] [PATCH 10/41] drm/i915: add definitions for DDI_BUF_CTL registers
There is one instance of those registers for each DDI port. v2: access registers via the DDI_BUF_CTL() macro Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 666e319..ef99df3 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3915,4 +3915,27 @@ DP_TP_STATUS_B) #define DP_TP_STATUS_AUTOTRAIN_DONE (112) +/* DDI Buffer Control */ +#define DDI_BUF_CTL_A 0x64000 +#define DDI_BUF_CTL_B 0x64100 +#define DDI_BUF_CTL(port) _PORT(port, \ + DDI_BUF_CTL_A, \ + DDI_BUF_CTL_B) +#define DDI_BUF_CTL_ENABLE(131) +#define DDI_BUF_EMP_400MV_0DB_HSW (024) /* Sel0 */ +#define DDI_BUF_EMP_400MV_3_5DB_HSW (124) /* Sel1 */ +#define DDI_BUF_EMP_400MV_6DB_HSW (224) /* Sel2 */ +#define DDI_BUF_EMP_400MV_9_5DB_HSW (324) /* Sel3 */ +#define DDI_BUF_EMP_600MV_0DB_HSW (424) /* Sel4 */ +#define DDI_BUF_EMP_600MV_3_5DB_HSW (524) /* Sel5 */ +#define DDI_BUF_EMP_600MV_6DB_HSW (624) /* Sel6 */ +#define DDI_BUF_EMP_800MV_0DB_HSW (724) /* Sel7 */ +#define DDI_BUF_EMP_800MV_3_5DB_HSW (824) /* Sel8 */ +#define DDI_BUF_EMP_MASK (0xf24) +#define DDI_BUF_IS_IDLE (17) +#define DDI_PORT_WIDTH_X1 (01) +#define DDI_PORT_WIDTH_X2 (11) +#define DDI_PORT_WIDTH_X4 (31) +#define DDI_INIT_DISPLAY_DETECTED (10) + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/41] drm/i915: add S PLL control
This PLL control can drive DDI ports at desired frequencies for DisplayPort and FDI connections. Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |8 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 48346ad..db03446 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3966,4 +3966,12 @@ #define PIXCLK_GATE_UNGATE10 #define PIXCLK_GATE_GATE 00 +/* SPLL */ +#define SPLL_CTL 0x46020 +#define SPLL_PLL_ENABLE (131) +#define SPLL_PLL_SCC (128) +#define SPLL_PLL_NON_SCC (228) +#define SPLL_PLL_FREQ_810MHz (026) +#define SPLL_PLL_FREQ_1350MHz (126) + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 37/41] drm/i915: program iCLKIP on Lynx Point
The iCLKIP clock is used to drive the VGA pixel clock on the PCH. In order
to do so, it must be programmed to properly do the clock ticks according
to the divisor, phase direction, phase increments and a special auxiliary
divisor for 20MHz clock.
Those values can be programmed individually, by doing some math; or we
could use a pre-defined table of values for each modeset. For speed and
simplification, the idea was to just adopt the table of valid pixel clocks
and select the matching iCLKIP values from there.
As a possible idea for the future, it would be possible to add a fallback
and calculate those values manually in case no match is found. But I don't
think we'll encounter a mode not covered by those table, and VGA is pretty
much going away in the future anyway.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 309 ++
1 file changed, 309 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dc207e7..5aaf592 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2830,6 +2830,312 @@ static const long hsw_ddi_buf_ctl_values[] = {
DDI_BUF_EMP_800MV_3_5DB_HSW
};
+/* Available pixel clock values */
+struct iclk_vga_clock {
+ u32 clock;
+ u16 auxdiv;
+ u16 divsel;
+ u16 phasedir;
+ u16 phaseinc;
+};
+
+static const struct iclk_vga_clock iclk_vga_clock_table[] = {
+ {2, 1, 0x41, 0, 0x20}, /* 2 ppm=0 */
+ {21000, 0, 0x7E, 0, 0x25}, /* 20999 ppm=-53 */
+ {21912, 0, 0x79, 0, 0x0E}, /* 21912 ppm=12 */
+ {22000, 0, 0x78, 0, 0x2F}, /* 21999 ppm=-58 */
+ {23000, 0, 0x73, 0, 0x19}, /* 23000 ppm=6 */
+ {24000, 0, 0x6E, 0, 0x20}, /* 24000 ppm=0 */
+ {25000, 0, 0x6A, 0, 0x00}, /* 25000 ppm=0 */
+ {25175, 0, 0x69, 0, 0x10}, /* 25175 ppm=-7 */
+ {25200, 0, 0x69, 0, 0x09}, /* 25201 ppm=21 */
+ {26000, 0, 0x66, 1, 0x0A}, /* 26001 ppm=24 */
+ {27000, 0, 0x62, 0, 0x00}, /* 27000 ppm=0 */
+ {27027, 0, 0x62, 1, 0x06}, /* 27025 ppm=-62 */
+ {27500, 0, 0x60, 0, 0x0C}, /* 27498 ppm=-58 */
+ {28000, 0, 0x5E, 0, 0x1B}, /* 28002 ppm=70 */
+ {28320, 0, 0x5D, 0, 0x16}, /* 28319 ppm=-50 */
+ {28322, 0, 0x5D, 0, 0x15}, /* 28323 ppm=44 */
+ {29000, 0, 0x5B, 0, 0x07}, /* 28998 ppm=-64 */
+ {3, 0, 0x58, 0, 0x00}, /* 3 ppm=0 */
+ {31000, 0, 0x55, 0, 0x06}, /* 31001 ppm=35 */
+ {31500, 0, 0x54, 1, 0x12}, /* 31498 ppm=-53 */
+ {32000, 0, 0x52, 0, 0x18}, /* 32000 ppm=0 */
+ {32500, 0, 0x51, 0, 0x05}, /* 32500 ppm=-15 */
+ {33000, 0, 0x50, 1, 0x0C}, /* 33002 ppm=70 */
+ {34000, 0, 0x4D, 0, 0x1A}, /* 34002 ppm=70 */
+ {35000, 0, 0x4B, 0, 0x09}, /* 35001 ppm=29 */
+ {35500, 0, 0x4A, 0, 0x04}, /* 35497 ppm=-82 */
+ {36000, 0, 0x49, 0, 0x00}, /* 36000 ppm=0 */
+ {37000, 0, 0x47, 1, 0x02}, /* 37002 ppm=58 */
+ {38000, 0, 0x45, 0, 0x03}, /* 38003 ppm=82 */
+ {39000, 0, 0x43, 0, 0x0F}, /* 38998 ppm=-53 */
+ {4, 0, 0x41, 0, 0x20}, /* 4 ppm=0 */
+ {40500, 0, 0x41, 1, 0x15}, /* 40497 ppm=-79 */
+ {40541, 0, 0x41, 1, 0x1A}, /* 40544 ppm=95 */
+ {41000, 0, 0x40, 1, 0x09}, /* 40996 ppm=-87 */
+ {41540, 0, 0x3F, 0, 0x00}, /* 41538 ppm=-38 */
+ {42000, 0, 0x3E, 0, 0x12}, /* 42003 ppm=70 */
+ {43000, 0, 0x3D, 1, 0x0D}, /* 42996 ppm=-99 */
+ {43163, 0, 0x3D, 1, 0x1D}, /* 43168 ppm=108 */
+ {44000, 0, 0x3B, 0, 0x17}, /* 44003 ppm=70 */
+ {44900, 0, 0x3A, 0, 0x09}, /* 44895 ppm=-117 */
+ {45000, 0, 0x3A, 0, 0x00}, /* 45000 ppm=0 */
+ {46000, 0, 0x39, 1, 0x13}, /* 45994 ppm=-128 */
+ {47000, 0, 0x37, 0, 0x1D}, /* 46995 ppm=-110 */
+ {48000, 0, 0x36, 0, 0x10}, /* 48000 ppm=0 */
+ {49000, 0, 0x35, 0, 0x07}, /* 48993 ppm=-134 */
+ {49500, 0, 0x35, 1, 0x1D}, /* 49499 ppm=-27 */
+ {5, 0, 0x34, 0, 0x00}, /* 5 ppm=0 */
+ {51000, 0, 0x33, 1, 0x04}, /* 51004 ppm=70 */
+ {52000, 0, 0x32, 1, 0x05}, /* 52001 ppm=24 */
+ {52406, 0, 0x32, 1, 0x1F}, /* 52411 ppm=101 */
+ {53000, 0, 0x31, 1, 0x04}, /* 53006 ppm=116 */
+ {54000, 0, 0x30, 0, 0x00}, /* 54000
[Intel-gfx] [PATCH 15/41] drm/i915: add PIXCLK_GATE register
Pixel clock gating control for Lynx point. Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index d6c0e36..48346ad 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3960,4 +3960,10 @@ #define SBI_RESPONSE_SUCCESS (0x01) #define SBI_BUSY (0x10) #define SBI_READY (0x00) + +/* LPT PIXCLK_GATE */ +#define PIXCLK_GATE0xC6020 +#define PIXCLK_GATE_UNGATE10 +#define PIXCLK_GATE_GATE 00 + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/41] drm/i915: add SSC offsets for SBI access
Different registers are identified by their target id and offset. To simplify their programming, they are called as RegisterNameTargetId. For example, SSCCTL register accessed through SBI at target id 6 and offset 0c is called SBI_SSCCTL6. Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 81b076c..b7eca0c 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3961,6 +3961,21 @@ #define SBI_BUSY (0x10) #define SBI_READY (0x00) +/* SBI offsets */ +#define SBI_SSCDIVINTPHASE6 0x0600 +#define SBI_SSCDIVINTPHASE_DIVSEL_MASK ((0x7f)1) +#define SBI_SSCDIVINTPHASE_DIVSEL(x) ((x)1) +#define SBI_SSCDIVINTPHASE_INCVAL_MASK ((0x7f)8) +#define SBI_SSCDIVINTPHASE_INCVAL(x) ((x)8) +#define SBI_SSCDIVINTPHASE_DIR(x)((x)15) +#define SBI_SSCDIVINTPHASE_PROPAGATE (10) +#define SBI_SSCCTL0x020c +#define SBI_SSCCTL6 0x060C +#define SBI_SSCCTL_DISABLE (10) +#define SBI_SSCAUXDIV60x0610 +#define SBI_SSCAUXDIV_FINALDIV2SEL(x)((x)4) +#define SBI_DBUFF00x2a00 + /* LPT PIXCLK_GATE */ #define PIXCLK_GATE0xC6020 #define PIXCLK_GATE_UNGATE10 -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 27/41] drm/i915: share pipe count handling with Ivybridge
Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/intel_display.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 1484195..ea103ca 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -2330,7 +2330,7 @@ intel_pipe_set_base(struct drm_crtc *crtc, int x, int y, case 1: break; case 2: - if (IS_IVYBRIDGE(dev)) + if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) break; /* fall through otherwise */ default: -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 19/41] drm/i915: add LCPLL control registers
Those are used to control the display core clock. v2: change the enable bit setting, spotted by Rodrigo Vivi. Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index b7eca0c..fc24229 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4012,4 +4012,11 @@ #define PIPE_CLK_SEL_DISABLED (0x029) #define PIPE_CLK_SEL_PORT(x) ((x+1)29) +/* LCPLL Control */ +#define LCPLL_CTL 0x130040 +#define LCPLL_PLL_DISABLE (131) +#define LCPLL_PLL_LOCK(130) +#define LCPLL_CD_CLOCK_DISABLE(125) +#define LCPLL_CD2X_CLOCK_DISABLE (123) + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 33/41] drm/i915: initialize DDI buffer translations
Buffer translations for DDI links must be initialized prior to enablement.
For FDI and DP, first 9 pairs of values are used to select the connection
parameters. HDMI uses the last pair of values and ignores the first 9
pairs. So we program HDMI values in both cases, which allows HDMI to work
over both FDI and DP-friendly buffers.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 84 +-
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 84 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 72f2211..1fdcd56 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2728,6 +2728,86 @@ static void gen6_fdi_link_train(struct drm_crtc *crtc)
DRM_DEBUG_KMS(FDI train done.\n);
}
+/* HDMI/DVI modes ignore everything but the last 2 items. So we share
+ * them for both DP and FDI transports, allowing those ports to
+ * automatically adapt to HDMI connections as well
+ */
+static const long hsw_ddi_translations_dp[] = {
+ 0x00FF, 0x0006000E,
+ 0x00D75FFF, 0x0005000A,
+ 0x00C30FFF, 0x00040006,
+ 0x80AAAFFF, 0x000B,
+ 0x00FF, 0x0005000A,
+ 0x00D75FFF, 0x000C0004,
+ 0x80C30FFF, 0x000B,
+ 0x00FF, 0x00040006,
+ 0x80D75FFF, 0x000B,
+ 0x00FF, 0x00040006
+};
+
+static const long hsw_ddi_translations_fdi[] = {
+ 0x00FF, 0x0007000E,
+ 0x00D75FFF, 0x000F000A,
+ 0x00C30FFF, 0x00060006,
+ 0x00AAAFFF, 0x001E,
+ 0x00FF, 0x000F000A,
+ 0x00D75FFF, 0x00160004,
+ 0x00C30FFF, 0x001E,
+ 0x00FF, 0x00060006,
+ 0x00D75FFF, 0x001E,
+ 0x00FF, 0x00040006
+};
+
+/* On Haswell, DDI port buffers must be programmed with correct values
+ * in advance. The buffer values are different for FDI and DP modes,
+ * but the HDMI/DVI fields are shared among those. So we program the DDI
+ * in either FDI or DP modes only, as HDMI connections will work with both
+ * of those
+ */
+void hsw_prepare_ddi_buffers(struct drm_device *dev, enum port port, bool
use_fdi_mode)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ u32 reg;
+ int i, j;
+
+ DRM_DEBUG_DRIVER(Initializing DDI buffers for port %c in %s mode\n,
+ port_name(port),
+ use_fdi_mode ? FDI : DP);
+
+ WARN((use_fdi_mode (port != PORT_E)),
+ Programming port %c in FDI mode, this probably will not
work.\n,
+ port_name(port));
+
+ /* Those registers seem to be double-buffered, so write them twice */
+ for (j=0; j 2; j++) {
+ for (i=0, reg=DDI_BUF_TRANS(port); i
ARRAY_SIZE(hsw_ddi_translations_fdi); i++) {
+ I915_WRITE(reg,
+ (use_fdi_mode) ?
+ hsw_ddi_translations_fdi[i] :
+ hsw_ddi_translations_dp[i]);
+ reg += 4;
+ }
+ udelay(20);
+ }
+}
+
+/* Program DDI buffers translations for DP. By default, program ports A-D in DP
+ * mode and port E for FDI.
+ */
+static void intel_hsw_prepare_ddi_buffers(struct drm_device *dev)
+{
+ int port;
+
+ for (port = PORT_A; port PORT_E; port++)
+ hsw_prepare_ddi_buffers(dev, port, false);
+
+ /* DDI E is the suggested one to work in FDI mode, so program is as
such by
+* default. It will have to be re-programmed in case a digital DP output
+* will be detected on it
+*/
+ hsw_prepare_ddi_buffers(dev, PORT_E, true);
+}
+
/* Manual link training for Ivy Bridge A0 parts */
static void ivb_manual_fdi_link_train(struct drm_crtc *crtc)
{
@@ -9235,8 +9315,10 @@ void intel_modeset_init(struct drm_device *dev)
intel_init_quirks(dev);
- if (IS_HASWELL(dev))
+ if (IS_HASWELL(dev)) {
intel_init_power_wells(dev);
+ intel_hsw_prepare_ddi_buffers(dev);
+ }
intel_init_display(dev);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9cec6c3..ef1d4ca 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -407,6 +407,7 @@ extern void intel_init_clock_gating(struct drm_device *dev);
extern void intel_write_eld(struct drm_encoder *encoder,
struct drm_display_mode *mode);
extern void intel_cpt_verify_modeset(struct drm_device *dev, int pipe);
+extern void hsw_prepare_ddi_buffers(struct drm_device *dev, enum port port,
bool use_fdi_mode);
/* For use by IVB LP watermark workaround in intel_sprite.c */
extern void sandybridge_update_wm(struct drm_device *dev);
--
1.7.9.5
___
[Intel-gfx] [PATCH 34/41] drm/i915: perform Haswell DDI link training in FDI mode
This patch attempts at following the modeset sequence closely, retrying
with different voltages if the DP_TP_STATUS reports a failed training.
For training, we add a table of recommended settings for FDI, HDMI and DP
connections. For FDI and DP modes, we also add the HDMI buffer
translation as the last item. Those are ignored in such modes, so there is
no harm in having them set.
Initially, we use DDI E for FDI connectivity. This is the suggested
configuration, and this seems to be what should work the best with FDI.
Note that we leave the DDI Function for corresponding pipe active when we
are done with the training. This ensures that we only need to enable pipe
afterwards to get a working modesetting, in a similar fashion as on
pre-HSW hardware. The modeset disabling sequence mentions a correct order
of disabling things, but this is out of scope of this patch and is being
done separately, for clearer distinction of what happens when.
v2: improve comments a bit, use PORT enums instead of hardcoded PORT_E
registers, split DDI buffers programming into a separate patch.
v1 Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/gpu/drm/i915/intel_display.c | 118 ++
1 file changed, 118 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1fdcd56..09c18f8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2808,6 +2808,113 @@ static void intel_hsw_prepare_ddi_buffers(struct
drm_device *dev)
hsw_prepare_ddi_buffers(dev, PORT_E, true);
}
+static const long hsw_ddi_buf_ctl_values[] = {
+ DDI_BUF_EMP_400MV_0DB_HSW,
+ DDI_BUF_EMP_400MV_3_5DB_HSW,
+ DDI_BUF_EMP_400MV_6DB_HSW,
+ DDI_BUF_EMP_400MV_9_5DB_HSW,
+ DDI_BUF_EMP_600MV_0DB_HSW,
+ DDI_BUF_EMP_600MV_3_5DB_HSW,
+ DDI_BUF_EMP_600MV_6DB_HSW,
+ DDI_BUF_EMP_800MV_0DB_HSW,
+ DDI_BUF_EMP_800MV_3_5DB_HSW
+};
+
+
+/* Link training for HSW parts */
+static void hsw_fdi_link_train(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc-dev;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ int pipe = intel_crtc-pipe;
+ u32 reg, temp, i;
+
+ /* Configure CPU PLL, wait for warmup */
+ I915_WRITE(SPLL_CTL,
+ SPLL_PLL_ENABLE |
+ SPLL_PLL_FREQ_1350MHz |
+ SPLL_PLL_SCC);
+
+ /* Use SPLL to drive the output when in FDI mode */
+ I915_WRITE(PORT_CLK_SEL(PORT_E),
+ PORT_CLK_SEL_SPLL);
+ I915_WRITE(PIPE_CLK_SEL(pipe),
+ PIPE_CLK_SEL_PORT(PORT_E));
+
+ udelay(20);
+
+ /* Start the training iterating through available voltages and emphasis
*/
+ for (i=0; i ARRAY_SIZE(hsw_ddi_buf_ctl_values); i++) {
+ /* Configure DP_TP_CTL with auto-training */
+ I915_WRITE(DP_TP_CTL(PORT_E),
+ DP_TP_CTL_FDI_AUTOTRAIN |
+ DP_TP_CTL_ENHANCED_FRAME_ENABLE |
+ DP_TP_CTL_LINK_TRAIN_PAT1 |
+ DP_TP_CTL_ENABLE);
+
+ /* Configure and enable DDI_BUF_CTL for DDI E with next voltage
*/
+ temp = I915_READ(DDI_BUF_CTL(PORT_E));
+ temp = (temp ~DDI_BUF_EMP_MASK);
+ I915_WRITE(DDI_BUF_CTL(PORT_E),
+ temp |
+ DDI_BUF_CTL_ENABLE |
+ DDI_PORT_WIDTH_X2 |
+ hsw_ddi_buf_ctl_values[i]);
+
+ udelay(600);
+
+ /* Enable CPU FDI Receiver with auto-training */
+ reg = FDI_RX_CTL(pipe);
+ I915_WRITE(reg,
+ I915_READ(reg) |
+ FDI_LINK_TRAIN_AUTO |
+ FDI_RX_ENABLE |
+ FDI_LINK_TRAIN_PATTERN_1_CPT |
+ FDI_RX_ENHANCE_FRAME_ENABLE |
+ LPT_FDI_PORT_WIDTH_2X |
+ FDI_RX_PLL_ENABLE);
+ POSTING_READ(reg);
+ udelay(100);
+
+ temp = I915_READ(DP_TP_STATUS(PORT_E));
+ if (temp DP_TP_STATUS_AUTOTRAIN_DONE) {
+ DRM_INFO(BUF_CTL training done on %d step\n, i);
+
+ /* Enable normal pixel sending for FDI */
+ I915_WRITE(DP_TP_CTL(PORT_E),
+ DP_TP_CTL_FDI_AUTOTRAIN |
+ DP_TP_CTL_LINK_TRAIN_NORMAL |
+
[Intel-gfx] [PATCH 13/41] drm/i915: add SBI registers
Those are responsible for the Sideband Interface programming. v2: rename SBI bits to better reflect their meaning Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 58fcfae..d6c0e36 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3948,4 +3948,16 @@ DDI_BUF_TRANS_A, \ DDI_BUF_TRANS_B) +/* Sideband Interface (SBI) is programmed indirectly, via + * SBI_ADDR, which contains the register offset; and SBI_DATA, + * which contains the payload */ +#define SBI_ADDR 0xC6000 +#define SBI_DATA 0xC6004 +#define SBI_CTL_STAT 0xC6008 +#define SBI_CTL_OP_CRRD (0x68) +#define SBI_CTL_OP_CRWR (0x78) +#define SBI_RESPONSE_FAIL (0x11) +#define SBI_RESPONSE_SUCCESS (0x01) +#define SBI_BUSY (0x10) +#define SBI_READY (0x00) #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken LVDS output at mode changes
At Thu, 29 Mar 2012 08:07:05 -0700, Keith Packard wrote: On Thu, 29 Mar 2012 13:44:28 +0100, Chris Wilson ch...@chris-wilson.co.uk wrote: In conjunction with bits Power Sequence Progress field and Power Cycle Delay Active, this bit set to a one indicates that the panel is currently powered up or is currently in the power down sequence and it is unsafe to change the timing, port, and DPLL registers for the pipe or transcoder that is assigned to the panel output. The theory was that as we don't touch the DPLL and only modify the scaler, that the panel wouldn't care. I wonder what's confusing this one... The strange thing is that, although you can recover the display by turning off LVDS and on again once when the problem happens, but then the display starts flickering. And, the flickering continues even after reboot on BIOS boot screen. Even BIOS can't recover the problem by itself, too, as it seems. Then, keep the machine rest for long time and boot up, now the problem is gone. BTW, now I tested to disable LVDS unconditionally on different platforms as Daniel suggested. All worked fine, and I saw no regressions. Tested on IVY, SNB, ILK, GM45 and PineView. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken LVDS output at mode changes
#part sign=pgpmime On Thu, 29 Mar 2012 18:12:56 +0200, Takashi Iwai ti...@suse.de wrote: The strange thing is that, although you can recover the display by turning off LVDS and on again once when the problem happens, but then the display starts flickering. And, the flickering continues even after reboot on BIOS boot screen. Yeah, it's clearly the panel which is confused. It would be nice to know what happened to the LVDS signal which caused this problem with the panel. BTW, now I tested to disable LVDS unconditionally on different platforms as Daniel suggested. All worked fine, and I saw no regressions. Tested on IVY, SNB, ILK, GM45 and PineView. That's not surprising -- pre-PCH platforms disabled the LVDS anyways. I wonder if we could fix this by being more careful about the order of register operations during LVDS mode setting... -- keith.pack...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Broken LVDS output at mode changes
At Thu, 29 Mar 2012 09:57:41 -0700, Keith Packard wrote: #part sign=pgpmime On Thu, 29 Mar 2012 18:12:56 +0200, Takashi Iwai ti...@suse.de wrote: The strange thing is that, although you can recover the display by turning off LVDS and on again once when the problem happens, but then the display starts flickering. And, the flickering continues even after reboot on BIOS boot screen. Yeah, it's clearly the panel which is confused. It would be nice to know what happened to the LVDS signal which caused this problem with the panel. I'll try to poke someone in HP. BTW, now I tested to disable LVDS unconditionally on different platforms as Daniel suggested. All worked fine, and I saw no regressions. Tested on IVY, SNB, ILK, GM45 and PineView. That's not surprising -- pre-PCH platforms disabled the LVDS anyways. I wonder if we could fix this by being more careful about the order of register operations during LVDS mode setting... Sure, that'd be a preferred option. If you have any easy test in mind, let me know. thanks, Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/18] drm/i915: context switch implementation
On Sun, Mar 18, 2012 at 01:39:45PM -0700, Ben Widawsky wrote:
Implement the context switch code as well as the interfaces to do the
context switch. This patch also doesn't match 1:1 with the RFC patches.
The main difference is that from Daniel's responses the last context
object is now stored instead of the last context. This aids in allows us
to free the context data structure, and context object independently.
There is room for optimization: this code will pin the context object
until the next context is active. The optimal way to do it is to
actually pin the object, move it to the active list, do the context
switch, and then unpin it. This allows the eviction code to actually
evict the context object if needed.
The context switch code is missing workarounds, they will be implemented
in future patches.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Ok, I've looked at the use-sites of context_get and all this refcounting
and noticed that:
- we always hold dev-struct_mutex
- we always drop the acquired reference to the context structure in the
same function without dropping struct_mutex in between.
So we don't seem to require any reference counting on these (and
additional locking on the idr). Additionally the idr locking seems to give
us a false sense of security because afaics the locking/refcounting would
be broken when we would _not_ hold struct_mutex.
So can we just rip this out or do we need this (in which case it needs
some more work imo)?
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h |5 ++
drivers/gpu/drm/i915/i915_gem_context.c | 118
++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 +++
drivers/gpu/drm/i915/intel_ringbuffer.h |5 ++
4 files changed, 153 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f458a8f..c6c2ada 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1303,10 +1303,15 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
/* i915_gem_context.c */
+#define I915_CONTEXT_FORCED_SWITCH (10)
+#define I915_CONTEXT_INITIAL_SWITCH (11)
void i915_gem_context_load(struct drm_device *dev);
void i915_gem_context_unload(struct drm_device *dev);
void i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
+int i915_switch_context(struct intel_ring_buffer *ring,
+ struct drm_file *file,
+ int to_id, u32 seqno, u32 flags);
/* i915_gem_gtt.c */
int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 321bafd..cc508d5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -262,7 +262,7 @@ void i915_gem_context_close(struct drm_device *dev,
struct drm_file *file)
mutex_unlock(dev-struct_mutex);
}
-static __used struct i915_hw_context *
+static struct i915_hw_context *
i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
{
struct i915_hw_context *ctx = NULL;
@@ -279,3 +279,119 @@ i915_gem_context_get(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+
+static int do_switch(struct drm_i915_gem_object *from_obj,
+ struct i915_hw_context *to,
+ u32 seqno, u32 flags)
+{
+ bool initial_switch = (flags I915_CONTEXT_INITIAL_SWITCH) ? true :
false;
+ bool force = (flags I915_CONTEXT_FORCED_SWITCH) ? true : false;
+ struct intel_ring_buffer *ring = NULL;
+ u32 hw_flags = 0;
+ int ret;
+
+ BUG_ON(to == NULL);
+ BUG_ON(from_obj != NULL from_obj-pin_count == 0);
+ BUG_ON((from_obj != NULL from_obj-context_id 0) ||
to-obj-context_id 0);
+
+ ret = i915_gem_object_pin(to-obj, CONTEXT_ALIGN, false);
+ if (ret)
+ return ret;
+
+ if (initial_switch)
+ hw_flags |= MI_RESTORE_INHIBIT;
+ if (force)
+ hw_flags |= MI_FORCE_RESTORE;
+
+ ring = to-ring;
+ ret = intel_ring_mi_set_context(ring, to, hw_flags);
+ if (ret) {
+ i915_gem_object_unpin(to-obj);
+ return ret;
+ }
+
+ /* The backing object for the context is done after switching to the
+ * *next* context. Therefore we cannot retire the previous context until
+ * the next context has already started running. In fact, the below code
+ * is a bit suboptimal because the retiring can occur simply after the
+ * MI_SET_CONTEXT instead of when the next seqno has completed.
+ */
+ if (from_obj != NULL) {
+ i915_gem_object_move_to_active(from_obj, ring, seqno);
+
Re: [Intel-gfx] [PATCH 05/18] drm/i915: context switch implementation
On Thu, 29 Mar 2012 20:24:11 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sun, Mar 18, 2012 at 01:39:45PM -0700, Ben Widawsky wrote: Implement the context switch code as well as the interfaces to do the context switch. This patch also doesn't match 1:1 with the RFC patches. The main difference is that from Daniel's responses the last context object is now stored instead of the last context. This aids in allows us to free the context data structure, and context object independently. There is room for optimization: this code will pin the context object until the next context is active. The optimal way to do it is to actually pin the object, move it to the active list, do the context switch, and then unpin it. This allows the eviction code to actually evict the context object if needed. The context switch code is missing workarounds, they will be implemented in future patches. Signed-off-by: Ben Widawsky b...@bwidawsk.net Ok, I've looked at the use-sites of context_get and all this refcounting and noticed that: - we always hold dev-struct_mutex - we always drop the acquired reference to the context structure in the same function without dropping struct_mutex in between. So we don't seem to require any reference counting on these (and additional locking on the idr). Additionally the idr locking seems to give us a false sense of security because afaics the locking/refcounting would be broken when we would _not_ hold struct_mutex. So can we just rip this out or do we need this (in which case it needs some more work imo)? -Daniel I think it can be ripped out. I was on the fence about this before submitting the patches and left it out of laziness; it doesn't hurt as there is no lock contention assuming your statement is true with no bugs in the code, and it follows the canonical use of idrs. Let me look it over some more to make sure after you finish reviewing the other stuff. The idea was supposed to be contexts can be created and looked up without struct mutex, but that isn't actually done in the code. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/18] drm/i915: context switch implementation
On Sun, Mar 18, 2012 at 01:39:45PM -0700, Ben Widawsky wrote:
Implement the context switch code as well as the interfaces to do the
context switch. This patch also doesn't match 1:1 with the RFC patches.
The main difference is that from Daniel's responses the last context
object is now stored instead of the last context. This aids in allows us
to free the context data structure, and context object independently.
There is room for optimization: this code will pin the context object
until the next context is active. The optimal way to do it is to
actually pin the object, move it to the active list, do the context
switch, and then unpin it. This allows the eviction code to actually
evict the context object if needed.
The context switch code is missing workarounds, they will be implemented
in future patches.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Meh, I've forgotten half of the review, some more comments below.
---
drivers/gpu/drm/i915/i915_drv.h |5 ++
drivers/gpu/drm/i915/i915_gem_context.c | 118
++-
drivers/gpu/drm/i915/intel_ringbuffer.c | 26 +++
drivers/gpu/drm/i915/intel_ringbuffer.h |5 ++
4 files changed, 153 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f458a8f..c6c2ada 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1303,10 +1303,15 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
enum i915_cache_level cache_level);
/* i915_gem_context.c */
+#define I915_CONTEXT_FORCED_SWITCH (10)
+#define I915_CONTEXT_INITIAL_SWITCH (11)
void i915_gem_context_load(struct drm_device *dev);
void i915_gem_context_unload(struct drm_device *dev);
void i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
+int i915_switch_context(struct intel_ring_buffer *ring,
+ struct drm_file *file,
+ int to_id, u32 seqno, u32 flags);
/* i915_gem_gtt.c */
int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 321bafd..cc508d5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -262,7 +262,7 @@ void i915_gem_context_close(struct drm_device *dev,
struct drm_file *file)
mutex_unlock(dev-struct_mutex);
}
-static __used struct i915_hw_context *
+static struct i915_hw_context *
i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
{
struct i915_hw_context *ctx = NULL;
@@ -279,3 +279,119 @@ i915_gem_context_get(struct drm_i915_file_private
*file_priv, u32 id)
return ctx;
}
+
+static int do_switch(struct drm_i915_gem_object *from_obj,
+ struct i915_hw_context *to,
+ u32 seqno, u32 flags)
+{
+ bool initial_switch = (flags I915_CONTEXT_INITIAL_SWITCH) ? true :
false;
+ bool force = (flags I915_CONTEXT_FORCED_SWITCH) ? true : false;
I don't like this flag passing. force seems to be totally unused. And imo
inital_switch would work much better if we track this in
i915_hw_context-intialized (which will be false on context create) and
check this when before doing the context switch.
That way you'd also lose the complexity of having to initialize a context
explicitly after create - it would just magically happen.
+ struct intel_ring_buffer *ring = NULL;
+ u32 hw_flags = 0;
+ int ret;
+
+ BUG_ON(to == NULL);
+ BUG_ON(from_obj != NULL from_obj-pin_count == 0);
+ BUG_ON((from_obj != NULL from_obj-context_id 0) ||
to-obj-context_id 0);
+
+ ret = i915_gem_object_pin(to-obj, CONTEXT_ALIGN, false);
+ if (ret)
+ return ret;
+
+ if (initial_switch)
+ hw_flags |= MI_RESTORE_INHIBIT;
+ if (force)
+ hw_flags |= MI_FORCE_RESTORE;
Please move this into the function that actually emits the MI_ command -
it's imo hard to read things if it's distributed all over the place. And
because we don't seem to need force, a simple (and destriptive) bool
inhibit_restore would be sufficient.
+
+ ring = to-ring;
+ ret = intel_ring_mi_set_context(ring, to, hw_flags);
+ if (ret) {
+ i915_gem_object_unpin(to-obj);
+ return ret;
+ }
+
+ /* The backing object for the context is done after switching to the
+ * *next* context. Therefore we cannot retire the previous context until
+ * the next context has already started running. In fact, the below code
+ * is a bit suboptimal because the retiring can occur simply after the
+ * MI_SET_CONTEXT instead of when the next seqno has completed.
+ */
+ if
Re: [Intel-gfx] [PATCH 05/18] drm/i915: context switch implementation
On Thu, Mar 29, 2012 at 11:43:12AM -0700, Ben Widawsky wrote: On Thu, 29 Mar 2012 20:24:11 +0200 Daniel Vetter dan...@ffwll.ch wrote: On Sun, Mar 18, 2012 at 01:39:45PM -0700, Ben Widawsky wrote: Implement the context switch code as well as the interfaces to do the context switch. This patch also doesn't match 1:1 with the RFC patches. The main difference is that from Daniel's responses the last context object is now stored instead of the last context. This aids in allows us to free the context data structure, and context object independently. There is room for optimization: this code will pin the context object until the next context is active. The optimal way to do it is to actually pin the object, move it to the active list, do the context switch, and then unpin it. This allows the eviction code to actually evict the context object if needed. The context switch code is missing workarounds, they will be implemented in future patches. Signed-off-by: Ben Widawsky b...@bwidawsk.net Ok, I've looked at the use-sites of context_get and all this refcounting and noticed that: - we always hold dev-struct_mutex - we always drop the acquired reference to the context structure in the same function without dropping struct_mutex in between. So we don't seem to require any reference counting on these (and additional locking on the idr). Additionally the idr locking seems to give us a false sense of security because afaics the locking/refcounting would be broken when we would _not_ hold struct_mutex. So can we just rip this out or do we need this (in which case it needs some more work imo)? -Daniel I think it can be ripped out. I was on the fence about this before submitting the patches and left it out of laziness; it doesn't hurt as there is no lock contention assuming your statement is true with no bugs in the code, and it follows the canonical use of idrs. Let me look it over some more to make sure after you finish reviewing the other stuff. The idea was supposed to be contexts can be created and looked up without struct mutex, but that isn't actually done in the code. Well, if you want to leave it I have to add some more review comments about it - atm I think it would be buggy and racy without holding struct_mutex ... -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/18] drm/i915: possibly invalidate TLB before context switch
On Sun, Mar 18, 2012 at 01:39:49PM -0700, Ben Widawsky wrote:
From http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol1_Part3.pdf
[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT
entries). This can be done by a pipelined PIPE_CONTROL with TLB inv bit
set immediately before MI_SET_CONTEXT.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Hm, I've beend decently confused about the meaning of
GFX_TLB_INVALIDATE_ALWAYS - it actually means that we flush tlbs on every
full flush (i.e. always) when it's reset. And we don't set this so this
workaround is pretty much just informational. I'm hence wondering whether
a big comment wouldn't be better?
-Daniel
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 12
drivers/gpu/drm/i915/intel_ringbuffer.h |4
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index e892364..392e782 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -399,6 +399,10 @@ static int init_render_ring(struct intel_ring_buffer
*ring)
return ret;
}
+ if (INTEL_INFO(dev)-gen == 6)
+ ring-itlb_before_ctx_switch =
+ !!(I915_READ(GFX_MODE) GFX_TLB_INVALIDATE_ALWAYS);
+
if (INTEL_INFO(dev)-gen = 6) {
I915_WRITE(INSTPM,
INSTPM_FORCE_ORDERING 16 | INSTPM_FORCE_ORDERING);
@@ -927,6 +931,14 @@ int intel_ring_mi_set_context(struct intel_ring_buffer
*ring,
{
int ret;
+ if (IS_GEN6(ring-dev) ring-itlb_before_ctx_switch) {
+ /* w/a: If Flush TLB Invalidation Mode is enabled, driver must
+ * do a TLB invalidation prior to MI_SET_CONTEXT
+ */
+ gen6_render_ring_flush(ring, 0, 0);
+ }
+
+
ret = intel_ring_begin(ring, 6);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0ed98bb..e404e52 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -120,6 +120,10 @@ struct intel_ring_buffer {
wait_queue_head_t irq_queue;
drm_local_map_t map;
+ /**
+ * Do an explicit TLB flush before MI_SET_CONTEXT
+ */
+ bool itlb_before_ctx_switch;
struct i915_hw_context *default_context;
struct drm_i915_gem_object *last_context_obj;
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/18] drm/i915: switch to default context on idle
On Sun, Mar 18, 2012 at 01:39:51PM -0700, Ben Widawsky wrote:
To keep things as sane as possible, switch to the default context before
idling. This should help free context objects, as well as put things in
a more well defined state before suspending.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Context are yet another thing that will nicely fragment our global gtt
space. You don't pin them to mappable, which is a start, but I wonder
whether we should integrate this into our evict_something code? Although
that project is more involved with the current evict code, so maybe just
add a fixme.
---
drivers/gpu/drm/i915/i915_gem.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 0985aa5..c1aab45 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3685,6 +3685,8 @@ int
i915_gem_idle(struct drm_device *dev)
{
drm_i915_private_t *dev_priv = dev-dev_private;
+ struct intel_ring_buffer *ring = dev_priv-ring[RCS];
+ u32 seqno;
int ret;
mutex_lock(dev-struct_mutex);
@@ -3694,6 +3696,10 @@ i915_gem_idle(struct drm_device *dev)
return 0;
}
+ seqno = i915_gem_next_request_seqno(ring);
+ i915_switch_context(ring, NULL, DEFAULT_CONTEXT_ID, seqno, 0);
+ WARN_ON(i915_wait_request(ring, seqno, false));
This can block and potentially return early due to a signal, i.e. you need
to properly handle this (like the i915_gpu_idle below).
+
ret = i915_gpu_idle(dev, true);
if (ret) {
mutex_unlock(dev-struct_mutex);
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915: opencode get/put irq for gen6+
Before Chris get's all mad and complains that I did the opposite with
semaphores - semaphores did have a bit of logic which many had found
confusing and it was greatly simplified by abstracting it.
Anyhow, this removes a few lines that really didn't serve much purpose.
It also seems I can collapse the GT and GEN6 interrupt definitions into
1, but I'll have to check, and it's a separate patch anyway.
Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 80 ---
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
2 files changed, 21 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index b7b50a5..7e4b18c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -788,10 +788,12 @@ ring_add_request(struct intel_ring_buffer *ring,
}
static bool
-gen6_ring_get_irq(struct intel_ring_buffer *ring, u32 gflag, u32 rflag)
+gen6_ring_get_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
+ u32 gflag = ring-irq_enable[0];
+ u32 rflag = ring-irq_enable[1];
if (!dev-irq_enabled)
return false;
@@ -813,10 +815,12 @@ gen6_ring_get_irq(struct intel_ring_buffer *ring, u32
gflag, u32 rflag)
}
static void
-gen6_ring_put_irq(struct intel_ring_buffer *ring, u32 gflag, u32 rflag)
+gen6_ring_put_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
+ u32 gflag = ring-irq_enable[0];
+ u32 rflag = ring-irq_enable[1];
spin_lock(ring-irq_lock);
if (--ring-irq_refcount == 0) {
@@ -1285,6 +1289,8 @@ static const struct intel_ring_buffer render_ring = {
.get_seqno = ring_get_seqno,
.irq_get= render_ring_get_irq,
.irq_put= render_ring_put_irq,
+ .irq_enable = {GT_USER_INTERRUPT,
+ GEN6_RENDER_USER_INTERRUPT},
.dispatch_execbuffer= render_ring_dispatch_execbuffer,
.cleanup= render_ring_cleanup,
.sync_to= render_ring_sync_to,
@@ -1373,38 +1379,6 @@ gen6_ring_dispatch_execbuffer(struct intel_ring_buffer
*ring,
return 0;
}
-static bool
-gen6_render_ring_get_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_get_irq(ring,
-GT_USER_INTERRUPT,
-GEN6_RENDER_USER_INTERRUPT);
-}
-
-static void
-gen6_render_ring_put_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_put_irq(ring,
-GT_USER_INTERRUPT,
-GEN6_RENDER_USER_INTERRUPT);
-}
-
-static bool
-gen6_bsd_ring_get_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_get_irq(ring,
-GT_GEN6_BSD_USER_INTERRUPT,
-GEN6_BSD_USER_INTERRUPT);
-}
-
-static void
-gen6_bsd_ring_put_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_put_irq(ring,
-GT_GEN6_BSD_USER_INTERRUPT,
-GEN6_BSD_USER_INTERRUPT);
-}
-
/* ring buffer for Video Codec for Gen6+ */
static const struct intel_ring_buffer gen6_bsd_ring = {
.name = gen6 bsd ring,
@@ -1416,8 +1390,10 @@ static const struct intel_ring_buffer gen6_bsd_ring = {
.flush = gen6_ring_flush,
.add_request= gen6_add_request,
.get_seqno = gen6_ring_get_seqno,
- .irq_get= gen6_bsd_ring_get_irq,
- .irq_put= gen6_bsd_ring_put_irq,
+ .irq_enable = {GT_GEN6_BSD_USER_INTERRUPT,
+ GEN6_BSD_USER_INTERRUPT},
+ .irq_get= gen6_ring_get_irq,
+ .irq_put= gen6_ring_put_irq,
.dispatch_execbuffer= gen6_ring_dispatch_execbuffer,
.sync_to= gen6_bsd_ring_sync_to,
.semaphore_register = {MI_SEMAPHORE_SYNC_VR,
@@ -1426,24 +1402,6 @@ static const struct intel_ring_buffer gen6_bsd_ring = {
.signal_mbox= {GEN6_RVSYNC, GEN6_BVSYNC},
};
-/* Blitter support (SandyBridge+) */
-
-static bool
-blt_ring_get_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_get_irq(ring,
-GT_BLT_USER_INTERRUPT,
-GEN6_BLITTER_USER_INTERRUPT);
-}
-
-static void
-blt_ring_put_irq(struct intel_ring_buffer *ring)
-{
- gen6_ring_put_irq(ring,
- GT_BLT_USER_INTERRUPT,
- GEN6_BLITTER_USER_INTERRUPT);
-}
-
static int blt_ring_flush(struct intel_ring_buffer *ring,
Re: [Intel-gfx] [PATCH 12/18] drm/i915: try to reset the gpu before unload
On Sun, Mar 18, 2012 at 01:39:52PM -0700, Ben Widawsky wrote: paranoia For context support the HW expects the default context to always be available as there is no way to shut off HW contexts once turned on (afaics). This is problematic when unloading the driver as we have no way to prevent the GPU from expecting the BO to still be present once unloaded. The best we can do to remedy the situation is to attempt a GPU reset when doing the unload. NOTE: this patch isn't *really* required to go with the rest of the context serious. Signed-off-by: Ben Widawsky b...@bwidawsk.net I think the paranoia here is justified (albeit it would benefit from some commit-message love imo). But we do not support i915_reset on all gens, so I think you need to add a gen = 5 check here. --- drivers/gpu/drm/i915/i915_gem.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index c1aab45..848cc45 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3910,6 +3910,9 @@ i915_gem_lastclose(struct drm_device *dev) ret = i915_gem_idle(dev); if (ret) DRM_ERROR(failed to idle hardware: %d\n, ret); + ret = i915_reset(dev, GRDOM_FULL); + if (ret) + DRM_ERROR(failed to reset gpu: %d\n, ret); } static void -- 1.7.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/18] drm/i915/context: create destroy ioctls
On Sun, Mar 18, 2012 at 01:39:53PM -0700, Ben Widawsky wrote:
Add the interfaces to allow user space to create and destroy contexts.
Contexts are destroyed automatically if the file descriptor for the dri
device is closed.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_dma.c |2 +
drivers/gpu/drm/i915/i915_drv.h |4 ++
drivers/gpu/drm/i915/i915_gem_context.c | 64
+++
include/drm/i915_drm.h | 16
4 files changed, 86 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4c7c1dc..fb3fccb 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -2333,6 +2333,8 @@ struct drm_ioctl_desc i915_ioctls[] = {
DRM_IOCTL_DEF_DRV(I915_OVERLAY_ATTRS, intel_overlay_attrs,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_SET_SPRITE_COLORKEY, intel_sprite_set_colorkey,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(I915_GET_SPRITE_COLORKEY, intel_sprite_get_colorkey,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_CREATE,
i915_gem_context_create_ioctl, DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(I915_GEM_CONTEXT_DESTROY,
i915_gem_context_destroy_ioctl, DRM_UNLOCKED),
};
int i915_max_ioctl = DRM_ARRAY_SIZE(i915_ioctls);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c6c2ada..d49615e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1312,6 +1312,10 @@ void i915_gem_context_close(struct drm_device *dev,
struct drm_file *file);
int i915_switch_context(struct intel_ring_buffer *ring,
struct drm_file *file,
int to_id, u32 seqno, u32 flags);
+int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file);
+int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file);
/* i915_gem_gtt.c */
int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index d9a08f2..accb3de 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -411,3 +411,67 @@ out:
kref_put(to-nref, destroy_hw_context);
return ret;
}
+
+int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_gem_context_create *args = data;
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+ struct intel_ring_buffer *ring = dev_priv-ring[RCS];
+ struct i915_hw_context *ctx;
+ int ret;
+
+ if (dev_priv-hw_contexts_disabled)
+ return -EPERM;
+
+ ret = create_hw_context(dev, file_priv, ctx);
Note that the gem_alloc_object call in here is rather unsafe, due to the
unsafe statistics-keeping in i915_gem_info_add_obj. Pre-existing looking
goof-up, but can I maybe volunteer you to fix this? I think we need an
mm stats spinlock because these counters could be rather big (and atomic_t
is only 32 bits).
+ if (ret)
+ return ret;
+
+ /* We need to do a special switch (save-only) either now, or before the
+ * context is actually used in order to keep the context switch request
+ * in execbuffer fairly simple.
+ */
+ mutex_lock(dev-struct_mutex);
+ ret = i915_switch_context(ring, file, ctx-id, ring-get_seqno(ring),
+ I915_CONTEXT_INITIAL_SWITCH);
With the hw_context-is_intialized change you could ditch this (imo).
+ mutex_unlock(dev-struct_mutex);
+ if (ret)
+ return ret;
+
+ args-ctx_id = ctx-id;
+ DRM_DEBUG_DRIVER(HW context %d created\n, args-ctx_id);
+ return ret;
+}
+
+int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file)
+{
+ struct drm_i915_gem_context_destroy *args = data;
+ struct drm_i915_file_private *file_priv = file-driver_priv;
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct i915_hw_context *ctx;
+
+ if (dev_priv-hw_contexts_disabled)
+ return -EPERM;
+
+ mutex_lock(dev-struct_mutex);
+ ctx = i915_gem_context_get(file_priv, args-ctx_id);
+ if (!ctx) {
+ mutex_unlock(dev-struct_mutex);
+ return -EINVAL;
+ }
+
+ /* The first put is for the context ref we got just up above. The second
+ * put should unref the original ref (and will therefore destroy the
context
+ * unless someone else holds a reference
+
Re: [Intel-gfx] [PATCH 14/18] drm/i915/context: switch contexts with execbuf2
On Sun, Mar 18, 2012 at 01:39:54PM -0700, Ben Widawsky wrote:
Use the rsvd1 field in execbuf2 to specify the context ID associated
with the workload. This will allow the driver to do the proper context
switch when/if needed.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c |6 ++
include/drm/i915_drm.h |4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 81687af..c365e12 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1058,6 +1058,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
struct drm_i915_gem_object *batch_obj;
struct drm_clip_rect *cliprects = NULL;
struct intel_ring_buffer *ring;
+ u32 ctx_id = args-context_info I915_EXEC_CONTEXT_ID_MASK;
u32 exec_start, exec_len;
u32 seqno;
u32 mask;
@@ -1266,6 +1267,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
goto err;
}
+ ret = i915_switch_context(ring, file, ctx_id, seqno, 0);
+ if (ret)
+ goto err;
+
Already complained a bit about these:
- Imo the seqno and hw_flags param can/should go away.
- You need to add some sanity checks somewhere so that we correctly bail
out of the do_execbuffer stuff without launching the batch. Obviously
also a prime candidate for an i-g-t tests (because it'll nicely exercise
a piece of code which usually is rather hard to tests).
Aside: I haven't yet looked at your testcases, so maybe I'll come up with
a crazy idea for another testcase ;-)
trace_i915_gem_ring_dispatch(ring, seqno);
exec_start = batch_obj-gtt_offset + args-batch_start_offset;
@@ -1372,6 +1377,7 @@ i915_gem_execbuffer(struct drm_device *dev, void *data,
exec2.num_cliprects = args-num_cliprects;
exec2.cliprects_ptr = args-cliprects_ptr;
exec2.flags = I915_EXEC_RENDER;
+ exec2.context_info = 0;
ret = i915_gem_do_execbuffer(dev, data, file, exec2, exec2_list);
if (!ret) {
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index bead13e..03d159f 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -660,13 +660,15 @@ struct drm_i915_gem_execbuffer2 {
#define I915_EXEC_CONSTANTS_ABSOLUTE (16)
#define I915_EXEC_CONSTANTS_REL_SURFACE (26) /* gen4/5 only */
__u64 flags;
- __u64 rsvd1;
+ __u64 context_info;
__u64 rsvd2;
};
/** Resets the SO write offset registers for transform feedback on gen7. */
#define I915_EXEC_GEN7_SOL_RESET (18)
+#define I915_EXEC_CONTEXT_ID_MASK(0x)
+
struct drm_i915_gem_pin {
/** Handle of the buffer to be pinned. */
__u32 handle;
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/18] drm/i915/context: anonymous context interfaces
On Sun, Mar 18, 2012 at 01:39:56PM -0700, Ben Widawsky wrote:
Ironlake RC6 needs to allocate a power context object which the hardware
can automatically switch to. Since the new context code nicely handles
contexts, create some interfaces so we can hook up the existing code to
the new code.
The right way to do this is to move a bunch of code out of
intel_display.c but I don't feel like doing it at this time. This patch
is a step in the right direction though.
CC: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
I've looked through this and assuming I understand things correctly, this
is just to replace the power context on ilk. For the render context stuff
I expect that we can just directly re-use the default context.
Adding up the diffs I don't think the added indirection of these anonymous
contexts over simply using a plain gem object for the powercontext is
worth it. So I suggest we just rip this out.
-Daniel
---
drivers/gpu/drm/i915/i915_drv.h |3 +++
drivers/gpu/drm/i915/i915_gem_context.c | 40
+--
2 files changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d49615e..003b62e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -280,6 +280,7 @@ struct i915_hw_ppgtt {
/* This must match up with the value previously used for execbuf2.rsvd1. */
#define DEFAULT_CONTEXT_ID 0
+#define ANONYMOUS_CONTEXT_ID 1
struct i915_hw_context {
struct drm_i915_file_private *file_priv;
struct kref nref;
@@ -1316,6 +1317,8 @@ int i915_gem_context_create_ioctl(struct drm_device
*dev, void *data,
struct drm_file *file);
int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
struct drm_file *file);
+struct i915_hw_context *i915_context_alloc_anonymous(struct drm_device *dev);
+void i915_context_destroy_anonymous(struct i915_hw_context *ctx);
/* i915_gem_gtt.c */
int __must_check i915_gem_init_aliasing_ppgtt(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index accb3de..de1f3ce 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -122,7 +122,7 @@ again:
spin_lock(file_priv-context_lock);
ret = idr_get_new_above(file_priv-context_idr, *ctx_out,
- DEFAULT_CONTEXT_ID + 1, id);
+ ANONYMOUS_CONTEXT_ID + 1, id);
if (ret == 0)
(*ctx_out)-id = id;
spin_unlock(file_priv-context_lock);
@@ -254,7 +254,7 @@ static int context_idr_cleanup(int id, void *p, void
*data)
struct drm_i915_file_private *file_priv = file-driver_priv;
struct i915_hw_context *ctx;
- BUG_ON(id == DEFAULT_CONTEXT_ID);
+ BUG_ON(id == DEFAULT_CONTEXT_ID || id == ANONYMOUS_CONTEXT_ID);
ctx = i915_gem_context_get(file_priv, id);
BUG_ON(ctx == NULL);
kref_put(ctx-nref, destroy_hw_context);
@@ -380,6 +380,8 @@ int i915_switch_context(struct intel_ring_buffer *ring,
if (ring != dev_priv-ring[RCS])
return 0;
+ BUG_ON(to_id == ANONYMOUS_CONTEXT_ID);
+
if (file)
file_priv = file-driver_priv;
@@ -475,3 +477,37 @@ int i915_gem_context_destroy_ioctl(struct drm_device
*dev, void *data,
DRM_DEBUG_DRIVER(HW context %d destroyed\n, args-ctx_id);
return 0;
}
+
+struct i915_hw_context *
+i915_context_alloc_anonymous(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct i915_hw_context *ctx;
+ int ret;
+
+ if (dev_priv-hw_contexts_disabled)
+ return NULL;
+
+ ret = create_hw_context(dev, NULL, ctx);
+ if (ret)
+ return NULL;
+
+ ctx-id = ANONYMOUS_CONTEXT_ID;
+ ctx-obj-context_id = ANONYMOUS_CONTEXT_ID;
+
+ /* Anonymous contexts are assumed to be always pinned */
+ ret = i915_gem_object_pin(ctx-obj, CONTEXT_ALIGN, false);
+ if (ret)
+ do_destroy(ctx);
+
+ return ctx;
+}
+
+void i915_context_destroy_anonymous(struct i915_hw_context *ctx)
+{
+ BUG_ON(ctx-id != ANONYMOUS_CONTEXT_ID);
+ BUG_ON(ctx-obj-context_id != ANONYMOUS_CONTEXT_ID);
+
+ i915_gem_object_unpin(ctx-obj);
+ kref_put(ctx-nref, destroy_hw_context);
+}
--
1.7.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/18] drm/i915: Ironlake rc6 can use context interfaces
On Sun, Mar 18, 2012 at 01:39:57PM -0700, Ben Widawsky wrote:
Use the context interfaces to create the power context. Assuming we
have a default context, there should be no need to switch to
the render context anymore as the default context should already serve
this purpose.
As a double cautionary measure we check the CCID to make sure everything
looks kosher, and don't enable RC6 if it doesn't.
There is an important difference in logic when switching to the context
interface. The old code use MI_SUSPEND_FLUSH before MI_SET_CONTEXT which was
an
ILK specific workaround I remember seeing in old docs but can no longer find.
That workaround is not implemented in the standard context code.
PS. I think there is a double mutex_unlock in the existing error path
CC: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky b...@bwidawsk.net
As I've said in the previous patch review, I don't think it makes much
sense to convert the powercontext to your context code. Afaics the word
context is the only common thing here.
The reaping of the add-hoc renderctx in here is rather nice though. But I
expected this to go hand-in-hand with enabling your context code for gen5
(so that this gets replaced with the default context).
I've been pretty confused when trying to figure out how your code decides
whether it should enable hw context, until I've noticed that you return -1
in get_context_size. Can we make this slightly more explicit, with e.g.
not even attempting to init hw contexts for gen 5/6? HAS_HW_CONTEXT
macro that checks the gen would be nice ...
-Daniel
---
drivers/gpu/drm/i915/i915_debugfs.c |8 +--
drivers/gpu/drm/i915/i915_drv.h |3 +-
drivers/gpu/drm/i915/i915_reg.h |1 +
drivers/gpu/drm/i915/intel_display.c | 89
+++---
4 files changed, 10 insertions(+), 91 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fdb7cce..6c98d18 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1372,13 +1372,7 @@ static int i915_context_status(struct seq_file *m,
void *unused)
if (dev_priv-pwrctx) {
seq_printf(m, power context );
- describe_obj(m, dev_priv-pwrctx);
- seq_printf(m, \n);
- }
-
- if (dev_priv-renderctx) {
- seq_printf(m, render context );
- describe_obj(m, dev_priv-renderctx);
+ describe_obj(m, dev_priv-pwrctx-obj);
seq_printf(m, \n);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 003b62e..1329b1f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -352,8 +352,7 @@ typedef struct drm_i915_private {
drm_dma_handle_t *status_page_dmah;
uint32_t counter;
drm_local_map_t hws_map;
- struct drm_i915_gem_object *pwrctx;
- struct drm_i915_gem_object *renderctx;
+ struct i915_hw_context *pwrctx;
struct resource mch_res;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 6b6d685..4965638 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1360,6 +1360,7 @@
* Logical Context regs
*/
#define CCID 0x2180
+#define CCID_MASK0xf000
#define CCID_EN(10)
#define CXT_SIZE 0x21a0
#define GEN6_CXT_POWER_SIZE(cxt_reg) ((cxt_reg 24) 0x3f)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index de1ba19..4ef968a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -7948,42 +7948,6 @@ static const struct drm_mode_config_funcs
intel_mode_funcs = {
.output_poll_changed = intel_fb_output_poll_changed,
};
-static struct drm_i915_gem_object *
-intel_alloc_context_page(struct drm_device *dev)
-{
- struct drm_i915_gem_object *ctx;
- int ret;
-
- WARN_ON(!mutex_is_locked(dev-struct_mutex));
-
- ctx = i915_gem_alloc_object(dev, 4096);
- if (!ctx) {
- DRM_DEBUG(failed to alloc power context, RC6 disabled\n);
- return NULL;
- }
-
- ret = i915_gem_object_pin(ctx, 4096, true);
- if (ret) {
- DRM_ERROR(failed to pin power context: %d\n, ret);
- goto err_unref;
- }
-
- ret = i915_gem_object_set_to_gtt_domain(ctx, 1);
- if (ret) {
- DRM_ERROR(failed to set-domain on power context: %d\n, ret);
- goto err_unpin;
- }
-
- return ctx;
-
-err_unpin:
- i915_gem_object_unpin(ctx);
-err_unref:
- drm_gem_object_unreference(ctx-base);
- mutex_unlock(dev-struct_mutex);
- return NULL;
-}
-
bool ironlake_set_drps(struct drm_device *dev, u8 val)
{
struct drm_i915_private *dev_priv =
Re: [Intel-gfx] [PATCH 00/18] i915 HW Context Support
On Mon, Mar 19, 2012 at 11:14:32AM +0100, Daniel Vetter wrote: On Sun, Mar 18, 2012 at 01:39:40PM -0700, Ben Widawsky wrote: The patches have changed quite a bit since the RFC, and therefore I didn't feel comfortable trying to do v2 information. I didn't feel comfortable taking the few r-bs that I had from the RFC except for the one patch that I applied wholesale. Summary: - Completely redid the patch splitting. I've only done a quick and cursory reading, but I like the new splitting _much_ more. The storyline behind these patches is now much clearer. I'll try to do a more in-depth review later this week. Ok, I've gone through it and noticed a few things - mostly stuff that are imo more complicated than necessary and that could be cut out. Safe for the tlb flush wa I haven't cross-checked anything with Bspec, but I don't expect any surprises there. I also haven't checked how good the test coverage is (safe for suggesting that one test for execbuf failure handling). But again, that's something which can be easily fixed. The last thing I'm wondering is: How ready is mesa for this? I'd like to merge this only when the mesa patches are ready to put it to good use. Otherwise we run the decent risk of shipping broken code, which could end up in a decent pain for userspace (worst case we have to add a new flag to claim 'fixed context support'). Cheers, Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/41] drm/i915: add definition of LPT FDI port width registers
On Thu, Mar 29, 2012 at 12:32:28PM -0300, Eugeni Dodonov wrote: Reviewed-by: Rodrigo Vivi rodrigo.v...@intel.com Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 880c4f7..58fcfae 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -3475,6 +3475,9 @@ #define FDI_LINK_TRAIN_PATTERN_IDLE_CPT (28) #define FDI_LINK_TRAIN_NORMAL_CPT (38) #define FDI_LINK_TRAIN_PATTERN_MASK_CPT (38) +/* LPT */ +#define LPT_FDI_PORT_WIDTH_1X (019) +#define LPT_FDI_PORT_WIDTH_2X (119) bikeshed: Surounding defines seem to use the _LTP postfix annotation. Also please sort these in so that the bits are descending. -Daniel #define _FDI_RXA_MISC0xf0010 #define _FDI_RXB_MISC0xf1010 -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 14/41] drm/i915: add support for SBI ops
On Thu, Mar 29, 2012 at 12:32:30PM -0300, Eugeni Dodonov wrote:
With Lynx Point, we need to use SBI to communicate with the display clock
control. This commit adds helper functions to access the registers via
SBI.
v2: de-inline the function and address changes in bits names
v1 Reviewed-by: Rodrigo Vivi rodrigo.v...@gmail.com
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
The corresponding stuff from vlv is protected by dpio_lock. I think just
for paranoia and consistency it would make sense to do the same in the sbi
read/write helpers. I think you could just reuse the dpio_lock (with
irqsafe spinlock variants).
-Daniel
---
drivers/gpu/drm/i915/intel_display.c | 44
++
1 file changed, 44 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a0e3166..8e5f5be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1220,6 +1220,50 @@ static void intel_disable_pll(struct drm_i915_private
*dev_priv, enum pipe pipe)
POSTING_READ(reg);
}
+/* SBI access */
+static void
+intel_sbi_write(struct drm_i915_private *dev_priv, u16 reg, u32 value)
+{
+ if (wait_for((I915_READ(SBI_CTL_STAT) SBI_READY) == 0,
+ 10))
+ DRM_ERROR(timeout waiting for SBI to become ready\n);
+
+ I915_WRITE(SBI_ADDR,
+ (reg 16));
+ I915_WRITE(SBI_DATA,
+ value);
+ I915_WRITE(SBI_CTL_STAT,
+ SBI_BUSY |
+ SBI_CTL_OP_CRWR);
+
+ if (wait_for((I915_READ(SBI_CTL_STAT) (SBI_READY |
SBI_RESPONSE_SUCCESS)) == 0,
+ 10))
+ DRM_ERROR(timeout waiting for SBI to complete write
transaction\n);
+}
+
+static u32
+intel_sbi_read(struct drm_i915_private *dev_priv, u16 reg)
+{
+ u32 value;
+ if (wait_for((I915_READ(SBI_CTL_STAT) SBI_READY) == 0,
+ 10))
+ DRM_ERROR(timeout waiting for SBI to become ready\n);
+
+ I915_WRITE(SBI_ADDR,
+ (reg 16));
+ I915_WRITE(SBI_CTL_STAT,
+ SBI_BUSY |
+ SBI_CTL_OP_CRRD);
+
+ if (wait_for((I915_READ(SBI_CTL_STAT) (SBI_READY |
SBI_RESPONSE_SUCCESS)) == 0,
+ 10))
+ DRM_ERROR(timeout waiting for SBI to complete read
transaction\n);
+
+ value = I915_READ(SBI_DATA);
+
+ return value;
+}
+
/**
* intel_enable_pch_pll - enable PCH PLL
* @dev_priv: i915 private structure
--
1.7.9.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/18] drm/i915: switch to default context on idle
On Thu, 29 Mar 2012 21:29:05 +0200, Daniel Vetter dan...@ffwll.ch wrote: On Sun, Mar 18, 2012 at 01:39:51PM -0700, Ben Widawsky wrote: To keep things as sane as possible, switch to the default context before idling. This should help free context objects, as well as put things in a more well defined state before suspending. Signed-off-by: Ben Widawsky b...@bwidawsk.net Context are yet another thing that will nicely fragment our global gtt space. You don't pin them to mappable, which is a start, but I wonder whether we should integrate this into our evict_something code? Although that project is more involved with the current evict code, so maybe just add a fixme. My suggestion for when we want to step beyond having the context pinned all the time was for a hook into unbind that checked to see if this was a pinned object and to fixup any registers to point back to the default. In the case of contexts, it would check a flag to see if it was indeed the active context and then schedule a change back to the default context prior to unbinding. From another viewpoint, this sounds alot like fences, and maybe we should add the tracking to the CXTID register in a similar manner. -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] drm/i915: opencode get/put irq for gen6+
On Thu, 29 Mar 2012 12:26:49 -0700, Ben Widawsky b...@bwidawsk.net wrote: Before Chris get's all mad and complains that I did the opposite with semaphores - semaphores did have a bit of logic which many had found confusing and it was greatly simplified by abstracting it. Anyhow, this removes a few lines that really didn't serve much purpose. Yup, looks a worthwhile saving. It also seems I can collapse the GT and GEN6 interrupt definitions into 1, but I'll have to check, and it's a separate patch anyway. But that's the patch I've been waiting for too long now! And I think this patch would look even better afterwards. -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 22/41] drm/i915: add SFUSE_STRAP registers for digital port detection
On Thu, Mar 29, 2012 at 12:32:38PM -0300, Eugeni Dodonov wrote: DDIA is detected via the DDI_BUF_CTL registers bit 0, but for DDIB, DDIC and DDID we need to consult SFUSE_STRAP values. Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com --- drivers/gpu/drm/i915/i915_reg.h |7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index d9df228..f300f5f 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4037,4 +4037,11 @@ #define PIPE_WM_LINETIME_TIME(x) ((x)) #define PIPE_WM_LINETIME_IPS_LINETIME_MASK (0x1ff16) #define PIPE_WM_LINETIME_IPS_LINETIME(x) ((x)16) + +/* SFUSE_STRAP */ +#define SFUSE_STRAP 0xc2014 +#define SFUSE_STRAP_DDIB_DETECTED (12) +#define SFUSE_STRAP_DDIC_DETECTED (11) +#define SFUSE_STRAP_DDID_DETECTED (10) I've noticed that we have another sfuse here indicating whether the vga port is present. Do we not need this? -Daniel + #endif /* _I915_REG_H_ */ -- 1.7.9.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: add Ivy Bridge GT2 Server entries
This adds PCI ID for IVB GT2 server variant which we were missing.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
drivers/char/agp/intel-agp.h|1 +
drivers/char/agp/intel-gtt.c|2 ++
drivers/gpu/drm/i915/i915_drv.c |1 +
3 files changed, 4 insertions(+)
diff --git a/drivers/char/agp/intel-agp.h b/drivers/char/agp/intel-agp.h
index 0b07101..c009175 100644
--- a/drivers/char/agp/intel-agp.h
+++ b/drivers/char/agp/intel-agp.h
@@ -235,6 +235,7 @@
#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_M_GT2_IG 0x0166
#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_HB 0x0158 /* Server */
#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT1_IG 0x015A
+#define PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT2_IG 0x016A
#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_HB 0x0F00 /* VLV1 */
#define PCI_DEVICE_ID_INTEL_VALLEYVIEW_IG 0x0F30
#define PCI_DEVICE_ID_INTEL_HASWELL_HB 0x0400 /*
Desktop */
diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 7e223a2..936ca69 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1486,6 +1486,8 @@ static const struct intel_gtt_driver_description {
Ivybridge, sandybridge_gtt_driver },
{ PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT1_IG,
Ivybridge, sandybridge_gtt_driver },
+ { PCI_DEVICE_ID_INTEL_IVYBRIDGE_S_GT2_IG,
+ Ivybridge, sandybridge_gtt_driver },
{ PCI_DEVICE_ID_INTEL_VALLEYVIEW_IG,
ValleyView, valleyview_gtt_driver },
{ PCI_DEVICE_ID_INTEL_HASWELL_D_GT1_IG,
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 0efc02e..85900dd 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -340,6 +340,7 @@ static const struct pci_device_id pciidlist[] = {
/* aka */
INTEL_VGA_DEVICE(0x0152, intel_ivybridge_d_info), /* GT1 desktop */
INTEL_VGA_DEVICE(0x0162, intel_ivybridge_d_info), /* GT2 desktop */
INTEL_VGA_DEVICE(0x015a, intel_ivybridge_d_info), /* GT1 server */
+ INTEL_VGA_DEVICE(0x016a, intel_ivybridge_d_info), /* GT2 server */
{0, 0, 0}
};
--
1.7.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] intel: add Ivy Bridge GT2 server variant
From: Eugeni Dodonov eug...@dodonov.net We were missing this one and it is being used by Bromolow. Signed-off-by: Eugeni Dodonov eug...@dodonov.net --- intel/intel_chipset.h |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h index 435d01a..9c1abc8 100644 --- a/intel/intel_chipset.h +++ b/intel/intel_chipset.h @@ -44,6 +44,7 @@ #define PCI_CHIP_IVYBRIDGE_M_GT1 0x0156 /* mobile */ #define PCI_CHIP_IVYBRIDGE_M_GT2 0x0166 #define PCI_CHIP_IVYBRIDGE_S 0x015a /* server */ +#define PCI_CHIP_IVYBRIDGE_S_GT2 0x016a /* server */ #define PCI_CHIP_HASWELL_GT10x0402 /* Desktop */ #define PCI_CHIP_HASWELL_GT20x0412 @@ -128,7 +129,8 @@ dev == PCI_CHIP_IVYBRIDGE_GT2 || \ dev == PCI_CHIP_IVYBRIDGE_M_GT1 || \ dev == PCI_CHIP_IVYBRIDGE_M_GT2 || \ -dev == PCI_CHIP_IVYBRIDGE_S) +dev == PCI_CHIP_IVYBRIDGE_S || \ +dev == PCI_CHIP_IVYBRIDGE_S_GT2) #define IS_HSW_GT1(devid) (devid == PCI_CHIP_HASWELL_GT1 || \ devid == PCI_CHIP_HASWELL_M_GT1) -- 1.7.9.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] intel_driver: add support for Ivy Bridge GT2 Server chipset
This is the GT2 variant of Ivy Bridge server chip.
Signed-off-by: Eugeni Dodonov eugeni.dodo...@intel.com
---
src/intel_driver.h |1 +
src/intel_module.c |2 ++
2 files changed, 3 insertions(+)
diff --git a/src/intel_driver.h b/src/intel_driver.h
index e9d6d9e..98973e5 100644
--- a/src/intel_driver.h
+++ b/src/intel_driver.h
@@ -190,6 +190,7 @@
#define PCI_CHIP_IVYBRIDGE_D_GT1 0x0152
#define PCI_CHIP_IVYBRIDGE_D_GT2 0x0162
#define PCI_CHIP_IVYBRIDGE_S_GT1 0x015a
+#define PCI_CHIP_IVYBRIDGE_S_GT2 0x016a
#endif
diff --git a/src/intel_module.c b/src/intel_module.c
index 2c0e5cc..c6f94f5 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -142,6 +142,7 @@ static const SymTabRec _intel_chipsets[] = {
{PCI_CHIP_IVYBRIDGE_D_GT1, Ivybridge Desktop (GT1) },
{PCI_CHIP_IVYBRIDGE_D_GT2, Ivybridge Desktop (GT2) },
{PCI_CHIP_IVYBRIDGE_S_GT1, Ivybridge Server },
+ {PCI_CHIP_IVYBRIDGE_S_GT2, Ivybridge Server (GT2) },
{-1,NULL}
};
#define NUM_CHIPSETS (sizeof(_intel_chipsets) / sizeof(_intel_chipsets[0]))
@@ -210,6 +211,7 @@ static const struct pci_id_match intel_device_match[] = {
INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_D_GT1, intel_ivybridge_info ),
INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_D_GT2, intel_ivybridge_info ),
INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_S_GT1, intel_ivybridge_info ),
+ INTEL_DEVICE_MATCH (PCI_CHIP_IVYBRIDGE_S_GT2, intel_ivybridge_info ),
{ 0, 0, 0 },
};
--
1.7.9.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: open code gen6+ ring irqs
We can now open-code the get/put irq functions as they were just
abstracting single register definitions.
It would be nice to merge this in with the IRQ handling code... but that
is too much work for me at present. In addition I could probably
collapse this in to a lot of the Ironlake stuff, but I don't think it's
worth the potential regressions.
This patch itself should not effect functionality.
CC: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 62 ---
drivers/gpu/drm/i915/intel_ringbuffer.h |1 +
2 files changed, 17 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 25b9b9c..6b12ede 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -788,10 +788,11 @@ ring_add_request(struct intel_ring_buffer *ring,
}
static bool
-gen6_ring_get_irq(struct intel_ring_buffer *ring, u32 mask)
+gen6_ring_get_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
+ u32 mask = ring-irq_enable;
if (!dev-irq_enabled)
return false;
@@ -813,10 +814,11 @@ gen6_ring_get_irq(struct intel_ring_buffer *ring, u32
mask)
}
static void
-gen6_ring_put_irq(struct intel_ring_buffer *ring, u32 mask)
+gen6_ring_put_irq(struct intel_ring_buffer *ring)
{
struct drm_device *dev = ring-dev;
drm_i915_private_t *dev_priv = dev-dev_private;
+ u32 mask = ring-irq_enable;
spin_lock(ring-irq_lock);
if (--ring-irq_refcount == 0) {
@@ -1373,30 +1375,6 @@ gen6_ring_dispatch_execbuffer(struct intel_ring_buffer
*ring,
return 0;
}
-static bool
-gen6_render_ring_get_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_get_irq(ring, GT_USER_INTERRUPT);
-}
-
-static void
-gen6_render_ring_put_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_put_irq(ring, GT_USER_INTERRUPT);
-}
-
-static bool
-gen6_bsd_ring_get_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_get_irq(ring, GEN6_BSD_USER_INTERRUPT);
-}
-
-static void
-gen6_bsd_ring_put_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_put_irq(ring, GEN6_BSD_USER_INTERRUPT);
-}
-
/* ring buffer for Video Codec for Gen6+ */
static const struct intel_ring_buffer gen6_bsd_ring = {
.name = gen6 bsd ring,
@@ -1408,8 +1386,9 @@ static const struct intel_ring_buffer gen6_bsd_ring = {
.flush = gen6_ring_flush,
.add_request= gen6_add_request,
.get_seqno = gen6_ring_get_seqno,
- .irq_get= gen6_bsd_ring_get_irq,
- .irq_put= gen6_bsd_ring_put_irq,
+ .irq_enable = GEN6_BSD_USER_INTERRUPT,
+ .irq_get= gen6_ring_get_irq,
+ .irq_put= gen6_ring_put_irq,
.dispatch_execbuffer= gen6_ring_dispatch_execbuffer,
.sync_to= gen6_bsd_ring_sync_to,
.semaphore_register = {MI_SEMAPHORE_SYNC_VR,
@@ -1420,18 +1399,6 @@ static const struct intel_ring_buffer gen6_bsd_ring = {
/* Blitter support (SandyBridge+) */
-static bool
-blt_ring_get_irq(struct intel_ring_buffer *ring)
-{
- return gen6_ring_get_irq(ring, GEN6_BLITTER_USER_INTERRUPT);
-}
-
-static void
-blt_ring_put_irq(struct intel_ring_buffer *ring)
-{
- gen6_ring_put_irq(ring, GEN6_BLITTER_USER_INTERRUPT);
-}
-
static int blt_ring_flush(struct intel_ring_buffer *ring,
u32 invalidate, u32 flush)
{
@@ -1463,8 +1430,9 @@ static const struct intel_ring_buffer gen6_blt_ring = {
.flush = blt_ring_flush,
.add_request= gen6_add_request,
.get_seqno = gen6_ring_get_seqno,
- .irq_get= blt_ring_get_irq,
- .irq_put= blt_ring_put_irq,
+ .irq_get= gen6_ring_get_irq,
+ .irq_put= gen6_ring_put_irq,
+ .irq_enable = GEN6_BLITTER_USER_INTERRUPT,
.dispatch_execbuffer= gen6_ring_dispatch_execbuffer,
.sync_to= gen6_blt_ring_sync_to,
.semaphore_register = {MI_SEMAPHORE_SYNC_BR,
@@ -1482,8 +1450,9 @@ int intel_init_render_ring_buffer(struct drm_device *dev)
if (INTEL_INFO(dev)-gen = 6) {
ring-add_request = gen6_add_request;
ring-flush = gen6_render_ring_flush;
- ring-irq_get = gen6_render_ring_get_irq;
- ring-irq_put = gen6_render_ring_put_irq;
+ ring-irq_get = gen6_ring_get_irq;
+ ring-irq_put = gen6_ring_put_irq;
+ ring-irq_enable = GT_USER_INTERRUPT;
ring-get_seqno = gen6_ring_get_seqno;
}
[Intel-gfx] [PATCH 1/2] drm/i915: ring irq cleanups
- gen6 put/get only need one argument rflags and gflags are always the same (see above explanation) - remove a couple redundantly defined IRQs - reordered some lines to make things go in descending order Every ring has its own interrupts, enables, masks, and status bits that are fed into the main interrupt enable/mask/status registers. At one point in time it seemed like a good idea to make our functions support the notion that each interrupt may have a different bit position in the corresponding register (blitter parser error may be bit n in IMR, but bit m in blitter IMR). It turned out though that the HW designers did us a solid on Gen6+ and this unfortunate situation has been avoided. This allows our interrupt code to be cleaned up a bit. I jammed this into one commit because there should be no functional change with this commit, and staging it into multiple commits was unnecessarily artificial IMO. CC: Chris Wilson ch...@chris-wilson.co.uk CC: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Ben Widawsky benjamin.widaw...@intel.com --- drivers/gpu/drm/i915/i915_irq.c | 16 +++--- drivers/gpu/drm/i915/i915_reg.h |6 ++ drivers/gpu/drm/i915/intel_ringbuffer.c | 36 +++ 3 files changed, 22 insertions(+), 36 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 998116e..c550901 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -503,9 +503,9 @@ static irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS) if (gt_iir (GT_USER_INTERRUPT | GT_PIPE_NOTIFY)) notify_ring(dev, dev_priv-ring[RCS]); - if (gt_iir GT_GEN6_BSD_USER_INTERRUPT) + if (gt_iir GEN6_BSD_USER_INTERRUPT) notify_ring(dev, dev_priv-ring[VCS]); - if (gt_iir GT_BLT_USER_INTERRUPT) + if (gt_iir GEN6_BLITTER_USER_INTERRUPT) notify_ring(dev, dev_priv-ring[BCS]); if (de_iir DE_GSE_IVB) @@ -571,7 +571,7 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS) atomic_inc(dev_priv-irq_received); if (IS_GEN6(dev)) - bsd_usr_interrupt = GT_GEN6_BSD_USER_INTERRUPT; + bsd_usr_interrupt = GEN6_BSD_USER_INTERRUPT; /* disable master interrupt before clearing iir */ de_ier = I915_READ(DEIER); @@ -605,7 +605,7 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS) notify_ring(dev, dev_priv-ring[RCS]); if (gt_iir bsd_usr_interrupt) notify_ring(dev, dev_priv-ring[VCS]); - if (gt_iir GT_BLT_USER_INTERRUPT) + if (gt_iir GEN6_BLITTER_USER_INTERRUPT) notify_ring(dev, dev_priv-ring[BCS]); if (de_iir DE_GSE) @@ -1869,8 +1869,8 @@ static int ironlake_irq_postinstall(struct drm_device *dev) if (IS_GEN6(dev)) render_irqs = GT_USER_INTERRUPT | - GT_GEN6_BSD_USER_INTERRUPT | - GT_BLT_USER_INTERRUPT; + GEN6_BSD_USER_INTERRUPT | + GEN6_BLITTER_USER_INTERRUPT; else render_irqs = GT_USER_INTERRUPT | @@ -1942,8 +1942,8 @@ static int ivybridge_irq_postinstall(struct drm_device *dev) I915_WRITE(GTIIR, I915_READ(GTIIR)); I915_WRITE(GTIMR, dev_priv-gt_irq_mask); - render_irqs = GT_USER_INTERRUPT | GT_GEN6_BSD_USER_INTERRUPT | - GT_BLT_USER_INTERRUPT; + render_irqs = GT_USER_INTERRUPT | GEN6_BSD_USER_INTERRUPT | + GEN6_BLITTER_USER_INTERRUPT; I915_WRITE(GTIER, render_irqs); POSTING_READ(GTIER); diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 52a06be..e906885 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -589,7 +589,7 @@ #define GEN6_RENDER_COMMAND_PARSER_MASTER_ERROR (1 3) #define GEN6_RENDER_SYNC_STATUS (1 2) #define GEN6_RENDER_DEBUG_INTERRUPT (1 1) -#define GEN6_RENDER_USER_INTERRUPT (1 0) +#define GEN6_RENDER_USER_INTERRUPT (1 0) /* Alias for GT_USER_INTERRUPT */ #define GEN6_BLITTER_HWSTAM0x22098 #define GEN6_BLITTER_IMR 0x220a8 @@ -3069,12 +3069,10 @@ #define DEIER 0x4400c /* GT interrupt */ +#define GT_BSD_USER_INTERRUPT (1 5) #define GT_PIPE_NOTIFY (1 4) #define GT_SYNC_STATUS (1 2) #define GT_USER_INTERRUPT (1 0) -#define GT_BSD_USER_INTERRUPT (1 5) -#define GT_GEN6_BSD_USER_INTERRUPT (1 12) -#define GT_BLT_USER_INTERRUPT (1 22) #define GTISR 0x44010 #define GTIMR 0x44014 diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c b/drivers/gpu/drm/i915/intel_ringbuffer.c index b7b50a5..25b9b9c 100644 --- a/drivers/gpu/drm/i915/intel_ringbuffer.c +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c @@
Re: [Intel-gfx] Broken LVDS output at mode changes
#part sign=pgpmime On Thu, 29 Mar 2012 20:02:01 +0200, Takashi Iwai ti...@suse.de wrote: Sure, that'd be a preferred option. If you have any easy test in mind, let me know. The way I'd love to see it tested would be to capture signal traces on the LVDS link across mode set and see what glitches appear. That sounds hard to do without an LVDS signal analyser... -- keith.pack...@intel.com ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
