The VOP2 has limitations on its input and output sizes. The clipped
display region must be at least 4px in each dimension for both
framebuffer source and plane destination, and the clipped source region
must be no greater than a per-version limit.
It is never valid for VOP2 to have a framebuffer which is less than four
pixels in either dimension, so declare that as our min width/height,
enforced by AddFB failing if the user tries. It can theoretically be
valid to have a single large framebuffer of which only certain clipped
regions are shown, but this is a very uncommon case. Declaring to
userspace that the framebuffer's maximum width and height is the maximum
source clip helps it make better decisions as to which mode to use,
instead of trying unsupported sizes and having to fall back.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20251015110042.41273-3-daniels@collabora.com
A plane check failing is a normal and expected condition, as userspace
isn't aware of the specific constraints and will try any and every
combination until one succeeds. Push this down to a debug message, so
users can see it if they want to, but make sure we don't spam the log
during normal operation.
Fixes: 604be85547 ("drm/rockchip: Add VOP2 driver")
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20251015110042.41273-2-daniels@collabora.com
Aside from the main CMA region, it can be useful to allow userspace to
allocate from the other CMA reserved regions.
Indeed, those regions can have specific properties that can be useful to
a specific us-case.
For example, one of them platform I've been with has ECC enabled on the
entire memory but for a specific region. Using that region to allocate
framebuffers can be particular beneficial because enabling the ECC has a
performance and memory footprint cost.
Thus, exposing these regions as heaps user-space can allocate from and
import wherever needed allows to cover that use-case.
For now, only shared-dma-pools regions with the reusable property (ie,
backed by CMA) are supported, but eventually we'll want to support other
DMA pools types.
Since we collected all the CMA regions created during boot, we can
simply iterate over all of them to create the heaps.
This has a weird interaction with the recent work on the CMA name, in
particular the backward compatibility code created by commit
854acbe75f ("dma-buf: heaps: Give default CMA heap a fixed name").
Indeed, the old name was either 'reserved', or the name of the
reserved-memory region device tree node if the linux,cma-default
property was set.
In both these cases, we have now collected this region during boot, and
we're using the same name. So we're now largely redundant with the
code to handle backward compatibility code, and we can thus remove it
and the associated Kconfig option.
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: rebased the doc to latest]
Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-5-04ce150ea3d9@kernel.org
In order to create a CMA dma-buf heap instance for each CMA heap region
in the system, we need to collect all of them during boot.
They are created from two main sources: the reserved-memory regions in
the device tree, and the default CMA region created from the
configuration or command line parameters, if no default region is
provided in the device tree.
Let's collect all the device-tree defined CMA regions flagged as
reusable.
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-3-04ce150ea3d9@kernel.org
In order to create a CMA heap instance for each CMA region found in the
system, we need to register each of these instances.
While it would appear trivial, the CMA regions are created super early
in the kernel boot process, before most of the subsystems are
initialized. Thus, we can't just create an exported function to create a
heap from the CMA region being initialized.
What we can do however is create a two-step process, where we collect
all the CMA regions into an array early on, and then when we initialize
the heaps we iterate over that array and create the heaps from the CMA
regions we collected.
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-2-04ce150ea3d9@kernel.org
Since we're going to introduce multiple instances of the CMA heap
driver, there's no single CMA heap anymore.
Let's use the heap name instead to differentiate between all the heaps
available in the system.
While we're at it, let's also rework the backward compatibility part to
make it easier to amend later on.
Reviewed-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org>
[sumits: rebased to latest Doc]
Link: https://lore.kernel.org/r/20251013-dma-buf-ecc-heap-v8-1-04ce150ea3d9@kernel.org
Replace all dev_err(), dev_warn(), dev_info() and DRM_ERROR/WARN/INFO()
calls in drivers/gpu/drm/arm/display/komeda/komeda_crtc.c with the
corresponding drm_err(), drm_warn(), and drm_info() helpers.
The new drm_*() logging functions take a struct drm_device * as the
first argument. This allows the DRM core to prefix log messages with
the specific DRM device name and instance, which is essential for
distinguishing logs when multiple GPUs or display controllers are present.
This change aligns komeda with the DRM TODO item: "Convert logging to
drm_* functions with drm_device parameter".
Signed-off-by: Rahul Kumar <rk0006818@gmail.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Liviu Dudau <liviu.dudau@arm.com>
Link: https://lore.kernel.org/r/20250926093008.1949131-1-rk0006818@gmail.com
Currently the TIMER_BASE_CONFIG0 register gets initialized to a fixed
value as initially found in vendor driver code supporting the RK3588
SoC. As a matter of fact the value matches the rate of the HDMI TX
reference clock, which is roughly 428.57 MHz.
However, on RK3576 SoC that rate is slightly lower, i.e. 396.00 MHz, and
the incorrect register configuration breaks CEC functionality.
Set the timer base according to the actual reference clock rate that
shall be provided by the platform driver. Otherwise fallback to the
vendor default.
While at it, also drop the unnecessary empty lines in
dw_hdmi_qp_init_hw().
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250903-rk3588-hdmi-cec-v4-2-fa25163c4b08@collabora.com
Use a vblank timer to simulate the vblank interrupt. The DRM vblank
helpers provide an implementation on top of Linux' hrtimer. Qxl
enables and disables the timer as part of the CRTC. The atomic_flush
callback sets up the event. Like vblank interrupts, the vblank timer
fires at the rate of the display refresh.
Most userspace limits its page flip rate according to the DRM vblank
event. Qxl's virtual hardware does not provide vblank interrupts, so
DRM sends each event ASAP. With the fast access times of virtual display
memory, the event rate is much higher than the display mode's refresh
rate; creating the next page flip almost immediately. This leads to
excessive CPU overhead from even small display updates, such as moving
the mouse pointer.
This problem affects qxl and all other virtual displays. See [1] for
a discussion in the context of hypervdrm.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/dri-devel/SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com/ # [1]
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://lore.kernel.org/r/20251008122911.231674-1-tzimmermann@suse.de
Use a vblank timer to simulate the vblank interrupt. The DRM vblank
helpers provide an implementation on top of Linux' hrtimer. Cirrus-qemu
enables and disables the timer as part of the CRTC. The atomic_flush
callback sets up the event. Like vblank interrupts, the vblank timer
fires at the rate of the display refresh.
Most userspace limits its page flip rate according to the DRM vblank
event. Cirrus-qemu' virtual hardware does not provide vblank interrupts,
so DRM sends each event ASAP. With the fast access times of virtual display
memory, the event rate is much higher than the display mode's refresh
rate; creating the next page flip almost immediately. This leads to
excessive CPU overhead from even small display updates, such as moving
the mouse pointer.
This problem affects cirrus-qemu and all other virtual displays. See [1]
for a discussion in the context of hypervdrm.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/dri-devel/SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com/ # [1]
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://lore.kernel.org/r/20251008121450.227997-1-tzimmermann@suse.de
Use a vblank timer to simulate the vblank interrupt. The DRM vblank
helpers provide an implementation on top of Linux' hrtimer. Bochs
enables and disables the timer as part of the CRTC. The atomic_flush
callback sets up the event. Like vblank interrupts, the vblank timer
fires at the rate of the display refresh.
Most userspace limits its page flip rate according to the DRM vblank
event. Bochs' virtual hardware does not provide vblank interrupts, so
DRM sends each event ASAP. With the fast access time of virtual display
memory, the event rate is much higher than the display mode's refresh
rate; creating the next page flip almost immediately. This leads to
excessive CPU overhead from even small display updates, such as moving
the mouse pointer.
This problem affects bochs and all other virtual displays. See [1] for
a discussion in the context of hypervdrm.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Link: https://lore.kernel.org/dri-devel/SN6PR02MB415702B00D6D52B0EE962C98D46CA@SN6PR02MB4157.namprd02.prod.outlook.com/ # [1]
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://lore.kernel.org/r/20251008093931.19138-1-tzimmermann@suse.de
Store each hardware's CRTC memory threshold in the specific instance
of struct ast_device_quirks. Removes the calls to IS_AST_GENn() from
ast_set_crtthd_reg().
The values stored in the registers appear to be plain limits. Hence
write them in the driver in decimal format instead of hexadecimal.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20251007150343.273718-4-tzimmermann@suse.de
Init the new field dclk_table in struct ast_device to the per-gen
table of DRAM clock parameters. Use the field during modesetting.
The table is static, so a setup is only required once. Removes the
call to IS_AST_GEN() from the atomic commit's code path.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com>
Link: https://lore.kernel.org/r/20251007150343.273718-2-tzimmermann@suse.de
When a BO is created, qaic will use the page allocator to request the
memory chunks that the BO will be composed of in-memory. The number of
chunks increases when memory is segmented. For example, a 16MB BO can
be composed of four 4MB chunks or 4096 4KB chunks.
A BO is then sliced into a single or multiple slices to be transferred
to the device on the DBC's xfer queue. For that to happen, the slice
needs to encode its memory chunks into DBC requests and keep track of
them in an array, which is allocated using kcalloc(). Knowing that the
BO might be very fragmented, this array can grow so large that the
allocation may fail to find contiguous memory for it.
Replace kcalloc() with kvcalloc() to allocate the DBC requests array
for a slice.
Signed-off-by: Youssef Samir <quic_yabdulra@quicinc.com>
Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com>
Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Reviewed-by: Carl Vanderlip <carl.vanderlip@oss.qualcomm.com>
Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20251007121845.337382-1-youssef.abdulrahman@oss.qualcomm.com
On SoCs, like the SAM9X75, which embed the XLCDC ip, the registers that
configure the unified scaling engine were not filled with proper values.
Indeed, for YCbCr formats, the VXSCFACT bitfield of the HEOCFG25
register and the HXSCFACT bitfield of the HEOCFG27 register were
incorrect.
For 4:2:0 formats, both vertical and horizontal factors for
chroma chanels should be divided by 2 from the factors for the luma
channel. Hence:
HEOCFG24.VXSYFACT = VFACTOR
HEOCFG25.VSXCFACT = VFACTOR / 2
HEOCFG26.HXSYFACT = HFACTOR
HEOCFG27.HXSCFACT = HFACTOR / 2
However, for 4:2:2 formats, only the horizontal factor for chroma
chanels should be divided by 2 from the factor for the luma channel;
the vertical factor is the same for all the luma and chroma channels.
Hence:
HEOCFG24.VXSYFACT = VFACTOR
HEOCFG25.VXSCFACT = VFACTOR
HEOCFG26.HXSYFACT = HFACTOR
HEOCFG27.HXSCFACT = HFACTOR / 2
Fixes: d498771b0b ("drm: atmel_hlcdc: Add support for XLCDC using IP specific driver ops")
Signed-off-by: Cyrille Pitchen <cyrille.pitchen@microchip.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20241014094942.325211-1-manikandan.m@microchip.com
Signed-off-by: Manikandan Muralidharan <manikandan.m@microchip.com>
