This patch add null pointer check for amdgpu_vm_put_task_info and
amdgpu_vm_get_task_info_vm, because there is only a warning if create
task_info failed in amdgpu_vm_init.
Fixes: b8f67b9ddf4f ("drm/amdgpu: change vm->task_info handling")
Signed-off-by: Lu Yao
---
drivers/gpu/drm/amd/amdgpu/amdgp
On 12/31/24 9:31 PM, Laurent Pinchart wrote:
Hi Marek,
Hi,
Thank you for the patch.
On Tue, Dec 31, 2024 at 08:28:48PM +0100, Marek Vasut wrote:
Add a flag meant purely to work around broken i.MX8MP DTs which enable
HDMI but do not contain the HDMI connector node. This flag allows such
DTs
Hi Marek,
Thank you for the patch.
On Tue, Dec 31, 2024 at 08:28:48PM +0100, Marek Vasut wrote:
> Add a flag meant purely to work around broken i.MX8MP DTs which enable
> HDMI but do not contain the HDMI connector node. This flag allows such
> DTs to work by creating the connector in the HDMI bri
Add a flag meant purely to work around broken i.MX8MP DTs which enable
HDMI but do not contain the HDMI connector node. This flag allows such
DTs to work by creating the connector in the HDMI bridge driver. Do not
use this flag, do not proliferate this flag, please fix your DTs.
Signed-off-by: Mar
Commit a25b988ff83f ("drm/bridge: Extend bridge API to disable connector
creation")
added DRM_BRIDGE_ATTACH_NO_CONNECTOR bridge flag and all bridges handle
this flag in some way since then.
Newly added bridge drivers must no longer contain the connector creation and
will fail probing if this flag
The dw-hdmi output_port is set to 1 in order to look for a connector
next bridge in order to get DRM_BRIDGE_ATTACH_NO_CONNECTOR working.
The output_port set to 1 makes the DW HDMI driver core look up the
next bridge in DT, where the next bridge is often the hdmi-connector .
Similar to 0af5e0b41110
Commit a25b988ff83f ("drm/bridge: Extend bridge API to disable connector
creation")
added DRM_BRIDGE_ATTACH_NO_CONNECTOR bridge flag and all bridges handle
this flag in some way since then.
Newly added bridge drivers must no longer contain the connector creation and
will fail probing if this flag
On Tue, Dec 31, 2024 at 3:34 AM Dmitry Baryshkov
wrote:
[...]
> > I checked all instances of struct hdmi_codec_ops in v6.13-rc3 and it
> > seems that there is only a single driver which uses the .prepare
> > callback (drivers/gpu/drm/vc4/vc4_hdmi.c). All other drivers seem to
> > implement .hw_par
Hi--
On 12/31/24 2:39 AM, Luca Ceresoli wrote:
> Document in detail the new refcounted bridges as well as the "legacy" way.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> This patch was added in v5.
> ---
> Documentation/gpu/drm-kms-helpers.rst | 6 ++
> drivers/gpu/drm/drm_bridge.c
From: Arthur Grillo
Add support to the YUV formats bellow:
- NV12/NV16/NV24
- NV21/NV61/NV42
- YUV420/YUV422/YUV444
- YVU420/YVU422/YVU444
The conversion from yuv to rgb is done with fixed-point arithmetic, using
32.32 fixed-point numbers and the drm_fixed helpers.
To do the conversion, a spec
This add the support for:
- R1/R2/R4/R8
R1 format was tested with [1] and [2].
[1]:
https://lore.kernel.org/r/20240313-new_rotation-v2-0-6230fd5ca...@bootlin.com
[2]:
https://lore.kernel.org/igt-dev/20240306-b4-kms_tests-v1-0-8fe451efd...@bootlin.com/
Reviewed-by: Pekka Paalanen
Signed-off-by
From: Arthur Grillo
Now that the driver internally handles these quantization ranges and YUV
encoding matrices, expose the UAPI for setting them.
Signed-off-by: Arthur Grillo
[Louis Chauvet: retained only relevant parts, updated the commit message]
Acked-by: Pekka Paalanen
Signed-off-by: Louis
From: Arthur Grillo
VKMS has support for YUV formats now. Remove the task from the TODO
list.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/gpu/vkms.rst b/Documentati
This patchset is extracted from [1]. The goal is to introduce the YUV
support, thanks to Arthur's work.
- PATCH 1: Add the support of YUV formats
- PATCH 2: Add some drm properties to expose more YUV features
- PATCH 3: Cleanup the todo
- PATCH 4..6: Add some kunit tests
- PATCH 7: Add the support
From: Arthur Grillo
Create KUnit tests to test the conversion between YUV and RGB. Test each
conversion and range combination with some common colors.
The code used to compute the expected result can be found in comment.
[Louis Chauvet:
- fix minor formating issues (whitespace, double line)
- c
From: Arthur Grillo
Now that we have KUnit tests, add instructions on how to run them.
Signed-off-by: Arthur Grillo
Signed-off-by: Louis Chauvet
---
Documentation/gpu/vkms.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.
The functions drm_get_color_encoding_name and drm_get_color_range_name
are useful for clarifying test results. Therefore, export them so they
can be used in tests built as modules.
Signed-off-by: Louis Chauvet
---
drivers/gpu/drm/drm_color_mgmt.c | 3 +++
1 file changed, 3 insertions(+)
diff --
Dmitry Baryshkov writes:
> On Tue, Dec 31, 2024 at 04:34:34PM +0100, Javier Martinez Canillas wrote:
>> Dmitry Baryshkov writes:
>>
>> Hello Dmitry,
>>
>> > On Tue, Dec 31, 2024 at 12:44:58PM +0100, Javier Martinez Canillas wrote:
>
> [...]
>
>> >> Since the check is done even for built-in dri
On Thu, Dec 19, 2024 at 11:34:00PM +0200, Jani Nikula wrote:
> Write the DP2 specific VFREQ registers.
>
> This is preparation for enabling 128b/132b SST. This path is not
> reachable yet.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12
> 1 fil
On Thu, Dec 19, 2024 at 11:34:00PM +0200, Jani Nikula wrote:
> Write the DP2 specific VFREQ registers.
>
> This is preparation for enabling 128b/132b SST. This path is not
> reachable yet.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12
> 1 fil
On Thu, Dec 19, 2024 at 11:33:59PM +0200, Jani Nikula wrote:
> Write the payload allocation table for 128b/132b SST. Use VCPID 1 and
> start from slot 0, with dp_m_n.tu slots.
>
> This is preparation for enabling 128b/132b SST. This path is not
> reachable yet. Indeed, we don't yet compute TU for
On Tue, Dec 31, 2024 at 04:34:34PM +0100, Javier Martinez Canillas wrote:
> Dmitry Baryshkov writes:
>
> Hello Dmitry,
>
> > On Tue, Dec 31, 2024 at 12:44:58PM +0100, Javier Martinez Canillas wrote:
[...]
> >> Since the check is done even for built-in drivers, drop the condition to
> >> only d
On Thu, Dec 19, 2024 at 11:33:58PM +0200, Jani Nikula wrote:
> It's not very clearly specified, and the hardware bit is ill-named, but
> 128b/132b SST also needs the MST mode set in the DP_TP_CTL register.
>
> This is preparation for enabling 128b/132b SST. This path is not
> reachable yet.
>
> S
On Thu, Dec 19, 2024 at 11:33:57PM +0200, Jani Nikula wrote:
> 128b/132b SST needs 128b/132b mode enabled in the TRANS_DDI_FUNC_CTL
> register.
>
> This is preparation for enabling 128b/132b SST. This path is not
> reachable yet.
>
> v2: Use the MST path instead of SST to also set transport selec
On Thu, Dec 19, 2024 at 11:33:56PM +0200, Jani Nikula wrote:
> Handle 128b/132b SST in intel_dp_mtp_tu_compute_config(). The remote
> bandwidth overhead and time slot allocation are only relevant for MST;
> SST only needs the local bandwidth and a check that 64 slots isn't
> exceeded.
>
> Signed-o
On Thu, Dec 19, 2024 at 11:33:55PM +0200, Jani Nikula wrote:
> Extract intel_dp_mtp_tu_compute_config() for figuring out the TU. Move
> the link configuration and mst state access to the callers. This will be
> easier to adapt to 128b/132b SST.
>
> v2: Don't add SST stuff here yet
>
> Signed-off-
On Tue, Dec 31, 2024 at 11:40:04AM +0100, Luca Ceresoli wrote:
> This driver implements the point of a DRM pipeline where a connector allows
> removal of all the following bridges up to the panel.
>
> The DRM subsystem currently allows hotplug of the monitor but not preceding
> components. However
On Thu, Dec 19, 2024 at 11:33:54PM +0200, Jani Nikula wrote:
> The crtc_state->pbn member is only used as a temporary variable within
> mst_stream_find_vcpi_slots_for_bpp(). Remove it as unnecessary.
>
> Suggested-by: Imre Deak
> Signed-off-by: Jani Nikula
Reviewed-by: Imre Deak
> ---
> driv
Dmitry Baryshkov writes:
Hello Dmitry,
> On Tue, Dec 31, 2024 at 12:44:58PM +0100, Javier Martinez Canillas wrote:
>> The only reason for the ssd130x-spi driver to have an spi_device_id table
>> is that the SPI core always reports an "spi:" MODALIAS, even when the SPI
>> device has been register
On Thu, Dec 19, 2024 at 11:33:53PM +0200, Jani Nikula wrote:
> The callers of mst_stream_find_vcpi_slots_for_bpp() don't need the
> returned slots for anything. On the contrary, they need to jump through
> hoops to just distinguish between success and failure. Just return 0
> instead of slots from
On Thu, Dec 19, 2024 at 11:33:52PM +0200, Jani Nikula wrote:
> intel_dp_mst_compute_m_n() doesn't need the connector. Remove the
> parameter.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +--
> 1 file changed, 1 insertion(+), 2
On Thu, Dec 19, 2024 at 11:33:51PM +0200, Jani Nikula wrote:
> intel_dp_mst_bw_overhead() doesn't need the connector. Remove the
> parameter.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 ++---
> 1 file changed, 2 insertions(+),
On Thu, Dec 19, 2024 at 11:33:50PM +0200, Jani Nikula wrote:
> The struct drm_dp_mst_topology_mgr *mgr parameter is only used for debug
> logging in case the passed in link rate or lane count are zero. There's
> no further error checking as such, and the function returns 0.
>
> There should be no
On Tue, Dec 31, 2024 at 11:40:02AM +0100, Luca Ceresoli wrote:
> Instead of using dsi->out_bridge during the bridge search process, use a
> temporary variable and assign dsi->out_bridge only on successful
> completion.
>
> The main goal is to be able to drm_bridge_get() the out_bridge before
> set
On Tue, Dec 31, 2024 at 12:44:58PM +0100, Javier Martinez Canillas wrote:
> The only reason for the ssd130x-spi driver to have an spi_device_id table
> is that the SPI core always reports an "spi:" MODALIAS, even when the SPI
> device has been registered via a Device Tree Blob.
>
> Without spi_dev
On Tue, Dec 31, 2024 at 11:40:03AM +0100, Luca Ceresoli wrote:
> Refcount the out_bridge to avoid a use-after-free in case it is
> hot-unplugged.
>
> Signed-off-by: Luca Ceresoli
>
> ---
>
> This patch was added in v5.
> ---
> drivers/gpu/drm/bridge/samsung-dsim.c | 11 ---
> 1 file ch
On Tue, 31 Dec 2024 at 15:24, Jun Nie wrote:
>
> Dmitry Baryshkov 于2024年12月20日周五 06:29写道：
>
>
> >
> > On Thu, Dec 19, 2024 at 03:49:28PM +0800, Jun Nie wrote:
> > > Add pipe as trace argument to ease converting pipe into
> > > pipe array later.
> >
> > Isn't it already converted in on of the prev
Dmitry Baryshkov 于2024年12月20日周五 06:29写道：
>
> On Thu, Dec 19, 2024 at 03:49:28PM +0800, Jun Nie wrote:
> > Add pipe as trace argument to ease converting pipe into
> > pipe array later.
>
> Isn't it already converted in on of the previous patches? Also you are
> adding it to a particular trace fun
On 30/12/2024 15:34, Jani Nikula wrote:
> On Tue, 17 Dec 2024, Jani Nikula wrote:
>> Having cec.h include linux/debugfs.h leads to all users of all cec
>> headers include and depend on debugfs.h and its dependencies for no
>> reason. Drop the include from cec.h, and include debugfs.h and
>> seq_fi
On 22/11/2024 15:51, Rob Clark wrote:
On Fri, Nov 22, 2024 at 4:21 AM Konrad Dybcio
wrote:
On 21.11.2024 5:48 PM, Rob Clark wrote:
From: Rob Clark
Debugging incorrect UAPI usage tends to be a bit painful, so add a
helper macro to make it easier to add debug logging which can be enabled
at
230-174205
base: linus/master
patch link:
https://lore.kernel.org/r/a4cfdeed1a91a7a12c7ebe56bed2ba94991c4065.1735550269.git.zhoubinbin%40loongson.cn
patch subject: [PATCH v1 2/4] ipmi: Add Loongson-2K BMC support
config: loongarch-randconfig-r123-20241231
(https://download.01.org/0day-ci/archiv
The only reason for the ssd130x-spi driver to have an spi_device_id table
is that the SPI core always reports an "spi:" MODALIAS, even when the SPI
device has been registered via a Device Tree Blob.
Without spi_device_id table information in the module's metadata, module
autoloading would not work
On Tue, 31 Dec 2024, Luca Ceresoli wrote:
> DRM bridges are currently considered as a fixed element of a DRM card, and
> thus their lifetime is assumed to extend for as long as the card
> exists. New use cases, such as hot-pluggable hardware with video bridges,
> require DRM bridges to be added an
In preparation for allowing bridges to be added to and removed from a DRM
card without destroying the whole card, add a new DRM bridge function
called on addition and removal of bridges.
Signed-off-by: Luca Ceresoli
---
Changed in v5:
- fixed kerneldoc errors
This patch was added in v4.
---
Instead of using dsi->out_bridge during the bridge search process, use a
temporary variable and assign dsi->out_bridge only on successful
completion.
The main goal is to be able to drm_bridge_get() the out_bridge before
setting it in dsi->out_bridge, which is done in a later commit. Setting
dsi->o
With proper use of drm_bridge_get() and _put(), this allows the bridge to
be removable without dangling pointers and use-after-free.
Signed-off-by: Luca Ceresoli
---
This patch was added in v5.
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 13 +++--
1 file changed, 11 insertions(+), 2 de
Supporting hardware whose final part of the DRM pipeline can be physically
removed requires the ability to detach all bridges from a given point to
the end of the pipeline.
Introduce a variant of drm_encoder_cleanup() for this.
Signed-off-by: Luca Ceresoli
---
Changes in v5: none
Changes in v4
Refcount the out_bridge to avoid a use-after-free in case it is
hot-unplugged.
Signed-off-by: Luca Ceresoli
---
This patch was added in v5.
---
drivers/gpu/drm/bridge/samsung-dsim.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/samsung-d
This driver implements the point of a DRM pipeline where a connector allows
removal of all the following bridges up to the panel.
The DRM subsystem currently allows hotplug of the monitor but not preceding
components. However there are embedded devices where the "tail" of the DRM
pipeline, includi
Document in detail the new refcounted bridges as well as the "legacy" way.
Signed-off-by: Luca Ceresoli
---
This patch was added in v5.
---
Documentation/gpu/drm-kms-helpers.rst | 6 ++
drivers/gpu/drm/drm_bridge.c | 122 ++
2 files changed, 128 inser
Enable lifetime management of panel-bridge, so that other modules taking a
pointer to a panel bridge can refcount it and avoid use-after-free in case
the panel bridge is hot-unplugged.
Signed-off-by: Luca Ceresoli
---
This patch was added in v5.
---
drivers/gpu/drm/bridge/panel.c | 20
Add two simple KUnit tests for the newly introduced drm_bridge_init() and
the corresponding .destroy deallocation function.
Signed-off-by: Luca Ceresoli
---
This patch was added in v5.
---
drivers/gpu/drm/tests/Makefile | 1 +
drivers/gpu/drm/tests/drm_bridge_test.c | 128 ++
Hello,
this series aims at supporting Linux devices with a DRM pipeline whose
final components can be hot-plugged and hot-unplugged, including one or
more bridges.
If you already know the use case and the approach, feel free to skip to
"Roadmap and current status" below for the ongoing changes.
DRM bridges are currently considered as a fixed element of a DRM card, and
thus their lifetime is assumed to extend for as long as the card
exists. New use cases, such as hot-pluggable hardware with video bridges,
require DRM bridges to be added and removed to a DRM card without tearing
the card do
Hi,
On Tue, Dec 10, 2024 at 12:10:19AM +0100, Heiko Stuebner wrote:
> From: Heiko Stuebner
>
> Add a Synopsys Designware MIPI DSI host DRM bridge driver for their
> DSI2 host controller, based on the Rockchip version from the driver
> rockchip/dw-mipi-dsi2.c in their vendor-kernel with phy & bri
Hi all:
This patch set introduces the Loongson-2K0500 BMC.
It is a PCIe device present on servers similar to the Loongson-3C6000.
And it is a multifunctional device (MFD), such as display as a sub-function
of it.
For IPMI, according to the existing design, we use software simulation to
implement
Since the display is a sub-function of the Loongson-2K BMC, when the
BMC reset, the entire BMC PCIe is disconnected, including the display
which is interrupted.
Not only do you need to save/restore the relevant PCIe registers
throughout the reset process, but you also need to re-push the display
t
This patch adds Loongson-2K BMC IPMI support.
According to the existing design, we use software simulation to
implement the KCS interface registers: Stauts/Command/Data_Out/Data_In.
Also since both host side and BMC side read and write kcs status, I use
fifo pointer to ensure data consistency.
T
On Fri, Sep 13, 2024 at 10:12:39PM +0100, Hugh Cole-Baker wrote:
> Hi Geraldo, and apologies for resurrecting a 2 year old thread...
>
> On 17/10/2022 13:04, Geraldo Nascimento wrote:
> > Hi Mark, resending this as it failed to apply in my last submission. Added
> > Neil Armstrong to Cc: as hopefu
Adds a driver for the Loongson-2K BMC display as a sub-function of
the BMC device.
Display-related scan output buffers, sizes, and display formats are
provided through the Loongson-2K BMC MFD driver.
Co-developed-by: Chong Qiao
Signed-off-by: Chong Qiao
Signed-off-by: Binbin Zhou
---
drivers/
The Loongson-2K Board Management Controller provides an PCIe
interface to the host to access the feature implemented in the BMC.
The BMC is assembled on a server similar to the server machine with
Loongson-3C6000 CPUs. It supports multiple sub-devices like DRM.
Co-developed-by: Chong Qiao
Signed
On 30.12.2024 10:11 PM, Akhil P Oommen wrote:
> Add a module param to disable ACD which will help to quickly rule it
> out for any GPU issues.
>
> Signed-off-by: Akhil P Oommen
> ---
Is that something useful during internal development, or do we
see ACD causing issues in the wild?
If the latter
From: Andy Yan
RK3576 HDMI TX Controller is very similar to that of RK3588, but
with some control bits for IO and interrupts status scattered across
different GRF.
Signed-off-by: Andy Yan
---
(no changes since v1)
.../bindings/display/rockchip/rockchip,rk3588-dw-hdmi-qp.yaml| 1 +
1 file
On 31/12/2024 10:44, Andy Yan wrote:
> From: Andy Yan
>
> RK3576 HDMI TX Controller is very similar to that of RK3588, but
> with some control bits for IO and interrupts status scattered across
> different GRF.
>
> Signed-off-by: Andy Yan
> ---
>
v2 was sent few days ago, so this is v3.
Acke
On 30.12.2024 11:25 PM, Rob Herring (Arm) wrote:
>
> On Tue, 31 Dec 2024 02:41:05 +0530, Akhil P Oommen wrote:
>> Add a new schema which extends opp-v2 to support a new vendor specific
>> property required for Adreno GPUs found in Qualcomm's SoCs. The new
>> property called "qcom,opp-acd-level" ca
On 30/12/2024 22:11, Akhil P Oommen wrote:
ACD a.k.a Adaptive Clock Distribution is a feature which helps to reduce
the power consumption. In some chipsets, it is also a requirement to
support higher GPU frequencies. This patch adds support for GPU ACD by
sending necessary data to GMU and AOSS. T
From: Andy Yan
RK3576 HDMI TX Controller is very similar to that of RK3588, but with
some control bits for IO and interrupts status scattered across different
GRF.
PATCH 1/3 is add platform ctrl callback for IO setting and interrupts
status handing.
PATCH 2/3 ~ 3/3 are add support for rk3576
C
From: Andy Yan
There are some control bits for IO and interrupts status scattered
across different GRF on differt SOC.
Add platform callback for this IO setting and interrupts status
handling.
Signed-off-by: Andy Yan
---
Changes in v2:
- Fix compilation warning: unused variable ‘val’ [-Wunuse
From: Andy Yan
The HDMI on RK3576 shares the same IP block (PHY and Controller)
with rk3588.
However, there are some control bits scattered in different GRF.
Signed-off-by: Andy Yan
Signed-off-by: Detlev Casanova
Tested-by: Detlev Casanova
---
(no changes since v1)
.../gpu/drm/rockchip/dw_
This adds support for DSS subsystem present in TI's AM62L SoC
which supports single display pipeline with DPI output which
is also routed to DSI Tx controller within the SoC.
Devarsh Thakkar (2):
dt-bindings: display: ti,am65x-dss: Add support for AM62L DSS
drm/tidss: Add support for AM62L dis
The DSS controller on TI's AM62L SoC is an update from that on TI's
AM625/AM65x/AM62A7 SoC. The AM62L DSS [1] only supports a single display
pipeline using a single overlay manager, single video port and a single
video lite pipeline which does not support scaling.
The output of video port is route
From: Andy Yan
The Cluster windows of upcoming VOP on rk3576 also support
linear YUV support, we need to set uv swap bit for it.
As the VOP2_WIN_UV_SWA register defined on rk3568/rk3588 is
0x, so this register will not be touched on these
two platforms.
Signed-off-by: Andy Yan
Tested-b
From: Andy Yan
In the upcoming VOP of rk3576, a window cannot attach to all Video
Ports, we introduce a possible_vp_mask for every window to indicate
which Video Ports this window can attach to.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detlev Casanova
---
(no
From: Andy Yan
There is a version number hardcoded in the VOP VERSION_INFO
register, and the version number increments sequentially based
on the production order of the SOC.
So using this version number to distinguish different VOP features
will simplify the code.
Signed-off-by: Andy Yan
Teste
From: Andy Yan
The VOP interface mux, overlay, background delay cycle configuration
of different SOC are much different. Add platform specific callback
ops to let the core driver look cleaner and more refined.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detlev Casa
From: Andy Yan
VOP2 on rk3576:
Three video ports:
VP0 Max 4096x2160
VP1 Max 2560x1600
VP2 Max 1920x1080
2 4K Cluster windows with AFBC/RFBC, line RGB and YUV
4 Esmart windows with line RGB/YUV support:
Esmart0/1: 4K
Esmart2/3: 2k, or worked together as a single 4K plane at shared
line buffer mod
From: Andy Yan
This is the only afbc format supported by the upcoming
VOP for rk3576.
Add support for it.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detlev Casanova
---
(no changes since v2)
Changes in v2:
- split it from main patch add support for rk3576
d
From: Andy Yan
In the upcoming VOP for rk3576, every VP has it's own LAYER_SEL
register, and the configuration value of each VP for the same
window maybe different, so extend the layer_sel_id to array,
let it can descption the layer select configuration value for
different VP.
Signed-off-by: And
From: Andy Yan
In the upcoming VOP of rk3576, a Window cannot attach to all Video Ports,
so make sure all VP find it's suitable primary plane, then register the
remain windows as overlay plane will make code easier.
Signed-off-by: Andy Yan
Tested-by: Michael Riesch # on RK3568
Tested-by: Detle
From: Andy Yan
Add vop found on rk3576, the main difference between rk3576 and the
previous vop is that each VP has its own interrupt line.
Signed-off-by: Andy Yan
---
Changes in v8:
- Fix dt_binding_check errors
- ordered by soc name
- Link to the previous version:
https://lore.kernel.org
From: Andy Yan
Here is the V8
Patches that have already been merged in V6 are dropped.
PATCH 1~7 are preparations for rk3576 support
PATCH 8~9 are real support for rk376
I test it with a 1080P/4K HDMI output with modetest and weston
output.
If there are some one want to have a try, I have a t
Enable display for AM62L DSS [1] which supports only a single display
pipeline using a single overlay manager, single video port and a single
video lite pipeline which does not support scaling.
The output of video port is routed to SoC boundary via DPI interface and
the DPI signals from the video
Hi Krzysztof,
At 2024-12-31 16:23:39, "Krzysztof Kozlowski" wrote:
>On Sun, Dec 29, 2024 at 06:49:38PM +0800, Andy Yan wrote:
>>
>>
>> Hi Krzysztof,
>>
>> At 2024-12-29 18:13:39, "Krzysztof Kozlowski" wrote:
>> >On Sat, Dec 28, 2024 at 08:21:48PM +0800, Andy Yan wrote:
>> >> From: Andy Yan
On Sun, Dec 29, 2024 at 06:49:38PM +0800, Andy Yan wrote:
>
>
> Hi Krzysztof,
>
> At 2024-12-29 18:13:39, "Krzysztof Kozlowski" wrote:
> >On Sat, Dec 28, 2024 at 08:21:48PM +0800, Andy Yan wrote:
> >> From: Andy Yan
> >>
> >> Add vop found on rk3576, the main difference between rk3576 and the
84 matches
Mail list logo
