- 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:
Jani Nikula <jani.nikula@intel.com> Signed-off-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ä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221122120825.26338-11-ville.syrjala@linux.intel.comReviewed-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 17 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:Uma Shankar <uma.shankar@intel.com> Signed-off-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: -
Ville Syrjälä authored
Since CHV has the dedicate CGM degamma unit readout is trivial. Just do it. v2: deal with post_csc_lut Reviewed-by:
-
Ville Syrjälä authored
Read out the degamma LUT on glk+. No state cheker as of yet since it requires dealing with the glk csc vs. degamma mess. v2: deal with post_csc_lut v3: add icl_has_{pre,post}_csc_lut(*) helpers Reviewed-by: -
Ville Syrjälä authored
Rename a the LUT state check foo_gamma_precision() functions to foo_post_csc_lut_precision() to make it more clear what they really do. Signed-off-by:
-
Ville Syrjälä authored
The degamma LUT is interpolated so we need the 128th (==1.0) entry to represent the full < 1.0 input range. Only the 129th and 130th entries are strictly for the >=1.0 extended range inputs. Signed-off-by:
-
Ville Syrjälä authored
bigjoiner_pipes() doesn't consider that: - RKL only has three pipes - some pipes may be fused off This means that intel_atomic_check_bigjoiner() won't reject all configurations that would need a non-existent pipe. Instead we just keep on rolling witout actually having reserved the slave pipe we need. It's possible that we don't outright explode anywhere due to this since eg. for_each_intel_crtc_in_pipe_mask() will only walk the crtcs we've registered even though the passed in pipe_mask asks for more of them. But clearly the thing won't do what is expected of it when the required pipes are not present. Fix the problem by consulting the device info pipe_mask already in bigjoiner_pipes(). Cc: stable@vger.kernel.org Signed-off-by:
Arun R Murthy <arun.r.murthy@intel.com>
-
Vinod Govindapillai authored
Enable the SDP split configuration for DP2.0. v2: Move the register handling out of compute config function (JaniN) v3: Patch styling and register access based on platform support (JaniN) v4: Rebased v5: Use unconditional clear bit in intel_de_rmw (Jani Nikula) Bspec: 67768 Signed-off-by:
Vinod Govindapillai <vinod.govindapillai@intel.com> Reviewed-by:
-
Anusha Srivatsa authored
MTL supports both squash and crawl. Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221118190008.824412-1-anusha.srivatsa@intel.com
-
- 21 Nov, 2022 3 commits
-
-
Anusha Srivatsa authored
As per bSpec MTL has 38.4 MHz Reference clock. Adding the cdclk tables and cdclk_funcs that MTL will use. v2: Revert to using bxt_get_cdclk() BSpec: 65243 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221117230002.792096-3-anusha.srivatsa@intel.com
-
Ville Syrjälä authored
For MTL, changing cdclk from between certain frequencies has both squash and crawl. Use the current cdclk config and the new(desired) cdclk config to construct a mid cdclk config. Set the cdclk twice: - Current cdclk -> mid cdclk - mid cdclk -> desired cdclk Driver should not take some Pcode mailbox communication in the cdclk path for platforms that are Display version 14 and later. v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via modeset for platforms that support squash_crawl sequences(Ville) v3: Add checks for: - scenario where only slow clock is used and cdclk is actually 0 (bringing up display). - PLLs are on before looking up the waveform. - Squash and crawl capability checks.(Ville) v4: Rebase - Move checks to be more consistent (Ville) - Add comments (Bala) v5: - Further small changes. Move checks around. - Make if-else better looking (Ville) v6: MTl should not follow PUnit mailbox communication as the rest of gen11+ platforms.(Anusha) Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221117230002.792096-2-anusha.srivatsa@intel.com
-
Anusha Srivatsa authored
cdclk_sanitize() function was written assuming vco was a signed integer. vco gets assigned to -1 (essentially ~0) for the case where PLL might be enabled and vco is not a frequency that will ever get used. In such a scenario the right thing to do is disable the PLL and re-enable it again with a valid frequency. However the vco is declared as a unsigned variable. With the above assumption, driver takes crawl path when not needed. Add explicit check to not crawl in the case of an invalid PLL. v2: Move the check from .h to .c (MattR) - Move check to bxt_set_cdclk() instead of intel_modeset_calc_cdclk() which is directly in the path of the sanitize() function (Ville) v3: remove unwanted parenthesis(Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Suggested-by:
-
- 19 Nov, 2022 7 commits
-
-
Ville Syrjälä authored
Convert the lonely DRM_DEBUG_KMS() to the per-device variant. Signed-off-by:
-
Ville Syrjälä authored
Follow the modern style and rename most 'dev_priv' variables to 'i915'. intel_dvo_init_dev() is the sole exception since it needs the magic 'dev_priv' variable for the DPLL register macros. Signed-off-by:
-
Ville Syrjälä authored
Remove the pointless intel_ namespace from our encoder/connector variables. Signed-off-by:
-
Ville Syrjälä authored
The loop over intel_dvo_devices[] makes intel_dvo_init() an ugly mess. Pull the i2c device probe out to a separate function so that we can get rid of the loop and flatten the code. Signed-off-by:
-
Ville Syrjälä authored
Reorder the drm_encoder_init() vs. encoder->port assignment so that we don't need the extra 'port' variable. Signed-off-by:
-
Ville Syrjälä authored
Introduce intel_dvo_connector_type() as a counterpart to intel_dvo_encoder_type(), mainly to declutter intel_dvo_init() a bit. Signed-off-by:
-
Ville Syrjälä authored
We call drm_encoder_init() before determining the correct encoder type, thus we always end up with DRM_MODE_ENCODER_NONE. Determine the correct encoder type earlier. Signed-off-by:
-
