- 25 Jan, 2019 5 commits
-
-
Lucas De Marchi authored
Instead of considering we have defined entries for any index in the table, let's keep track of the ones we explicitly defined. This will allow Gen 11 to have it's new table defined in which we have holes of undefined entries. Repeated comments about the meaning of undefined entries were removed since they are overly verbose and copy-pasted in several functions: now the definition is in the top only. v2: add helper function to get the index (from Chris) Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190124000604.18861-6-lucas.demarchi@intel.com
-
Lucas De Marchi authored
Let's use a macro to make tables smaller and at the same time allow us to add fields that apply to all entries in future. v2: rewrap lines to respect 80 chars limit and make it more readable (from Chris) Signed-off-by:Tomasz Lis <tomasz.lis@intel.com> Reviewed-by:
-
Tomasz Lis authored
The MOCS tables are going to be very similar across platforms. To reduce the amount of copied code, this patch rips the common part and puts it into a definition valid for all gen9 platforms. v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE to MOCS_ENTRIES. (Joonas) v3 (Lucas): - Fix indentation - Rebase on rework done by additional patch - Remove define for or-ing flags as it made the table more complex by requiring zeroed values to be passed - Do not embed comma in the macro, so to treat that just as another item and please source code formatting tools Signed-off-by: -
Lucas De Marchi authored
Make the defines for LE and L3 caching options to contain the shifts and remove the zeros from the tables as shifting zeros always result in zero. Starting from Ice Lake the MOCS table is defined in the spec and contains all entries. So to simplify checking the table with the values set in code, the value is now part of the macro name. This allows to still give the most used option and sensible name, but also to easily cross check the table from the spec for gen >= 11. By removing the zeros we avoid maintaining a huge table since the one from spec contains many more entries. The new table for Ice Lake will be added by other patches, this only reformats the table. While at it also fix the indentation. Signed-off-by:
-
Lucas De Marchi authored
Instead of initializing them to uncached, let's set them to PTE for kernel tracking. While at it do some minor adjustments to comments and coding style. From Chris: "What it does mean is that the buffer contents are consistent with our cache tracking; and for userspace the results were always undefined. So we should at least be able to guarantee that the data written by userspace from the CPU is visible. After that, your caches are on your own". Signed-off-by:
-
- 24 Jan, 2019 16 commits
-
-
Rodrigo Vivi authored
Signed-off-by:Rodrigo Vivi <vivijim@rdvivi-cozumel.jf.intel.com>
-
https://github.com/intel/gvt-linuxRodrigo Vivi authored
gvt-next-2019-01-24 - split kvmgt as seperate module (Zhenyu) - Coffeelake GVT support (Fred) - const treatment and change for kernel type (Jani) Signed-off-by:
-
Maarten Lankhorst authored
This way we don't accidentally double allocate it. Noticed this when I wrote a patch to sanity check all of the scaler state. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108160842.13396-4-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
Now that our state comparison functions are pretty complete, we should enable fastset by default when a modeset can be avoided. Even if we're not completely certain about the inherited state, we can be certain after the first modeset that our sw state matches the hw state. There is one testcase explicitly testing fastset, kms_panel_fitting.atomic-fastset but other testcases do so indirectly because most tests don't clean up the display during exit, or otherwise indirectly preserve mode by doing igt_display_reset or inheriting during init. Signed-off-by:
-
Maarten Lankhorst authored
On lynxpoint the bios sometimes sets up the backlight using the CPU display, but the driver expects using the PWM PCH override register. Read the value from the CPU register, then convert it to the other units by converting from the old duty cycle, to freq, to the new units. This value is then programmed in the override register, after which we set the override and disable the CPU display control. This allows us to switch the source without flickering, and make the backlight controls work in the driver. Changes since v1: - Read BLC_PWM_CPU_CTL2 to cpu_ctl2. - Clean up cpu_mode if slightly. - Always disable BLM_PWM_ENABLE in cpu_ctl2. Changes since v2: - Simplify cpu_mode handling (Jani) Signed-off-by:
Tolga Cakir <cevelnet@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190108160842.13396-2-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
Restore our saved values for backlight. This way even with fastset on S4 resume we will correctly restore the backlight to the active values. Changes since v1: - Call enable_backlight() when backlight.level is set. On suspend backlight.enabled is always cleared, this makes it not a good indicator. Also check for crtc->state->active. Changes since v2: - Use the new update_pipe() callback to run this on resume as well. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Nip some inline spaghetti in the bud before the problem gets too bad. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190124083710.7033-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
The VBT int_crt_support can't be trusted on earlier platforms, and is always set to true in intel_bios.c for pre-DDI and pre-VLV platforms. We can simplify the output setup by unconditionally calling intel_crt_init() for these platforms. Suggested-by:
-
Jani Nikula authored
Gen 2 mobile and not I830 is, in fact, I85X. Simplify. Suggested-by:
-
Jani Nikula authored
Clarify that the name is specific to ILK+ PCH platforms. v2: prefix the name with ilk rather than pch (Ville) Reviewed-by:
-
Jani Nikula authored
With most platforms not having TV support, only call intel_tv_init() on platforms that might actually have TV, specifically gens 3 and 4. This puts intel_tv_init() more in line with the rest of the outputs, and makes it slightly easier for the uninitiated to figure out which platforms actually have what. Reviewed-by:
-
Jani Nikula authored
Now that intel_lvds_init() is only called for platforms that might have LVDS, move the remaining checks to intel_setup_outputs(), again similar to other outputs, and remove the overlapping checks. Reviewed-by:
-
Jani Nikula authored
With new platforms not having LVDS support, only call intel_lvds_init() on platforms that might actually have LVDS. Move the comment about eDP init to the PCH block where it's relevant. This puts intel_lvds_init() more in line with the rest of the outputs, and makes it slightly easier for the uninitiated to figure out which platforms actually have what. Reviewed-by:
-
Jani Nikula authored
With new platforms not having CRT support and most conditions in intel_crt_present() being specific to DDI, split out the CRT initialization to platform specific blocks in the if ladder. Add new Pineview block for this. This puts intel_crt_init() more in line with the rest of the outputs, and makes it slightly easier for the uninitiated to figure out which platforms actually have what. v2: keep gen >= 9 check in intel_ddi_crt_present() (Ville) Reviewed-by:
-
Matt Roper authored
We currently program userspace-provided gamma and degamma LUT's into our hardware without really checking to see whether they satisfy our hardware's rules. We should try to catch tables that are invalid for our hardware early and reject the atomic transaction. All of our platforms that accept a degamma LUT expect that the entries in the LUT are always flat or increasing, never decreasing. Also, our GLK and ICL platforms only accept degamma tables with r=g=b entries; so we should also add the relevant checks for that in anticipation of degamma support landing for those platforms. v2: - Use new API (single check function with bitmask of tests to apply) - Call helper for our gamma table as well (with no additional tests specified) so that the table size will be validated. v3: - Don't call on the gamma table since the LUT size is already tested at property blob upload and we don't have any additional hardware constraints for that LUT. v4: - Apply equal color channel check on gen10 as well; the bspec has some strange tagging for CNL platforms, but this appears to apply there as well. (Ville) Cc: Uma Shankar <uma.shankar@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20181218175158.5739-1-matthew.d.roper@intel.com
-
Matt Roper authored
Some hardware may place additional restrictions on the gamma/degamma curves described by our LUT properties. E.g., that a gamma curve never decreases or that the red/green/blue channels of a LUT's entries must be equal. Let's add a helper function that drivers can use to test that a userspace-provided LUT is valid and doesn't violate hardware requirements. v2: - Combine into a single helper that just takes a bitmask of the tests to apply. (Brian Starkey) - Add additional check (always performed) that LUT property blob size is always a multiple of the LUT entry size. (stolen from ARM driver) v3: - Drop the LUT size check again since drm_atomic_replace_property_blob_from_id() already covers this for us. (Alexandru Gheorghe) v4: - Use an enum to describe possible test values rather than #define's; this is cleaner to provide kerneldoc for. (Daniel Vetter) - s/DRM_COLOR_LUT_INCREASING/DRM_COLOR_LUT_NON_DECREASING/. (Ville) Cc: Uma Shankar <uma.shankar@intel.com> Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Brian Starkey <Brian.Starkey@arm.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Brian Starkey <brian.starkey@arm.com> Reviewed-by:
Alexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20181217224415.12848-1-matthew.d.roper@intel.com
-
- 23 Jan, 2019 9 commits
-
-
Chris Wilson authored
Record the priority boost we giving to the preempted client or else we may end up in a situation where the priority queue no longer matches the request priority order and so we can end up in an infinite loop of preempting the same pair of requests. Fixes: e9eaf82d ("drm/i915: Priority boost for waiting clients") Signed-off-by:
-
Rodrigo Vivi authored
We just got aware that there was more IDs available at spec, so let's add them already. Cc: James Ausmus <james.ausmus@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Daniele Ceraolo Spurio authored
When reading GEN11_GT_INTR_DWx closely after enabling the interrupts in gen11_irq_postinstall, the returned value is garbage. This can cause other parts of the setup code (e.g. gen11_reset_one_iir) to think that there are interrupts to be cleared when there are none. The garbage value is only seen on the first read done after the enable, so this looks like a posting issue. Adding a posting read after enabling the interrupts does indeed fix the problem. Note that the posting read has been purposely added outside of gen11_master_intr_enable since the issue has only been observed when the full interrupt setup is performed. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Acked-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' v2: rebase Acked-by:
-
Jani Nikula authored
Mixed C99 and kernel types use is getting ugly. Prefer kernel types. sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g' Acked-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
José Roberto de Souza authored
The value of this registers will be used to test if PSR2 is doing selective update and if the number of blocks match with the expected. v2: - Using new macros - Changed the string output v3: - reading PSR2_SU_STATUS registers together(Dhinakaran) - printing SU blocks of frames with 0 updates(Dhinakaran) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
José Roberto de Souza authored
This register contains how many blocks was sent in the past selective updates. Those registers are not kept set all the times but polling it after flip can show the values corresponding to the last 8 frames. v2: Improved macros(Dhinakaran) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
José Roberto de Souza authored
The old debugfs fields was not following a naming partern and it was a bit confusing. So it went from: ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status Sink_Support: yes PSR mode: PSR1 Enabled: yes Busy frontbuffer bits: 0x000 Main link in standby mode: no HW Enabled & Active bit: yes Source PSR status: 0x24050006 [SRDONACK] To: ~$ sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status Sink support: yes [0x03] PSR mode: PSR1 enabled Source PSR ctl: enabled [0x81f00e26] Source PSR status: IDLE [0x04010006] Busy frontbuffer bits: 0x00000000 The 'Main link in standby mode' was removed as it is not useful but if needed by someone the information is still in the register value of 'Source PSR ctl' inside of the brackets, PSR mode and Enabled was squashed into PSR mode, some renames and reorders and we have this cleaner version. This will also make easy to parse debugfs for IGT tests. v2: Printing sink PSR version with only 2 hex digits as it is a byte Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Suggested-by:
-
José Roberto de Souza authored
For now PSR2 is still disabled by default for all platforms but is our intention to let debugfs to enable it for debug and tests proporses, so intel_psr2_enabled() that is also used by debugfs to decide if PSR2 is going to be enabled needs to take in consideration the debug field. v2: Using the switch/case that intel_psr2_enabled() already had to handle this(DK) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
- 22 Jan, 2019 8 commits
-
-
Rodrigo Vivi authored
We need avi infoframe stuff who got merged via drm-misc Signed-off-by: -
Chris Wilson authored
This turns out to be quite useful if one happens to be debugging semaphore deadlocks. Signed-off-by:
-
Chris Wilson authored
A repeated pattern is to test the signaled bit of our request->fence.flags. Make this an inline to shorten a few lines and remove unnecessary line continuations. Signed-off-by:
-
Chris Wilson authored
Prior to adding a third instance of intel_context_init() and extending the information stored therewithin, refactor out the common assignments. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
-
Chris Wilson authored
Replace the open-coding of advance with a call instead. Signed-off-by:
-
Chris Wilson authored
Before adding yet another copy of struct live_test and its handler, refactor the existing code into a common framework for live selftests. For many live selftests, we want to know if the GPU hung or otherwise misbehaved during the execution of the test (beyond any infraction in the behaviour under test), live_test provides this by comparing the GPU state before and after, alerting if it unexpectedly changed (e.g. the reset counter changed). It also ensures that the GPU is idle before and after the test, so that residual code running on the GPU is flushed before testing. Signed-off-by:
-
Chris Wilson authored
Some tests (e.g. igt_vma_pin1) presume that we have a completely clean GGTT so that it can probe boundaries without fear that something is already allocated there. However, the mock device is starting to get complicated and following similar rules to the live device, i.e. we can't guarantee that i915->ggtt remains clean, so create a temporary address_space equivalent to the mock ggtt for the purpose. Signed-off-by:
-
Chris Wilson authored
During review of commit 71fc448c ("drm/i915/selftests: Make evict tolerant of foreign objects"), Matthew mentioned it would be better if we explicitly tracked the objects we created. We have an obj->st_link hook for this purpose, so add the corresponding list of objects and reduce our loops to only consider our own list. References: 71fc448c ("drm/i915/selftests: Make evict tolerant of foreign objects") Signed-off-by:
-
- 21 Jan, 2019 2 commits
-
-
Hans de Goede authored
The display engine has 2 dithering enable bits which both need to be set for dithering to happen, 1 in the PIPECONF register which is taken care of by i9xx_set_pipeconf() and a second bit at the encoder level. The dsi code was not setting the encoder level dithering enable bit causing dithering to be disabled, this commit fixes this. Signed-off-by:
-
Hans de Goede authored
There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc pixel-formats which this commit addresses: 1) It assumes that the pipe_bpp is the same as the bpp going over the dsi lanes. This assumption is not valid for MIPI_DSI_FMT_RGB666, where pipe_bpp should be 18 so that we do proper dithering but we actually send 24 bpp over the dsi lanes (MIPI_DSI_FMT_RGB666_PACKED sends 18 bpp). This assumption is enforced by an assert in *_dsi_get_pclk(). This assert triggers on the initial hw-state readback on BYT/CHT devices which use MIPI_DSI_FMT_RGB666, such as the Prowise PT301 tablet. PIPECONF is set to 6BPC / 18 bpp by the GOP, while mipi_dsi_pixel_format_to_bpp() returns 24. This commits switches the calculations in *_dsi_get_pclk() to use the bpp from mipi_dsi_pixel_format_to_bpp(intel_dsi->pixel_format) which returns the bpp going over the mipi lanes and drops the assert. 2) On BXT bxt_dsi_get_pipe_config() wrongly overrides the pipe_bpp which i9xx_get_pipe_config() reads from PIPECONF with the return value from mipi_dsi_pixel_format_to_bpp(). This avoids the assert from 1. but is wrong since the pipe is actually running at the value configured in PIPECONF. This commit drops the override of pipe_bpp from bxt_dsi_get_pipe_config(). 3) The dsi encoder's compute_config() never assigns a value to pipe_bpp, unlike most other encoders. Falling back on compute_baseline_pipe_bpp() which always picks 24. 24 is only correct for MIPI_DSI_FMT_RGB88 for the others we should use 18 bpp so that we correctly do 6bpc color dithering. This commit adds code to intel_dsi_compute_config() to properly set pipe_bpp based on intel_dsi->pixel_format. Signed-off-by:
-
