- 08 Dec, 2022 7 commits
-
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Andrzej Hajda <andrzej.hajda@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/262a0cf647b37e27a1c7776d3816e1b4ef959a91.1670433372.git.jani.nikula@intel.com
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Avoid direct uncore use in display code. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
There's no need to save the register offsets. Drop the variables. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
A similar thing was added in intel_uncore_rmw(). Make it available for display too. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Add more de helpers to be able to avoid direct calls to uncore. v3 by Jani: - drop intel_de_write_samevalue/intel_de_rewrite_fw altogether v2 by Jani: - drop pcode stuff for now - rename intel_de_write_samevalue -> intel_de_rewrite_fw Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
- 07 Dec, 2022 7 commits
-
-
Jani Nikula authored
Fix the final straggler. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/4769f8377be11536bd19840a2e59ef9f8c0a558c.1670405587.git.jani.nikula@intel.com
-
Jani Nikula authored
Prefer only having struct drm_i915_private *i915 around. Drop the drm_device *dev locals. Signed-off-by:
-
Jani Nikula authored
With the implicit dev_priv usage gone, we can rename dev_priv to i915 throughout. Do some drive-by whitespace cleanups while at it. Signed-off-by:
-
Jani Nikula authored
None of the remaining backlight registers that use DISPLAY_MMIO_BASE() are used on VLV/CHV, which are the only platforms that have non-zero base. Just drop the DISPLAY_MMIO_BASE() use, reducing the implicit dev_priv references. Signed-off-by:
-
Jani Nikula authored
Since the VLV/CHV backlight registers are only used on VLV/CHV, there's no need to dynamically look up DISPLAY_MMIO_BASE(). We know it's VLV_DISPLAY_BASE. Use it statically, reducing the implicit dev_priv references. Signed-off-by:
-
Miaoqian Lin authored
intel_uncore_forcewake_put__locked() is used to release a reference. Fixes: a6111f7b ("drm/i915: Reduce locking in execlist command submission") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
-
Jani Nikula authored
The locking should not be needed after commits de5bd083 ("drm/i915/fbc: Skip nuke when flip is pending") and 7cfd1a18 ("drm/i915: Remove remaining locks from i9xx plane udpates"). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221205122918.3092092-1-jani.nikula@intel.com
-
- 30 Nov, 2022 3 commits
-
-
Taylor, Clinton A authored
Replace integrated with discrete for dgfx platforms. v2: commit title reword (Jani) v3: use variable name i915 (Jani) v4: commit message reword (MattR) Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Taylor, Clinton A <clinton.a.taylor@intel.com> Signed-off-by:
-
Gustavo Sousa authored
Release notes: 1. Fixes for Register noclaims and few restore. Fixes: c4cf059d ("drm/i915/dmc: Update DG2 DMC firmware to v2.07") Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by:
-
Swati Sharma authored
Use HAS_DSC(__i915) wrapper containing runtime info of has_dsc member. Platforms supporting dsc has this flag enabled; no need of DISPLAY_VER() check. Also, simplified intel_dsc_source_support() based on above changes. Suggested-by:
Swati Sharma <swati2.sharma@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221110093312.13932-1-swati2.sharma@intel.com
-
- 29 Nov, 2022 2 commits
-
-
Mikko Kovanen authored
intel_dsi->ports contains bitmask of enabled ports and correspondingly logic for selecting port for VBT packet sending must use port specific bitmask when deciding appropriate port. Fixes: 08c59dde ("drm/i915/dsi: fix VBT send packet port selection for ICL+") Cc: stable@vger.kernel.org Signed-off-by:
Mikko Kovanen <mikko.kovanen@aavamobile.com> Reviewed-by:
-
Xia Fukun authored
When (size != 0 || ptrs->lvds_ entries != 3), the program tries to free() the ptrs. However, the ptrs is not created by calling kzmalloc(), but is obtained by pointer offset operation. This may lead to memory leaks or undefined behavior. Fix this by replacing the arguments of kfree() with ptrs_block. Fixes: a87d0a84 ("drm/i915/bios: Generate LFP data table pointers if the VBT lacks them") Signed-off-by:
Xia Fukun <xiafukun@huawei.com> Signed-off-by:
-
- 23 Nov, 2022 11 commits
-
-
Ville Syrjälä authored
Currently it's not 100% obvious which DVO encoder chip was found on which port. Leave a slightly better trace in log. Signed-off-by:
-
Ville Syrjälä authored
Pull the DVO port register definitons into their own header to declutter i915_reg.h a bit. Signed-off-by:
-
Ville Syrjälä authored
Replace the hand rolled RMW with intel_de_rmw() in the DVO port enable/disable functions. Also switch to intel_de_posting_read() for the posting read (though maybe it should be just be nuked...). Signed-off-by:
-
Ville Syrjälä authored
Polish the DVO port registers with REG_BIT()/etc. Signed-off-by:
-
Ville Syrjälä authored
We have two sets of bits for DVO "data order" stuff. Rename one set to ACT_DATA_ORDER to make it clear they are separate bitfields. Signed-off-by:
-
Ville Syrjälä authored
Define a few extra interrupt related bits on the DVO register. One of these we included in the DVO_PRESERVE_MASK already. Signed-off-by:
-
Ville Syrjälä authored
Get rid of the dvo_reg/dvo_srcdim_reg stuff by parametrizing the DVO port registers. Signed-off-by:
-
Ville Syrjälä authored
Poke a few more bits into the SiI164 to make it recover after S3. HEN/VEN are the important bits, the rest PLL filter/HPD detection I just did for good measure to match the BIOS programming. Note that the spec recommended SCNT bit in REGC isn't set by the BIOS at least for me, so I left it out. Signed-off-by:
-
Ville Syrjälä authored
Drop the pointless return statements at the end of void functions. Signed-off-by:
-
Ville Syrjälä authored
Poke a few more bits into the ch7xxx to make it output a picture after being reset during S3. In particular we need to set the input buffer select (IBS), and enable VGA vsync output on the BCO pin. Selecting VGA hsync on the c/h sync pin doesn't actually seem necessary on my ADD card at least, but the BIOS selects it so why not. Signed-off-by:
-
Jani Nikula authored
If phy is PHY_NONE, the shift to register bits becomes negative. Check and warn about this. Reported-by:
coverity-bot <keescook@chromium.org> References: https://lore.kernel.org/r/202211180848.D39006C@keescookSigned-off-by:
-
- 22 Nov, 2022 10 commits
-
-
Ville Syrjälä authored
Some gen2/gen3 parts have a 10bit gamma mode, on some pipes. Expose it. The format is different to the later i965+ style in that we store a 10bit value and a 6 bit floating point slope for each entry. Ie. the hardware extrapolates the intermediate steps from the current LUT entry, instead of interpolating between the current and next LUT entries. This also means we don't store the last LUT entry in any register as it is defined by the previous LUT entry's value+slope. The slope has limited precision though (2 bit exponent + 4 bit mantissa), so we'd have to allow for more error in the state checker for the last entry and we have to make sure userspace doesn't pass in something where the slope is simply to steep. In theory we should perhaps check the slope for every interval, but we don't do that for any other interpolated gamma mode and I suspect they may also have some internal limit on the slope. I haven't confirmed that theory though. Anyways, for ease of implementation we shall just ignore the last entry in the state checker. If all the other entries match anyway then that seems like a good indication that the hardware was programmed as expected. v2: Redo the state checker logic a bit Rebase due to other changes v3: Fix C8 readout v4: Use REG_FIELD_PREP() Acked-by: -
Ville Syrjälä authored
On hsw+ and glk class hardware we current make a mess of things when we have to both generate limited range output and use the hw gamma LUT. Since we do the range compression using the pipe CSC unit (which is situated before the gamma LUT in the pipe) we are in fact applying the gamma to the limited range data instead of the full range data as the user intended. We can work around this by applying the range compression via the gamma LUT instead of using the pipe CSC for it. Fairly easy to do now that we have the internal post_csc_lut attachment point where we can stick our new cooked LUT. On hsw+ this only needs to be done when using the split gamma mode or when the ctm is enabled since otherwise we can simply reorder the LUT vs. CSC. On glk we need to do this any time a gamma LUT is used since no reordering is possible. We do lose a bit of coverage in intel_color_assert_luts(), but so be it. Signed-off-by:
-
Ville Syrjälä authored
On glk we can no longer reorder the hw LUTS vs. pipe CSC like we could on earlier platforms, and neither do we have a separate output CSC like on icl+. That means if we use the pipe CSC for YCbCr output we are currently applying the gamma LUT after the RGB->YCbCr conversion, which is just wrong. The further we go from a linear curve the more distorted the resulting colors become. To work around this terrible limitation the best we can do is repurpose the hw degamma LUT as a poor man's gamma LUT. Now that we have the internal pre_csc_lut attachment point that is not particularly hard to do. What makes this less than ideal however is the fact that the hw degamma LUT and gamma LUTs have very different capabilities. The gamma LUT can operate in direct color type modes, whereas the degamma LUT can't and just always operates in interpolated mode. Additionally the degamma LUT is just a single 1D LUT, whereas the gamma LUT is made of three separate 1D LUts (one for each channel). So in order to make this semi-sensible we must also verify the user supplied LUT more less matches the hw degamma LUT capabilities. We still end up losing most of the LUT entries though, so the results might be a bit crap. The other option of flat out rejecting the YCbCr+gamma LUT combo seems extremely likely to just cause a black screen for the user. Eg. pretty sure Xorg always applies some kind of gamma LUT, and if the user then plugs in a display that needs YCbCr output we're toast. Signed-off-by:
-
Ville Syrjälä authored
Currently crtc_state_is_legacy_gamma() has a very specific set of conditions, not all of which are actually necessary. Also when we detect those conditions check_luts() just skips all the checks. That will no longer work for glk soon when we'll start to use the hw degamma LUT in place of the hw gamma LUT for YCbCr output. So let's rework the logic to only really consider whether the user provided gamma_lut is one that matches the hw legacy LUT capabilities or not. We'll need to reject C8+degamma on ivb+ since the presence of degamma_lut would either mean we have to really use the LUT for degamma as opposed to C8 palette, or we have to enable split gamma mode which also can't work as the C8 palette. Otherwise this will now cause the legacy LUT to go through the regular lut checks as well. As a side effect we also start to allow the use of the legacy LUT with CTM, but that is perfectly fine as far a the hardware is concerned. Signed-off-by:
-
Ville Syrjälä authored
We have full readout now for all platforms (sans the icl+ multi-segment readout hw fail), so hook up the LUT state checker for everyone. We add a new vfunc for this since different platforms need to handle the details a bit differently. The implementation is rather repetitive in places. Probably we want to think of a more declarative approach for the LUT precision/etc. stuff in the future... Note that we're currently missing readout for c8_planes, so we'll have to skip the state check in that case. v2: Fix readout for C8 use cases v3: Skip C8 entirely due to lack of c8_planes readout Add ilk_has_pre_csc_lut() helper and use other such helpers Signed-off-by: -
Ville Syrjälä authored
Every platform now implements .read_luts(). Make it mandatory. Signed-off-by:
-
Ville Syrjälä authored
Add the approproate c8_planes checks to make the LUT code ready for C8 palette readout. Note we currently lack the actual c8_planes readout, so this won't work yet. But no harm in making the code somewhat more ready for the day when we do get c8_planes readout. Signed-off-by:
-
Ville Syrjälä authored
Just like ivb+, ilk/snb can select whether the hw lut acts as gamma or degamma. Make the readout cognizant of that fact. v2: deal with pre_csc_lut v3: use ilk_has_post_csc_lut() helper Reviewed-by:
-
Ville Syrjälä authored
We now have all the code necessary for gamma/degamma readout on ivb/hsw. Plug it all in. As with bdw+ the cooked {pre,post}_csc_lut make this trivial even in split gamma mode. Note that on HSW if IPS is enabled the hardware will hang if you try to access the LUT in split gamma mode. Thus we need to reorder the LUT readout vs. IPS enable steps. v2: deal with {pre,post}_csc_lut split gamma is no longer a problem handle HSW IPS w/a v3: use ilk_has_post_csc_lut() helper Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by: -
Ville Syrjälä authored
Read out the gamma/degamma LUT on bdw+. Now that the {pre,post}_csc_lut match the hardware LUT size even in split gamma mode this is trivial. v2: deal with {pre,post}_csc_lut split gamma is no longer a problem v3: add ilk_has_post_csc_lut() helper Reviewed-by: Uma Shankar <uma.shankar@intel.com> #v1 Signed-off-by:
-
