Age | Commit message (Collapse) | Author |
|
Enable Pipe Degamma for XE_LPD. Extend the legacy implementation
to incorparate the extended lut size for XE_LPD.
v2: Added a helper for degamma lut size (Ville)
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211207071135.3660332-3-uma.shankar@intel.com
|
|
Enable pipe color support for Display 13 platforms. Currently
limit to just 10bit gamma and later extend it for logarithmic
gamma, once the new UAPI is agreed by community and implemented
by a userspace consumer.
v2: Updated dev_priv to i915 (Ville)
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211207071135.3660332-2-uma.shankar@intel.com
|
|
Increase the max size of DMC on ADL-P to account for support of new
features in the current/upcoming DMC versions.
Signed-off-by: Madhumitha Tolakanahalli Pradeep <madhumitha.tolakanahalli.pradeep@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211207023718.322349-1-madhumitha.tolakanahalli.pradeep@intel.com
|
|
Certain functions within i915 uses macros that are defined for
specific architectures by the mmu, such as _PAGE_RW and _PAGE_PRESENT
(Some architectures don't even have these macros defined, like ARM64).
Instead of re-using bits defined for the CPU, we should use bits
defined for i915. This patch introduces two new 64 bit macros,
GEN8_PAGE_PRESENT and GEN8_PAGE_RW, to check for bits 0 and 1 and, to
replace all occurrences of _PAGE_RW and _PAGE_PRESENT within i915.
v2(Michael Cheng): Use GEN8_ instead of I915_
Signed-off-by: Michael Cheng <michael.cheng@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
[ Move defines together with other GEN8 defines ]
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211206215245.513677-2-michael.cheng@intel.com
|
|
Since commit 8f59ee9a570c ("drm/msm/dsi: Adjust probe order"), the
DSI host gets initialized earlier, but this caused unability to probe
the entire stack of components because they all depend on interrupts
coming from the main `mdss` node (mdp5, or dpu1).
To fix this issue, move mdss device initialization (which include irq
domain setup) to msm_mdev_probe() time, as to make sure that the
interrupt controller is available before dsi and/or other components try
to initialize, finally satisfying the dependency.
Fixes: 8f59ee9a570c ("drm/msm/dsi: Adjust probe order")
Co-Developed-By: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20211201202023.2313971-1-dmitry.baryshkov@linaro.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
In preparation for registering the mdss interrupt controller earlier,
move the allocation of msm_drm_private from component bind time to
msm_drv probe; this also allows us to use the devm variant of kzalloc.
Since it is not right to allocate the drm_device at probe time (as
it should exist only when all components are bound, and taken down
when components get cleaned up), the only way to make this happen is
to pass a pointer to msm_drm_private as driver data (like done in
many other DRM drivers), instead of one to drm_device like it's
currently done in this driver.
This is also simplifying some bind/unbind functions around drm/msm,
as some of them are using drm_device just to grab a pointer to the
msm_drm_private structure, which we now retrieve in one call.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20211201105210.24970-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
Backmerge drm-next to pull in:
8f59ee9a570c ("drm/msm/dsi: Adjust probe order")
Signed-off-by: Rob Clark <robdclark@chromium.org>
|
|
The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-Car V3U
SoC. It currently supports DSI mode only.
Signed-off-by: LUU HOAI <hoai.luu.ub@renesas.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Tested-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
|
|
On platforms with an external clock, both the group and crtc must be
handled accordingly to correctly pass through the external clock and
configure the DU to use the external rate.
The CRTC support was missed while adding the DSI support on the r8a779a0
which led to the output clocks being incorrectly determined.
Ensure that when a CRTC is routed through the DSI encoder, the external
clock is used without any further divider being applied.
Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The DSI output names were not added when the DSI pipeline support was
introduced.
Add the correct labels for these outputs, and fix the sort order to
match 'enum rcar_du_output' while we are here.
Fixes: b291fdcf5114 ("drm: rcar-du: Add r8a779a0 device support")
Suggested-by: Biju Das <biju.das.jz@bp.renesas.com>
Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
When the CMM is enabled, an offset of 25 pixels must be subtracted from
the HDS (horizontal display start) and HDE (horizontal display end)
registers. Fix the timings calculation, and take this into account in
the mode validation.
This fixes a visible horizontal offset in the image with VGA monitors.
HDMI monitors seem to be generally more tolerant to incorrect timings,
but may be affected too.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The meaning of the 'imply' keyword has changed recently, and neither the
old meaning (select the symbol if its dependencies are met) nor the new
meaning (enable it by default, but let the user set any other setting)
is what we want here.
Work around this by adding two more Kconfig options that lead to
the correct behavior: if DRM_RCAR_USE_CMM and DRM_RCAR_USE_LVDS
are enabled, that portion of the driver becomes usable, and no
configuration results in a link error.
This avoids a link failure:
arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_begin':
rcar_du_crtc.c:(.text+0x1444): undefined reference to `rcar_cmm_setup'
arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable':
rcar_du_crtc.c:(.text+0x14d4): undefined reference to `rcar_cmm_enable'
arm-linux-gnueabi-ld: rcar_du_crtc.c:(.text+0x1548): undefined reference to `rcar_cmm_setup'
arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable':
rcar_du_crtc.c:(.text+0x18b8): undefined reference to `rcar_cmm_disable'
arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function `rcar_du_modeset_init':
Link: https://lore.kernel.org/all/20200417155553.675905-5-arnd@arndb.de/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
|
The aspeed driver uses the gem_cma_helper code, but does
noto enforce enabling this through Kconfig:
x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_drv.o:(.rodata+0x2c8): undefined reference to `drm_gem_cma_prime_import_sg_table'
x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_drv.o:(.rodata+0x2d8): undefined reference to `drm_gem_cma_dumb_create'
x86_64-linux-ld: drivers/gpu/drm/aspeed/aspeed_gfx_crtc.o: in function `aspeed_gfx_pipe_update':
aspeed_gfx_crtc.c:(.text+0xe5): undefined reference to `drm_fb_cma_get_gem_obj'
Add the same 'select' that is used in other such drivers.
Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211204174637.1160725-2-arnd@kernel.org
|
|
The fsl-dcu driver uses the gem_cma_helper code, but does
noto enforce enabling this through Kconfig:
arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o:(.rodata+0x32c): undefined reference to `drm_gem_cma_prime_import_sg_table'
arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.o:(.rodata+0x334): undefined reference to `drm_gem_cma_dumb_create'
arm-linux-gnueabi-ld: drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.o: in function `fsl_dcu_drm_plane_atomic_update':
fsl_dcu_drm_plane.c:(.text+0x144): undefined reference to `drm_fb_cma_get_gem_obj'
Add the same 'select' that is used in other such drivers.
Fixes: 09717af7d13d ("drm: Remove CONFIG_DRM_KMS_CMA_HELPER option")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20211204174637.1160725-1-arnd@kernel.org
|
|
Remove force probe protection from ADL_P platform. Did not obsevre
warnings, errors, flickering or any visual defects while doing ordinary
tasks like browsing and editing documents in a two monitor setup.
For more info drm-tip idle run results :
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211204010140.22839-1-clinton.a.taylor@intel.com
|
|
Originally "out_fence" was set using out_fence = sync_file_create() but
which returns NULL, but now it is set with out_fence = eb_requests_create()
which returns error pointers. The error path needs to be modified to
avoid an Oops in the "goto err_request;" path.
Fixes: 544460c33821 ("drm/i915: Multi-BB execbuf")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211202044831.29583-1-matthew.brost@intel.com
|
|
cgroup.h (therefore swap.h, therefore half of the universe)
includes bpf.h which in turn includes module.h and slab.h.
Since we're about to get rid of that dependency we need
to clean things up.
v2: drop the cpu.h include from cacheinfo.h, it's not necessary
and it makes riscv sensitive to ordering of include files.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Krzysztof Wilczyński <kw@linux.com>
Acked-by: Peter Chen <peter.chen@kernel.org>
Acked-by: SeongJae Park <sj@kernel.org>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/all/20211120035253.72074-1-kuba@kernel.org/ # v1
Link: https://lore.kernel.org/all/20211120165528.197359-1-kuba@kernel.org/ # cacheinfo discussion
Link: https://lore.kernel.org/bpf/20211202203400.1208663-1-kuba@kernel.org
|
|
From VBT, ddc pin info suggests the following mapping:
VBT DRIVER
DDI TC1->ddc_pin=3 should translate to PORT_TC1->0x9
DDI TC2->ddc_pin=4 should translate to PORT_TC2->0xa
DDI TC3->ddc_pin=5 should translate to PORT_TC3->0xb
DDI TC4->ddc_pin=6 should translate to PORT_TC4->0xc
Adding pin map to facilitate this translation as we cannot use existing
icl ddc pin map due to conflict with DDI C and DDI TC1 info.
Bspec:20124
v2:
- Changed Author to Tejas Upadhyay
Cc: Clinton Taylor <Clinton.A.Taylor@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com>
Signed-off-by: Tejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com>
Signed-off-by: Raviteja Goud Talla <ravitejax.goud.talla@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211203073720.3823371-1-ravitejax.goud.talla@intel.com
|
|
Bspec page says "Reset: BUS", Accordingly moving w/a's:
Wa_1407352427,Wa_1406680159 to proper function icl_gt_workarounds_init()
Which will resolve guc enabling error
v2:
- Previous patch rev2 was created by email client which caused the
Build failure, This v2 is to resolve the previous broken series
Reviewed-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Raviteja Goud Talla <ravitejax.goud.talla@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211203145603.4006937-1-ravitejax.goud.talla@intel.com
|
|
Replace the "sizes are 0 based" stuff with just straight
up -1 where needed. Less confusing all around.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-4-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
|
Now that each plane tracks its own no_fbc_reason we can print that
out in debugfs, and we can also show which plane is currently
selected for FBC duty.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-21-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
|
|
Commit 7120a447c7fe ("drm/ttm: Double check mem_type of BO while eviction")
made ttm_bo_evict_swapout_allowable() function actually check the
placement, but we always used a dummy placement in ttm_bo_swapout.
Fix this by using the real placement instead.
Signed-off-by: Christian König <christian.koenig@amd.com>
Fixes: 7120a447c7fe ("drm/ttm: Double check mem_type of BO while eviction")
Reviewed-by: Pan, Xinhui <Xinhui.Pan@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211202103828.44573-1-christian.koenig@amd.com
|
|
FBC and double wide pipe are mutually exclusive. Disable FBC when
we have to resort to double wide.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-20-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Rename the 'params' to just fbc state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-19-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Currently we track the FBC plane as a pointer under intel_fbc
and also as a i9xx_plane_id under intel_fbc_state. Just store
the pointer once in the fbc state.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-18-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
fbc->state_cache has now become useless. We can simply update
the reg params directly from the plane/crtc states during
__intel_fbc_enable().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-17-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Currently a FIFO underrun just causes FBC to be deactivated,
and later checks then prevent it from being reactivated. We
can simpify our lives a bit by logically disabling FBC on
FIFO underruns. This avoids the funny intermediate state where
FBC is logically enabled but can't actually be activated.
v2: intel_wait_for_vblank() is no more
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-16-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
intel_fbc_check_plane()
Don't really see a good reason why we can't just do the vgpu and
modparam checks already in intel_fbc_check_plane().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-15-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
In the future we may have more than one FBC instance on some
platforms. So let's just allocate it dynamically. This also
lets us fully hide the implementation from prying eyes.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-14-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
In order to better encapsulate the FBC implementation
introduce a small helper to do the plane<->FBC instance
association.
We'll also try to structure the plane init code such
that introducing multiple FBC instances will be easier
down the line.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-13-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
In order to encapsulate FBC harder let's just move the debugfs
stuff into intel_fbc.c.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-12-ville.syrjala@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
|
|
The underrun code doesn't need to know any details about FBC, so
just pass in the whole device rather than a specific FBC instance.
We could make this a bit more fine grained by also passing in the
pipe to intel_fbc_handle_fifo_underrun_irq() and letting the FBC
code figure which FBC instance (if any) is active on said pipe.
But that seems a bit overkill for this so don't bother.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-11-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Use an early return to flatten most of __intel_fbc_pre_update().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-10-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
In the future we may have multiple planes on the same pipe
capable of using FBC. Prepare for that by tracking FBC usage
per-plane rather than per-crtc.
v2: s/intel_get_crtc_for_pipe/intel_crtc_for_pipe/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-9-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Pass the FBC instance instead of the crtc to a bunch of places.
We also adjust intel_fbc_post_update() to do the
intel_fbc_get_reg_params() things instead of doing it from the lower
level function (which also gets called for front buffer tracking).
Nothing in there will change during front buffer updates.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-8-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
The FBC state cache and params are now nearly identical. Just
use the same structure for both.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-7-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
There isn't a good reason why we'd have to cache all this
plane state stuff in the FBC state. Instead we can just
pre-calculate what FBC will really need.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-6-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Move intel_fbc_override_cfb_stride() next to its cousins.
Helps with later patches.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-5-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
There's no need to store all this stuff in intel_fbc_state_cache.
Just check it all against the plane/crtc states and store only
what we need. Probably more should get nuked still, but this
is a start.
So what we'll do is:
- each plane will check its own state and update its local
no_fbc_reason
- the per-plane no_fbc_reason (if any) then gets propagated
to the cache->no_fbc_reason while doing the actual update
- fbc->no_fbc_reason gets updated in the end with either
the value from the cache or directly from frontbuffer
tracking
It's still a bit messy, but should hopefuly get cleaned up
more in the future. At least now we can observe each plane's
reasons for rejecting FBC now more consistently, and we don't
have so mcuh redundant state store all over the place.
v2: store no_fbc_reason per-plane instead of per-pipe
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-4-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
No reason to burden the caller with the details on how the minimum
compression limit is calculated, so just pass in the whole plane
state instead of just the cpp value.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-3-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
The ilk fbc watermark computation uses intel_fbc_is_active() which
is racy since we don't know whether FBC will be enabled or not at
some point. So let's just assume it will be if both HAS_FBC()
and the modparam agree.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211124113652.22090-2-ville.syrjala@linux.intel.com
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
|
|
Rename the PLANE_CUS_CTL Y plane selection bits to actually
say "Y plane".
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-6-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
|
Rename the YUV byte order bits to be a bit more consistent.
v2: Deal with gvt
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-3-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
|
Let's just stick to 32bit mmio accesses so we can get rid
of the bare "uncore" reg access in display code. The register
are defined as 32bit in the spec anyway.
We could define a 64bit "de" variant I suppose, but doesn't
really make much sense just for this one case, and when we
start to use the DSB for this stuff we'd also need another
64bit variant for that. Just easier to do 32bit always.
While at it we can reorder stuff a bit so that we write the
registers in order of increasing offset (more or less).
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211201152552.7821-2-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
|
|
Break the dependency on i915_drv.h.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ee740f494e416d875e057c2eda585f4e66d65500.1638366969.git.jani.nikula@intel.com
|
|
Avoid looking into the guts of struct drm_i915_private in
headers. Again, converting an inline function to a macro is less than
ideal, but avoids having to pull in i915_drv.h just for the to_i915()
part.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/ed6c43455d13c90ebfed442b196625af5e6ede88.1638366969.git.jani.nikula@intel.com
|
|
It's not the ideal location, but a better alternative than
i915_drv.h. The goal is to break the intel_display_types.h to i915_drv.h
dependency.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9f882eff78cdc6b28c18e73f5e53f57e413240dc.1638366969.git.jani.nikula@intel.com
|
|
This is far from ideal, but it reduces the i915_drv.h dependency from
intel_display_types.h. Maybe in the future we'll need a better split.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c6c60d9a8f6dcd1fa2f4b187000c5bb6843a1371.1638366969.git.jani.nikula@intel.com
|
|
Move fb functions where they belong, and un-inline to avoid looking into
struct drm_i915_private guts in header files.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4aa89f113ce6d840d62f50c989e2a1415483557c.1638366969.git.jani.nikula@intel.com
|
|
Move a number of crtc/pipe related functions to intel_crtc.[ch], and
un-inline to avoid looking into struct drm_i915_private guts in header
files.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c0be2adc4a7f7e72a47e12a57f742aaa42b813e6.1638366969.git.jani.nikula@intel.com
|