- 26 Mar, 2019 13 commits
-
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of register access, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190325214940.23632-8-daniele.ceraolospurio@intel.com
-
Daniele Ceraolo Spurio authored
The intel_uncore structure is the owner of FW, so subclass the function to it. While at it, use a local uncore var and switch to the new read/write functions where it makes sense. Signed-off-by:
-
Daniele Ceraolo Spurio authored
The full read/write ops can now work on the intel_uncore struct. Introduce intel_uncore_read/write functions working on intel_uncore and switch the I915_READ/WRITE macro to internally call those. v2: no change v3: add intel_uncore_read/write functions (Chris), update commit msg Signed-off-by:
-
Daniele Ceraolo Spurio authored
Remove a bit of pointer dancing in the reg access path. Signed-off-by:
-
Daniele Ceraolo Spurio authored
Save the HW capabilities to avoid having to jump back to dev_priv every time. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
We have several cases where we don't have forcewake (older gens, GVT and planned display-only uncore), so, instead of checking every time against the various condition, save the info in a flag and use that. Note that this patch also change the behavior for gen5 with vpgu enabled, but this is not an issue since we don't support vgpu on gen5. v2: split out from previous path, fix check for missing case (Paulo) v3: Inline helper for clarity in testing flags Signed-off-by:
-
Daniele Ceraolo Spurio authored
They now work on uncore, so use raw_uncore_ prefix. Also move them to uncore.h Signed-off-by:
-
Lucas De Marchi authored
Now that pll_id is not used anymore for combophy, reduce its scope. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322223751.22089-6-lucas.demarchi@intel.comReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
Lucas De Marchi authored
By the time icl_ddi_clock_get() is called we've just got the hw state from the pll registers. We don't need to read them again: we can rather reuse what was cached in the dpll_hw_state. While at it, s/refclk/ref_clock/ just to be consistent with the name used in code nearby. Signed-off-by:
-
Lucas De Marchi authored
By the time cnl_ddi_clock_get() is called we've just got the hw state from the pll registers. We don't need to read them again: we can rather reuse what was cached in the dpll_hw_state. This also affects the code for ICL since it partially reuses the CNL code. However the more intricate part on ICL is left for another patch. Signed-off-by:
-
Lucas De Marchi authored
Rename state to pll_state and use it as the argument to bxt_calc_pll_link(), similar to how it's done in the skl variant. The WARN_ON(!crtc_state->shared_dpll) is not very useful, so remove it as well. Signed-off-by:
-
Lucas De Marchi authored
By the time skl_ddi_clock_get() is called - and thus skl_calc_wrpll_link() - we've just got the hw state from the pll registers. We don't need to read them again: we can rather reuse what was cached in the dpll_hw_state. v2: rename state variable to pll_state, make argument const in skl_calc_wrpll_link() and remove not useful warning (from Ville) Signed-off-by: -
Dan Carpenter authored
The live_context() function returns error pointers. It never returns NULL. Fixes: 9c1477e8 ("drm/i915/selftests: Exercise adding requests to a full GGTT") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
-
- 25 Mar, 2019 6 commits
-
-
Daniele Ceraolo Spurio authored
We're already updating the engine_mask to reflect what's in the HW, so we can just get the info from there. A couple of macros have been added to facilitate this. v2: Appease checkpatch Suggested-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Jani Nikula authored
Iterate over child devices instead of ports in parse_ddi_ports() to initialize ddi_port_info. We'll eventually need to decide some stuff based on the child device order, which may be different from the port order. As a bonus, this allows better abstractions for e.g. dvo port mapping. There's a subtle change in the DDC pin and AUX channel sanitization as we change the order. Otherwise, this should not change behaviour. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190322121008.4456-1-jani.nikula@intel.com
-
Chris Wilson authored
Fixup the errno as we adjusted the error path to receive the errno and not compute it itself from ERR_PTR(ctx) anymore. drivers/gpu/drm/i915/i915_gem_context.c:793 i915_gem_context_open() warn: passing a valid pointer to 'PTR_ERR' Reported-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190325090413.19906-2-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
The vblank timestamp->counter guesstimator seems to be working sufficiently well, so there's no reason not to disable vblank interrupts ASAP even on gen2. Signed-off-by:
-
Ville Syrjälä authored
The AGPBUSY thing doesn't work on i945gm anymore. This means the gmch is incapable of waking the CPU from C3 when an interrupt is generated. The interrupts just get postponed indefinitely until something wakes up the CPU. This is rather annoying for vblank interrupts as we are unable to maintain a steady framerate unless the machine is sufficiently loaded to stay out of C3. To combat this let's use pm_qos to prevent C3 whenever vblank interrupts are enabled. To maintain reasonable amount of powersaving we will attempt to limit this to C3 only while leaving C1 and C2 enabled. v2: Use READ_ONCE() (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=30364Signed-off-by:
-
Ville Syrjälä authored
If I'm reading the spec right AML 0x87CA is a Y SKU, so it should be marked as ULX in our old style terminology. Cc: stable@vger.kernel.org Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Fixes: c0c46ca4 ("drm/i915/aml: Add new Amber Lake PCI ID") Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
- 24 Mar, 2019 3 commits
-
-
Chris Wilson authored
Since commit b7137e0c ("drm/i915: Defer enabling rc6 til after we submit the first batch/context"), intel_suspend_gt_powersave() has been a no-op. As we still do not need to do anything explicitly on suspend (we do everything required on idling), remove the defunct function. References: b7137e0c ("drm/i915: Defer enabling rc6 til after we submit the first batch/context") Suggested-by:
"Hiatt, Don" <don.hiatt@intel.com> Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190323214009.23294-1-chris@chris-wilson.co.uk
-
Michal Wajdeczko authored
GuC may send notification messages with payload larger than single u32. Prepare driver to accept longer messages. Signed-off-by:
-
Zhenyu Wang authored
Initially found issue with closed context debug check when pin hw_id for GVT context, looks we should always pin hw_id for that as GVT context is fixed for each vGPU life cycle, and we'd also like to get pinned hw_id e.g for perf reason, etc. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by:
-
- 22 Mar, 2019 18 commits
-
-
Anusha Srivatsa authored
EHL uses the same firmware as ICL. Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Bob Paauwe <bob.j.paauwe@intel.com> Reviewed-by:
-
Bob Paauwe authored
EHL has a different number of subslices. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Bob Paauwe authored
Configure the correct set of outputs for EHL. EHL has three DDI's plus DSI. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Lucas De Marchi authored
Elkhart Lake has a different set of PLLs as compared to Ice Lake, although programming them is very similar. v2: Rebase on top of s/icl_pll_funcs/combo_pll_funcs Signed-off-by:
-
Bob Paauwe authored
Add ElkhartLake as a unique platform as there are some differences between it and Icelake. Signed-off-by:
-
James Ausmus authored
Add known EHL PCI IDs. v2 (Rodrigo): Removed x86 early quirk. To be sent in a separated patch cc'ing the appropriated list and maintainers for proper ack. v3: (Rodrigo): - Removed .num_pipes = 3 that is coming since GEN&_FEATURES. - Added ppgtt type and size after rework from Bob and Chris v4: (Rodrigo): - remove ppgtt type added on v3. Jose pointed it is not needed. Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:James Ausmus <james.ausmus@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Rename intel_find_panel_downclock() to intel_panel_edid_downclock_mode() to make it clear it's looking for the downclock mode in the EDID. And while at it polish the implementation a bit as well. Signed-off-by:
-
Ville Syrjälä authored
Utilize drm_mode_match() instead of hand rolling it when looking for the DRRS downclock mode. Signed-off-by:
-
Ville Syrjälä authored
DSI has its own convoluted way of grabbing the fixed mode from the VBT. Change it to follow the path laid out by LVDS/eDP. Signed-off-by:
-
Ville Syrjälä authored
LVDS and eDP have essentially the same code for grabbing the fixed mode from VBT. Pull that code to a common location. Signed-off-by:
-
Ville Syrjälä authored
Some monitors apparently forget to mark any mode as preferred in the EDID. In this particular case we have a very generic looking ID "PNP Model 0 Serial Number 4" / "LVDS 800x600" so a specific quirk doesn't seem particularly wise. Also the quirk we have (EDID_QUIRK_FIRST_DETAILED_PREFERRED) is actually defunct so we'd have to fix it first. When there is no preferred mode we currently fall back to the VBT. That approach fails us here as the VBT mode is 1024x768 whereas the panel resolution is 800x600. So instead of falling back to the VBT when there is no preferred mode let's just pick the first probed mode. Only if the EDID provided no modes we fall back to the VBT. For this machine the VBIOS would appear to select the 800x600 60Hz EST mode rather than the first detailed mode (which is the new fallback will pick). The two modes differ only by having opposite sync polarities, which does not seem to matter to the panel in question. v2: Make sure the probed_modes list is not empty Cc: Adam Jackson <ajax@redhat.com> Cc: Roberto Viola <cagnulein@gmail.com> Tested-by:
Roberto Viola <cagnulein@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109780Signed-off-by:
Adam Jackson <ajax@redhat.com> Acked-by:
-
Ville Syrjälä authored
Both LVDS and eDP have the same code to look up the preferred mode from the connector probed_modes list. Move the code to a common location. Signed-off-by:
-
Ville Syrjälä authored
I added the loop but neglected to actually pass the level to the function. So we were just looping 8 times calculating the exact same thing every time. Fixes: df331de3 ("drm/i915: Allocate enough DDB for the cursor") Signed-off-by:
-
Chris Wilson authored
Previously, our view has been always to run the engines independently within a context. (Multiple engines happened before we had contexts and timelines, so they always operated independently and that behaviour persisted into contexts.) However, at the user level the context often represents a single timeline (e.g. GL contexts) and userspace must ensure that the individual engines are serialised to present that ordering to the client (or forgot about this detail entirely and hope no one notices - a fair ploy if the client can only directly control one engine themselves ;) In the next patch, we will want to construct a set of engines that operate as one, that have a single timeline interwoven between them, to present a single virtual engine to the user. (They submit to the virtual engine, then we decide which engine to execute on based.) To that end, we want to be able to create contexts which have a single timeline (fence context) shared between all engines, rather than multiple timelines. v2: Move the specialised timeline ordering to its own function. Signed-off-by:
-
Chris Wilson authored
It can be useful to have a single ioctl to create a context with all the initial parameters instead of a series of create + setparam + setparam ioctls. This extension to create context allows any of the parameters to be passed in as a linked list to be applied to the newly constructed context. v2: Make a local copy of user setparam (Tvrtko) v3: Use flags to detect availability of extension interface Signed-off-by:
-
Chris Wilson authored
In preparation to making the ppGTT binding for a context explicit (to facilitate reusing the same ppGTT between different contexts), allow the user to create and destroy named ppGTT. v2: Replace global barrier for swapping over the ppgtt and tlbs with a local context barrier (Tvrtko) v3: serialise with struct_mutex; it's lazy but required dammit v4: Rewrite igt_ctx_shared_exec to be more different (aimed to be more similarly, turned out different!) v5: Fix up test unwind for aliasing-ppgtt (snb) v6: Tighten language for uapi struct drm_i915_gem_vm_control. v7: Patch the context image for runtime ppgtt switching! Testcase: igt/gem_vm_create Testcase: igt/gem_ctx_param/vm Testcase: igt/gem_ctx_clone/vm Testcase: igt/gem_ctx_shared Signed-off-by:
-
Chris Wilson authored
An idea for extending uABI inspired by Vulkan's extension chains. Instead of expanding the data struct for each ioctl every time we need to add a new feature, define an extension chain instead. As we add optional interfaces to control the ioctl, we define a new extension struct that can be linked into the ioctl data only when required by the user. The key advantage being able to ignore large control structs for optional interfaces/extensions, while being able to process them in a consistent manner. In comparison to other extensible ioctls, the key difference is the use of a linked chain of extension structs vs an array of tagged pointers. For example, struct drm_amdgpu_cs_chunk { __u32 chunk_id; __u32 length_dw; __u64 chunk_data; }; struct drm_amdgpu_cs_in { __u32 ctx_id; __u32 bo_list_handle; __u32 num_chunks; __u32 _pad; __u64 chunks; }; allows userspace to pass in array of pointers to extension structs, but must therefore keep constructing that array along side the command stream. In dynamic situations like that, a linked list is preferred and does not similar from extra cache line misses as the extension structs themselves must still be loaded separate to the chunks array. v2: Apply the tail call optimisation directly to nip the worry of stack overflow in the bud. v3: Defend against recursion. v4: Fixup local types to match new uabi Opens: - do we include the result as an out-field in each chain? struct i915_user_extension { __u64 next_extension; __u64 name; __s32 result; __u32 mbz; /* reserved for future use */ }; * Undecided, so provision some room for future expansion. Signed-off-by: -
Sujaritha Sundaresan authored
Adding a call to intel_uc_suspend in i915_gem_suspend, which is a common point for the suspend/resume and hibernate paths. This fixes an unbalanced call that causes issues with the CTB register/deregister. v2: Making the call unconditional (Daniele) Moving the call to after the GEM_BUG_ON (Chris) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Sujaritha Sundaresan <sujaritha.sundaresan@intel.com> Reviewed-by:
-
