An error occurred fetching the project authors.
- 04 Jun, 2019 2 commits
-
-
Ville Syrjälä authored
Pass around intel_atomic_state rather than drm_atomic_state. This avoids some extra casts and annoing aliasing variables. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190517193132.8140-3-ville.syrjala@linux.intel.comReviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
Pass around intel_atomic_state rather than drm_atomic_state. This avoids some extra casts and annoing aliasing variables. Signed-off-by:
-
- 29 May, 2019 1 commit
-
-
Chris Wilson authored
Before we start prepping the system for an atomic modeset, wake the device up. We then keep track of this wakeref until we complete the atomic commit, so we hold keep the device awake for all potential HW access, and do not allow the device to sleep with a pending modeset. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110771Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
-
- 28 May, 2019 4 commits
-
-
Ville Syrjälä authored
When the first C8 plane gets enabled, or the last one gets disabled we may need to enable/disable the pipe gamma for the other active planes. Check for that and run through the normal intel_color_check() path. Signed-off-by:
-
Chris Wilson authored
Use the per-object local lock to control the cache domain of the individual GEM objects, not struct_mutex. This is a huge leap forward for us in terms of object-level synchronisation; execbuffers are coordinated using the ww_mutex and pread/pwrite is finally fully serialised again. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528092956.14910-10-chris@chris-wilson.co.uk
-
Chris Wilson authored
Continuing the theme of separating out the GEM clutter. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190528092956.14910-8-chris@chris-wilson.co.uk
-
Uma Shankar authored
Added state readout for DRM infoframe and enabled state validation for DRM infoframe. v2: Addressed Ville's review comments and dropped the unused drm infoframe read at intel_hdmi_init. v3: Removed a redundant platform check as per Ville's comment. Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
- 27 May, 2019 1 commit
-
-
Ville Syrjälä authored
ICL has so many planes that it can easily exceed the maximum effective memory bandwidth of the system. We must therefore check that we don't exceed that limit. The algorithm is very magic number heavy and lacks sufficient explanation for now. We also have no sane way to query the memory clock and timings, so we must rely on a combination of raw readout from the memory controller and hardcoded assumptions. The memory controller values obviously change as the system jumps between the different SAGV points, so we try to stabilize it first by disabling SAGV for the duration of the readout. The utilized bandwidth is tracked via a device wide atomic private object. That is actually not robust because we can't afford to enforce strict global ordering between the pipes. Thus I think I'll need to change this to simply chop up the available bandwidth between all the active pipes. Each pipe can then do whatever it wants as long as it doesn't exceed its budget. That scheme will also require that we assume that any number of planes could be active at any time. TODO: make it robust and deal with all the open questions v2: Sleep longer after disabling SAGV v3: Poll for the dclk to get raised (seen it take 250ms!) If the system has 2133MT/s memory then we pointlessly wait one full second :( v4: Use the new pcode interface to get the qgv points rather that using hardcoded numbers v5: Move the pcode stuff into intel_bw.c (Matt) s/intel_sagv_info/intel_qgv_info/ Do the NV12/P010 as per spec for now (Matt) s/IS_ICELAKE/IS_GEN11/ v6: Ignore bandwidth limits if the pcode query fails Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Acked-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190524153614.32410-1-ville.syrjala@linux.intel.com
-
- 20 May, 2019 7 commits
-
-
Ville Syrjälä authored
With gtt remapping in place we can use arbitrarily large framebuffers. Let's bump the limits to 16kx16k on gen7+. The limit was chosen to match the maximum 2D surface size of the 3D engine. With the remapping we could easily go higher than that for the display engine. However the modesetting ddx will blindly assume it can handle whatever is reported via kms. The oversized buffer dimensions are not caught by glamor nor Mesa until finally an assert will trip when genxml attempts to pack the SURFACE_STATE. So we pick a safe limit to avoid the X server from crashing (or potentially misbehaving if the genxml asserts are compiled out). Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110187Signed-off-by:
-
Ville Syrjälä authored
With gtt remapping plugged in we can simply raise the stride limit on gen4+. Let's just pick the limit to match the render engine max stride (256KiB on gen7+, 128KiB on gen4+). No remapping CCS because the virtual address of each page actually matters due to the new hash mode (WaCompressedResourceDisplayNewHashMode:skl,kbl etc.), and no remapping on gen2/3 due extra complications from fence alignment and gen2 2KiB GTT tile size. Also no real benefit since the display engine limits already match the other limits. v2: Rebase due to is_ccs_modifier() v3: Tweak the comment and commit msg v4: Fix gen4+ stride limit to be 128KiB Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> #v3 Signed-off-by:
-
Ville Syrjälä authored
Align dumb buffer stride to 4k if the fb will be big enough to require gtt remapping. v2: Leave the stride alone for buffers that look to be for the cursor v3: Make it not a hack (Daniel) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
The display engine stride limits are getting in our way. On SKL+ we are limited to 8k pixels, which is easily exceeded with three 4k displays. To overcome this limitation we can remap the pages in the GTT to provide the display engine with a view of memory with a smaller stride. The code is mostly already there as We already play tricks with the plane surface address and x/y offsets. A few caveats apply: * linear buffers need the fb stride to be page aligned, as otherwise the remapped lines wouldn't start at the same spot * compressed buffers can't be remapped due to the new ccs hash mode causing the virtual address of the pages to affect the interpretation of the compressed data. IIRC the old hash was limited to the low 12 bits so if we were using that mode we could remap. As it stands we just refuse to remapp with compressed fbs. * no remapping gen2/3 as we'd need a fence for the remapped vma, which we currently don't have. Need to deal with the fence POT requirements, and do something about the gen2 gtt page size vs tile size difference v2: Rebase due to is_ccs_modifier() Fix up the skl+ stride_mult mess memset() the gtt_view because otherwise we could leave junk in plane[1] when going from 2 plane to 1 plane format v3: intel_check_plane_stride() was split out v4: Drop the aligned viewport stuff, it was meant for ccs which can't be remapped anyway v5: Introduce intel_plane_can_remap() Reorder the code so that plane_state->view gets filled even for invisible planes, otherwise we'd keep using stale values and could explode during remapping. The new logic never remaps invisible planes since we don't have a viewport, and instead pins the full fb instead v6: Fix plane src coord checks after remapping by moving plane_state->base.src to the final plane x/y offsets. Allow intel_plane_check_stride() to fail even with remapping (can happen at least with a linear 64bpp fb with a 4k plane and a suitably inconvenient src coordinates). Improve aux plane FIXME (Daniel) Move some code shuffling into a separate patch (Daniel) Testcase: igt/kms_big_fb Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: -
Ville Syrjälä authored
Reorganize some fb stride checking code a bit to prepare for gtt remapping. And do a bit of s/pitch/stride/ renaming in the process for a bit more uniformity (apart from the whole fb->pitches[] thing). Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
Add a live selftest to excercise rotated/remapped vmas. We simply write through the rotated/remapped vma, and confirm that the data appears in the right page when read through the normal vma. Not sure what the fallout of making all rotated/remapped vmas mappable/fenceable would be, hence I just hacked it in the test. v2: Grab rpm reference (Chris) GEM_BUG_ON(view.type not as expected) (Chris) Allow CAN_FENCE for rotated/remapped vmas (Chris) Update intel_plane_uses_fence() to ask for a fence only for normal vmas on gen4+ v3: Deal with intel_wakeref_t v4: Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: -
Ville Syrjälä authored
To overcome display engine stride limits we'll want to remap the pages in the GTT. To that end we need a new gtt_view type which is just like the "rotated" type except not rotated. v2: Use intel_remapped_plane_info base type s/unused/unused_mbz/ (Chris) Separate BUILD_BUG_ON()s (Chris) Use I915_GTT_PAGE_SIZE (Chris) v3: Use i915_gem_object_get_dma_address() (Chris) Trim the sg (Tvrtko) v4: Actually trim this time. Limit the max length to one row of pages to keep things simple Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Reviewed-by:
-
- 14 May, 2019 3 commits
-
-
Imre Deak authored
There isn't a separate power domain specific to PLLs. When programming them we require the same power domain to be enabled which is needed when accessing other display core parts (not specific to any pipe/port/transcoder). This corresponds to the DISPLAY_CORE domain added previously in this patchset, so use that instead to save bits in the power domain mask. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Vandita Kulkarni authored
Move bdw_get_pipemisc_bpp alongside bdw_set_pipemisc Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1556809862-31203-2-git-send-email-vandita.kulkarni@intel.com
-
Vandita Kulkarni authored
Adjust the get transcoder timings for mipi dsi as per the set timing calculations. v2: Use the existing intel_get_pipe_timings and do the dsi specific adjustments in the encoder get_config hook.(Ville, Jani) v3: Exclude VBLANK and HBLANK registers for dsi transcoder. v4: Fix the incomplete conditional logic. Signed-off-by:
-
- 13 May, 2019 1 commit
-
-
Ville Syrjälä authored
On HSW the pipe A panel fitter lives inside the display power well, and the input MUX for the EDP transcoder needs to be configured appropriately to route the data through the power well as needed. Changing the MUX setting is not allowed while the pipe is active, so we need to force a full modeset whenever we need to change it. Currently we may end up doing a fastset which won't change the MUX settings, but it will drop the power well reference, and that kills the pipe. Cc: stable@vger.kernel.org Cc: Hans de Goede <hdegoede@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: d19f958d ("drm/i915: Enable fastset for non-boot modesets.") Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
- 09 May, 2019 2 commits
-
-
Ville Syrjälä authored
Convert the HSW pch_pfit.force_thru to a proper state variable with readout and accompanying pipe conf check. Makes the logic a bit more straightforward, and hopefully prevents some breakage in the future. 'force_thru' is probably not the best name for this, but I didn't manage to come up with anything better either, so I left it alone. Signed-off-by:
-
Ville Syrjälä authored
On HSW the pipe A panel fitter lives inside the display power well, and the input MUX for the EDP transcoder needs to be configured appropriately to route the data through the power well as needed. Changing the MUX setting is not allowed while the pipe is active, so we need to force a full modeset whenever we need to change it. Currently we may end up doing a fastset which won't change the MUX settings, but it will drop the power well reference, and that kills the pipe. Cc: stable@vger.kernel.org Cc: Hans de Goede <hdegoede@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Fixes: d19f958d ("drm/i915: Enable fastset for non-boot modesets.") Signed-off-by:
-
- 06 May, 2019 1 commit
-
-
Ville Syrjälä authored
hsw_enable_pc8()/hsw_disable_pc8() are more less equivalent to the display core init/unit functions of later platforms. Relocate the hsw/bdw code into intel_runtime_pm.c so that it sits next to its cousins. Signed-off-by:
-
- 03 May, 2019 7 commits
-
-
Ville Syrjälä authored
We have a lot of '(u64)foo * bar' everywhere. Replace with mul_u32_u32() to avoid gcc failing to use a regular 32x32->64 multiply for this. Signed-off-by:
-
Ville Syrjälä authored
Turns out the cursor is compatible with the pipe "HDR mode". It's only the actual SDR planes that get entirely bypassed during blending. So let's ignore the cursor when checking if we have any planes active that aren't HDR compatible. This fixes the regressions in the kms_cursor_crc and kms_plane_cursor tests. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110579 Fixes: 09b25812 ("drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used") Signed-off-by:
-
Ville Syrjälä authored
I fumbled the PIPEMISC write into the wrong place. It only gets called for fastsets, but since value needs to be updated based on the set of active planes it needs to be done for all plane updates. Move it to the correct spot. The symptoms include SDR planes never showing up if a previous modeset/fastset left the pipe in HDR mode. This was immediately obvious when running the kms_plane pixel format tests. Unfortunately the test didn't realize it was scanning out pure black all the time and declared success anyway. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Fixes: 09b25812 ("drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used") Signed-off-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. While at it, rename intel_i2c.c to intel_gmbus.c and the functions to intel_gmbus_*. No functional changes. Reviewed-by:
-
Jani Nikula authored
Reduce clutter from i915_drv.h. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
Reduce clutter from intel_drv.h with the minimal change. Reviewed-by:
-
- 30 Apr, 2019 8 commits
-
-
Ville Syrjälä authored
The pipe has a special HDR mode with higher precision when only HDR planes are active. Let's use it. Curiously this fixes the kms_color gamma/degamma tests when using a HDR plane, which is always the case unless one hacks the test to use an SDR plane. If one does hack the test to use an SDR plane it does pass already. I have no actual explanation how the output after the gamma LUT can be different between the two modes. The way the tests are written should mean that the output should be identical between the solid color vs. the gradient. But clearly that somehow doesn't hold true for the HDR planes in non-HDR pipe mode. Anyways, as long as we stick to one type of plane the test should produce sensible results now. v2: s/HDR_MODE/HDR_MODE_PRECISION/ (Shashank) Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com>
-
Ville Syrjälä authored
Move the platform checks out from haswell_set_pipemisc() and rename it to bdw_set_pipemisc() to make it clear when to call it. Signed-off-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: fix sparse warnings on undeclared global functions Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. v2: fix sparse warnings on undeclared global functions Reviewed-by:
-
Jani Nikula authored
It used to be handy that we only had a couple of headers, but over time intel_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by:
-
- 26 Apr, 2019 3 commits
-
-
Chris Wilson authored
Split the sideback declarations out of the ginormous i915_drv.h Signed-off-by:
-
Chris Wilson authored
We now have two locks for sideband access. The general one covering sideband access across all generation, sb_lock, and a specific one covering sideband access via the punit on vlv/chv. After lifting the sb_lock around the punit into the callers, the pcu_lock is now redudant and can be separated from its other use to regulate RPS (essentially giving RPS a lock all of its own). v2: Extract a couple of minor bug fixes. Signed-off-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190426081725.31217-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
Lift the sideband acquisition for vlv_punit_read and vlv_punit_write into their callers, so that we can lock the sideband once for a sequence of operations, rather than perform the heavyweight acquisition on each request. Signed-off-by:
-
