- 16 Oct, 2013 25 commits
-
-
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:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Damien Lespiau <damien.lespiau@intel.com> 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:
Chris Wilson <chris@chris-wilson.co.uk> Tested-by: xunx.fang@intel.com [danvet: Only set ums.suspended for !kms as discussed earlier. Chris noticed that this slipped through.] Signed-off-by:
-
Chon Ming Lee authored
There is no functional change on this patch. Only rename several hdmi encoder function name which suppose to use only by valleyview from intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc. Signed-off-by:
Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by:
-
Daniel Vetter authored
We not only want const strings, but a const array of them. Reported by checkpatch.pl Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by:
-
Daniel Vetter authored
Also use #ifdef to keep consistent with all other such cases. Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by:
-
Damien Lespiau authored
It's time to declare them ready. Unleash the beast. Signed-off-by:
-
Damien Lespiau authored
It doesn't really make sense to have two processes dequeueing the CRC values at the same time. Forbid that usage. Signed-off-by:
-
Damien Lespiau authored
seq_file is not quite the right interface for these ones. We have a circular buffer with a new entry per vblank on one side and a process wanting to dequeue the CRC with a read(). It's quite racy to wait for vblank in user land and then try to read a pipe_crc file, sometimes the CRC interrupt hasn't been fired and we end up with an EOF. So, let's have the read on the pipe_crc file block until the interrupt gives us a new entry. At that point we can wake the reading process. Signed-off-by:
-
Damien Lespiau authored
Following commit needs drm_add_fake_info_node() higher in the file to avoid having a forward declaration. Move this helper near the top of the file. This also makes the next commit diff a bit easier to review. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
This shouldn't happen as the buffer is freed after disable pipe CRCs, but better be safe than sorry. Signed-off-by:
-
Damien Lespiau authored
In the same spirit than: drm/i915: Generalize the CRC command format for future work Let's move from writing 'A plane1' to 'pipe A plane1' to i915_pipe_crc_ctl. This will allow us to extend the interface to transcoders or DDIs in the future. Let's rename the CRC control file to be more generic. Signed-off-by: -
Damien Lespiau authored
Let's move from writing 'A plane1' to 'pipe A plane1' to i915_pipe_crc_ctl. This will allow us to extend the interface to transcoders or DDIs in the future. Signed-off-by:
-
Damien Lespiau authored
So we don't eat that memory when not needed. Signed-off-by:
-
Damien Lespiau authored
So we don't read out stale CRCs from a previous run left in the buffer. Signed-off-by:
-
Damien Lespiau authored
This way we can have some init/fini code on those transitions. Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
Signed-off-by:
-
Damien Lespiau authored
There are a few good properties to a circular buffer, for instance it has a number of entries (before we were always dumping the full buffer). Signed-off-by:
-
Daniel Vetter authored
Note the "return -ENODEV;" in pipe_crc_set_source(). The ctl file is disabled until the end of the series to be able to do incremental improvements. Signed-off-by:
-
Shuang He authored
There are several points in the display pipeline where CRCs can be computed on the bits flowing there. For instance, it's usually possible to compute the CRCs of the primary plane, the sprite plane or the CRCs of the bits after the panel fitter (collectively called pipe CRCs). v2: Quite a bit of rework here and there (Damien) Signed-off-by:
Shuang He <shuang.he@intel.com> Signed-off-by:
-
Ben Widawsky authored
I've sent this patch several times for various reasons. It essentially cleans up a lot of code where we need to do something per ring, and want to query whether or not the ring exists on that hardware. It has various uses coming up, but for now it shouldn't be too offensive. v2: Big conflict resolution on Damien's DEV_INFO_FOR_EACH stuff v3: Resolved vebox addition v4: Rebased after months of disuse. Also made failed ringbuffer init cleaner. v5: Remove the init cleaner from v4. There is a better way to do it. (Chris) Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
I had this lying around from he original PPGTT series, and thought we might try to get it in by itself. With the introduction of context refcounting we never explicitly ref/unref the backing object. As such, the previous fix was a bit wonky. Aside from fixing the above, this patch also puts us in good shape for an upcoming patch which allows a failure to occur in between context_init and the first do_switch. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
Ben Widawsky authored
I had this lying around from he original PPGTT series, and thought we might try to get it in by itself. It's convenient to just call i915_gem_init_hw at reset because we'll be adding new things to that function, and having just one function to call instead of reimplementing it in two places is nice. In order to accommodate we cleanup ringbuffers in order to bring them back up cleanly. Optionally, we could also teardown/re initialize the default context but this was causing some problems on reset which I wasn't able to fully debug, and is unnecessary with the previous context init/enable split. This essentially reverts: commit 8e88a2bd Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jun 19 18:40:00 2012 +0200 drm/i915: don't call modeset_init_hw in i915_reset It seems to work for me on ILK now. Perhaps it's due to: commit 8a5c2ae7 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Mar 28 13:57:19 2013 -0700 drm/i915: fix ILK GPU reset for render Signed-off-by:
-
- 15 Oct, 2013 15 commits
-
-
Ville Syrjälä authored
Using the 5/6 DDB split make sense only when sprites are enabled. So check that before we waste any cycles computing the merged watermarks with the 5/6 DDB split. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Makes the behaviour of the function more clear. Signed-off-by:
-
Ville Syrjälä authored
Makes the intention more clear. Signed-off-by:
-
Ville Syrjälä authored
We want to be able to use the masks to decode the register contents regardless of the hardware generation. So just expand the masks to cover all available bits, even if those are reserved on some generations. v2: Don't extend WM1_LP_SR_MASK so far, for the *future* Signed-off-by:
-
Ville Syrjälä authored
This debug print just adds overhead to the watermark merging process, and doesn't really give enough information to be useful. Just kill and let's add something much better a bit later. Signed-off-by:
-
Ville Syrjälä authored
Fill out the HSW watermark s/w tracking structures with the current hardware state in intel_modeset_setup_hw_state(). This allows us to skip the HW state readback during watermark programming and just use the values we keep around in dev_priv->wm. Reduces the overhead of the watermark programming quite a bit. v2: s/init_wm/wm_get_hw_state Remove stale comment about sprites Make DDB partitioning readout safer Signed-off-by: -
Ville Syrjälä authored
Currently hsw_write_vm_values() may write to certain watermark registers needlessly. For instance if only, say, LP3 changes, the current code will again disable all LP1+ watermarks even though only LP3 needs to be reconfigured. Add an easy to read function that will compute the dirtyness of the watermarks, and use that information to further optimize the watermark programming. v2: Disable LP1+ watermarks around changing LP0 watermarks for Paulo Signed-off-by:
-
Ville Syrjälä authored
To make it easier to check what watermark updates are actually necessary, keep copies of the relevant bits that match the current hardware state. Also add DDB partitioning into hsw_wm_values as that's another piece of state we want to track. We don't read out the hardware state on init yet, so we can't really start using this yet, but it will be used later. Signed-off-by:
-
Ville Syrjälä authored
The fbc_wm_enabled member in intel_wm_config is useless for the time being. The original idea for it was that we'd pre-compute it and so that the WM merging process could know whether it needs to worry about FBC watermarks at all. But we don't have a convenient way to pre-check for the possibility of FBC being used. intel_update_fbc() should be split up for that. Signed-off-by:
-
Ville Syrjälä authored
On HSW the LP1,LP2,LP3 levels are either 1,2,3 or 1,3,4. We make the conversion from LPn to to the level at one point current. Later we're going to do it in a few places, so move it to a separate function. Signed-off-by:
-
Ville Syrjälä authored
Using the 5/6 DDB split make sense only when sprites are enabled. So check that before we waste any cycles computing the merged watermarks with the 5/6 DDB split. Signed-off-by:
-
Ville Syrjälä authored
Move the watermark max computations into haswell_update_wm(). This allows keeping the 1/2 vs. 5/6 split code in one place, and avoid having to pass around so many things. We also save a bit of stack space by only requiring one copy of struct hsw_wm_maximums. Also move the intel_wm_config out from hsw_compute_wm_parameters() and pass it it. We'll have some need for it in haswell_update_wm() later. Signed-off-by:
-
Ville Syrjälä authored
Let's try to keep using the intermediate intel_pipe_wm representation for as long as possible. It avoids subtle knowledge about the internals of the hardware registers when trying to choose the best watermark configuration. While at it replace the memset() w/ zero initialization. Signed-off-by:
-
Ville Syrjälä authored
I want to convert hsw_find_best_result() to use intel_pipe_wm, so we need to move the merging to happen outside hsw_compute_wm_results(). Signed-off-by:
-
Ville Syrjälä authored
No point in re-computing the watermarks for all pipes, when only one pipe has changed. The watermarks stored under intel_crtc.wm.active are still valid for the other pipes. We just need to redo the merging. We can also skip the merge/update procedure completely if the new watermarks for the affected pipe come out unchanged. Signed-off-by:
-
