- 21 Oct, 2013 18 commits
-
-
Imre Deak authored
So far the modeset code enabled all power domains if it needed any. It wasn't a problem since HW generations so far only had one always-on power well and one dynamic power well that can be enabled/disabled. For domains powered by always-on power wells (panel fitter on pipe A and the eDP transcoder) we didn't do anything, for all other domains we just enabled the single dynamic power well. Future HW generations will change this, as they add multiple dynamic power wells. Support for these will be added later, this patch prepares for those by making sure we only enable the required domains. Note that after this change on HSW we'll enable all power domains even if it was the domain for the panel fitter on pipe A or the eDP transcoder. This isn't a problem since the power domain framework already checks if the domain is on an always-on power well and doesn't do anything in this case. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
We'll need the same functionality for other HW generations. The support for these will be added by upcoming patches. Signed-off-by:
-
Imre Deak authored
There is no hard need for this to be a spin lock, as we don't take these locks in irq context from anywhere. An upcoming patch will add calls to punit read/write functions from within regions protected by this lock and those functions need a mutex in turn. As a solution for that convert the spin lock to be a mutex. Signed-off-by:
-
Imre Deak authored
It is just cleaner this way and makes it easier to add support for other HW generations with always-on power wells powering a different set of domains. Signed-off-by:
-
Imre Deak authored
Upcoming patches will add tracking for a set of power domains via a bitmask; to make things simple there remove the current gap in the enum values. Signed-off-by:
-
Daniel Vetter authored
- Give them an _irq_handler postfix, like all the other irq stuff. - Shuffle the DEBUG_FS=n dummy functions around a bit. This is prep work to extract all the crc debug stuff into intel_display_testing.c Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
v2: Actually enable it. Reviewed-by:
-
Daniel Vetter authored
Really simple, and we don't even have working frame numbers. v2: Actually enable it ... v3: Review from Ville: - Unconditionally enable the border in the CRC checksum for consistency with gen3+. - Handle the "none" source to be able to disable the CRC machinery again. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
On pre-gen5 and vlv we can't use the pipe source when TV-out or a DP port is connected to the pipe. Hence we need to expose new CRC sources. Also simplify the existing pipe source platform code a bit by rejecting all unhandled sources by default. Reviewed-by:
-
Daniel Vetter authored
The PIPE_B #define was missing the display mmio offset. Use the _PIPE_INC macro instead, it's simpler. Reviewed-by:
-
Daniel Vetter authored
Reviewed-by:
-
Daniel Vetter authored
And throw in a tiny for_each_pipe refactoring for gen2. Reviewed-by:
-
Daniel Vetter authored
A bit a mess, since with DP/TV outputs we can't use the pipe CRC. Also, no plane CRCs, so we need to update the basic testcases. Reviewed-by:
-
Daniel Vetter authored
Should work down to gen2. The #defines for the interrupt sources are already there in PIPESTAT and are the same on all gmch platforms for gen2 up to vlv. Reviewed-by:
-
Chris Wilson authored
The current output looks like: Num Pipes: 2 Pipe [0]: SRC: 027f01df Plane [0]: CNTR: d9000000 STRIDE: 00001400 SIZE: 031f04ff POS: 00000000 ADDR: 00020000 Cursor [0]: CNTR: 00000000 POS: 00000000 BASE: 00000000 Pipe [1]: SRC: 04ff031f Plane [1]: CNTR: 01000000 STRIDE: 00000000 SIZE: 018f02cf POS: 00000000 ADDR: 00000000 Cursor [1]: CNTR: 00000000 POS: 00000000 BASE: 00000000 CPU transcoder: A CONF: 00000000 HTOTAL: 031f027f HBLANK: 03170287 HSYNC: 02ef028f VTOTAL: 020c01df VBLANK: 020401e7 VSYNC: 01eb01e9 CPU transcoder: B CONF: 80000000 HTOTAL: 059f04ff HBLANK: 059f04ff HSYNC: 054f052f VTOTAL: 0336031f VBLANK: 0336031f VSYNC: 03280322 which lacks the important visual clue to demarque the transcoder blocks from the last cursor. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Paulo Zanoni authored
Use the nice Kernel macro, it makes the code much more readable. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Ben Widawsky authored
Since we use intel_enable_rc6() now for more than just when we're enabling RC6, we'll see this message many times, and it is just confusing. As an example, calc_residency calls this function whenever poked via sysfs. This leaves the impression in dmesg that we're constantly re-enabling RC6. While at it, move the defines and description from drv.h to intel_pm.c, since these are only ever used in that code. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
-
- 18 Oct, 2013 14 commits
-
-
Jani Nikula authored
This is useful with the follow-up patch that frobs dev_priv->vbt.edp_bpp, and the value no longer comes directly from VBT. Signed-off-by:
-
Daniel Vetter authored
In Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jun 5 13:34:23 2013 +0200 drm/i915: consolidate pch pll enable sequence I've removed all the code from this if block, but somehow forgotten to kill the block itself. Reviewed-by: -
Daniel Vetter authored
hw designers decided to change the CRC registers and coalesce them all into one. Otherwise nothing changed. I've opted for a new hsw_ version to grab the crc sample since hsw+1 will have the same crc registers, but different interrupt source registers. So this little helper function will come handy there. Also refactor the display error handler with a neat pipe loop. v2: Use for_each_pipe. Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Daniel Vetter authored
We've set up all files, but removed only those for which we have a pipe. Which leaves the one for pipe C on machines with less than 2 pipes, breaking module reload. v2: We can't get at the drm device this early (wtf), so just register all the files and also remove them all again. Reviewed-by:
-
Daniel Vetter authored
This avoids a spurious spurious interrupt warning. Reviewed-by:
-
Daniel Vetter authored
Suggested by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
We enable the interrupt unconditionally and only control it through the enable bit in the CRC control register. v2: Extract per-platform helpers to compute the register values. Reviewed-by:
-
Daniel Vetter authored
Also add a new _PIPE_INC macro which takes an base plus increment. Much less likely to botch the job by missing an s/A/B/ somewhere. v2: They've moved the bitfield. Argh! Reviewed-by:
-
Daniel Vetter authored
The ringbuffer update logic should always be the same, but different platforms have different amounts of CRC registers. Hence extract it. Reviewed-by:
-
Daniel Vetter authored
Failed to properly test this. Reported-by:
-
Jani Nikula authored
The HDMI audio expects HDMI pixel clock to be set in the audio configuration. We've currently just set 0, using 25.2 / 1.001 kHz frequency, which fails with some modes. v2: Now with a commit message. Reference: http://mid.gmane.org/CAGpEb3Ep1LRZETPxHGRfBDqr5Ts2tAc8gCukWwugUf1U5NYv1g@mail.gmail.com Reference: http://mid.gmane.org/20130206213533.GA16367@hardeman.nuReported-by:
David Härdeman <david@hardeman.nu> Reported-by:
Jasper Smet <josbeir@gmail.com> Tested-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Jani Nikula authored
This will be needed for setting the HDMI pixel clock for audio config. No functional changes. v2: Now with a commit message. Signed-off-by:
-
Daniel Vetter authored
The drm/i915 driver wants to adjust it's own power policies using the cpu policies as a guideline (we can implicitly boost the cpus through the gpus on some platforms). To avoid a dreaded select (since a depends will leave users wondering where where their driver has gone too) add dummy functions. Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: kbuild test robot <fengguang.wu@intel.com> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Viresh Kumar <viresh.kumar@linaro.org> Cc: cpufreq@vger.kernel.org Cc: linux-pm@vger.kernel.org Cc: linux-kernel@vger.kernel.org Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
-
Daniel Vetter authored
It's better to catch such fallout early, and this way we can rely on the checking done by the drm core on fb->heigh/width at modeset time. If we ever support planar formats on intel we might want to look into a common helper to do all this, but for now this is good enough. v2: Take tiling into account, requested by Ville. v3: Fix tile height on gen2, spotted by Ville. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Requested-by:
-
- 16 Oct, 2013 8 commits
-
-
Daniel Vetter authored
At least on linux sizeof(long) == sizeof(void*) and the thinking is that you can grab about as many references as there's memory. Doesn't really matter, just a bit of OCD since the fixed size data type in a pure in-kernel datastructure look off. v2: Ville asked for an overflow check since no one prevents userspace from incrementing the pin count forever. v3: s/INT/LONG/, noticed by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Assuming that all framebuffer related metadata is invariant simplifies our userspace input data checking. And current userspace always first updates the tiling of an object before creating a framebuffer with it. This allows us to upconvert a check in pin_and_fence to a WARN. In the future it should also be helpful to know which buffer objects are potential scanout targets for e.g. frontbuffer rendering tracking and similar things. Note that SNA shipped for one prerelease with code which will be broken through this patch. But users shouldn't notice since it's purely an optimization and will transparently fall back to allocating a new fb. i-g-t also had offending code (now fixed), but we don't really care about breaking the test-suite. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
We look at gem state (like obj->tiling/obj->stride), we better have the relevant locks. Right now this doesn't matter much since most of these checks are a curtesy to safe buggy userspace, but I'd like to freeze the tiling once we have framebuffer objects attached. And then locking matters. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Imre Deak authored
Since commit 912d812e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 11 20:08:23 2012 +0200 drm/i915/crt: don't set HOTPLUG bits on !PCH on VLV we don't detect any VGA unplug event after a modeset, since there we reset the ADPA hotplug bits. Fix it by preserving the hotplug bits on VLV as well. Signed-off-by:
-
Thomas Wood authored
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor Specific Data Block to expose more stereo 3D modes. v2: Use (1 << 0) for consistency. (Ville Syrjälä) Skip adding any modes if 3D_MASK is indicated as being present but the length only includes 3D_Structure_ALL. (Ville Syrjälä) Check that the value of HDMI_3D_LEN is large enough to include 3D_Structure_ALL and 3D_MASK, if they are present. (Ville Syrjälä) v3: Increment offset before the length checks. (Ville Syrjälä) Signed-off-by:Thomas Wood <thomas.wood@intel.com> Reviewed-by:
-
Artem Bityutskiy authored
This patch changes HDMI port registration order for the BayTrail platform. The story is that in kernel version 3.11 i915 supported only one HDMI port - the HDMIB port. So this port ended up being HDMI-1 in user-space. But commit '6f6005a5 drm/i915: expose HDMI connectors on port C on BYT' introduced HDMIC port support. And added HDMIC registration prior to HDMIB, so HDMIB became HDMI-2 and HDMIC became HDMI-1. Well, this is fine as far as the kernel is concerned. i915 does not give any guarantees to the numbering, and has never given them. However, this breaks wayland setup in Tizen IVI. We have only one single HDMI port on our hardware, and it is connected to HDMIB. Our configuration relies on the fact that it is HDMI-1. Well, certainly this is user-space problem which was exposed with Jesse's patch. However, there is a reason why we have to do this assumption - we use touchscreen monitors and we have to associate event devices with the monitors, and this is not easy to do dynamically, so we just have a static setup. Anyway, while the user-space setup will have to be fixed regardless, let's chane the HDMI port registration order so that HDMIB stays HDMI-1, just like it was in 3.11. Simply because there is no strong reason for changing the order in the kernel, and it'll help setups like ours in sense that we'll have more time for fixing the issue properly. Also amend the commentary which looks a bit out-of-date. Signed-off-by:
Artem Bityutskiy <artem.bityutskiy@linux.intel.com> [danvet: Drop the commment, SDVOC is gone and we have a proper HDMIC define now.] Signed-off-by:
-
Damien Lespiau authored
Yet other direct usages of the pipe number instead of pipe_name(). We've been tracking them lately but managed to miss these last ones. v2: Catch them all! (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1) Signed-off-by:
-
Chris Wilson authored
We have two once very similar functions, i915_gpu_idle() and i915_gem_idle(). The former is used as the lower level operation to flush work on the GPU, whereas the latter is the high level interface to flush the GEM bookkeeping in addition to flushing the GPU. As such i915_gem_idle() also clears out the request and activity lists and cancels the delayed work. This is what we need for unloading the driver, unfortunately we called i915_gpu_idle() instead. In the process, make sure that when cancelling the delayed work and timer, which is synchronous, that we do not hold any locks to prevent a deadlock if the work item is already waiting upon the mutex. This requires us to push the mutex down from the caller to i915_gem_idle(). v2: s/i915_gem_idle/i915_gem_suspend/ Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70334Signed-off-by:
-
