- 28 Oct, 2022 1 commit
-
-
Ville Syrjälä authored
We try to filter out the corresponding xxx1 output if the xxx0 output is not present. But the way that is being done is pretty awkward. Make it less so. Cc: stable@vger.kernel.org Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221026101134.20865-2-ville.syrjala@linux.intel.comReviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
- 27 Oct, 2022 15 commits
-
-
Ville Syrjälä authored
Pull the SDVO audio state computation into a helper. This is almost identical to intel_hdmi_has_audio(), except the sink capabilities are stored under intel_sdvo rather than intel_hdmi. Might be nice to get rid of this duplication eventually... Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
The spec tells us to do a bunch of vblank waits in the audio enable/disable sequences. Make it so. The FIXMEs are nonsense since we do the audio disable very early and enable very late, so vblank interrupts are in fact enabled when we do this. TODO not sure we actually want these since we don't even rely on the hw ELD buffer, and these might be there just to give the audio side a bit of time to respond to the unsol events. OTOH they might be really needed for some other reason. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Acked-by:
-
Ville Syrjälä authored
On the older platforms the audio presence detect bit is in the port register, so it gets written outside audio codec hooks and is this separate from the ELD valid toggling. Split the operations into two steps on hsw+ to be more consistent with both the other platforms and the spec. Also according to the spec we might need some vblank waits between the two which definitely needs them done separately. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
The audio code does a lot of RMW accesses. Utilize intel_de_rmw() to make that a bit less tedious. There are still some hand rolled RMW left, but those have a lot of code in between the read and write to calculate the new value, so would need some refactoring first. v2: Add parens around the ?: to satisfy the robot Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Make the eld pointer u32* so we don't have to do super ugly casting in the code itself. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Currently we only write as many dwords into the hardware ELD buffers as drm_eld_size() tells us. That could mean the remainder of the hardware buffer is left with whatever stale garbage it had before, which doesn't seem entirely great. Let's zero out the remainder of the buffer in case the provided ELD doesn't fill it fully. We can also sanity check out idea of the hardware ELD buffer's size by making sure the address wrapped back to zero once we wrote the entire buffer. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
We currently read the ELD buffer size from hardware on g4x, but on ilk+ we just hardcode it to 84 bytes. Let's unify this and just do the hardware readout on all platforms, in case the size changes in the future or something. TODO: should perhaps do the readout during driver init and stash the results somewhere so that we could check that the connector's ELD actually fits and not even try to enable audio in that case... v2: Document the size is in dwords (Jani) Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
No idea why we do this ELD comparions on g4x before loading the new ELD. Seems entirely pointless so just get rid of it. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
On the "ilk" platforms AUD_CNTL_ST2 is a singleton. Protect it with the audio mutex in case we ever want to do parallel RMW access to it. Currently that should not happen since we only do audio enable/disable from full modesets, and those are fully serialized. But we probably want to think about toggling audio on/off from fastsets too. The hsw codepaths already have the same locking. g4x should not need it since it can only do audio to a single port at a time, which means it's actually broken in more ways than this atm. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Rename a few g4x bits to match the ibx+ bits. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Switch the audio registers to REG_BIT() & co. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
The "ilk" audio codec codepaths have some duplicated code to figure out the correct registers to use on each platform. Extrat that into a single place. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
We don't use the audio code on crestline (CL) since it doesn't support native HDMI output, and SDVO has it's own way of doing audio. And Bearlake-C (BLC) doesn't even exist in the real world, so no point it trying to deal with it. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Remove some leftovers I missed in commit 2dd43144 ("drm/i915: Streamline the artihmetic") Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Rename the 'dev_priv' variables to 'i915' in the audio code to match modern style conventions. v2: Drop some needless braces in intel_audio_hooks_init() Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Kai Vehmanen <kai.vehmanen@linux.intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
- 26 Oct, 2022 8 commits
-
-
Anusha Srivatsa authored
No functional change. Introduce dg2_cdclk_squash_program and move squash_ctl register programming bits to this. v2: s/dg2_cdclk_squash_programming/dg2_cdclk_squash_program (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221025223042.138810-4-anusha.srivatsa@intel.com
-
Anusha Srivatsa authored
No functional change. Moving segments out to simplify bxt_set_cdlck() v2: s/bxt_cdclk_pll/bxt_cdclk_pll_update (Jani) Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Anusha Srivatsa authored
Driver had discrepancy in how cdclk squash and crawl support were checked. Like crawl, add squash as a 1 bit feature flag to the display section of DG2. Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Anusha Srivatsa authored
No functional changes. Changing terminology in some print statements. s/has_cdclk_squasher/has_cdclk_squash, s/crawler/crawl and s/squasher/squash. Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
Not all Dekel PHY registers have a lane instance, so having to specify this when using them is awkward. It makes more sense to define each PHY register with its full internal PHY offset where bits 15:12 is the lane for lane-instanced PHY registers and just a register bank index for other PHY registers. This way lane-instanced registers can be referred to with the (tc_port, lane) parameters, while other registers just with a tc_port parameter. An additional benefit of this change is to prevent passing a Dekel register to a generic MMIO access function or vice versa. v2: - Fix parameter reuse in the DKL_REG_MMIO definition. v3: - Rebase on latest patchset version. Cc: Jani Nikula <jani.nikula@intel.com> Acked-by:
Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221025114457.2191004-3-imre.deak@intel.com
-
Imre Deak authored
Move the TypeC DKL PHY register definitions to intel_dkl_phy_regs.h. No functional changes. v2: - Move the definitions to a new intel_dkl_phy_regs.h file. (Jani). v3: - Rebase on latest patchset version. Cc: Jani Nikula <jani.nikula@intel.com> Acked-by:
-
Imre Deak authored
An upcoming patch moves the DKL PHY register definitions to intel_dkl_phy_regs.h, so for consistency rename intel_tc_phy_regs.h containing only MG PHY register definitions to intel_mg_phy_regs.h. Suggested-by:
-
Imre Deak authored
Accessing the TypeC DKL PHY registers during modeset-commit, -verification, DP link-retraining and AUX power well toggling is racy due to these code paths being concurrent and the PHY register bank selection register (HIP_INDEX_REG) being shared between PHY instances (aka TC ports) and the bank selection being not atomic wrt. the actual PHY register access. Add the required locking around each PHY register bank selection-> register access sequence. Kudos to Ville for noticing the race conditions. v2: - Add the DKL PHY register accessors to intel_dkl_phy.[ch]. (Jani) - Make the DKL_REG_TC_PORT macro independent of PHY internals. - Move initing the DKL PHY lock to a more logical place. v3: - Fix parameter reuse in the DKL_REG_TC_PORT definition. - Document the usage of phy_lock. v4: - Fix adding TC_PORT_1 offset in the DKL_REG_TC_PORT definition. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v5.5+ Acked-by:
-
- 25 Oct, 2022 5 commits
-
-
Ville Syrjälä authored
Make glk_load_luts() a bit lighter for the common case where neither the degamma LUT nor pipe CSC are enabled by not loading the linear degamma LUT. Making .load_luts() as lightweight as possible is a good idea since it may need to execute from a vblank worker under tight deadlines. My earlier reasoning for always loading the linear degamma LUT was to avoid an extra LUT load when just enabling/disabling the pipe CSC, but that is nonsense since we load the LUTs on every flagged color management change/modeset anyway (either of which is needed for a pipe CSC toggle). We can also get rid of the glk_can_preload_luts() special case since the presence of the degamma LUT will now always match csc_enable. v2: Fix typos (Uma) Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Since we now have a place (pre_csc_lut) to stuff a purely internal LUT we can replace glk_load_degamma_lut_linear() with such a thing and just rely on the normal glk_load_degamma_lut() to load it as well. drm_mode_config_cleanup() will clean this up for us. v2: Pass on the error pointer Drop a hint about this into the state dump Reviewed-by: -
Ville Syrjälä authored
Since we now have the extra step from hw.(de)gamma_lut into {pre,post}_csc_lut let's make sure we didn't forget to assign them appropriately. Ie. basically making sure intel_color_check() was called when necessary (and that it did its job suitable well). Reviewed-by: -
Ville Syrjälä authored
Add an extra remapping step between the logical state of the LUTs (hw.(de)gamma_lut) as specified via uapi/bigjoiner copy vs. the actual state of the LUTs programmed into the hardware. With this we should be finally able finish the (de)gamma readout/state checker support for the remaining platforms (ilk-skl) where the same hardware LUT can be positioned either before or after the pipe CSC unit. Where we position it depends on factors such as presence of the logical degamma LUT, RGB vs. YCbCr output, full vs. limited RGB quantization range. Without the extra remapping step the state readout doesn't really know whether the LUT read from the hardware is the degamma or gamma LUT, and so we is unable to accurately store it into our crtc state. With the remapping step we know exactly where to put it given the order of the LUT vs. CSC in the hardware state. Only the initial hw->uapi state readout done during driver load/resume still has the problem of not really knowing what to do with the LUT(s). But we can just assume 1:1 mapping there and let subsequent commits fix things up. Another benefit is that we now have a place for purely internal LUTs, without complicating the bigjoiner uapi->hw copy logic. This should prove useful for streamlining glk degamma LUT handling. Reviewed-by:
-
Ville Syrjälä authored
Make ilk_load_luts() ready for a degamma lut. Currently we never have one, but soon we may get one from readout, and I think we may want to change the state computation such that we may end up with one even when userspace has simply supplied a gamma lut. At least the code now follows the path laid out by the ivb/bdw counterpars. Reviewed-by:
-
- 22 Oct, 2022 5 commits
-
-
Ville Syrjälä authored
Add a common helper to answer the question "do we need to update color management stuff?". Reviewed-by:
-
Ville Syrjälä authored
Be consistent in whether we flag a full modeset or a fastset for the pipe. intel_modeset_all_pipes() would seem to be the only codepath not getting this right. The other case is when we flag the fastset initially, currently we just clear the mode_changed flag and set the update_pipe flag. But we could still have connectors_changed==true or active_changed==true forcing a full modeset anyway. So check for that after clearing the mode_changed flag. And let's add a WARN to make sure we did get it right. v2: Deal with {connectors,active}_changed Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by: -
Ville Syrjälä authored
These 'mode_changed' booleans aren't very helpful. Just replace them with direct intel_crtc_needs_modeset() calls which is more descriptive. Reviewed-by:
-
Ville Syrjälä authored
Replace the somewhat obscure crtc_state.update_pipe checks with a more descriptive thing. Also nicely matches the intel_crtc_needs_modeset() counterpart for full modesets. v2: Handle one more case in the fbc code Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Signed-off-by:
-
Ville Syrjälä authored
On BDW+ we have just the one set of DP M/N registers. The values we write into said registers depends on whether we want DRRS to be in high or low gear. This causes issues for the state checker which currently has to assume either set of M/N (high or low refresh rate) values may appear there. That sort of works for M/N itself, but all other values derived from the M/N (dotclock, pixel rate) are not handled correctly, leading to potential for state checker mismatches. Let's avoid all those problems by simply keeping DRRS in high gear until the state checker has done its hardware state readout. Note that hitting this issue presumable became very hard after commit 1b333c67 ("drm/i915: Do DRRS disable/enable during pre/post_plane_update()") since the state check would have to laze about for one full second (delay used by intel_drrs_schedule_work()) to see the low refresh rate. But it is still theoretically possible. Signed-off-by:
-
- 21 Oct, 2022 2 commits
-
-
Ville Syrjälä authored
Apparently some panels declare multiple modes with random sync polarities. Seems a bit weird, but looks like Windows/GOP doesn't care, so let follow suit and accept alternate fixed modes regardless of their sync polarities. v2: Don't pollute the DRM_ namespace with a define (Jani) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6968Acked-by:
-
Suraj Kandpal authored
Remove one use macro for_each_connector_on_encoder which is only being used at intel_encoder_find_connector. Signed-off-by:
Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by:
Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by:
-
- 20 Oct, 2022 2 commits
-
-
Ankit Nautiyal authored
Remove extraline left after intel_dp_configure_protocol_converter. Signed-off-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
-
Ankit Nautiyal authored
For cases where DP has HDMI2.1 sink and FRL Link issues are detected, reset the flag to state FRL trained status before restarting FRL training. Fixes: 9488a030 ("drm/i915: Add support for enabling link status and recovery") Cc: Swati Sharma <swati2.sharma@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> (v2) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 19 Oct, 2022 1 commit
-
-
Nirmoy Das authored
Print returned error code for better debuggability. References: https://gitlab.freedesktop.org/drm/intel/-/issues/7211Signed-off-by:
Nirmoy Das <nirmoy.das@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014154655.14075-1-nirmoy.das@intel.com
-
- 18 Oct, 2022 1 commit
-
-
Anshuman Gupta authored
DGFX platforms has lmem and cpu can access the lmem objects via mmap and i915 internal i915_gem_object_pin_map() for i915 own usages. Both of these methods has pre-requisite requirement to keep GFX PCI endpoint in D0 for a supported iomem transaction over PCI link. (Refer PCIe specs 5.3.1.4.1) Both DG1/DG2 have a known hardware bug that violates the PCIe specs and support the iomem read write transaction over PCIe bus despite endpoint is D3 state. Due to above H/W bug, we had never observed any issue with i915 runtime PM versus lmem access. But this issue becomes visible when PCIe gfx endpoint's upstream bridge enters to D3, at this point any lmem read/write access will be returned as unsupported request. But again this issue is not observed on every platform because it has been observed on few host machines DG1/DG2 endpoint's upstream bridge does not bind with pcieport driver. which really disables the PCIe power savings and leaves the bridge at D0 state. We need a unique interface to read/write from lmem with runtime PM wakeref protection something similar to intel_uncore_{read, write}, keep autosuspend control to 'on' on all discrete platforms, until we have a unique interface to read/write from lmem. This just change the default autosuspend setting of i915 on dGPU, user can still change it to 'auto'. v2: - Modified the commit message and subject with more information. - Changed the Fixes tag to LMEM support commit. [Joonas] - Changed !HAS_LMEM() Cond to !IS_DGFX(). [Rodrigo] Fixes: b908be54 ("drm/i915: support creating LMEM objects") Suggested-by:Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221014113258.1284226-1-anshuman.gupta@intel.com
-
