CC Gareth
On Fri, Nov 4, 2022 at 2:18 PM Maxime Ripard wrote:
>
> The Renesas r9a06g032 bitselect clock implements a mux with a set_parent
> hook, but doesn't provide a determine_rate implementation.
>
> This is a bit odd, since set_parent() is there to, as its name implies,
> change the parent
Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Add vdosys1 ETHDR definition.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Krzysztof Kozlowski
Tested-by: AngeloGioacchino Del Regno
---
.../display/mediatek/mediatek,ethdr.yaml | 188 ++
1 file changed, 188
ETHDR is a part of ovl_adaptor.
ETHDR is designed for HDR video and graphics conversion in the external
display path. It handles multiple HDR input types and performs tone
mapping, color space/color format conversion, and then combine
different layers, output the required HDR or SDR signal to the
Add drm ovl_adaptor sub driver. Bring up ovl_adaptor sub driver if
the component exists in the path.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
Tested-by: Nícolas F. R. A. Prado
---
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Changes in v28:
- rebase to next-20221107
- fix reviewer comment in v27
- extra new line at the end mtk_ethdr.h
Changes
MT8195 have two mmsys. Modify drm for MT8195 multi-mmsys support.
The two mmsys (vdosys0 and vdosys1) will bring up two drm drivers,
only one drm driver register as the drm device.
Each drm driver binds its own component. The last bind drm driver
allocates and registers the drm device to drm core.
This is a preparation for adding support for the ovl_adaptor sub driver
Ovl_adaptor is a DRM sub driver, which doesn't have dma dev. Add
dma_dev_get function for getting representative dma dev in ovl_adaptor.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioachino Del Regno
Reviewed-by: CK Hu
Add driver data of mt8195 vdosys1 to mediatek-drm.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 17 -
1 file changed, 16
Add new mmsys component: ethdr_mixer and mdp_rdma. These components will
use in mt8195 vdosys1.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
---
include/linux/soc/mediatek/mtk-mmsys.h | 9
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Add the number of reset bits and reset base in mmsys
private data.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by:
Add mtk-mutex support for mt8195 vdosys1.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements
which include MDP_RDMA0~7, MERGE0~3, and ETHDR.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Add mtk-mutex DDP_COMPONENT_DP_INTF1 component. The MT8195 vdosys1 path
component contains ovl_adaptor, merge5, and dp_intf1. It is a preparation
for adding support for MT8195 vdosys1 path component.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be written in the same vblanking time.
Cmdq
Simplify code for update mmsys reg.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
Reviewed-by: Nícolas F. R. A. Prado
---
drivers/soc/mediatek/mtk-mmsys.c | 45
Add vdosys1 mmsys compatible for MT8195 platform.
For MT8195, VDOSYS0 and VDOSYS1 are 2 display HW pipelines binding to
2 different power domains, different clock drivers and different
mediatek-drm drivers.
Signed-off-by: Nancy.Lin
Reviewed-by: Nícolas F. R. A. Prado
---
Add mmsys for support 64 reset bits. It is a preparation for MT8195
vdosys1 HW reset. MT8195 vdosys1 has more than 32 reset bits.
1. Add the number of reset bits in mmsys private data
2. move the whole "reset register code section" behind the
"get mmsys->data" code section for getting the
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add mmsys and mutex modules support by the patches below:
Changes in v28:
- rebase to next-20221107
- fix reviewer comment in v27
- remove change id
- fix mmsys config api
Add vdosys1 reset control bit for MT8195 platform.
Signed-off-by: Nancy.Lin
Reviewed-by: Chun-Kuang Hu
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Rex-BC Chen
Acked-by: Krzysztof Kozlowski
Acked-by: Philipp Zabel
Tested-by: AngeloGioacchino Del Regno
---
Add four mmsys config APIs. The config APIs are used for config
mmsys reg. Some mmsys regs need to be set according to the
HW engine binding to the mmsys simultaneously.
1. mtk_mmsys_merge_async_config: config merge async width/height.
async is used for cross-clock domain synchronization.
2.
Add mt8195 vdosys1 routing table to the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Rex-BC Chen
Reviewed-by: CK Hu
Tested-by: AngeloGioacchino Del Regno
Tested-by: Bo-Chen Chen
---
drivers/soc/mediatek/mt8195-mmsys.h | 139
Add support for FRL Link training state and transition
to different states during FRL Link training.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 383 ++
While disabling HDMI, reset the FRL transcoder config if FRL mode was
used.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_ddi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
This patch adds the bits for port width for TRANS_DDI_FUNC_CTL and
port data width for DDI_BUF_CTL.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
HDMI2.1 specifies new SCDC registers to configure FRL Training
between source and sink and get the FRL Training updated from
and HDMI2.1 sink.
This patch adds new SCDC registers and helper functions to
read and configure these registers.
Signed-off-by: Ankit Nautiyal
---
In case of HDMI2.1 FRL training failure for a given mode, the user
should be sent a uevent signalling Link failure.
This patch adds support for sending uevent to userspace in case of link
training failure.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 30
In FRL mode, the Scrambling is always enabled by the HW.
The High TMDS Char Rate and Scrambing Enable bit of
reg TRANS_DDI_FUNC_CTRL are only set in TMDS mode and not
in FRL mode.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 8 +++-
1 file changed, 7
This patch adds bits related to HDMI2.1 in PORT_BUF_CTL_1 that
is needed to be programmed for D2D Interface for Ports in
IO expansion Die.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_cx0_reg_defs.h | 8
1 file changed, 8 insertions(+)
diff --git
Add new struture to store FRL related configurations for a pipe.
These members to be calculated during compute config phase, when FRL
mode is to be used.
Signed-off-by: Ankit Nautiyal
---
.../drm/i915/display/intel_display_types.h| 23 +++
1 file changed, 23 insertions(+)
Add registers for FRL configuration.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/i915_reg.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 765a10e0de88..b50e1349d22c 100644
---
For platforms supporting HDMI2.1 we need to fill the lane count
in Transcoder and DDI/PORT registers for FRL mode.
Similarly, FRL SHIFTER ENABLE, and DATA_WIDTH bits are to be set
in FRL mode. These bits are written in both the DDI_BUF_CTL and
PORT_BUF_CTL registers.
Signed-off-by: Ankit Nautiyal
HDMI2.1 supports higher resolutions using Fixed Rate Link.
Source need to do FRL link training on the 4 lanes before video
stream transmission.
This patch adds the members to crtc_state and intel_hdmi for
identifying the FRL supporting HDMI sink and to maintain the frl
training information, after
From: Mika Kahola
(Patch is part of the series to add C10/C20 PHY support, which is in
review : https://patchwork.freedesktop.org/series/109714/)
Create a separate file to store registers for PICA chips
C10 and C20.
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
---
From: Vandita Kulkarni
>From the max_frl_rate field of vbt parse the maxfrl_rate.
Signed-off-by: Vandita Kulkarni
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_bios.c | 51 +++
drivers/gpu/drm/i915/display/intel_bios.h | 1 +
Add the helpers for getting the max FRL rate with and without DSC
for an HDMI sink.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/drm_edid.c | 38 ++
include/drm/drm_edid.h | 2 ++
2 files changed, 40 insertions(+)
diff --git
This set is RFC for adding support for HDMI2.1 FRL Link training.
FRL or Fixed Rate Link is defined by HDMI2.1 spec for supporting higher
bit-rate. As per HDMI2.1 specification, a new data-channel or lane is
added in FRL mode, by repurposing the TMDS clock Channel. This enables
HDMI to support 48
Re-use the drm helpers for getting max FRL rate for an HDMI sink.
This patch removes the duplicate code and calls the already defined
drm helpers for the task.
Signed-off-by: Ankit Nautiyal
---
drivers/gpu/drm/i915/display/intel_dp.c | 17 -
1 file changed, 4 insertions(+), 13
Thanks, I will send the fix patch.
Regards,
Ma Jun
On 11/5/2022 4:40 AM, Felix Kuehling wrote:
> On 2022-11-04 15:41, coverity-bot wrote:
>> Hello!
>>
>> This is an experimental semi-automated report about issues detected by
>> Coverity from a scan of next-20221104 as part of the linux-next scan
The A64 case should have limited maxItems, instead of duplicating the
minItems value from the main binding. While here, simplify the binding
by making this an "else" case of the two-clock conditional block.
Fixes: fe5040f2843a ("dt-bindings: sun6i-dsi: Document A64 MIPI-DSI controller")
Acked-by:
The "40nm" MIPI DSI controller found in the A100 and D1 SoCs has the
same register layout as previous SoC integrations. However, its module
clock now comes from the TCON, which means it no longer runs at a fixed
rate, so this needs to be distinguished in the driver.
The controller also now uses
This series adds support for the digital part of the DSI controller
found in the A100 and D1 SoCs (plus T7, which is not supported by
mainline Linux). There are two changes to the hardware integration:
1) the module clock routes through the TCON TOP, and
2) the separate I/O domain is removed.
Replace the ad-hoc calls to of_device_is_compatible() with a structure
describing the differences between variants. This is in preparation for
adding more variants to the driver.
Reviewed-by: Jernej Skrabec
Signed-off-by: Samuel Holland
---
Changes in v2:
- Add the variant check to the probe
The A100 variant of the MIPI DSI controller now gets its module clock
from the TCON via the TCON TOP, so the clock rate cannot be set to a
fixed value. Otherwise, it appears to be the same as the A31 variant.
Reviewed-by: Jernej Skrabec
Signed-off-by: Samuel Holland
---
(no changes since v1)
On 9/22/2022 4:30 AM, Dmitry Baryshkov wrote:
SM8350 and SM8450 use 5nm DSI PHYs, which share register definitions
with 7nm DSI PHYs. Rather than duplicating the driver, handle 5nm
variants inside the common 5+7nm driver.
I do realize that there is common code across PHYs but i am concerned
Hi all,
After merging the drm-misc tree, today's linux-next build (htmldocs)
produced this warning:
include/drm/drm_fb_helper.h:204: warning: Function parameter or member
'hint_leak_smem_start' not described in 'drm_fb_helper'
Introduced by commit
e7c5c29a9eb1 ("drm/fb-helper: Set flag in
Linus,
As discussed here:
https://lore.kernel.org/all/20221106212427.739928...@goodmis.org/
Add a "shutdown" state for timers. This is performed by the new
timer_shutdown_sync() and timer_shutdown() function calls. When this is
called on a timer, it will no longer be able to be re-armed.
Hi all,
After merging the drm tree, today's linux-next build (KCONFIG_NAME)
produced this warning:
drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or
member 'lock' not described in 'i915_perf_stream'
Introduced by commit
2db609c01495 ("drm/i915/perf: Replace
On Fri, 4 Nov 2022 16:23:16 +0300, Dmitry Baryshkov wrote:
> The 'qcom,dsi-ctrl-6g-qcm2290' compatibility string was added in the
> commit ee1f09678f14 ("drm/msm/dsi: Add support for qcm2290 dsi
> controller") in February 2022, but was not properly documented in the
> bindings. Adding this
On Sat, 24 Sep 2022 12:43:45 +0300, Dmitry Baryshkov wrote:
> Historically HDMI PHY device tree nodes used the hdmi-phy@ names.
> Replace them with generic phy@ names.
>
> While there is no such requirement in the DT schema, it's worth doing
> that because:
>
> 1) The recent qcom DT files
On 2022/11/5 2:31, Alex Deucher wrote:
On Fri, Nov 4, 2022 at 6:05 AM Hanjun Guo wrote:
VBIOSImageOffset in struct UEFI_ACPI_VFCT is ULONG (unsigned long),
but it will be assigned to "unsigned offset", so use unsigned long
instead of unsigned for the offset, to avoid possible overflow.
On Tue, 22 Feb 2022 00:57:02 -0800, Andi Shyti wrote:
>
Old thread, new comment below at the bottom. Please take a look. Thanks.
> Hi Tvrtko and Joonas,
>
> > > > > > Now tiles have their own sysfs interfaces under the gt/
> > > > > > directory. Because RC6 is a property that can be configured
Like the Acer Switch One 10 S1003, for which there already is a quirk,
the Acer Switch V 10 (SW5-017) has a 800x1280 portrait screen mounted
in the tablet part of a landscape oriented 2-in-1. Add a quirk for this.
Cc: Rudolf Polzer
Signed-off-by: Hans de Goede
---
del_timer_sync() is often called before the object that owns the timer is
freed. But sometimes there's a race that enables the timer again before it is
freed and causes a use after free when that timer triggers. This patch set
adds a new "shutdown" timer state, which is set on the new
The accelerator devices are exposed to user-space using a dedicated
major. In addition, they are represented in /dev with new, dedicated
device char names: /dev/accel/accel*. This is done to make sure any
user-space software that tries to open a graphic card won't open
the accelerator device by
Now that we have the accel framework code ready, let's call the
accel functions from all the appropriate places. These places are the
drm module init/exit functions, and all the drm_minor handling
functions.
Signed-off-by: Oded Gabbay
---
Changes in v3:
- Call the new accel_debugfs_init() to
Add a new Kconfig for the accel subsystem. The Kconfig currently
contains only the basic CONFIG_DRM_ACCEL option that will be used to
decide whether to compile the accel registration code. Therefore, the
kconfig option is defined as bool.
The accel code will be compiled as part of drm.ko and will
This is the third version of the RFC following the comments given on the
second version, but more importantly, following testing done by the VPU
driver people and myself. We found out that there is a circular dependency
between DRM and accel. DRM calls accel exported symbols during init and when
From: Rodrigo Siqueira
[ Upstream commit ca08a1725d0d78efca8d2dbdbce5ea70355da0f2 ]
When using a device based on DCN32/321,
we have an issue where a second
4k@60Hz display does not light up,
and the system becomes unresponsive
for a few minutes. In the debug process,
it was possible to see a
From: Rodrigo Siqueira
[ Upstream commit ca08a1725d0d78efca8d2dbdbce5ea70355da0f2 ]
When using a device based on DCN32/321,
we have an issue where a second
4k@60Hz display does not light up,
and the system becomes unresponsive
for a few minutes. In the debug process,
it was possible to see a
From: Christian König
[ Upstream commit b3af84383e7abdc5e63435817bb73a268e7c3637 ]
We leaked dependency fences when processes were beeing killed.
Additional to that grab a reference to the last scheduled fence.
Signed-off-by: Christian König
Reviewed-by: Andrey Grodzovsky
Link:
From: Alvin Lee
[ Upstream commit abe4d9f03fae76c9650b0d942faf6990b35c377b ]
pipe_ctx[i] exists even if the pipe is not
in use. If the pipe is not in use it will
always have a null stream, so don't return
false in this case.
Tested-by: Daniel Wheeler
Reviewed-by: Rodrigo Siqueira
Acked-by:
From: Rodrigo Siqueira
[ Upstream commit ca08a1725d0d78efca8d2dbdbce5ea70355da0f2 ]
When using a device based on DCN32/321,
we have an issue where a second
4k@60Hz display does not light up,
and the system becomes unresponsive
for a few minutes. In the debug process,
it was possible to see a
From: Yiqing Yao
[ Upstream commit 226dcfad349f23f7744d02b24f8ec3bc4f6198ac ]
[why]
MES response time in sriov may be longer than default value
due to reset or init in other VF. A timeout value specific
to sriov is needed.
[how]
When in sriov, adjust the timeout value to calculated
worst case
From: Akhil P Oommen
[ Upstream commit 76efc2453d0e8e5d6692ef69981b183ad674edea ]
In adreno_unbind, we should clean up gpu device's drvdata to avoid
accessing a stale pointer during system suspend. Also, check for NULL
ptr in both system suspend/resume callbacks.
Signed-off-by: Akhil P Oommen
Den 27.10.2022 00.02, skrev Mateusz Kwiatkowski:
> Hi Maxime,
>
> First of all, nice idea with the helper function that can be reused by
> different
> drivers. This is neat!
>
> But looking at this function, it feels a bit overcomplicated. You're creating
> the two modes, then checking which
Den 26.10.2022 17.33, skrev max...@cerno.tech:
> Most of the TV connectors will need a similar get_modes implementation
> that will, depending on the drivers' capabilities, register the 480i and
> 576i modes.
>
> That implementation will also need to set the preferred flag and order
> the
This patch includes changes below:
1) pin_user_pages() is unsafe without protection of mmap_lock,
fix it by calling mmap_read_lock() & mmap_read_unlock().
2) fix & refactor the incorrect exception handling procedure in
vmw_mksstat_add_ioctl().
Fixes: 7a7a933edd6c ("drm/vmwgfx: Introduce
Hi,
Can you tell me what are we waiting for? Maybe I can help.
Thanks.
Matthieu
On Wed, Oct 12 2022 at 07:16:29 PM +0200, Matthieu CHARETTE
wrote:
By crash, I mean that an error is returned here:
On Wed, Nov 2, 2022 at 4:23 PM Oded Gabbay wrote:
>
> On Mon, Sep 12, 2022 at 12:17 AM Michał Winiarski
> wrote:
> >
> > IDR is deprecated, and since XArray manages its own state with internal
> > locking, it simplifies the locking on DRM side.
> > Additionally, don't use the IRQ-safe variant,
On Sun, Nov 6, 2022 at 12:54 PM Oded Gabbay wrote:
>
> On Thu, Nov 3, 2022 at 7:26 AM Jiho Chu wrote:
> >
> > On Wed, 2 Nov 2022 22:34:04 +0200
> > Oded Gabbay wrote:
> >
> > > +/**
> > > + * accel_open - open method for ACCEL file
> > > + * @inode: device inode
> > > + * @filp: file pointer.
Den 26.10.2022 17.33, skrev max...@cerno.tech:
> Our new tv mode option allows to specify the TV mode from a property.
> However, it can still be useful, for example to avoid any boot time
> artifact, to set that property directly from the kernel command line.
>
> Let's add some code to allow
Den 26.10.2022 17.33, skrev max...@cerno.tech:
> We'll need to get the pixel clock to generate proper display modes for
> all the current named modes. Let's add it to struct drm_cmdline_mode and
> fill it when parsing the named mode.
>
> Signed-off-by: Maxime Ripard
> ---
I would just squash
Den 26.10.2022 17.33, skrev max...@cerno.tech:
> The current code to deal with named modes will only set the mode name, and
> then it's up to drivers to try to match that name to whatever mode or
> configuration they see fit.
>
I couldn't find any driver that does that, all I could find that
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
macro") says, flush_scheduled_work() is dangerous and will be forbidden.
We are on the way for removing all flush_scheduled_work() callers from
the kernel, and there are only 4 callers remaining as of linux-20221104.
On Wed, Nov 2, 2022 at 11:30 PM Jeffrey Hugo wrote:
>
> On 11/2/2022 2:34 PM, Oded Gabbay wrote:
> > @@ -163,7 +174,11 @@ static int drm_minor_register(struct drm_device *dev,
> > unsigned int type)
> >
> > ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
> > if (ret) {
On Thu, Nov 3, 2022 at 7:26 AM Jiho Chu wrote:
>
> On Wed, 2 Nov 2022 22:34:04 +0200
> Oded Gabbay wrote:
>
> > +/**
> > + * accel_open - open method for ACCEL file
> > + * @inode: device inode
> > + * @filp: file pointer.
> > + *
> > + * This function must be used by drivers as their
On Wed, Nov 2, 2022 at 11:17 PM Jeffrey Hugo wrote:
>
> On 11/2/2022 2:34 PM, Oded Gabbay wrote:
> > @@ -24,16 +33,6 @@ static char *accel_devnode(struct device *dev, umode_t
> > *mode)
> >
> > static CLASS_ATTR_STRING(accel_version, 0444, "accel 1.0.0 20221018");
> >
> > -/**
> > - *
77 matches
Mail list logo
