- 14 11月, 2014 27 次提交
-
-
由 Ville Syrjälä 提交于
When reading a CCK register we should obviously read it from CCK not Punit. This problem has been present ever since this of code was introduced in commit 67c3bf6f Author: Deepak S <deepak.s@linux.intel.com> Date: Thu Jul 10 13:16:24 2014 +0530 drm/i915: populate mem_freq/cz_clock for chv The problem was raised during review by Mika [1] but somehow slipped through the cracks, and the patch got applied with the problem unfixed. [1] http://lists.freedesktop.org/archives/intel-gfx/2014-July/048937.html Cc: Deepak S <deepak.s@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDeepak S <deepak.s@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Neil Roberts 提交于
The predicate source registers are needed to implement conditional rendering without stalling. The two source registers are used to load the previous values of the PS_DEPTH_COUNT register saved from PIPE_CONTROL commands. These can then be compared and used to set the predicate enable bit via the MI_PREDICATE command. The command parser version number is increased to 2 to make it easier to detect the new functionality in user space. Signed-off-by: NNeil Roberts <neil@linux.intel.com> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> (v1) Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> (v1) Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
This only affects the fastboot path as-is. In that case, we simply need to make sure that we update the pipe size at the first mode set. Rather than putting it off until we decide to flip (if indeed we do end up flipping), update the pipe size as appropriate a bit earlier in the set_config call. This sets us up for better pipe tracking in later patches. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
If these change (e.g. after a modeset following a fastboot), we need to do a full mode set. v2: - put under pipe_config check so we don't deref a null state (Jesse) Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
This is useful for checking things later. v2: - fix hsw infoframe enabled check (Ander) Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> [danvet: Add the missing PIPE_CONF_CHECK_I(has_infoframe); line to the hw state cross-checker.] [danet: Squash in fixup from Jesse to correctly compute has_infoframe in the hdmi compute_config function.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
This will allow us to consult more info before deciding whether to flip or do a full mode set. v2: - don't use uninitialized or incorrect pipe masks in set_config failure path (Ander) v3: - fixup for pipe_config changes in compute_config (Jesse) v4: - drop spurious hunk in force restore path (Ander) Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
This allows us to calculate the full pipe config before we do any mode setting work. v2: - clarify comments about global vs. per-crtc mode set (Ander) - clean up unnecessary pipe_config = NULL setting (Ander) v3: - fix pipe_config handling (alloc in compute_config, free in set_mode) (Jesse) - fix arg order in set_mode (Jesse) - fix failure path of set_config (Ander) Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Now that the backlight device no longer gets registered too early we should be able to drop most of the INVALID_PIPE checks from the backlight code. The only exceptio is the opregion stuff where we may (in theory at least) get a request from the BIOS already during driver init as soon as the backlight setup has been done. In which case we can still get the INVALID_PIPE from intel_get_pipe_from_connector(). So leave that check in place, and add a comment explaining why. For the rest, if we still manage to get here with INVALID_PIPE on VLV/CHV we will now get a WARN from the lower level functions and can then actually investigate further. v2: Leave the check in the BIOS related code (Jani) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Currently we register the backlight device as soon as we register the connector. That means we can get backlight requests from userspace already before reading out the current modeset hardware state. That means we don't yet know the current crtc->encoder->connector mapping, which causes problems for VLV/CHV which need to know the current pipe in order to figure out which BLC registers to poke. Currently we just ignore such requests fairly deep in the backlight code which means the backlight device brightness property will get out of sync with our backlight.level and the actual hardware state. Fix the problem by delaying the backlight device registration until the entire modeset init has been performed. And we also move the backlight unregisteration to happen as the first thing during the modeset cleanup so that we also won't be bothered with userspace backlight requested during teardown. This is a real world problem on machines using systemd, because systemd, for some reason, wants to restore the backlight to the level it used last time. And that happens as soon as it sees the backlight device appearing in the system. Sometimes the userspace access makes it through before the modeset init, sometimes not. v2: Do not lie to the user in the debug prints (Jani) Include connector name in the prints (Jani) Fix a typo in the commit message (Jani) Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
On VLV/CHV both pipes A and B have their own backlight control registers. In order to correctly read out the current hardware state at init we need to know which pipe is driving the eDP port. Pass that information down from the eDP init code into the backlight code. To determine the correct pipe we first look at which pipe is currently configured in the port control register, if that look invalid we look at which pipe's PPS is currently controlling the port, and if that too looks invalid we just assume pipe A. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
If the connector would have an encoder but the encoder didn't have a crtc we might dereference a NULL crtc here. I suppose that should never happen due to intel_sanitize_encoder(), but let's be a bit paranoid print a warning if we ever hit this and return INVALID_PIPE to the caller. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
On VLV/CHV when the display is off, we can't read out the current backlight level from the hardware since we have no pipe to do so. Currently we end up reading a bigus register due to passing INVALID_PIPE to VLV_BLC_PWM_CTL(). Skip the entire .get_backlight() call if the backlight isn't enabled according to backlight.enabled. This problem can be reproduced simply by reading the backlight device actual_brightness file while the display is off. Cc: Jani Nikula <jani.nikula@intel.com> Suggested-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
VLV/CHV have backlight controls only on pipes A and B. Bail out without touching registers that don't exist, and print a warning. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
Currently objects for which the hardware needs a contiguous physical address are allocated a shadow backing storage to satisfy the contraint. This shadow buffer is not wired into the normal obj->pages and so the physical object is incoherent with accesses via the GPU, GTT and CPU. By setting up the appropriate scatter-gather table, we can allow userspace to access the physical object via either a GTT mmaping of or by rendering into the GEM bo. However, keeping the CPU mmap of the shmemfs backing storage coherent with the contiguous shadow is not yet possible. Fortuituously, CPU mmaps of objects requiring physical addresses are not expected to be coherent anyway. This allows the physical constraint of the GEM object to be transparent to userspace and allow it to efficiently render into or update them via the GTT and GPU. v2: Fix leak of pci handle spotted by Ville v3: Remove the now duplicate call to detach_phys_object during free. v4: Wait for rendering before pwrite. As this patch makes it possible to render into the phys object, we should make it correct as well! Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
Paulo noticed that we don't support RPS on GEN9 yet, so WARN for and ignore any RPS interrupts on that platform. Signed-off-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
The logical place for these functions is in i915_irq.c next to the rest of PM interrupt handling functions. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
The GEN6 and GEN8 versions differ only in the PM IIR and IER register addresses and that on GEN8 we need to keep the GEN8_PMINTR_REDIRECT_TO_NON_DISP PM interrupt unmasked. Abstract away these 3 things in the GEN6 versions of the helpers and use them everywhere. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
After the previous patch the GEN8 RPS handler became very similar to the GEN6 version, so unify the two functions. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Move one misplaced hunk from a later patch to fix a bisect issue as reported by Wu Fengguang's 0-day builder and fix suggested by Imre.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
The helpers to enable/disable PM IRQs for GEN6 and GEN8 are the same except for the PM interrupt mask register, so abstract away this register in the GEN6 versions and use these everywhere. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Arun Siluvery 提交于
+WaForceEnableNonCoherent:chv +WaHdcDisableFetchWhenMasked:chv For: VIZ-4090 Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Arun Siluvery 提交于
WaDisablePartialInstShootdown:chv and WaDisableThreadStallDopClockGating:chv are related to the same register so combine them. Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Arun Siluvery 提交于
-WaDisableDopClockGating:chv -WaDisableSamplerPowerBypass:chv -WaDisableGunitClockGating:chv -WaDisableFfDopClockGating:chv -WaDisableDopClockGating:chv v2: Remove pre-production WA instead of restricting them based on revision id (Ville) For: VIZ-4090 Signed-off-by: NArun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
Commit "drm/i915: create a prepare phase for sprite plane updates" changed the old_obj pointer we use when committing sprite planes, which caused a WARN() and a BUG() to be triggered. Later, commit "drm/i915: use intel_fb_obj() macros to assign gem objects" introduced the same problem to function intel_commit_sprite_plane(). Regression introduced by: commit ec82cb793c9224e0692eed904f43490cf70e8258 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Fri Oct 24 14:51:32 2014 +0100 drm/i915: create a prepare phase for sprite plane updates and: commit 77cde952 Author: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Date: Fri Oct 24 14:51:33 2014 +0100 drm/i915: use intel_fb_obj() macros to assign gem objects Credits to Imre Deak for pointing out the exact lines that were wrong. v2: Also fix intel_commit_sprite_plane() (Ville) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85634 Testcase: igt/pm_rpm/legacy-planes Testcase: igt/pm_rpm/legacy-planes-dpms Testcase: igt/pm_rpm/universal-planes Testcase: igt/pm_rpm/universal-planes-dpms Credits-to: Imre Deak <imre.deak@intel.com> Cc: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniele Ceraolo Spurio 提交于
- ppgtt init/release: these tracepoints are useful for observing the creation and destruction of Full PPGTTs. - ctx create/free: we can use the ctx_free trace in combination with the ppgtt_release one to be sure that the ppgtt doesn't stay alive for too long after the ctx is destroyed. ctx_create is there for simmetry - switch_mm: important point in the lifetime of the vm v4: add DOC information v5: pull the DOC in drm.tmpl v6: clean ppgtt init/release traces + add ctx create/free and switch_mm tracepoints (Chris) v7: drop execlist_submit_context tracepoint Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
The Baseline_ELD_Len field does not include ELD Header Block size. From High Definition Audio Specification, Revision 1.0a: The header block is a fixed size of 4 bytes. The baseline block is variable size in multiple of 4 bytes, and its size is defined in the header block Baseline_ELD_Len field (in number of DWords). Do not include the header size in Baseline_ELD_Len field. Fix all known users of eld[2]. While at it, switch to DIV_ROUND_UP instead of open coding it. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Acked-by: NBen Skeggs <bskeggs@redhat.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: NDave Airlie <airlied@linux.ie> [danvet: Fix compile fail in nouveau.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Alexey Khoroshilov 提交于
Since a8bb6818 __intel_framebuffer_create() is called with struct_mutex held, so it should use drm_gem_object_unreference() instead of drm_gem_object_unreference_unlocked(). Found by Linux Driver Verification project (linuxtesting.org). This regression has been introduced in commit a8bb6818 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Feb 10 18:00:39 2014 +0100 drm/i915: Fix error path leak in fbdev fb allocation Signed-off-by: NAlexey Khoroshilov <khoroshilov@ispras.ru> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Bob Paauwe 提交于
Use the new pipe config values to calculate the updated pll dividers. This regression was introduced in commit 0dbdf89f27b17ae1eceed6782c2917f74cbb5d59 Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Wed Oct 29 11:32:33 2014 +0200 drm/i915: Add infrastructure for choosing DPLLs before disabling crtcs and commit 00d958817dd3daaa452c221387ddaf23d1e4c06f Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Wed Oct 29 11:32:36 2014 +0200 drm/i915: Covert remaining platforms to choose DPLLS before disabling CRTCs v2: Use intel_pipe_will_have_type() to look at new configuration - Ander Signed-off-by: NBob Paauwe <bob.j.paauwe@intel.com> CC: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 11月, 2014 1 次提交
-
-
The cleanup path would reset pll->new_config to NULL but wouldn't free the allocated memory. Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 11月, 2014 3 次提交
-
-
由 Daniel Vetter 提交于
Backmerge drm-next so that I can keep merging patches. Specifically I want: - atomic stuff, yay! - eld parsing patch from Jani. Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Dave Airlie 提交于
These two didn't get documented properly, do so. Pointed out by Daniel. v1.1: add missing boilerplate (Daniel) Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
Merge tag 'topic/atomic-helpers-2014-11-09' of git://anongit.freedesktop.org/drm-intel into drm-next So here's my atomic series, finally all debugged&reviewed. Sean Paul has done a full detailed pass over it all, and a lot of other people have commented and provided feedback on some parts. Rob Clark also converted msm over the w/e and seems happy. The only small thing is that Rob wants to export the wait_for_vblank, which imo makes sense. Since there's other stuff still to do I think we should apply Rob's patch (once it has grown appropriate kerneldoc) later on top of this. This is just the core<->driver interface plus a big pile of helpers. Short recap of the main ideas: - There are essentially three helper libraries in this patch set: * Transitional helpers to use the new plane callbacks for legacy plane updates and in the crtc helper's ->mode_set callback. These helpers are only temporarily used to convert drivers to atomic, but they allow a nice separation between changing the driver backend and switching to the atomic commit logic. * Legacy helpers to implement all the legacy driver entry points (page_flip, set_config, plane vfuncs) on top of the new atomic driver interface. These are completely driver agnostic. The reason for having the legacy support as helpers is that drivers can switch step-by-step. And they could e.g. even keep the legacy page_flip code around for some old platforms where converting to full-blown atomic isn't worth it. * Atomic helpers which implement the various new ->atomic_* driver interfaces in terms of the revised crtc helper and new plane helper hooks. - The revised crtc helper implemenation essentially implements all the lessons learned in the i915 modeset rework (when using the atomic helpers only): * Enable/disable sequence for a given config are always the same and callbacks are always called in the same order. This contrast starkly with the crtc helpers, where the sequence of operations is heavily dependent on the previous config. One corollary of this is that if the configuration of a crtc only partially changes (e.g. a connector moves in a cloned config) the helper code will still disable/enable the full display pipeline. This is the only way to ensure that the enable/disable sequence is always the same. * It won't call disable or enable hooks more than once any more because it lost track of state, thanks to the atomic state tracking. And if drivers implement the ->reset hook properly (by either resetting the hw or reading out the hw state into the atomic structures) this even extends to the hardware state. So no more disable-me-harder kind of nonsense. * The only thing missing is the hw state readout/cross-check support, but if drivers have hw state readout support in their ->reset handlers it's simple to extend that to cross-check the hw state. * The crtc->mode_set callback is gone and its replacement only sets crtc timings and no longer updates the primary plane state. This way we can finally implement primary planes properly. - The new plane helpers should be suitable enough for pretty much everything, and a perfect fit for hardware with GO bits. Even if they don't fit the atomic helper library is rather flexible and exports all the functions for the individual steps to drivers. So drivers can pick what matches and implement their own magic for everything else. - A big difference compared to all previous atomic series is that this one doesn't implement async commit in a generic way. Imo driver requirements for that are too diverse to create anything reasonable sane which would actually work on a reasonable amount of different drivers. Also, we've never had a helper library for page_flips even, so it's really hard to know what might work and what's stupid without a bit of experience in the form of a few driver implementations. I think with the current flexibility for drivers to pick individual stages and existing helpers like drm_flip_queue it's rather easy though to implement proper async commit. - There's a few other differences of minor importance to earlier atomic series: * Common/generic properties are parsed in the callers/core and not in drivers, and passed to drivers by directly setting the right members in atomic state structures. That greatly simplifies all the transitional and legacy helpers an removes a lot of boilerplate code. * There's no crazy trylock mode used for the async commit since these helpers don't do async commit. A simple ordered flip queue of atomic state updates should be sufficient for preventing concurrent hw access anyway, as long as synchronous updates stall correctly with e.g. flush_work_queue or similar function. Abusing locks to enforce ordering isn't a good idea imo anyway. * These helpers reuse the existing ->mode_fixup hooks in the atomic_check callback. Which means that drivers need to adapat and move a lot less code into their atomic_check callbacks. Now this isn't everything needed in the drm core and helpers for full atomic support. But it's enough to start with converting drivers, and except for actually testing multiplane and multicrtc updates also enough to implement full atomic updates. Still missing are: - Per-plane locking. Since these helpers here encapsulate the locking completely this should be fairly easy to implement. - fbdev support for atomic_check/commit, so that multi-pipe finally works sanely in fbcon. - Adding and decoding shared/core properties. That just needs to be rebased from Rob's latest patch series, with minor adjustments so that the decoding happens in the core instead of in drivers. - Actually adding the atomic ioctl. Again just rebasing Rob's latest patch should be all that's needed. - Resolving how to deal with DPMS in atomic. Atomic is a good excuse to fix up the crazy semantics dpms currently has. I'm floating an RFC about this topic already. - Finally I couldn't test connector/encoder stealing properly since my test vehicle here doesn't allow a connector on different crtcs. So drivers which support this might see some surprises in that area. There is no semantic change though in how encoder stealing and assignment works (or at least no intended one), so I think the risk is minimal. As just mentioned I've done a fake conversion of an existing driver using crtc helpers to debug the helper code and validate the smooth transition approach. And that smooth transition was the really big motivation for this. It seems to actually work and consists of 3 phases: Phase 1: Rework driver backend for crtc/plane helpers The requirement here is that universal plane support is already implement. If universal plane support isn't implement yet it might be better though to just do it as part of this phase, directly using the new plane helpers. There are two big things to do: - Split up the existing ->update/disable_plane hooks into check/commit hooks and extract the crtc-wide prep/flush parts (like setting/clearing GO bits). - The other big change is to split the crtc->mode_set hook into the plane update (done using the plane helpers) and the crtc setup in a new ->mode_set_nofb hook. When phase 1 is complete the driver implements all the new callbacks which push the software state into hardware, but still using all the legacy entry points and crtc helpers. The transitional helpers serve as impendance mismatch here. Phase 2: Rework state handling This consists of rolling out the state handling helpers for planes, crtcs and connectors and reviewing all ->mode_fixup and similar hooks to make sure they don't depend upon implicit global state which might change in the atomic world. Any such code must be moved into ->atomic_check functions which just rely on the free-standing atomic state update structures. This phase also adds a few small pieces of fixup code to make sure the atomic state doesn't get out of sync in the legacy driver callbacks. Phase 3: Roll out atomic support Now it's just about replacing vfuncs with the ones provided by the helper and filling out the small missing pieces (like atomic_check logic or async commit support needed for page_flips). Due to the prep work in phase 1 no changes to the driver backend functions should be required, and because of the prep work in phase 2 atomic implementations can be rolled out step-by-step. So if async commit ins't implemented yet page_flip can be implemented with the legacy functions without wreaking havoc in the other operations. * tag 'topic/atomic-helpers-2014-11-09' of git://anongit.freedesktop.org/drm-intel: drm/atomic: Refcounting for plane_state->fb drm: Docbook integration and over sections for all the new helpers drm/atomic-helpers: functions for state duplicate/destroy/reset drm/atomic-helper: implement ->page_flip drm/atomic-helpers: document how to implement async commit drm/atomic: Integrate fence support drm/atomic-helper: implementatations for legacy interfaces drm: Atomic crtc/connector updates using crtc/plane helper interfaces drm/crtc-helper: Transitional functions using atomic plane helpers drm/plane-helper: transitional atomic plane helpers drm: Add atomic/plane helpers drm: Global atomic state handling drm: Add atomic driver interface definitions for objects drm/modeset_lock: document trylock_only in kerneldoc drm: fixup kerneldoc in drm_crtc.h drm: Pull drm_crtc.h into the kerneldoc template drm: Move drm_crtc_init from drm_crtc.h to drm_plane_helper.h
-
- 08 11月, 2014 9 次提交
-
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
for the Brothers in Triage Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
We need the HPLL frequency when calculating cdclk. Currently we read that out from the hardware every single time, which isn't going to fly very well if the device is runtime suspended. So cache the HPLL frequency in dev_priv and use the cached value. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
This reverts commit 5cb13c07. While the relevance for WaRsDontPollForAckOnClearingFWBits is under investigation, revert this as regression. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85684Tested-by: NTested-by: lu hua <huax.lu@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: S, Deepak <deepak.s@intel.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
This simplifies the code quite a bit compared to iterating over all rings during the ring interrupt. Also, it allows us to drop the mmio_flip spinlock, since the mmio_flip struct is only accessed in two places. The first is when the flip is queued and the other when the mmio writes are done. Since a flip cannot be queued while there is a pending flip, the two paths shouldn't ever run in parallel. We might need to revisit that if support for replacing flips is implemented though. v2: Don't hold dev->struct_mutext while waiting (Chris) v3: Make the wait uninterruptable (Chris) Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
So that it can be used by the flip code to wait for rendering without holding any locks. Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
We may need to access various hardware bits in the .global_resources() hook, so move the call to occur after enabling all the newly required power wells, but before disabling all the now unneeded wells. This should guarantee that we have all the sufficient hardware resources available during the .global_resources() call. And if not, any additional resources must be explicitly acquired by the .global_resorces() hook. For instance on VLV/CHV we need to access the gunit mailbox so that we can talk to punit/cck over sideband. In addition some PFI credit reprogramming may need to be addes as well, which may require the disp2d well. This should also make the power domain refcounts consistent on platforms which don't have a .global_resource() hook since now they too will call modeset_update_crtc_power_domains() which will drop the init power. Previously init power was just left enabled for such platforms. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
v2: include the section in the drm docbook. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-