IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Hoist the intel_de.h include from intel_display_types.h one
level up. I need this in order to untangle the include order
so that I can add tracepoints into intel_de.h.
This little cocci script did most of the work for me:
@find@
@@
(
intel_de_read(...)
|
intel_de_read_fw(...)
|
intel_de_write(...)
|
intel_de_write_fw(...)
)
@has_include@
@@
(
#include "intel_de.h"
|
#include "display/intel_de.h"
)
@depends on find && !has_include@
@@
+ #include "intel_de.h"
#include "intel_display_types.h"
@depends on find && !has_include@
@@
+ #include "display/intel_de.h"
#include "display/intel_display_types.h"
Cc: Cooper Chiou <cooper.chiou@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210430143945.6776-1-ville.syrjala@linux.intel.com
To allow the simplification of FB/plane view computation in the
follow-up patches, unify the corresponding state in the
intel_framebuffer and intel_plane_state structs into a new intel_fb_view
struct.
This adds some overhead to intel_framebuffer as the rotated view will
have now space for 4 color planes instead of the required 2 and it'll
also contain the unused offset for each color_plane info. Imo this is an
acceptable trade-off to get a simplified way of the remap computation.
Use the new intel_fb_view struct for the FB normal view as well, so (in
the follow-up patches) we can remove the special casing for normal view
calculation wrt. the calculation of remapped/rotated views. This also
adds an overhead to the intel_framebuffer struct, as the gtt remap info
and per-color plane offset/pitch is not required for the normal view,
but imo this is an acceptable trade-off as above. The per-color plane
pitch filed will be used by a follow-up patch, so we can retrieve the
pitch for each view in the same way.
No functional changes in this patch.
v2:
- Make the patch have _no functional change_.
(fix skl_check_nv12_aux_surface() and skl_check_main_surface()).
- s/i915_color_plane_view::pitch/stride/ (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210325214808.2071517-17-imre.deak@intel.com
Use Coccinelle to convert most of the usage of INTEL_GEN() and IS_GEN()
in the display code to use DISPLAY_VER() comparisons instead. The
following semantic patch was used:
@@ expression dev_priv, E; @@
- INTEL_GEN(dev_priv) == E
+ IS_DISPLAY_VER(dev_priv, E)
@@ expression dev_priv; @@
- INTEL_GEN(dev_priv)
+ DISPLAY_VER(dev_priv)
@@ expression dev_priv; expression E; @@
- IS_GEN(dev_priv, E)
+ IS_DISPLAY_VER(dev_priv, E)
@@
expression dev_priv;
expression from, until;
@@
- IS_GEN_RANGE(dev_priv, from, until)
+ IS_DISPLAY_RANGE(dev_priv, from, until)
There are still some display-related uses of INTEL_GEN() in intel_pm.c
(watermark code) and i915_irq.c. Those will be updated separately.
v2:
- Use new IS_DISPLAY_RANGE and IS_DISPLAY_VER helpers. (Jani)
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-4-matthew.d.roper@intel.com
ILK is the only platform that we consider "gen5" and SNB is the only
platform we consider "gen6." Add an IS_SANDYBRIDGE() macro and then
replace numeric platform tests for these two generations with direct
platform tests with the following Coccinelle semantic patch:
@@ expression dev_priv; @@
- IS_GEN(dev_priv, 5)
+ IS_IRONLAKE(dev_priv)
@@ expression dev_priv; @@
- IS_GEN(dev_priv, 6)
+ IS_SANDYBRIDGE(dev_priv)
@@ expression dev_priv; @@
- IS_GEN_RANGE(dev_priv, 5, 6)
+ IS_IRONLAKE(dev_priv) || IS_SANDYBRIDGE(dev_priv)
This will simplify our upcoming patches which eliminate INTEL_GEN()
usage in the display code.
v2:
- Reverse ilk/snb order for IS_GEN_RANGE conversion. (Ville)
- Rebase + regenerate from semantic patch
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210320044245.3920043-2-matthew.d.roper@intel.com
It is a preliminary work for supporting multiple EDP PSR and
DP PanelReplay. And it refactors singleton PSR to Multi Transcoder
supportable PSR.
And this moves and renames the i915_psr structure of drm_i915_private's to
intel_dp's intel_psr structure.
It also causes changes in PSR interrupt handling routine for supporting
multiple transcoders. But it does not change the scenario and timing of
enabling and disabling PSR. And it not support multiple pipes with
a single transcoder PSR case yet.
v2: Fix indentation and add comments
v3: Remove Blank line
v4: Rebased
v5: Rebased and Addressed Anshuman's review comment.
- Move calling of intel_psr_init() to intel_dp_init_connector()
v6: Address Anshuman's review comments
- Remove wrong comments and add comments for a limit of supporting of
a single pipe PSR
v7: Update intel_psr_compute_config() for supporting multiple transcoder
PSR on BDW+
v8: Address Anshuman's review comments
- Replace DRM_DEBUG_KMS with drm_dbg_kms() / DRM_WARN with drm_warn()
v9: Fix commit message
v10: Rebased
v11: Address Jose's review comment.
- Reorder calling order of intel_psr2_program_trans_man_trk_ctl().
- In order to reduce changes keep the old name for drm_i915_private.
- Change restrictions of multiple instances of PSR.
v12: Address Jose's review comment.
- Change the calling of intel_psr2_program_trans_man_trk_ctl() into
commit_pipe_config().
- Change a checking order of CAN_PSR() and connector_status to original
on i915_psr_sink_status_show().
- Drop unneeded intel_dp_update_pipe() function.
- In order to wait a specific encoder which belong to crtc_state on
intel_psr_wait_for_idle(), add checking of encoder.
- Add an whitespace to comments.
v13: Rebased and Address Jose's review comment.
- Add and use for_each_intel_psr_enabled_encoder() macro.
- In order to use correct frontbuffer_bit for each pipe,
fix intel_psr_invalidate() and intel_psr_flush().
- Remove redundant or unneeded codes.
- Update comments.
v14: Address Jose's review comment
- Add and use for_each_intel_encoder_can_psr() macro and
for_each_intel_encoder_mask_can_psr() macro.
- Add source_support member variable into intel_psr structure.
- Update CAN_PSR() macro that checks source_support.
- Move encoder's PSR availity check to psr_init() from
psr_compute_config().
- Remove redundant or unneeded codes.
v15: Remove wrong mutex lock/unlock of PSR from
intel_psr2_program_trans_man_trk_ctl()
Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210204134015.419036-1-gwan-gyeong.mun@intel.com
Limit pre-skl plane stride to below 4k or 8k pixels (depending on
the platform). We do this in order guarantee that TILEOFF/OFFSET.x
does not get too big.
Currently this is not a problem as we align SURF to 4k, and so
TILEOFF/OFFSET only have to deal with a single tile's worth of
pixels. But for async flips we're going to have to bump SURF
alignment to 256k, and thus we can no longer guarantee
TILEOFF/OFFSET.x will stay within acceptable bounds. We can avoid
this by borrowing a trick from the skl+ code and limit the max
plane stride to whatever value we can fit into TILEOFF/OFFSET.x.
The slight downside is that we may end up doing GTT remapping in
a few more cases where previously we did not have to. But since
that will only happen with huge buffers I'm not really concerned
about it.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210111163711.12913-3-ville.syrjala@linux.intel.com
Reviewed-by: Karthik B S <karthik.b.s@intel.com>
Prevent the ICL HDR plane pipeline from performing YUV color range
correction twice when the input is in limited range. This is done by
removing the limited-range code from icl_program_input_csc().
Before this patch the following could happen: user space gives us a YUV
buffer in limited range; per the pipeline in [1], the plane would first
go through a "YUV Range correct" stage that expands the range; the plane
would then go through the "Input CSC" stage which would also expand the
range because icl_program_input_csc() would use a matrix and an offset
that assume limited-range input; this would ultimately cause dark and
light colors to appear darker and lighter than they should respectively.
This is an issue because if a buffer switches between being scanned out
and being composited with the GPU, the user will see a color difference.
If this switching happens quickly and frequently, the user will perceive
this as a flickering.
[1] https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf#page=281
Cc: stable@vger.kernel.org
Signed-off-by: Andres Calderon Jaramillo <andrescj@chromium.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201215224219.3896256-1-andrescj@google.com
VRR achieves vblank stretching using the HW PUSH functionality.
So once the VRR is enabled during modeset then for each flip
request from userspace, in the atomic tail pipe_update_end()
we need to set the VRR push bit in HW for it to terminate
the vblank at configured flipline or anytime after flipline
or latest at the Vmax.
The HW clears the PUSH bit after the double buffer updates
are completed.
v2:
* Move send push to after irq en (Manasi)
* Call send push unconditionally (Jani N)
v3:
* Stall w.r.t Vrr vmax (Manasi, Gary Smith)
v4:
* Remove the rmw (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Gary Smith <gary.k.smith@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210122232647.22688-11-manasi.d.navare@intel.com
Render Decompression is supported with Y-Tiled main surface. The CCS is
linear and has 4 bits of data for each main surface cache line pair, a
ratio of 1:256. Additional Clear Color information is passed from the
user-space through an offset in the GEM BO. Add a new modifier to identify
and parse new Clear Color information and extend Gen12 render decompression
functionality to the newly added modifier.
v2: Fix has_alpha flag for modifiers, omit CC modifier during initial
plane config(Matt). Fix Lookup error.
v3: Fix the panic while running kms_cube
v4: Add alignment check and reuse the comments for ge12_ccs_formats(Matt)
v5: Fix typos and wrap comments(Matt)
v6:
- Use format block descriptors to get the subsampling calculations for
the CCS surface right.
- Use helpers to convert between main and CCS surfaces.
- Prevent coordinate checks for the CC surface.
- Simplify reading CC value from surface map, add description of CC val
layout.
- Remove redundant ccval variable from skl_program_plane().
v7:
- Move the CC value readout after syncing against any GPU write on the
FB obj (Nanley, Chris)
- Make sure the CC value readout works on platforms w/o struct pages
(dGFX) and other non-coherent platforms wrt. CPU reads (none atm).
(Chris)
v8:
- Rebase on the function param order change of
i915_gem_object_read_from_page().
- Clarify code comment on the clear color value format and the required
FB obj pinning/syncing by the caller.
- Remove redundant variables in
intel_atomic_prepare_plane_clear_colors().
v9:
- Fix s/sizeof(&ccval)/sizeof(ccval)/ typo.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Ville Syrjala <ville.syrjala@intel.com>
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Nanley G Chery <nanley.g.chery@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210115213952.1040398-1-imre.deak@intel.com
Since we try and estimate how long we require to update the registers to
perform a plane update, it is of vital importance that we measure the
distribution of plane updates to better guide our estimate. If we
underestimate how long it takes to perform the plane update, we may
slip into the next scanout frame causing a tear. If we overestimate, we
may unnecessarily delay the update to the next frame, causing visible
jitter.
Replace the warning that we exceed some arbitrary threshold for the
vblank update with a histogram for debugfs.
v2: Add a per-crtc debugfs entry so that the information is easier to
extract when testing individual CRTC, and so that it can be reset before
a test.
v3: Flip the graph on its side; creates space to label the time axis.
Updates: 4684
|
1us |
|
4us |********
|**********
16us |***********
|*****
66us |
|
262us |
|
1ms |
|
4ms |
|
17ms |
|
Min update: 5918ns
Max update: 54781ns
Average update: 16628ns
Overruns > 250us: 0
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1982
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20201202212814.26320-1-chris@chris-wilson.co.uk
GEN >= 10 hardware supports the programmable scaler filter.
Attach scaling filter property for CRTC and plane for GEN >= 10
hardwares and program scaler filter based on the selected filter
type.
changes since v3:
* None
changes since v2:
* Use updated functions
* Add ps_ctrl var to contain the full PS_CTRL register value (Ville)
* Duplicate the scaling filter in crtc and plane hw state (Ville)
changes since v1:
* None
Changes since RFC:
* Enable properties for GEN >= 10 platforms (Ville)
* Do not round off the crtc co-ordinate (Danial Stone, Ville)
* Add new functions to handle scaling filter setup (Ville)
* Remove coefficient set 0 hardcoding.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201020161427.6941-5-pankaj.laxminarayan.bharadiya@intel.com
Another step towards PSR2 selective fetch, here programming plane
selective fetch registers and MAN_TRK_CTL enabling selective fetch but
for now it is fetching the whole area of the planes.
The damaged area calculation will come as next and final step.
v2:
- removed warn on when no plane is visible in state
- removed calculations using plane damaged area in
intel_psr2_program_plane_sel_fetch()
v3:
- do not shift 16 positions the plane dst coordinates, only src is
shifted
v4:
- only setting PLANE_SEL_FETCH_CTL_ENABLE and MCURSOR_MODE in
PLANE_SEL_FETCH_CTL
v5:
- not masking bits for cursor
BSpec: 55229
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201007195238.53955-3-jose.souza@intel.com
when the hardware isn't going to use the aux plane there's no
real point in dealing with the relevant hardware restrictions.
So let's just skip all that when not necessary.
We can now also remove the offset=~0xfff behaviour for unused
color planes. Let's just zero out everyting so as to not leave
stale garbage behind to confuse people debugging the code.
v2: Explicitly set AUX_DIST to zero when there is no aux plane
Reviewed-by: Imre Deak <imre.deak@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201009120028.32422-1-ville.syrjala@linux.intel.com
In TE Gate mode or TE NO_GATE mode on every flip we need to set the
frame update request bit. After this bit is set transcoder hardware will
automatically send the frame data to the panel in case of TE NO_GATE
mode, where it sends after it receives the TE event in case of TE_GATE
mode. Once the frame data is sent to the panel, we see the frame counter
updating.
v2: Use intel_de_read/write
v3: remove the usage of private_flags
v4: Use icl_dsi in func names if non static,
fix code formatting issues. (Jani)
v5: Send frame update request at the beginning of
pipe_update_end, use crtc_state mode_flags (Ville)
v6: Add platform and dsi checks (Ville)
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200928110834.15077-1-vandita.kulkarni@intel.com
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
and call it from intel_update_plane. (Ville)
v8: -Rebased.
v9: -Use if-else instead of return in intel_update_plane(). (Ville)
-Rename 'program_async_surface_address' to 'async_flip'. (Ville)
v10: -Check if async_flip hook is present before calling it.
Otherwise it will OOPS during legacy cursor updates. (Ville)
v11: -Rename skl_program_async_surface_address(). (Ville)
Signed-off-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: 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/20200921110210.21182-6-karthik.b.s@intel.com
Since the flip done event will be sent in the flip_done_handler,
no need to add the event to the list and delay it for later.
v2: -Moved the async check above vblank_get as it
was causing issues for PSR.
v3: -No need to wait for vblank to pass, as this wait was causing a
16ms delay once every few flips.
v4: -Rebased.
v5: -Rebased.
v6: -Rebased.
v7: -No need of irq disable if we are not doing vblank evade. (Ville)
v8: -Rebased.
v9: -Move the return in intel_pipe_update_end before tracepoint. (Ville)
v10: Rebased.
Signed-off-by: Karthik B S <karthik.b.s@intel.com>
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: 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/20200921110210.21182-5-karthik.b.s@intel.com
Even if we're not doing downscaling we should account for
some of the extra dotclock limitations for g4x+ sprites. In
particular we must never exceed the 90% rule, and with RGB
that limits actually drops to 80%.
So instead of bailing out when upscaling let's clamp the
scaling factor appropriately and go through the rest of
calculation normally. By luck we already did the full
calculations for the 1:1 case.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200206201204.31704-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
TGL made stepping a litte mess, workarounds refer to the stepping of
the IP(GT or Display) not of the GPU stepping so it would already
require the same solution as used in commit 96c5a15f9f
("drm/i915/kbl: Fix revision ID checks").
But to make things even more messy it have a different IP stepping
mapping between SKUs and the same stepping revision of GT do not match
the same HW between TGL U/Y and regular TGL.
So it was required to have 2 different macros to check GT WAs while
for Display we are able to use just one macro that uses the right
revids table.
All TGL workarounds checked and updated accordingly.
v2:
- removed TODO to check if WA 14010919138 applies to regular TGL.
- fixed display stepping in regular TGL (Anusha)
BSpec: 52890
BSpec: 55378
BSpec: 44455
Reviewed-by: Anusha Srivatsa <anusha.srivtsa@intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Penne Lee <penne.y.lee@intel.com>
Cc: Guangyao Bai <guangyao.bai@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200827233943.400946-1-jose.souza@intel.com
Currently the plane property doesn't have support for YCBCR_BT2020,
which enables the corresponding color conversion mode on plane CSC.
Enabling the plane property for the planes for GLK & ICL+ platforms.
Also as per spec, update the Plane Color CSC from YUV601_TO_RGB709
to YUV601_TO_RGB601.
V2: Enabling support for YCBCT_BT2020 for HDR planes on
platforms GLK & ICL
V3: Refined the condition check to handle GLK & ICL+ HDR planes
Also added BT2020 handling in glk_plane_color_ctl.
V4: Combine If-else into single If
V5: Drop the checking for HDR planes and enable YCBCR_BT2020
for platforms GLK & ICL+.
V6: As per Spec, update PLANE_COLOR_CSC_MODE_YUV601_TO_RGB709
to PLANE_COLOR_CSC_MODE_YUV601_TO_RGB601 as per Ville's
feedback.
V7: Rebased
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Kishore Kadiyala <kishore.kadiyala@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200601073544.11291-1-kishore.kadiyala@intel.com
There seems to be a bit of confusing redundancy in a way, how
plane data rate/min cdclk are calculated.
In fact both min cdclk, pixel rate and plane data rate are all
part of the same formula as per BSpec.
However currently we have intel_plane_data_rate, which is used
to calculate plane data rate and which is also used in bandwidth
calculations. However for calculating min_cdclk we have another
piece of code, doing almost same calculation, but a bit differently
and in a different place. However as both are actually part of same
formula, probably would be wise to use plane data rate calculations
as a basis anyway, thus avoiding code duplication and possible bugs
related to this.
Another thing is that I've noticed that during min_cdclk calculations
we account for plane scaling, while for plane data rate, we don't.
crtc->pixel_rate seems to account only for pipe ratio, however it is
clearly stated in BSpec that plane data rate also need to account
plane ratio as well.
So what this commit does is:
- Adds a plane ratio calculation to intel_plane_data_rate
- Removes redundant calculations from skl_plane_min_cdclk which is
used for gen9+ and now uses intel_plane_data_rate as a basis from
there as well.
v2: - Don't use 64 division if not needed(Ville Syrjälä)
- Now use intel_plane_pixel_rate as a basis for calculations both
at intel_plane_data_rate and skl_plane_min_cdclk(Ville Syrjälä)
v3: - Again fix the division macro
- Fix plane_pixel_rate to pixel_rate at intel_plane_pixel_rate
callsites
v4: - Renamed skl_plane_ratio function back(Ville Syrjälä)
v5: - Don't precalculate plane pixel rate for invisible plane,
check for visibility first, as in invisible case it will
have dst_w and dst_h equal to zero, causing divide error.
v6: - Removed useless warn in intel_plane_pixel_rate(Ville Syrjälä)
- Fixed alignment in intel_plane_data_rate(Ville Syrjälä)
- Changed pixel_rate type to be unsigned int in
skl_plane_min_cdclk(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227150935.2107-1-stanislav.lisovskiy@intel.com
