| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
Split the currently combined plane data_rate into the proper
Y vs. CbCr components. This matches how we now track the
plane dbuf allocations, and thus will make the dbuf bandwidth
calculations actually produce the correct numbers for each
dbuf slice.
Reviewed-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/20220303191207.27931-3-ville.syrjala@linux.intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
No reason the high level intel_update_crtc() needs to know
that there is something magical about the commit order of
planes between different platforms. So let's hide that
detail even better.
In order to keep to somewhat consistent naming between
things we shall call this intel_crtc_planes_update_arm()
to match the plane->update_arm() vfunc naming convention.
And let's rename the noarm counterpart to
intel_crtc_planes_update_noarm() to more clearly associate
it with the plane->update_noarm() vfunc.
v2: Change the naming convention a bit
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/20220216232806.6194-2-ville.syrjala@linux.intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Exfiltrate intel_plane_atomic_calc_changes() and its friends from
intel_display.c to intel_atomic_plane.c since that is a much better
fit.
While at it also nuke the official looking kernel docs for
intel_wm_need_update() and flag it for eventual destruction so
that people don't get any wrong ideas about using it in new code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220211090629.15555-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes we might need to change the way we calculate
watermarks, based on which particular plane it is calculated
for. Thus it would be convenient to pass plane struct to those
functions.
v2: Pass plane instead of plane_id
v3: Do not pass plane to skl_cursor_allocation(Ville Syrjälä)
v4: - Make intel_crtc_get_plane static again(Ville Syrjälä)
- s/cursor_plane/plane(Ville Syrjälä)
- Pass plane to skl_compute_wm_* instead of plane_id(Ville Syrjälä)
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220124090653.14547-2-stanislav.lisovskiy@intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The amount of plane registers we have to write has been steadily
increasing, putting more pressure on the vblank evasion mechanism
and forcing us to increase its time budget. Let's try to take some
of the pressure off by splitting plane updates into two parts:
1) write all non-self arming plane registers, ie. the registers
where the write actually does nothing until a separate arming
register is also written which will cause the hardware to latch
the new register values at the next start of vblank
2) write all self arming plane registers, ie. registers which always
just latch at the next start of vblank, and registers which also
arm other registers to do so
Here we just provide the mechanism, but don't actually implement
the split on any platform yet. so everything stays now in the _arm()
hooks. Subsequently we can move a whole bunch of stuff into the
_noarm() part, especially in more modern platforms where the number
of registers we have to write is also the greatest. On older
platforms this is less beneficial probably, but no real reason
to deviate from a common behaviour.
And let's sprinkle some TODOs around the areas that will need
adapting.
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211018115030.3547-5-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
|
| |
|
|
|
|
|
|
| |
Add a small helper to keep intel_plane_helper_funcs static.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210518132426.7567-1-jani.nikula@intel.com
|
| |
|
|
|
|
|
|
|
| |
Replace the hand rolled pfit downscale calculations with
intel_adjusted_rate().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210330184254.6290-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need to look at hw.fb for the framebuffer, and add the translation
for the slave_plane_state. With these changes we set the correct
rectangle on the bigjoiner slave, and don't set incorrect
src/dst/visibility on the slave plane.
v2:
* Manual rebase (Manasi)
v3:
* hw.rotation instead of uapi.rotation (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-11-manasi.d.navare@intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using bigjoiner userspace is only controlling the "master"
plane, so use its uapi state for the "slave" plane as well.
hw.crtc needs a bit of magic since we don't want to copy that from
the uapi state (as it points to the wrong pipe for the "slave
" plane). Instead we pass the right crtc in explicitly but only
assign it when the uapi state indicates the plane to be logically
enabled (ie. uapi.crtc != NULL).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-10-manasi.d.navare@intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When doing the plane state copy from the UV plane to the Y plane
let's just copy the hw state directly instead of using the original
uapi state. The UV plane has already had its uapi state copied into
its hw state, so this extra detour via the uapi state for the Y plane
is pointless.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20201117194718.11462-2-manasi.d.navare@intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We only consider crtc_state->enable when initially calculating plane
visibility. Later on we try to override the plane's state to invisible
if the crtc is in DPMS off state (crtc_state->active==false).
Unfortunately the code doing that only updates the plane_state.visible
flag and the crtc_state.active_planes bimask, but forgets to update
some of the other plane bitmasks stored in the crtc_state. Namely
crtc_state.nv12_planes is left set up based on the original visibility
check which makes icl_check_nv12_planes() pick a slave plane for the
flagged plane in the bitmask. Later on we hit the watermark code
which sees a plane with a slave assigned and it then makes the
logical assumption that the master plane must itself be visible.
Since the master's plane_state.visible flag was already cleared
we get a WARN.
Fix the problem by clearing all the plane bitmasks for DPMS off.
This is more or less the wrong approach and instead we should
calculate all the plane related state purely based crtc_state->enable
(to guarantee that the subsequent DPMS on can't fail). However in
the past we definitely had some roadblocks to making that happen.
Not sure how many are left these days, but let's stick to the current
approach since it's a much simpler fix to the immediate problem
(the WARN).
v2: Keep the visible=false, it's important (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200318174515.31637-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Let's convert cdclk_state to be a proper global state. That allows
us to use the regular atomic old vs. new state accessor, hopefully
making the code less confusing.
We do have to deal with a few more error cases in case the cdclk
state duplication fails. But so be it.
v2: Fix new plane min_cdclk vs. old crtc min_cdclk check
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200121140353.25997-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we split plane_state which I didn't want to do yet, we can
program the slave plane without requiring the master plane.
This is useful for programming bigjoiner slave planes as well. We
will no longer need the master's plane_state.
Changes since v1:
- set src/dst rectangles after copy_uapi_to_hw_state.
Changes since v2:
- Use the correct color_plane for pre-gen11 by using planar_linked_plane != NULL.
- Use drm_format_info_is_yuv_semiplanar in skl_plane_check() to fix gen11+.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-12-maarten.lankhorst@linux.intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Splitting plane state is easier than splitting crtc_state,
before plane check we copy the drm properties to hw so we can
do the same in bigjoiner later on.
We copy the state after we did all the modeset handling, but fortunately
i915 seems to be split correctly and nothing during modeset looks
at plane_state.
Changes since v1:
- Do not clear hw state on duplication.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191031112610.27608-11-maarten.lankhorst@linux.intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Various pixel formats and plane scaling impose additional constraints
on the cdclk frequency. Provide a new plane->min_cdclk() hook that
will be used to compute the minimum acceptable cdclk frequency for
each plane.
Annoyingly on some platforms the numer of active planes affects
this calculation so we must also toss in more planes into the
state when the number of active planes changes.
The sequence of state computation must also be changed:
1. check_plane() (updates plane's visibility etc.)
2. figure out if more planes now require update min_cdclk
computaion
3. calculate the new min cdclk for each plane in the state
4. if the minimum of any plane now exceeds the current
logical cdclk we recompute the cdclk
4. during cdclk computation take the planes' min_cdclk into
accoutn
5. follow the normal cdclk programming to change the
cdclk frequency. This may now require a modeset (except
on bxt/glk in some cases), which either succeeds or
fails depending on whether userspace has given
us permission to perform a modeset or not.
v2: Fix plane id check in intel_crtc_add_planes_to_state()
Only print the debug message when cdclk needs bumping
Use dev_priv->cdclk... as the old state explicitly
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191015193035.25982-5-ville.syrjala@linux.intel.com
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We need to insert stuff between the plane and crtc .atomic_check()
drm_atomic_helper_check_planes() doesn't allow us to do that so
stop using it and hand roll the loops instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190708125325.16576-9-ville.syrjala@linux.intel.com
Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Pass along the correct state as much as possible, instead of relying
on the drm state internally. This is required to rely on hw state
internally soon.
While at it, clean up intel_plane_atomic_check slightly, by using a
helper function to get the intel_crtc. (Ville)
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190628085517.31886-6-maarten.lankhorst@linux.intel.com
|
|
|
Now that we have a new subdirectory for display code, continue by moving
modesetting core code.
display/intel_frontbuffer.h sticks out like a sore thumb, otherwise this
is, again, a surprisingly clean operation.
v2:
- don't move intel_sideband.[ch] (Ville)
- use tabs for Makefile file lists and sort them
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190613084416.6794-3-jani.nikula@intel.com
|
