- 07 Jun, 2019 14 commits
-
-
Ville Syrjälä authored
The "audio enable" bit on the SDVO/HDMI control register is only meant for HDMI. Audio is never delivered over the SDVO bus. Rename the define to reflect this fact. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190409144054.24561-4-ville.syrjala@linux.intel.comReviewed-by:
Chris Wilson <chris@chris-wilson.co.uk>
-
Ville Syrjälä authored
Our SDVO audio support is pretty bogus. We can't push audio over the SDVO bus, so trying to enable audio in the SDVO control register doesn't do anything. In fact it looks like the SDVO encoder will always mix in the audio coming over HDA, and there's no (at least documented) way to disable that from our side. So HDMI audio does work currently on gen4 but only by luck really. On gen3 it got broken by the referenced commit. And what has always been missing on every platform is the ELD. To pass the ELD to the audio driver we need to write it to magic buffer in the SDVO encoder hardware which then gets pulled out via HDA in the other end. Ie. pretty much the same thing we had for native HDMI before we started to just pass the ELD between the drivers. This sort of explains why we even have that silly hardware buffer with native HDMI. $ cat /proc/asound/card0/eld#1.0 -monitor_present 0 -eld_valid 0 +monitor_present 1 +eld_valid 1 +monitor_name LG TV +connection_type HDMI +... This also fixes our state readout since we can now query the SDVO encoder about the state of the "ELD valid" and "presence detect" bits. As mentioned those don't actually control whether audio gets sent over the HDMI cable, but it's the best we can do. And with the state checker appeased we can re-enable HDMI audio for gen3. Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: zardam@gmail.com Tested-by: zardam@gmail.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108976 Fixes: de44e256 ("drm/i915/sdvo: Shut up state checker with hdmi cards on gen3") Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
The AVI infoframe readout code currently issues a SDVO_CMD_GET_HBUF_TXRATE before SDVO_CMD_SET_HBUF_INDEX, which is not the correct order for these two operations. So far this wasn't a problem since we left the index pointing at the AVI infoframe buffer at the end of the modeset. However once we start to write to other buffers (namely ELD) that is no longer going to be true. Fix up the order so that we always read out the TX rate for the correct buffer. Signed-off-by:
-
Ville Syrjälä authored
We forgot to set .has_alpha=true for the A+CCS formats when the code started to consult .has_alpha. This manifests as A+CCS being treated as X+CCS which means no per-pixel alpha blending. Fix the format list appropriately. Cc: stable@vger.kernel.org Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Heinrich Fink <heinrich.fink@daqri.com> Reported-by:
Heinrich Fink <heinrich.fink@daqri.com> Tested-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Ville Syrjälä authored
intel_dp_link_down() is static and it's only called from the pre-ddi DP functions, so having a WARN_ON(HAS_DDI) in there is quite pointless. Remove it. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com>
-
Ville Syrjälä authored
It's a bit silly to go through intel_dp.c to assign the prepare_link_train vfunc for ddi platforms when we can just assign it directly from intel_ddi.c. Signed-off-by:
-
Tvrtko Ursulin authored
Get to uncore from the engine for better logic organization and use already available i915 everywhere. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Suggested-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Tvrtko Ursulin authored
Remove a couple dev_priv locals as a consequence. Signed-off-by:
-
Tvrtko Ursulin authored
These two are only used from within i915_gem_gtt.c and can trivially be made static. Signed-off-by:
-
Tvrtko Ursulin authored
Just tidying the flow a bit. Signed-off-by:
-
Tvrtko Ursulin authored
Similar to earlier conversions, eliminate the implicit dev_priv by introducing some helpers which take the engine parameter (since the register itself is per engine). v2: * Always use parentheses in macro arguments. Signed-off-by:
-
Tvrtko Ursulin authored
We can use intel_engine_mask_t to align with the rest of the codebase. Signed-off-by:
-
Tvrtko Ursulin authored
Pass down the engine mask to i915_clear_error_registers so only affected engines can be reset on the Gen6/7 path. Signed-off-by:
-
Lucas De Marchi authored
While loading the DMC firmware we were double checking the headers made sense, but in no place we checked that we were actually reading memory we were supposed to. This could be wrong in case the firmware file is truncated or malformed. Before this patch: # ls -l /lib/firmware/i915/icl_dmc_ver1_07.bin -rw-r--r-- 1 root root 25716 Feb 1 12:26 icl_dmc_ver1_07.bin # truncate -s 25700 /lib/firmware/i915/icl_dmc_ver1_07.bin # modprobe i915 # dmesg| grep -i dmc [drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin [drm] Finished loading DMC firmware i915/icl_dmc_ver1_07.bin (v1.7) i.e. it loads random data. Now it fails like below: [drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin [drm:csr_load_work_fn [i915]] *ERROR* Truncated DMC firmware, rejecting. i915 0000:00:02.0: Failed to load DMC firmware i915/icl_dmc_ver1_07.bin. Disabling runtime power management. i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915 Before reading any part of the firmware file, validate the input first. Fixes: eb805623 ("drm/i915/skl: Add support to load SKL CSR firmware.") Cc: stable@vger.kernel.org Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
- 06 Jun, 2019 5 commits
-
-
Chris Wilson authored
On i915_gem_load_power_context() we do care whether or not we succeed in completing the switch back to the kernel context (via idling the engines). Currently, we detect if an error occurs while we wait, but we do not report one if it occurred beforehand (and the status of the switch is undefined). Check the current terminally wedged status on entering the wait, and report it after flushing the requests, as if it had occurred during our own wait. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110824Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190531113245.30042-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
The intent was to skip unused HW contexts by checking ce->state. However, this only works for execlists where the ppGTT pointers is stored inside the HW context. For gen7, the ppGTT is alongside the logical state and must be updated on all active engines but, crucially, only on active engines. As we need different checks, and to keep context_barrier_task() agnostic, pass in the predicate. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110836 Fixes: 62c8e423 ("drm/i915: Skip unused contexts for context_barrier_task()") Signed-off-by:
-
Chris Wilson authored
Use i915_gem_object_lock() to guard the LUT and active reference to allow us to break free of struct_mutex for handling GEM_CLOSE. Testcase: igt/gem_close_race Testcase: igt/gem_exec_parallel Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190606112320.9704-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Just a straightforward bag of fixes for a clean htmldocs build. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190605095657.23601-2-jani.nikula@intel.com
-
Jani Nikula authored
The error messages could be more descriptive, but fix these caused by file moves: WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/i915_gem_shrinker.c' failed with return code 2 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function User command execution ./drivers/gpu/drm/i915/i915_gem_execbuffer.c' failed with return code 1 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/i915_gem_tiling.c' failed with return code 2 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function buffer object tiling ./drivers/gpu/drm/i915/i915_gem_tiling.c' failed with return code 1 Fixes: 10be98a7 ("drm/i915: Move more GEM objects under gem/") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
-
- 05 Jun, 2019 18 commits
-
-
Matt Roper authored
Unlike ICL, EHL's combo PHYs can support HBR3 data rates. Note that this just extends the upper limit; we will continue to honor the max data rate specified in the VBT in cases where it is lower than HBR3. Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190605211832.23945-1-matthew.d.roper@intel.comReviewed-by:
-
Hans de Goede authored
Prior to this commit we fail to init the DSI panel on the GPD MicroPC: https://www.indiegogo.com/projects/gpd-micropc-6-inch-handheld-industry-laptop#/ The problem is intel_dsi_vbt_init() failing with the following error: *ERROR* Burst mode freq is less than computed The pclk in the VBT panel modeline is 70000, together with 24 bpp and 4 lines this results in a bitrate value of 70000 * 24 / 4 = 420000. But the target_burst_mode_freq in the VBT is 418000. This commit works around this problem by adding an intel_fuzzy_clock_check when target_burst_mode_freq < bitrate and setting target_burst_mode_freq to bitrate when that checks succeeds, fixing the panel not working. Cc: stable@vger.kernel.org Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190524174028.21659-2-hdegoede@redhat.com
-
Jani Nikula authored
Better grouping, better semantics for find_section(). No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Add new fields in the LFP block. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
New bit to look in another BDB block for more. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Make it easier to find the right blocks. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Use the comments verbatim from the spec to help find the right block. No functional changes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Don't use bdb_ prefixes for structs within blocks. Add a new bdb struct for SDVO panel DTDs for completeness. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
We've carried this baggage for more than a decade. Time to let it go. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Change the order, add some stylistic touches, and add LSPCON. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Avoid iterating the child devices. This should be a non-functional change, but theoretically this might enable LSPCON on some extra ports with buggy VBTs. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Avoid iterating the child devices. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Add separate functions to get the port by DDC pin and AUX channel. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
This allows us to avoid iterating the child devices in some cases. Also replace the presence bit with child device being non-NULL, and set the child device pointer last to allow us to take advantage of it in follow-up work. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Make the child device order the priority order in sanitizing DDC pin and AUX CH. First come, first served. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Swati Sharma authored
In this patch, intel_color_get_config() is enabled and support for read_luts() will be added platform by platform incrementally in the follow-up patches. v4: -Renamed intel_get_color_config to intel_color_get_config [Jani] -Added the user early on such that support for get_color_config() can be added platform by platform incrementally [Jani] v5: -Incorrect place for calling intel_color_get_config() in haswell_get_pipe_config() [Ville] v6: -Renamed intel_color_read_luts() to intel_color_get_config() [Jani and Ville] Signed-off-by:Swati Sharma <swati2.sharma@intel.com> Signed-off-by:
-
Swati Sharma authored
In this patch, a vfunc read_luts() is introduced to create a hw lut i.e. lut having values read from gamma/degamma registers which will later be used to compare with sw lut to validate gamma/degamma lut values. v3: -Rebase v4: -Renamed intel_get_color_config to intel_color_get_config [Jani] -Wrapped get_color_config() [Jani] v5: -Renamed intel_color_get_config() to intel_color_read_luts() -Renamed get_color_config to read_luts v6: -Renamed intel_color_read_luts() back to intel_color_get_config() [Jani and Ville] Signed-off-by: -
Mauro Carvalho Chehab authored
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Hardware workarounds ./drivers/gpu/drm/i915/intel_workarounds.c' failed with return code 1 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function Logical Rings, Logical Ring Contexts and Execlists ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 1 WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal ./drivers/gpu/drm/i915/intel_lrc.c' failed with return code 2 Fixes: 112ed2d3 ("drm/i915: Move GraphicsTechnology files under gt/") Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
- 04 Jun, 2019 3 commits
-
-
Chris Wilson authored
Instead of relying on the caller holding struct_mutex across the allocation, push the allocation under a tree of spinlocks stored inside the page tables. Not only should this allow us to avoid struct_mutex here, but it will allow multiple users to lock independent ranges for concurrent allocations, and operate independently. This is vital for pushing the GTT manipulation into a background thread where dependency on struct_mutex is verboten, and for allowing other callers to avoid struct_mutex altogether. v2: Restore lost GEM_BUG_ON for removing too many PTE from gen6_ppgtt_clear_range. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190604153830.19096-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
As the GTT is outside of the powerwell, we can simplify flushing the GGTT writes by using an unchecked mmio write and post. v2: s/unc/uncore/ Signed-off-by:
-
Chris Wilson authored
As the fence registers are not part of the engine powerwells, we do not need to fiddle with forcewake in order to update a fence. Avoid using the heavyweight debug checking normal mmio writes as the checking dominates the selftest runtime and is superfluous! In the process, retire the I915_WRITE() implicit macro with the new intel_uncore_write interface. v2: s/unc/uncore/ Signed-off-by:
-
