Jouni Högander [Thu, 13 Feb 2025 06:47:52 +0000 (08:47 +0200)]
drm/i915/psr: Use PSR2_MAN_TRK_CTL CFF bit only to send full update
We are preparing for a change where only frontbuffer flush will use
single full frame bit of a new register (SFF_CTL) available on LunarLake
onwards.
It shouldn't be necessary to have SFF bit set if CFF bit is set in
PSR2_MAN_TRK_CTL -> removing setting it on all platforms as there is not
reason to have it different on older platforms.
Jani Nikula [Wed, 12 Feb 2025 16:36:43 +0000 (18:36 +0200)]
drm/i915/display: convert i915_pipestat_enable_mask() to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert i915_pipestat_enable_mask() to struct intel_display,
allowing further conversions elsewhere.
Jani Nikula [Wed, 12 Feb 2025 16:36:42 +0000 (18:36 +0200)]
drm/i915/display: convert intel_fifo_underrun.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_fifo_underrun.[ch] to
struct intel_display.
Jani Nikula [Wed, 12 Feb 2025 16:36:41 +0000 (18:36 +0200)]
drm/i915/combo-phy: convert intel_combo_phy.[ch] to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert as much as possible of intel_combo_phy.[ch] to struct
intel_display, along with intel_phy_is_combo() in intel_display.c.
Drive-by convert some drm_dbg() to drm_dbg_kms() while at it.
Jani Nikula [Wed, 12 Feb 2025 16:36:39 +0000 (18:36 +0200)]
drm/i915/display: convert intel_mode_valid_max_plane_size() to intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the intel_mode_valid_max_plane_size() helper to struct
intel_display, allowing further conversions elsewhere.
Jani Nikula [Wed, 12 Feb 2025 16:36:38 +0000 (18:36 +0200)]
drm/i915/display: convert intel_cpu_transcoder_mode_valid() to intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the intel_cpu_transcoder_mode_valid()() helper to
struct intel_display, allowing further conversions elsewhere.
Jani Nikula [Wed, 12 Feb 2025 16:36:36 +0000 (18:36 +0200)]
drm/i915/display: convert intel_set_{cpu,pch}_fifo_underrun_reporting() to intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert intel_set_cpu_fifo_underrun_reporting() and
intel_set_pch_fifo_underrun_reporting() to struct intel_display, along
with some of the call chains from there.
Jani Nikula [Wed, 12 Feb 2025 16:36:34 +0000 (18:36 +0200)]
drm/i915/display: convert assert_port_valid() to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the assert_port_valid() helper to struct intel_display,
allowing further conversions elsewhere.
Jani Nikula [Wed, 12 Feb 2025 16:36:33 +0000 (18:36 +0200)]
drm/i915/display: convert assert_transcoder*() to struct intel_display
Going forward, struct intel_display is the main display device data
pointer. Convert the assert_transcoder*() helpers to struct
intel_display, allowing further conversions elsewhere.
Do a few small opportunistic conversions right away.
Ville Syrjälä [Mon, 10 Feb 2025 16:07:11 +0000 (18:07 +0200)]
drm/i915/vrr: Check that the push send bit is clear after delayed vblank
Since we don't do mailbox updates the push send bit
should alwyas clear by the time the delay vblank fires
and the flip completes. Check for that to make sure we
haven't screwed up the sequencing/vblank evasion/etc.
On the DSB path we should be able to guarantee this
since we don't have to deal with any scheduler latencies
and whatnot. I suppose unexpected DMA/memory latencies
might be the only thing that might trip us up here.
For the MMIO path we do always have a non-zero chance
that vblank evasion fails (since we can't really guarantee
anything about the scheduling behaviour). That could trip
up this check, but that seems fine since we already print
errors for other types of vblank evasion failures.
Should the CPU vblank evasion actually fail, then the push
send bit can still be set when the next commit happens. But
both the DSB and MMIO paths should handle that situation
gracefully.
v2: Only check once instead of polling for two scanlines
since we should now be guaranteed to be past the
delayed vblank.
Also check in the MMIO path for good measure
v3: Skip the push send check when VRR is disabled.
With joiner the secondary pipe's DSBs doen't have access
to the transcoder registers, and so doing this check
there triggers a reponse timeout error on the DSB. VRR
is not currently allowed when using joiner, so this will
prevent the bogus register access.
Ville Syrjälä [Fri, 7 Feb 2025 22:31:57 +0000 (00:31 +0200)]
drm/i915/vrr: Reorder the DSB "wait for safe window" vs. TRANS_PUSH
Currently we trigger the push send first, then follow it with
a "wait for safe window". That approach no longer works on
PTL+ because triggering the push send immediately ends the safe
window. On prior hardware the safe window extended past the
push being sent (presumably all the way to the pipe's delayed
vblank).
In order to deal with the new hardware behaviour we must reverse
the order of these two operations: first wait for safe window,
then trigger the push.
The only slight danger with this approach is that if we mess up
the vblank evasion around the vmax decision boundary the push
might get postponed until after the next frame's vactive. But
assuming we don't mess up the vblank evasion this approach is
completely safe.
As a slight bonus we can perform the push after we've done the
LUT writes as well, meaning we no longer have to worry about
extending the vblank delay to provide enough time for LUT
programming. Instead we will now depend on the vblank evasion
at vmax decision boundary to guarantee this.
However vblank delay (or framestart delay) is still the only
way to provide extra time for the LUT programming in the
non-VRR use cases. Let's assume we don't need anything extra
for now, but eventually we should come up with some proper
estimates on how long the LUT programming can take and
configure the vblank delay accordingly for the non-VRR use
cases.
Ville Syrjälä [Fri, 7 Feb 2025 22:31:55 +0000 (00:31 +0200)]
drm/i915/dsb: Compute use_dsb earlier
Skip all the commit completion interrupt stuff on the
chained DSB when we don't take the full DSB path (ie. when
the plane/pipe programming is done via MMIO). The commit
completion will be done via the CPU side vblank interrupt.
Currently this is just a redundant interrupt, so not a big
deal. But in the future we'll be moving the TRANS_PUSH write
into the chained DSB as well, and that we definitely don't
want to do when it's also being done by the CPU from
intel_pipe_update_end().
Ville Syrjälä [Fri, 7 Feb 2025 22:31:54 +0000 (00:31 +0200)]
drm/i915/vrr: Account for TRANS_PUSH delay
When we send a push during vblank the TRANS_PUSH write happens
at some point during a scanline, and the hardware picks it up
on the next scanline. Thus there is up to one extra scanline
of delay between the TRANS_PUSH write and the delayed vblank
triggering. Account for that during intel_dsb_wait_vblank_delay()
so that we are guaranteed to be past the delayed vblank before
we trigger the completion interrupt for the commit.
Ville Syrjälä [Fri, 7 Feb 2025 22:31:53 +0000 (00:31 +0200)]
drm/i915/vrr: Don't send push for legacy cursor updates
We don't really want legacy cursor updates to trigger
VRR pushes because these can happen willy nilly and we
generally want more precise control over the pushes.
The fastpath in intel_legacy_cursor_update() doesn't
send pushes, but if we punt to the full commit path
(with the flip completion short circuited) we are currently
sending pushes. Skip those as well so that they don't
interfere with the push handling from normal commits.
Ville Syrjälä [Fri, 7 Feb 2025 22:31:52 +0000 (00:31 +0200)]
drm/i915/dsb: Move the +1 usec adjustment into dsb_wait_usec()
The "wait usec" DSB command doesn't quite seem to able to
guarantee that it always waits at least the specified
amount of usecs. Some of that could be just because it
supposedly just does some kind of dumb timestamp comparison
internally. But I also see cases where two hardware timestamps
sampled on each side of the "wait usec" command come out one
less than expected. So it looks like we always need at least a
+1 to guarantee that we never wait less than specified. Always
apply that adjustment in dsb_wait_usec().
Jani Nikula [Fri, 7 Feb 2025 10:17:37 +0000 (12:17 +0200)]
drm/i915/pch: Hide PCH device IDs
Only the PCH identification code needs the PCH device IDs, as all the
PCH checks are now based on PCH type. Hide the PCH device IDs inside
intel_pch.c. Remove the unused INTEL_PCH_ID() macro while at it.
Jani Nikula [Fri, 7 Feb 2025 10:17:36 +0000 (12:17 +0200)]
drm/i915/pch: Make LPT LP a dedicated PCH type
Add PCH type PCH_LPT_LP and rename PCH_LPT to PCH_LPT_H for
consistency. Keep the existing HAS_PCH_LPT*() macros, but express them
in terms of the PCH types instead of looking at the device IDs
directly. This makes the PCH checks independent of the PCH device IDs.
Suraj Kandpal [Wed, 12 Feb 2025 07:45:41 +0000 (13:15 +0530)]
drm/i915/dpll: Accept intel_display as argument for shared_dpll_init
Use intel_display as an argument for intel_shared_dpll_init() and
replace drm_i915_private in function wherever possible.
While at it prefer using display->platform.xx over IS_PLATFORM.
Initialize dpio_phy and dpio_channel since with IS_GEMINILAKE()
and IS_BROXTON() compiler knows it will return false for xe but
since display->platform.xx is a runtime check which means the
compiler sees a potential path where uninitialized variables
could be accessed and raises a warning.
--v2
-Amend commit message to explain why some variables were
initialized [Jani]
Suraj Kandpal [Wed, 12 Feb 2025 07:45:38 +0000 (13:15 +0530)]
drm/i915/dpll: Use intel_display possible in shared_dpll_mgr hooks
We use intel_display for function hooks of shared_dpll_mgr and
any function that gets called when we use for_each_shared_dpll.
This also contains some opportunistic display->platform.xx changes
all to reductate the use of drm_i915_private.
Suraj Kandpal [Wed, 12 Feb 2025 07:45:37 +0000 (13:15 +0530)]
drm/i915/dpll: Use intel_display for dpll dump and compare hw state
Let's use intel_display for dpll dump and compare hw state. This also
helps elimanate drm_i915_private dependency from i915_shared_dplls_info
in intel_display_debugfs.c
Suraj Kandpal [Wed, 12 Feb 2025 07:45:36 +0000 (13:15 +0530)]
drm/i915/dpll: Change param to intel_display in for_each_shared_dpll
Change the argument of for_each_shared_dpll to take intel_display which
helps move as an ongoing effort to get rid off the dependency on
drm_i915_private. Some opportunistic changes in intel_pch_refclk done
too.
Suraj Kandpal [Wed, 12 Feb 2025 07:45:35 +0000 (13:15 +0530)]
drm/i915: Use intel_display wherever possible
Use struct intel_display wherever possible in intel_display_debug_fs.c
to reduce the use of drm_i915_private.
While at it do the opportunistic display->platform.xx replacement.
--v2
-Rebase
--v3
-Don't use inline to_intel_display [Jani]
-Don't use display debug fs as subject prefix [Jani]
Convert the remaining intel_display_power.h interfaces to
take struct intel_display instead of struct drm_i915_private.
intel_display_power.c still has some internal uses due to
i915->runtime_pm.
Looks like I missed one of myriad CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
special cases when converting the intel_display_power_{get,put}()
code to use struct intel_display. Only noticed after the fact
when building a EXPERT=n kernel :/
Ville Syrjälä [Thu, 6 Feb 2025 18:55:33 +0000 (20:55 +0200)]
drm/i915: Pimp plane debugs
Include the standard "[PLANE:%d:s]" stuff in all plane debugs
(or rather all I was able to find), to provide better information
on which plane we're actually talking about.
There are a few spots where we care about the CRTC as well, so
include that where appropriate.
intel_sprite.c was partially converted to struct intel_display.
Finish the job now that we can deal with the platform checks
as well.
And while at it we also move the 'display' variable declaration
to be the first thing in most functions, consistency. We can
actually do that now since intel_display() accepts the intel_plane
and intel_plane_state types.
Ville Syrjälä [Thu, 6 Feb 2025 18:55:24 +0000 (20:55 +0200)]
drm/i915: Decouple intel_fb_bo.h interfaces from driver specific types
Make the intel_fb_bo.h interfaces operated purely in base
drm_ types so that each driver (i915 and xe) doesn't have to
know about each other, or the display stuff.
Ville Syrjälä [Thu, 6 Feb 2025 18:55:22 +0000 (20:55 +0200)]
drm/i915: Pass intel_display to intel_scanout_needs_vtd_wa()
Now that intel_scanout_needs_vtd_wa() is no longer used from
the gem code we can convert it to take struct intel_display.
which will help with converting the low level plane code over
as well.
Suraj Kandpal [Thu, 6 Feb 2025 06:32:50 +0000 (12:02 +0530)]
drm/i915/backlight: Modify function to get VESA brightness in Nits
Modify vesa_get_brightness function to take into account
luminance_control_support and based on that read the appropriate
register and return the value.
--v2
-Changes since we now use luminance instead of nits
Suraj Kandpal [Thu, 6 Feb 2025 06:32:49 +0000 (12:02 +0530)]
drm/i915/backlight: Check Luminance based brightness control for VESA
Check if we are capable of controlling brightness via luminance
which is dependent on PANEL_LUMINANCE_CONTROL_CAPABLE bit being set
on EDP_GENERAL_CAPABILITY_2 register.
--v2
-Prefer using luminance rather than nits [Jani]
-Fix commit message
--v3
-Fix the bit name used in commit message [Arun]
-Use correct edp_dpcd[] to check the capability [Arun]
Suraj Kandpal [Thu, 6 Feb 2025 06:32:48 +0000 (12:02 +0530)]
drm/i915/backlight: Use proper interface based on eDP version
eDP is supposed to use VESA interface when using revision 1.5 and above,
use Intel interface for backlight control otherwise. Add check to
use correct interface.
Imre Deak [Thu, 6 Feb 2025 00:17:26 +0000 (02:17 +0200)]
drm/i915/dp_mst: Fix getting display pointer in intel_dp_mst_compute_min_hblank()
The MST intel_connector::encoder pointer is NULL if the connector hasn't
been enabled before, so it can't be used to retrieve the display
pointer. Use instead the crtc_state and drop the unused connector
parameter.
v2: Use the crtc_state and drop the unused connector parameter.
Ville Syrjälä [Wed, 22 Jan 2025 15:17:55 +0000 (17:17 +0200)]
drm/i915/fbdev: Use fb->normal_view.gtt
Grab the GTT view for the fbdev fb pinning from
fb->normal_view.gtt instead of having and extra one on
the stack. Seems safer in case we ever put any new
information into normal GTT views.
Ville Syrjälä [Wed, 22 Jan 2025 15:17:54 +0000 (17:17 +0200)]
drm/i915: Use per-plane VT-d guard numbers
Bspec lists different VT-d guard numbers (the number of dummy
padding PTEs) for different platforms and plane types. Use those
instead of just assuming the max glk+ number for everything.
This could avoid a bit of overhead on older platforms due to
reduced padding, and it makes it easier to cross check with the
spec.
Note that VLV/CHV do not document this w/a at all, so not sure
if it's actually needed or not. Nor do we actually know how much
padding is required if it is needed. For now use the same 128
PTEs that we use for snb-bdw primary planes.
Ville Syrjälä [Wed, 22 Jan 2025 15:17:53 +0000 (17:17 +0200)]
drm/i915: Calculate the VT-d guard size in the display code
Currently i915_gem_object_pin_to_display_plane() uses
i915_gem_object_get_tile_row_size() to calculate the tile row
size for the VT-d guard w/a. That's not really proper since
i915_gem_object_get_tile_row_size() only works for fenced BOs,
nor does it take rotation into account.
Remedy the situation by calculating the VT-d guard size in the
display code where we have more information readily available.
Although the default guard size (168 PTEs now) should cover
the more typical fb size use cases anyway, and only very large
Y/Yf-tiled framebuffers might have tile row size that exceeds it.
Ville Syrjälä [Wed, 22 Jan 2025 15:17:52 +0000 (17:17 +0200)]
drm/i915: Use more optimal VTd alignment for planes
Depending on the platform and/or plane type we can get away
with a bit less alignment in the VT-d w/a. Reduce the numbers
accordingly.
Note that it's not actually clear in VLV/CHV need this w/a,
and if they do we don't actually know what kind of alignment
is sufficient. Leave the 256k alignment in place for now, but
toss in a FIXME.
Ville Syrjälä [Wed, 22 Jan 2025 15:17:51 +0000 (17:17 +0200)]
drm/i915: Move VT-d alignment into plane->min_alignment()
Currently we don't account for the VT-d alignment w/a in
plane->min_alignment() which means that panning inside a larger
framebuffer can still cause the plane SURF to be misaligned.
Fix the issue by moving the VT-d alignment w/a into
plane->min_alignment() itself (for the affected platforms).
Make the conditions easier to follow. We don't do anything for
!psr->enabled, so hoist psr->enabled check higher, avoiding all the
checks when !psr->enabled. Stop the bitwise OR abuse on booleans by
removing the temporary variable altogether.
Jani Nikula [Tue, 4 Feb 2025 13:58:43 +0000 (15:58 +0200)]
drm/i915/lspcon: rename interfaces to intel_lspcon_* to unify
Rename all the main functions to have intel_lspcon_ prefix. Keep the
infoframes hooks named lspcon_ for now, and grouped together, as there'd
be a clash with intel_lspcon_infoframes_enabled().
Jani Nikula [Tue, 4 Feb 2025 13:58:40 +0000 (15:58 +0200)]
drm/i915/lspcon: change signature of lspcon_detect_hdr_capability()
Switch from struct intel_lspcon to struct intel_digital_port to unify,
and return the value so the caller doesn't have to look at
lspcon->hdr_detected directly.
Gustavo Sousa [Fri, 24 Jan 2025 19:12:34 +0000 (16:12 -0300)]
drm/i915/dmc_wl: Do not check for DMC payload
Enabling and disabling of DMC wakelock is already coupled with enabling
and disabling of dynamic DC states, which already depend on the DMC
being properly loaded. As such, we do not need to check if we already
have a DMC payload parsed in __intel_dmc_wl_supported().
Furthermore, the presence of such a check causes inconsistencies in the
refcount if the following sequence of events happen:
1. A call to one of the register accessors from intel_de.h is done
before the DMC payload is parsed. That causes intel_dmc_wl_get() to
be called. Suppose the register offset qualifies as needing the
wakelock.
In normal circumstances, the refcount would be incremented, but,
because __intel_dmc_wl_supported() returns false, the refcount is
untouched.
2. In a separate worker thread, the DMC firmware is parsed. Parsing of
the DMC payload is finished before the corresponding
intel_dmc_wl_put() from (1) is called.
3. When in the context of (1), intel_dmc_wl_put() gets called, now we
have __intel_dmc_wl_supported() returning true and we hit the
warning, because the code doesn't expect a zero refcount.
Let's remove that check, since it is unnecessary and causes the
inconsistency illustrated above.
Jani Nikula [Tue, 4 Feb 2025 15:49:25 +0000 (17:49 +0200)]
drm/i915/dp: Fix potential infinite loop in 128b/132b SST
Passing 0 as the step only works when there are other reasons to break
out of the BPP loop in intel_dp_mtp_tu_compute_config(). Otherwise, an
infinite loop might occur. Fix it by explicitly checking for 0 step.
Fixes: ef0a0757bbea ("drm/i915/dp: compute config for 128b/132b SST w/o DSC") Reported-by: Imre Deak <imre.deak@intel.com> Closes: https://lore.kernel.org/r/Z6I0knh2Kt5T0JrT@ideak-desk.fi.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250204154925.3001781-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Jani Nikula [Tue, 4 Feb 2025 15:37:17 +0000 (17:37 +0200)]
drm/i915/mst: fix INT_MAX to .4 fixed point conversion mistake
intel_dp_mtp_tu_compute_config() conversion to use .4 fixed point didn't
take into account that intel_dp_mst_max_dpt_bpp() may return INT_MAX
when the transport limitation is not relevant. Converting INT_MAX to .4
fixed point results in -1.0, which then gets used as if it were a real
max BPP value:
i915 0000:00:02.0: [drm:intel_dp_mtp_tu_compute_config [i915]] Limiting bpp to max DPT bpp (24.0000 -> -1.0000)
i915 0000:00:02.0: [drm:intel_dp_mtp_tu_compute_config [i915]] Looking for slots in range min bpp 18.0000 max bpp -1.0000
Just return 0 for "no max DPT BPP", and handle it explicitly.
Fixes: 67782bf6e8a6 ("drm/i915/mst: Convert intel_dp_mtp_tu_compute_config() to .4 format") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13624 Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250204153717.2996923-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Arun R Murthy [Wed, 22 Jan 2025 05:55:42 +0000 (11:25 +0530)]
drm/i915/dp: Guarantee a minimum HBlank time
Mandate a minimum Hblank symbol cycle count between BlankingStart and
BlankingEnd in 8b/10b MST and 128b/132b mode.
v2: Affine calculation/updation of min HBlank to dp_mst (Jani)
v3: moved min_hblank from struct intel_dp to intel_crtc_state (Jani)
v4: use max/min functions, change intel_xx *intel_xx to intel_xx *xx
(Jani)
Limit hblank to 511 and accommodate BS/BE in calculated value
(Srikanth)
v5: Some spelling corrections (Suraj)
v6: Removed DP2.1 in comment as this is applicable for both DP2.1 and
DP1.4 (Suraj)
v7: crtc_state holds the logical values and the register value
computation is moved to mst_enable() (Jani)
v8: Limit max hblank to 0x10, disable min_hblank on mst_disable (Jani)
Gustavo Sousa [Mon, 3 Feb 2025 20:58:58 +0000 (17:58 -0300)]
drm/i915/dmc_wl: Track INITIATE_PM_DMD_REQ for DC5
The Bspec has been updated to include INITIATE_PM_DMD_REQ in the set of
register offsets that require the DMC wakelock for access during DC5.
Update our table accordingly.
Jani Nikula [Fri, 31 Jan 2025 12:50:06 +0000 (14:50 +0200)]
drm/i915/dp: Pass connector state all the way to dsc_compute_link_config()
Going forward, we'll need the connector state in
dsc_compute_link_config(). Pass it along through the chain. Maintain the
same parameter order where relevant.
With just the one platform independent loop left in
do_dsc_compute_compressed_bpp(), we don't really need the extra function
that is simply becoming increasingly hard to even figure out a decent
name for. Just merge the whole thing to
dsc_compute_compressed_bpp(). Good riddance to the short lived
do_dsc_compute_compressed_bpp().
Jani Nikula [Fri, 31 Jan 2025 12:50:00 +0000 (14:50 +0200)]
drm/i915/dp: Move force_dsc_fractional_bpp_en check to intel_dp_dsc_valid_bpp()
Add the fractional DSC BPP force check to intel_dp_dsc_valid_bpp(), and
use that in xelpd_dsc_compute_link_config(). This is another step closer
towards unifying the platform specific functions.
Instead of iterating the valid BPP array directly, switch to the same
approach as xelpd_dsc_compute_link_config(), with a separate function to
check if the DSC BPP is valid. This prepares us for unifying the
platform specific functions.
Jani Nikula [Fri, 31 Jan 2025 12:49:58 +0000 (14:49 +0200)]
drm/i915/dp: Move max DSC BPP reduction one level higher
Now that {icl,xelpd}_dsc_compute_link_config() take .4 fixed point as
parameter, move the common max DSC BPP reduction one level higher. Use
intel_dp_dsc_bpp_step() to compute the step, and pass on to both
platform specific functions. (Though it's unused for now in
icl_dsc_compute_link_config()).
We can drop the pipe_bpp and connector parameters.
Jani Nikula [Fri, 31 Jan 2025 12:49:57 +0000 (14:49 +0200)]
drm/i915/dp: Pass .4 BPP values to {icl,xelpd}_dsc_compute_link_config()
Try to keep the variables in the same domain a bit longer to reduce
juggling between integers and .4 fixed point. Change parameter order to
min, max while at it.
For now, keep the juggling in dsc_compute_compressed_bpp() ensure
min/max will always have 0 fractional part. To be fixed later.
projects / thirdparty / linux.git / log
