- 07 Dec, 2021 5 commits
-
-
Jani Nikula authored
The mode set sequence for 128b/132b requires setting the div32 version of MPLLB clock. Bspec: 53880, 54128 Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211202144456.2541305-1-jani.nikula@intel.com
-
Uma Shankar authored
XE_LPD has 128 Lut entries for Degamma, with additional 3 entries for extended range. It has 511 entries for gamma with additional 2 entries for extended range. v2: Updated lut size for 10bit gamma, added lut_tests (Ville) v3: Dropped the gamma lut tests fields (Ville) Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Reviewed-by:
-
Uma Shankar authored
Enable Pipe Degamma for XE_LPD. Extend the legacy implementation to incorparate the extended lut size for XE_LPD. v2: Added a helper for degamma lut size (Ville) Signed-off-by:
-
Uma Shankar authored
Enable pipe color support for Display 13 platforms. Currently limit to just 10bit gamma and later extend it for logarithmic gamma, once the new UAPI is agreed by community and implemented by a userspace consumer. v2: Updated dev_priv to i915 (Ville) Signed-off-by:
-
Madhumitha Tolakanahalli Pradeep authored
Increase the max size of DMC on ADL-P to account for support of new features in the current/upcoming DMC versions. Signed-off-by:
Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
- 04 Dec, 2021 1 commit
-
-
Clint Taylor authored
Remove force probe protection from ADL_P platform. Did not obsevre warnings, errors, flickering or any visual defects while doing ordinary tasks like browsing and editing documents in a two monitor setup. For more info drm-tip idle run results : https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html? Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
- 03 Dec, 2021 34 commits
-
-
Tejas Upadhyay authored
From VBT, ddc pin info suggests the following mapping: VBT DRIVER DDI TC1->ddc_pin=3 should translate to PORT_TC1->0x9 DDI TC2->ddc_pin=4 should translate to PORT_TC2->0xa DDI TC3->ddc_pin=5 should translate to PORT_TC3->0xb DDI TC4->ddc_pin=6 should translate to PORT_TC4->0xc Adding pin map to facilitate this translation as we cannot use existing icl ddc pin map due to conflict with DDI C and DDI TC1 info. Bspec:20124 v2: - Changed Author to Tejas Upadhyay Cc: Clinton Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Atwood <matthew.s.atwood@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Acked-by:Imre Deak <imre.deak@intel.com> Signed-off-by:
Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Signed-off-by:
Raviteja Goud Talla <ravitejax.goud.talla@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Replace the "sizes are 0 based" stuff with just straight up -1 where needed. Less confusing all around. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
Ville Syrjälä authored
Now that each plane tracks its own no_fbc_reason we can print that out in debugfs, and we can also show which plane is currently selected for FBC duty. Signed-off-by:
-
Ville Syrjälä authored
FBC and double wide pipe are mutually exclusive. Disable FBC when we have to resort to double wide. Signed-off-by:
Mika Kahola <mika.kahola@intel.com>
-
Ville Syrjälä authored
Rename the 'params' to just fbc state. Signed-off-by:
-
Ville Syrjälä authored
Currently we track the FBC plane as a pointer under intel_fbc and also as a i9xx_plane_id under intel_fbc_state. Just store the pointer once in the fbc state. Signed-off-by:
-
Ville Syrjälä authored
fbc->state_cache has now become useless. We can simply update the reg params directly from the plane/crtc states during __intel_fbc_enable(). Signed-off-by:
-
Ville Syrjälä authored
Currently a FIFO underrun just causes FBC to be deactivated, and later checks then prevent it from being reactivated. We can simpify our lives a bit by logically disabling FBC on FIFO underruns. This avoids the funny intermediate state where FBC is logically enabled but can't actually be activated. v2: intel_wait_for_vblank() is no more Signed-off-by:
-
Ville Syrjälä authored
Don't really see a good reason why we can't just do the vgpu and modparam checks already in intel_fbc_check_plane(). Signed-off-by:
-
Ville Syrjälä authored
In the future we may have more than one FBC instance on some platforms. So let's just allocate it dynamically. This also lets us fully hide the implementation from prying eyes. Signed-off-by:
-
Ville Syrjälä authored
In order to better encapsulate the FBC implementation introduce a small helper to do the plane<->FBC instance association. We'll also try to structure the plane init code such that introducing multiple FBC instances will be easier down the line. Signed-off-by:
-
Ville Syrjälä authored
In order to encapsulate FBC harder let's just move the debugfs stuff into intel_fbc.c. Signed-off-by:
-
Ville Syrjälä authored
The underrun code doesn't need to know any details about FBC, so just pass in the whole device rather than a specific FBC instance. We could make this a bit more fine grained by also passing in the pipe to intel_fbc_handle_fifo_underrun_irq() and letting the FBC code figure which FBC instance (if any) is active on said pipe. But that seems a bit overkill for this so don't bother. Signed-off-by:
-
Ville Syrjälä authored
Use an early return to flatten most of __intel_fbc_pre_update(). Signed-off-by:
-
Ville Syrjälä authored
In the future we may have multiple planes on the same pipe capable of using FBC. Prepare for that by tracking FBC usage per-plane rather than per-crtc. v2: s/intel_get_crtc_for_pipe/intel_crtc_for_pipe/ Signed-off-by:
-
Ville Syrjälä authored
Pass the FBC instance instead of the crtc to a bunch of places. We also adjust intel_fbc_post_update() to do the intel_fbc_get_reg_params() things instead of doing it from the lower level function (which also gets called for front buffer tracking). Nothing in there will change during front buffer updates. Signed-off-by:
-
Ville Syrjälä authored
The FBC state cache and params are now nearly identical. Just use the same structure for both. Signed-off-by:
-
Ville Syrjälä authored
There isn't a good reason why we'd have to cache all this plane state stuff in the FBC state. Instead we can just pre-calculate what FBC will really need. Signed-off-by:
-
Ville Syrjälä authored
Move intel_fbc_override_cfb_stride() next to its cousins. Helps with later patches. Signed-off-by:
-
Ville Syrjälä authored
There's no need to store all this stuff in intel_fbc_state_cache. Just check it all against the plane/crtc states and store only what we need. Probably more should get nuked still, but this is a start. So what we'll do is: - each plane will check its own state and update its local no_fbc_reason - the per-plane no_fbc_reason (if any) then gets propagated to the cache->no_fbc_reason while doing the actual update - fbc->no_fbc_reason gets updated in the end with either the value from the cache or directly from frontbuffer tracking It's still a bit messy, but should hopefuly get cleaned up more in the future. At least now we can observe each plane's reasons for rejecting FBC now more consistently, and we don't have so mcuh redundant state store all over the place. v2: store no_fbc_reason per-plane instead of per-pipe Signed-off-by:
-
Ville Syrjälä authored
No reason to burden the caller with the details on how the minimum compression limit is calculated, so just pass in the whole plane state instead of just the cpp value. Signed-off-by:
-
Ville Syrjälä authored
The ilk fbc watermark computation uses intel_fbc_is_active() which is racy since we don't know whether FBC will be enabled or not at some point. So let's just assume it will be if both HAS_FBC() and the modparam agree. Signed-off-by:
-
Ville Syrjälä authored
Rename the PLANE_CUS_CTL Y plane selection bits to actually say "Y plane". Signed-off-by:
-
Ville Syrjälä authored
Rename the YUV byte order bits to be a bit more consistent. v2: Deal with gvt Signed-off-by:
-
Ville Syrjälä authored
Let's just stick to 32bit mmio accesses so we can get rid of the bare "uncore" reg access in display code. The register are defined as 32bit in the spec anyway. We could define a 64bit "de" variant I suppose, but doesn't really make much sense just for this one case, and when we start to use the DSB for this stuff we'd also need another 64bit variant for that. Just easier to do 32bit always. While at it we can reorder stuff a bit so that we write the registers in order of increasing offset (more or less). Signed-off-by:
-
Jani Nikula authored
Break the dependency on i915_drv.h. Signed-off-by:
-
Jani Nikula authored
Avoid looking into the guts of struct drm_i915_private in headers. Again, converting an inline function to a macro is less than ideal, but avoids having to pull in i915_drv.h just for the to_i915() part. Signed-off-by:
-
Jani Nikula authored
It's not the ideal location, but a better alternative than i915_drv.h. The goal is to break the intel_display_types.h to i915_drv.h dependency. Signed-off-by:
-
Jani Nikula authored
This is far from ideal, but it reduces the i915_drv.h dependency from intel_display_types.h. Maybe in the future we'll need a better split. Signed-off-by:
-
Jani Nikula authored
Move fb functions where they belong, and un-inline to avoid looking into struct drm_i915_private guts in header files. Signed-off-by:
-
Jani Nikula authored
Move a number of crtc/pipe related functions to intel_crtc.[ch], and un-inline to avoid looking into struct drm_i915_private guts in header files. Signed-off-by:
-
Anshuman Gupta authored
gt_pm selftest calculates engine ticks cycles and wall time cycles by delta of respective engine elapsed TIMESTAMP and ktime for period of 1000us. It compares the engine ticks cycles with wall time cycles. Disable local cpu interrupt so that interrupt handler does not switch out the thread during measure_clocks() and prevent miscalculation of engine tick cycles. v2: - nuke preempt_{disable,enable}, as disable_local_irq() disable the preemption. (Chris) Cc: Chris P Wilson <chris.p.wilson@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Cc: Ashutosh Dixit <ashutosh.dixit@intel.com> Signed-off-by:Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by:
Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211130132005.6305-1-anshuman.gupta@intel.com
-
Matt Atwood authored
Extend existing workaround 1409120013 to DG2. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Matt Roper authored
This workaround is documented a bit strangely in the bspec; it's listed as an A0 workaround, but the description clarifies that the workaround is implicitly handled by the hardware and what the driver really needs to do is program a chicken bit to reenable some internal behavior. Signed-off-by:
-
