Ville Syrjälä [Mon, 11 Dec 2023 22:17:59 +0000 (00:17 +0200)]
drm/i915/cdclk: Rewrite cdclk->voltage_level selection to use tables
The cdclk->voltage_level if ladders are hard to read, especially as
they're written the other way around compared to how bspec lists
the limits. Let's rewrite them to use simple arrays that gives us
the max cdclk for each voltage level.
v2: Bump the jsl/ehl max cdclk in the table to 652.8 MHz to
accommodate JSL machines in CI that boot with high cdclk
Ville Syrjälä [Mon, 11 Dec 2023 22:16:36 +0000 (00:16 +0200)]
drm/i915/cdclk: Remove the assumption that cdclk divider==2 when using squashing
Currently we have a hardcoded assumption that the cdclk divider
(2*cd2x divider) is always 2 when squashing is used. While that
is true for all current platforms it might not hold in the future.
So eliminate the assumption and calculate the correct divider
from the other parameters.
Ville Syrjälä [Tue, 28 Nov 2023 11:51:31 +0000 (13:51 +0200)]
drm/i915/cdclk: s/-1/~0/ when dealing with unsigned values
cdclk_pll_is_unknown() used ~0 when checking for the "VCO is
unknown" value, but the assignment uses -1. They are the same
in the end, but let's use the same ~0 form on both sides for
consistency.
Mika Kahola [Tue, 12 Dec 2023 11:51:30 +0000 (13:51 +0200)]
drm/i915/display: Wait for PHY readiness not needed for disabling sequence
When going through the disconnection flow we don't need to wait for PHY
readiness and hence we can skip the wait part. For disabling the function
returns false as an indicator that the power is not enabled. After all,
we are not even using the return value when Type-C is disconnecting.
Ankit Nautiyal [Wed, 22 Nov 2023 06:46:27 +0000 (12:16 +0530)]
drm/i915/display: Get bigjoiner config before dsc config during readout
Currently we get bigjoiner config after the dsc get config, during HW
readout.
Since dsc_get_config now uses bigjoiner flags/pipes to compute DSC PPS
parameter pic_width, this results in a state mismatch when Bigjoiner
and DSC are used together.
So call get bigjoiner config before calling dsc get config function.
Fixes: 8b70b5691704 ("drm/i915/vdsc: Fill the intel_dsc_get_pps_config function") Cc: Suraj Kandpal <suraj.kandpal@intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Reviewed-by: Suraj Kandpal <suraj.kandpal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231122064627.905828-1-ankit.k.nautiyal@intel.com
Jani Nikula [Tue, 5 Dec 2023 18:05:51 +0000 (20:05 +0200)]
drm/i915/edp: don't write to DP_LINK_BW_SET when using rate select
The eDP 1.5 spec adds a clarification for eDP 1.4x:
> For eDP v1.4x, if the Source device chooses the Main-Link rate by way
> of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0].
We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using
DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel
to ignore the rate set method.
Moreover, 0 is a reserved value for DP_LINK_BW_SET, and should not be
used.
Ville Syrjälä [Thu, 28 Sep 2023 15:24:49 +0000 (18:24 +0300)]
drm/i915: Stop accessing crtc->state from the flip done irq
Assuming crtc->state is pointing at the correct thing for the
async flip commit is nonsense. If we had already queued up multiple
commits this would point at the very lates crtc state even if the
older commits hadn't even happened yet.
Instead properly stage/arm the event like we do for async flips.
Since we don't need to arm multiple of these at the same time we
don't need a list like the normal vblank even processing uses.
drm/i915/mtl: Rename the link_bit_rate to clock in C20 pll_state
With the cleanup of the misleading clock value to avoid extra
calculations to convert between link_bit_rate and clock, use
one standard "clock" field for the c20 pll which works with
crtc_state->port_clock field.
drm/i915/mtl: Remove misleading "clock" field from C20 pll_state
The field link_bit_rate serves as the actual clock value for the C20
pll_state structure. Remove the misleading clock field. The subsequent
patch would rename the link_bit_rate as the clock field.
drm/i915/mtl: Use port clock compatible numbers for C20 phy
In C20 pll_state link_bit_rate and clock fields are bit redundant. Since
many of the helpers assume the clock values, which are different from
link_bit_rate for dp2.0, convert the helpers to use the numbers that
are compatible with link_bit_rate.
Currently link_bit_rate is compatible with crtc_state->port_clock. The
function intel_c20pll_calc_port_clock returns the number which is
compatible with crtc_state->port_clock. In order to avoid extra
conversions b/ween clock and link_bit_rate, remove "clock" field from the
C20 pll_state and then rename "link_bit_rate" as "clock".
While at it rely on crtc_state->port_clock during C20 Pll programming.
Ville Syrjälä [Thu, 7 Dec 2023 19:34:36 +0000 (21:34 +0200)]
drm/i915: Drop redundant NULL check
intel_bios_get_dsc_params() is only called from
gen11_dsi_dsc_compute_config() and it always passes a non-NULL
crtc_state in. Drop the redundant check.
Since the plane_state variable is declared outside the scaler_users
loop in intel_atomic_setup_scalers(), and it's never reset back to
NULL inside the loop we may end up calling intel_atomic_setup_scaler()
with a non-NULL plane state for the pipe scaling case. That is bad
because intel_atomic_setup_scaler() determines whether we are doing
plane scaling or pipe scaling based on plane_state!=NULL. The end
result is that we may miscalculate the scaler mode for pipe scaling.
The hardware becomes somewhat upset if we end up in this situation
when scanning out a planar format on a SDR plane. We end up
programming the pipe scaler into planar mode as well, and the
result is a screenfull of garbage.
Fix the situation by making sure we pass the correct plane_state==NULL
when calculating the scaler mode for pipe scaling.
Ville Syrjälä [Tue, 5 Dec 2023 18:03:08 +0000 (20:03 +0200)]
drm/i915: Fix remapped stride with CCS on ADL+
On ADL+ the hardware automagically calculates the CCS AUX surface
stride from the main surface stride, so when remapping we can't
really play a lot of tricks with the main surface stride, or else
the AUX surface stride would get miscalculated and no longer
match the actual data layout in memory.
Supposedly we could remap in 256 main surface tile units
(AUX page(4096)/cachline(64)*4(4x1 main surface tiles per
AUX cacheline)=256 main surface tiles), but the extra complexity
is probably not worth the hassle.
So let's just make sure our mapping stride is calculated from
the full framebuffer stride (instead of the framebuffer width).
This way the stride we program into PLANE_STRIDE will be the
original framebuffer stride, and thus there will be no change
to the AUX stride/layout.
Luca Coelho [Fri, 1 Dec 2023 10:00:32 +0000 (12:00 +0200)]
drm/i915: handle uncore spinlock when not available
The uncore code may not always be available (e.g. when we build the
display code with Xe), so we can't always rely on having the uncore's
spinlock.
To handle this, split the spin_lock/unlock_irqsave/restore() into
spin_lock/unlock() followed by a call to local_irq_save/restore() and
create wrapper functions for locking and unlocking the uncore's
spinlock. In these functions, we have a condition check and only
actually try to lock/unlock the spinlock when I915 is defined, and
thus uncore is available.
This keeps the ifdefs contained in these new functions and all such
logic inside the display code.
Ville Syrjälä [Mon, 4 Dec 2023 20:24:43 +0000 (22:24 +0200)]
drm/i915: Fix ADL+ tiled plane stride when the POT stride is smaller than the original
plane_view_scanout_stride() currently assumes that we had to pad the
mapping stride with dummy pages in order to align it. But that is not
the case if the original fb stride exceeds the aligned stride used
to populate the remapped view, which is calculated from the user
specified framebuffer width rather than the user specified framebuffer
stride.
Ignore the original fb stride in this case and just stick to the POT
aligned stride. Getting this wrong will cause the plane to fetch the
wrong data, and can lead to fault errors if the page tables at the
bogus location aren't even populated.
TODO: figure out if this is OK for CCS, or if we should instead increase
the width of the view to cover the entire user specified fb stride
instead...
Jouni Högander [Sun, 3 Dec 2023 11:48:40 +0000 (13:48 +0200)]
drm/i915/display: Split i915 specific code away from intel_fb.c
We are preparing for Xe driver. Backing object implementation is differing
between i915 and Xe. Split i915 specific code into separate source file
built only for i915.
v9:
- Use ERR_CAST
v8:
- return original error code from intel_fb_bo_lookup_valid_bo on failure
v7:
- drop #include <drm/drm_plane.h>
- s/user_mode_cmd/mode_cmd/
- Use passed i915 pointer instead of to_i915(obj->base.dev)
v6: Add missing intel_fb_bo.[ch]
v5:
- Keep drm_any_plane_has_format check in intel_fb.c
- Use mode_cmd instead of user_mode_cmd for intel_fb_bo_lookup_valid_bo
v4: Move drm_any_plane_has_format check into intel_fb_bo.c
v3: Fix failure handling in intel_framebuffer_init
v2: Couple of fixes to error value handling
Jouni Högander [Sun, 3 Dec 2023 11:48:39 +0000 (13:48 +0200)]
drm/i915/display: Handle invalid fb_modifier in intel_fb_modifier_to_tiling
Lookup_modifier is returning INTEL_PLANE_CAP_TILING_4 on invalid
fb_modifier value. Use lookup_modifier_or_null in
intel_fb_modifier_to_tiling and return I915_TILING_NONE in case
lookup_modifier_or_null returns null.
Jouni Högander [Sun, 3 Dec 2023 11:48:37 +0000 (13:48 +0200)]
drm/i915/display: use intel_bo_to_drm_bo in intel_fb.c
We are preparing for Xe driver. I915 and Xe object implementation are
differing. Do not use i915_gem_object->base directly. Instead use
intel_bo_to_drm_bo.
Also use drm_gem_object_put instead of i915_gem_object_put. This should be
ok as i915_gem_object_put is really just doing __drm_gem_object_put.
Jouni Högander [Wed, 15 Nov 2023 09:07:19 +0000 (11:07 +0200)]
drm/i915/display: use intel_bo_to_drm_bo in intel_fbdev
We are preparing for Xe driver. I915 and Xe object implementation are
differing. Do not use i915_gem_object->base directly. Instead use
intel_bo_to_drm_bo.
Jouni Högander [Wed, 15 Nov 2023 09:07:18 +0000 (11:07 +0200)]
drm/i915/display: split i915 specific code from intel_fbdev
Split out code from intel_fbdev that can not be share between i915 and
xe. Create new i915 specific source/header file intel_fbdev_fb.[ch] which
contains this code.
Mika Kahola [Wed, 29 Nov 2023 12:22:21 +0000 (14:22 +0200)]
drm/i915/display: Skip state verification with TBT-ALT mode
With TBT-ALT mode we are not programming C20 chip PLL's and
hence we don't need to check state verification. We don't
need to program DP link signal levels i.e.pre-emphasis and
voltage swing either.
This patch fixes dmesg errors like this one
"[drm] ERROR PHY F Write 0c06 failed after 3 retries."
heminhong [Tue, 14 Nov 2023 02:43:41 +0000 (10:43 +0800)]
drm/i915: correct the input parameter on _intel_dsb_commit()
Current, the dewake_scanline variable is defined as unsigned int,
an unsigned int variable that is always greater than or equal to 0.
when _intel_dsb_commit function is called by intel_dsb_commit function,
the dewake_scanline variable may have an int value.
So the dewake_scanline variable is necessary to defined as an int.
Fixes: f83b94d23770 ("drm/i915/dsb: Use DEwake to combat PkgC latency") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202310052201.AnVbpgPr-lkp@intel.com/ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by: heminhong <heminhong@kylinos.cn> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231114024341.14524-1-heminhong@kylinos.cn
Ville Syrjälä [Mon, 27 Nov 2023 14:50:28 +0000 (16:50 +0200)]
drm/i915: Clean up some DISPLAY_VER checks
Use the >= and < operators for the DISPLAY_VER checks everywhere.
This is what most of the code does, but especially recently random
pieces of code have started doing this differently for no good reason.
Conversion done with the following cocci:
@find@
expression i915;
constant ver;
@@
(
DISPLAY_VER(i915) <= ver
|
DISPLAY_VER(i915) > ver
)
Ville Syrjälä [Mon, 27 Nov 2023 14:50:27 +0000 (16:50 +0200)]
drm/i915/mst: Reject modes that require the bigjoiner
We have no bigjoiner support in the MST code, so .mode_valid()
pretending otherwise is just going to result black screens for
users. Reject any mode that needs the joiner.
Ville Syrjälä [Mon, 27 Nov 2023 14:50:25 +0000 (16:50 +0200)]
drm/i915: Skip some timing checks on BXT/GLK DSI transcoders
Apparently some BXT/GLK systems have DSI panels whose timings
don't agree with the normal cpu transcoder hblank>=32 limitation.
This is perhaps fine as there are no specific hblank/etc. limits
listed for the BXT/GLK DSI transcoders.
Move those checks out from the global intel_mode_valid() into
into connector specific .mode_valid() hooks, skipping BXT/GLK
DSI connectors. We'll leave the basic [hv]display/[hv]total
checks in intel_mode_valid() as those seem like sensible upper
limits regardless of the transcoder used.
Ville Syrjälä [Fri, 24 Nov 2023 08:27:31 +0000 (10:27 +0200)]
drm/i915/psr: Include some basic PSR information in the state dump
Currently no one can figure out what the PSR code is doing since
we're including any of it in the basic state dump. Add at least the
bare minimum there.
Jouni Högander [Mon, 20 Nov 2023 08:26:06 +0000 (10:26 +0200)]
drm/i915/psr: Add proper handling for disabling sel fetch for planes
Currently we are enabling selective fetch for all planes that are visible.
This is suboptimal as we might be fetching for memory for planes that are
not part of selective update.
Fix this by adding proper handling for disabling plane selective fetch:
If plane previously part of selective update is now not part of update:
Add it into updated planes and let the plane configuration to disable
selective fetch for it.
v3: Checkpatch warnings fixed
v2:
- Add setting sel_fetch_area->y1/y2 to -1
- Remove setting again local sel_fetch_area variable
Jouni Högander [Mon, 20 Nov 2023 08:26:05 +0000 (10:26 +0200)]
drm/i915/psr: Move plane sel fetch configuration into plane source files
Currently selective fetch configuration for planes is implemented in psr
code. More suitable place for this code is where everything else is
configured for planes -> move it into skl_universal_plane.c and
intel_cursor.c. This also allows us to drop hooks for cursor handling.
v3: Checkpatch warnings fixed
v2: Removed setting sel_fetch_area->y1/y2 as -1
Ville Syrjälä [Fri, 13 Oct 2023 13:14:02 +0000 (16:14 +0300)]
drm/i915: Fix glk+ degamma LUT conversions
The current implementation of change_lut_val_precision() is just
a convoluted way of shifting by 8. Implement the proper rounding
by just using drm_color_lut_extract() and intel_color_lut_pack()
like everyone else does.
And as the uapi can't handle >=1.0 values but the hardware
can we need to clamp the results appropriately in the readout
path.
Ville Syrjälä [Fri, 13 Oct 2023 13:13:59 +0000 (16:13 +0300)]
drm: Fix color LUT rounding
The current implementation of drm_color_lut_extract()
generates weird results. Eg. if we go through all the
values for 16->8bpc conversion we see the following pattern:
So less values map to 0 and more values map 0xff, which
doesn't seem particularly great.
To get just the same number of input values to map to
the same output values we'd just need to drop the rounding
entrirely. But perhaps a better idea would be to follow the
OpenGL int<->float conversion rules, in which case we get
the following results:
Note that since the divisor is constant the compiler
is able to optimize away the integer division in most
cases. The only exception is the _ULL() case on 32bit
architectures since that gets emitted as inline asm
via do_div() and thus the compiler doesn't get to
optimize it.
Ville Syrjälä [Tue, 21 Nov 2023 05:43:24 +0000 (07:43 +0200)]
drm/i915: Implement audio fastset
There's no real reason why we'd need a full modeset for audio
changes. So let's allow audio to be toggled during fastset.
In case the ELD changes while has_audio isn't changing state
we force both audio disable and enable so the new ELD gets
propagated to the audio driver.
Ville Syrjälä [Tue, 21 Nov 2023 05:43:23 +0000 (07:43 +0200)]
drm/i915: Push audio_{enable,disable}() to the pre/post pane update stage
Relocate the audio enable/disable from the full modeset hooks into
the common pre/post plane update stage of the commit. Audio fastset
is within easy reach now.
Ville Syrjälä [Tue, 21 Nov 2023 05:43:21 +0000 (07:43 +0200)]
drm/i915: Convert audio enable/disable into encoder vfuncs
Add encoder vfuncs for audio enable/disable. This will allow
audio to be enabled/disabled during fastsets. An encoder hook
is necessary as on pre-hsw platforms different encoder types
implement audio in different ways.
Ville Syrjälä [Tue, 21 Nov 2023 05:43:18 +0000 (07:43 +0200)]
drm/i915: Wrap g4x+ DP/HDMI audio enable/disable
Put a wrapper around the intel_audio_codec_{enable,disable}()
calls in the g4x+ DP/HDMI code. We shall move the presence
detect enable/disable into the wrappers later.
Ville Syrjälä [Tue, 21 Nov 2023 05:43:17 +0000 (07:43 +0200)]
drm/i915: Push audio enable/disable further out
Push the audio enable/disable to be the last/first thing
respectively that is done in the encoder enable/disable hooks.
The goal is to move it further out of these encoder hooks entirely.
Ville Syrjälä [Tue, 21 Nov 2023 05:43:15 +0000 (07:43 +0200)]
drm/i915: Call intel_pre_plane_updates() also for pipes getting enabled
We used to call intel_pre_plane_updates() for any pipe going through
a modeset whether the pipe was previously enabled or not. This in
fact needed to apply all the necessary clock gating workarounds/etc.
Restore the correct behaviour.
Ville Syrjälä [Tue, 21 Nov 2023 05:43:14 +0000 (07:43 +0200)]
drm/i915: Check pipe active state in {planes,vrr}_{enabling,disabling}()
{planes,vrr}_{enabling,disabling}() are supposed to indicate
whether the specific hardware feature is supposed to be enabling
or disabling. That can only makes sense if the pipe is active
overall. So check for that before we go poking at the hardware.
I think we're semi-safe currently on due to:
- intel_pre_plane_update() doesn't get called when the pipe
was not-active prior to the commit, but this is actually a bug.
This saves vrr_disabling(), and vrr_enabling() is called from
deeper down where we have already checked hw.active.
- active_planes mirrors the crtc's hw.active
Mika Kahola [Thu, 16 Nov 2023 09:05:12 +0000 (11:05 +0200)]
drm/i915/display: Use int type for entry_setup_frames
entry_setup_frames variable is defined as u8. However, the
function call intel_psr_entry_setup_frames() can return
negative error code. There is a type mismatch here, so let's
switch to use int here as well.
Andy Shevchenko [Fri, 3 Nov 2023 20:18:30 +0000 (22:18 +0200)]
drm/i915/dsi: Combine checks in mipi_exec_gpio()
For a couple of cases the branches call the same bxt_gpio_set_value().
As Ville suggested they can be combined by dropping the DISPLAY_VER()
check from Gen 11 to Gen 9. Do it that way.
Andy Shevchenko [Fri, 3 Nov 2023 20:18:29 +0000 (22:18 +0200)]
drm/i915/dsi: Replace poking of CHV GPIOs behind the driver's back
It's a dirty hack in the driver that pokes GPIO registers behind
the driver's back. Moreoever it might be problematic as simultaneous
I/O may hang the system, see the commit 0bd50d719b00 ("pinctrl:
cherryview: prevent concurrent access to GPIO controllers") for
the details. Taking all this into consideration replace the hack
with proper GPIO APIs being used.
Andy Shevchenko [Fri, 3 Nov 2023 20:18:28 +0000 (22:18 +0200)]
drm/i915/dsi: Prepare soc_gpio_set_value() to distinguish GPIO communities
Currently soc_gpio_set_value() supports only a single indexing for GPIO
pin. For CHV case, for example, we will need to distinguish community
based index from the one that VBT is using. Introduce an additional
parameter to soc_gpio_set_value() and its callers.
Andy Shevchenko [Fri, 3 Nov 2023 20:18:27 +0000 (22:18 +0200)]
drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back
It's a dirty hack in the driver that pokes GPIO registers behind
the driver's back. Moreoever it might be problematic as simultaneous
I/O may hang the system, see the commit 40ecab551232 ("pinctrl:
baytrail: Really serialize all register accesses") for the details.
Taking all this into consideration replace the hack with proper
GPIO APIs being used.
Hans de Goede [Fri, 3 Nov 2023 20:18:25 +0000 (22:18 +0200)]
drm/i915/dsi: Fix wrong initial value for GPIOs in bxt_gpio_set_value()
Fix wrong initial value for GPIOs in bxt_gpio_set_value().
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-11-andriy.shevchenko@linux.intel.com
Hans de Goede [Fri, 3 Nov 2023 20:18:24 +0000 (22:18 +0200)]
drm/i915/dsi: Remove GPIO lookup table at the end of intel_dsi_vbt_gpio_init()
To properly deal with GPIOs used in MIPI panel sequences a temporary
GPIO lookup will be used. Since there can only be 1 GPIO lookup table
for the "0000:00:02.0" device this will not work if the GPIO lookup
table used by intel_dsi_vbt_gpio_init() is still registered.
After getting the "backlight" and "panel" GPIOs the lookup table
registered by intel_dsi_vbt_gpio_init() is no longer necessary,
remove it so that another temporary lookup-table for the "0000:00:02.0"
device can be added.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-10-andriy.shevchenko@linux.intel.com
Andy Shevchenko [Fri, 3 Nov 2023 20:18:23 +0000 (22:18 +0200)]
drm/i915/dsi: Replace check with a (missing) MIPI sequence name
Names of the MIPI sequence steps are sequential and defined, no
need to check for the gaps. However in seq_name the MIPI_SEQ_END
is missing. Add it there, and drop unneeded NULL check in
sequence_name().
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-9-andriy.shevchenko@linux.intel.com
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-8-andriy.shevchenko@linux.intel.com
Andy Shevchenko [Fri, 3 Nov 2023 20:18:21 +0000 (22:18 +0200)]
drm/i915/dsi: Replace while(1) with one with clear exit condition
Move existing condition to while(), so it will be clear on what
circumstances the loop is successfully finishing.
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-7-andriy.shevchenko@linux.intel.com
Jani Nikula [Fri, 3 Nov 2023 20:18:20 +0000 (22:18 +0200)]
drm/i915/dsi: bxt/icl GPIO set value do not need gpio source
Drop the unused parameter.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-6-andriy.shevchenko@linux.intel.com
Jani Nikula [Fri, 3 Nov 2023 20:18:19 +0000 (22:18 +0200)]
drm/i915/dsi: rename platform specific *_exec_gpio() to *_gpio_set_value()
The lowest level functions are about setting GPIO values, not about
executing any sequences anymore.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-5-andriy.shevchenko@linux.intel.com
Jani Nikula [Fri, 3 Nov 2023 20:18:18 +0000 (22:18 +0200)]
drm/i915/dsi: clarify GPIO exec sequence
With the various sequence versions and pointer increments interleaved,
it's a bit hard to decipher what's going on. Add separate paths for
different sequence versions.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-4-andriy.shevchenko@linux.intel.com
Jani Nikula [Fri, 3 Nov 2023 20:18:17 +0000 (22:18 +0200)]
drm/i915/dsi: switch mipi_exec_gpio() from dev_priv to i915
Follow the contemporary conventions.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-3-andriy.shevchenko@linux.intel.com
Jani Nikula [Fri, 3 Nov 2023 20:18:16 +0000 (22:18 +0200)]
drm/i915/dsi: assume BXT gpio works for non-native GPIO
Purely a guess. Drop the nop function.
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231103201831.1037416-2-andriy.shevchenko@linux.intel.com
Imre Deak [Thu, 16 Nov 2023 13:18:41 +0000 (15:18 +0200)]
drm/i915/dp: Reuse intel_dp_{max,effective}_data_rate in intel_link_compute_m_n()
Reuse intel_dp_max_data_rate() and intel_dp_effective_data_rate() in
intel_link_compute_m_n(), instead of open-coding the equivalent. Note
the kbit/sec -> kByte/sec unit change in the M/N values, but this not
reducing the precision, as the link rate value is based anyway on a less
precise 10 kbit/sec value.
Imre Deak [Thu, 16 Nov 2023 13:18:40 +0000 (15:18 +0200)]
drm/i915/dp: Simplify intel_dp_max_data_rate()
Simplify intel_dp_max_data_rate() using
drm_dp_bw_channel_coding_efficiency() to calculate the max data rate for
both DP1.4 and UHBR link rates. This trades a redundant multiply/divide
for readability.
Imre Deak [Thu, 16 Nov 2023 13:18:39 +0000 (15:18 +0200)]
drm/i915/dp: Report a rounded-down value as the maximum data rate
Callers of intel_dp_max_data_rate() use the return value as an upper
bound for the BW a given mode requires. As such the rounding shouldn't
result in a bigger value than the actual upper bound. Use round-down
instead of -closest accordingly.
Imre Deak [Fri, 17 Nov 2023 15:09:29 +0000 (17:09 +0200)]
drm/i915/dp_mst: Fix PBN / MTP_TU size calculation for UHBR rates
Atm the allocated MST PBN value is calculated from the TU size (number
of allocated MTP slots) as
PBN = TU * pbn_div
pbn_div being the link BW for each MTP slot. For DP 1.4 link rates this
worked, as pbn_div there is guraranteed to be an integer number, however
on UHBR this isn't the case. To get a PBN, TU pair where TU is a
properly rounded-up value covering all the BW corresponding to PBN,
calculate first PBN and from PBN the TU value.
Calculate PBN directly from the effective pixel data rate, instead of
calculating it indirectly from the corresponding TU and pbn_div values
(which are in turn derived from the pixel data rate and BW overhead).
Add a helper function to calculate the effective data rate, also adding
a note that callers of intel_dp_link_required() may also need to check
the effective data rate (vs. the data rate w/o the BW overhead).
While at it add a note to check if WA#14013163432 is applicable.
v2:
- Fix PBN calculation, deriving it from the effective data rate directly
instead of using the indirect TU and pbn_div values for this.
- Add a note about WA#14013163432. (Arun)
v3:
- Fix rounding up quotient while calculating remote_tu. (Ville)
Imre Deak [Thu, 16 Nov 2023 13:18:37 +0000 (15:18 +0200)]
drm/i915/dp_mst: Calculate the BW overhead in intel_dp_mst_find_vcpi_slots_for_bpp()
The next patch will calculate the PBN value directly from the pixel data
rate and the BW allocation overhead, not requiring the data, link M/N
and TU values for this. To prepare for that move the calculation of BW
overheads from intel_dp_mst_compute_m_n() to
intel_dp_mst_find_vcpi_slots_for_bpp().
While at it store link_bpp in a .4 fixed point format.
projects / mirror_ubuntu-kernels.git / log