Re: [PATCH 1/2] drm/sched: Rename priority MIN to LOW

Am 24.11.23 um 06:27 schrieb Luben Tuikov: Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW. This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler priorities in ascending order, DRM_SCHED_PRIORITY_LOW, DRM_SCHED_PRIORITY_NORMAL, DRM_SCHED_PRIORITY_HIGH,

RE: [Intel-gfx] [PATCH] drm/i915/irq: Improve error logging for unexpected DE Misc interrupts

> -Original Message- > From: Intel-gfx On Behalf Of Rahul > Rameshbabu > Sent: Thursday, November 23, 2023 11:27 PM > To: intel-...@lists.freedesktop.org > Cc: Nikula, Jani ; dri-devel@lists.freedesktop.org; > Rahul Rameshbabu > Subject: [Intel-gfx] [PATCH] drm/i915/irq: Improve error

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

Hi, On 2023/11/24 15:38, Maxime Ripard wrote: On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote: On 2023/11/23 16:08, Dmitry Baryshkov wrote: I'm agree with the idea that drm bridges drivers involved toward to a direction that support more complex design, but I think we should also

Re: [PATCH v2 0/4] eventfd: simplify signal helpers

On Wed, 22 Nov 2023 13:48:21 +0100, Christian Brauner wrote: > Hey everyone, > > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers > significantly. They can be made void and not take any unnecessary > arguments. > > I've added a few more simplifications based on Sean's

Re: [PATCH v5 9/9] drm: ci: Update xfails

Hi Daniel, On 19/10/23 13:55, Daniel Stone wrote: By the time we get this error, it indicates that there was previously memory corruption, but it is only being noticed at a later point. The skip lists here are way too big - stuff like drm_read is common testing not affected by virtio at all -

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

On Fri, Nov 24, 2023 at 01:52:26AM +0800, Sui Jingfeng wrote: > On 2023/11/23 16:08, Dmitry Baryshkov wrote: > > > I'm agree with the idea that drm bridges drivers involved toward to a > > > direction > > > that support more complex design, but I think we should also leave a way > > > for the >

Re: [PATCH v5 08/20] drivers/gpu/drm/loongson/lsdc_i2c.c: remove I2C_CLASS_DDC support

Hi, On 2023/11/23 17:40, Heiner Kallweit wrote: After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. Class-based device auto-detection is a legacy mechanism and shouldn't be used in new code. So we can

[PATCH RESEND 0/3] Update STM DSI PHY driver

This patch series aims to add several features of the dw-mipi-dsi phy driver that are missing or need to be updated. First patch adds runtime PM functionality to the driver. Second patch adds a clock provider generated by the PHY itself. As explained in the commit log of the second patch, a

[PATCH RESEND 2/3] drm/stm: dsi: expose DSI PHY internal clock

DSISRC __ __\_ |\ pll4_p_ck ->| 1 |dsi_k ck_dsi_phy ->| 0 | |/ A DSI clock is missing in the clock framework. Looking at the clk_summary, it appears that 'ck_dsi_phy' is not

[PATCH RESEND 3/3] arm: dts: st: fix DSI peripheral clock on stm32mp15 boards

In RCC driver, 'DSI_K' is a kernel clock while 'DSI' has pclk4 as parent clock, which means that it is an APB peripheral clock. Swap the clocks in the DSI peripheral clock reference. Signed-off-by: Raphael Gallais-Pou --- arch/arm/boot/dts/st/stm32mp157.dtsi | 2 +-

[PATCH RESEND 1/3] drm/stm: dsi: add pm runtime ops

From: Yannick Fertre Update control of clocks and supply thanks to the PM runtime mechanism to avoid kernel crash during a system suspend. Signed-off-by: Yannick Fertre --- drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 28 +++ 1 file changed, 20 insertions(+), 8 deletions(-)

Re: [PATCH 1/3] Revert "drm/prime: Unexport helpers for fd/handle conversion"

Am 23.11.23 um 20:36 schrieb Felix Kuehling: [+Alex] On 2023-11-17 16:44, Felix Kuehling wrote: This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3. These helper functions are needed for KFD to export and import DMABufs the right way without duplicating the tracking of DMABufs

Re: [PATCH v3 08/11] drm/mediatek: Support alpha blending in VDOSYS1

[PATCH 1/2] drm/sched: Rename priority MIN to LOW

Rename DRM_SCHED_PRIORITY_MIN to DRM_SCHED_PRIORITY_LOW. This mirrors DRM_SCHED_PRIORITY_HIGH, for a list of DRM scheduler priorities in ascending order, DRM_SCHED_PRIORITY_LOW, DRM_SCHED_PRIORITY_NORMAL, DRM_SCHED_PRIORITY_HIGH, DRM_SCHED_PRIORITY_KERNEL. Cc: Rob Clark Cc: Abhinav

[PATCH 2/2] drm/sched: Reverse run-queue priority enumeration

Reverse run-queue priority enumeration such that the higest priority is now 0, and for each consecutive integer the prioirty diminishes. Run-queues correspond to priorities. To an external observer a scheduler created with a single run-queue, and another created with DRM_SCHED_PRIORITY_COUNT

[PATCH 0/2] Make scheduling of the same index, the same

The first patch renames priority MIN to LOW. The second patch makes the "priority" of the same run-queue index in any two schedulers, the same. This series sits on top on this fix https://patchwork.freedesktop.org/patch/568723/ which I sent yesterday. Luben Tuikov (2): drm/sched: Rename

Re: [PATCH v2] drm/mediatek: Add spinlock for setting vblank event in atomic_begin

On Wed, Nov 8, 2023 at 3:27 PM CK Hu (胡俊光) wrote: > > Hi, Jason: > > On Wed, 2023-09-20 at 17:06 +0800, Jason-JH.Lin wrote: > > Add spinlock protection to avoid race condition on vblank event > > between mtk_drm_crtc_atomic_begin() and mtk_drm_finish_page_flip(). > > Reviewed-by: CK Hu Please

Re: [PATCH 3/4] arm64: dts: mediatek: mt8195: add DSI and MIPI DPHY nodes

On Thu, Nov 23, 2023 at 9:38 PM Michael Walle wrote: > > Add the two DSI controller node and the associated DPHY nodes. > Individual boards have to enable them in the board device tree. > > Signed-off-by: Michael Walle Reviewed-by: Chen-Yu Tsai I checked all the address ranges and interrupt

Re: [PATCH v1 3/4] drm/rockchip: rk3066_hdmi: Remove useless output format

Hi Johan: some information bellow hope can help a bit. On 11/23/23 20:54, Johan Jonker wrote: On 11/20/23 18:06, Heiko Stuebner wrote: Hi Johan, Am Donnerstag, 2. November 2023, 14:42:19 CET schrieb Johan Jonker: The Rk3066 hdmi output format is hard coded to RGB. Remove all useless code

linux-next: build warning after merge of the drm tree

Hi all, After merging the drm tree, today's linux-next build (htmldocs) produced this warning: include/uapi/drm/pvr_drm.h:1: warning: 'Flags for DRM_PVR_DEV_QUERY_HEAP_INFO_GET.' not found Introduced by commit 1088d89e5515 ("drm/imagination/uapi: Add PowerVR driver UAPI") -- Cheers,

linux-next: build warning after merge of the drm tree

Hi all, After merging the drm tree, today's linux-next build (htmldocs) produced this warning: drivers/gpu/drm/imagination/pvr_drv.c:1: warning: 'PowerVR Graphics Driver' not found Introduced by commit 815d8b0425ad ("drm/imagination: Add driver documentation") -- Cheers, Stephen Rothwell

linux-next: build warning after merge of the drm tree

Hi all, After merging the drm tree, today's linux-next build (htmldocs) produced this warning: Documentation/gpu/imagination/uapi.rst:124: WARNING: Title underline too short. CREATE_HWRT_DATASET and DESTROY_HWRT_DATASET -- Introduced by commit

Re: [PATCH v2 2/4] eventfd: simplify eventfd_signal()

On Wed, 2023-11-22 at 13:48 +0100, Christian Brauner wrote: > Ever since the evenfd type was introduced back in 2007 in commit > e1ad7468c77d ("signal/timer/event: eventfd core") the > eventfd_signal() > function only ever passed 1 as a value for @n. There's no point in > keeping that additional

[git pull] drm fixes for 6.7-rc3

Hi Linus, Back to regular scheduled fixes pull request, mainly a bunch of msm, some i915 and otherwise a few scattered, one memory crasher in the nouveau GSP paths is helping stabilise that work. Regards, Dave. drm-fixes-2023-11-24: drm fixes for 6.7-rc3 msm: - Fix the VREG_CTRL_1 for 4nm CPHY

[PATCH v2 17/17] drm/v3d: Create a CPU job extension for the copy performance query job

A CPU job is a type of job that performs operations that requires CPU intervention. A copy performance query job is a job that copy the complete or partial result of a query to a buffer. In order to copy the result of a performance query to a buffer, we need to get the values from the performance

[PATCH v2 15/17] drm/v3d: Create a CPU job extension to copy timestamp query to a buffer

A CPU job is a type of job that performs operations that requires CPU intervention. A copy timestamp query job is a job that copy the complete or partial result of a query to a buffer. As V3D doesn't provide any mechanism to obtain a timestamp from the GPU, it is a job that needs CPU intervention.

[PATCH v2 16/17] drm/v3d: Create a CPU job extension for the reset performance query job

A CPU job is a type of job that performs operations that requires CPU intervention. A reset performance query job is a job that resets the performance queries by resetting the values of the perfmons. Moreover, we also reset the syncobjs related to the availability of the query. So, create a user

[PATCH v2 13/17] drm/v3d: Create a CPU job extension for the timestamp query job

A CPU job is a type of job that performs operations that requires CPU intervention. A timestamp query job is a job that calculates the query timestamp and updates the query availability by signaling a syncobj. As V3D doesn't provide any mechanism to obtain a timestamp from the GPU, it is a job

[PATCH v2 14/17] drm/v3d: Create a CPU job extension for the reset timestamp job

A CPU job is a type of job that performs operations that requires CPU intervention. A reset timestamp job is a job that resets the timestamp queries based on the value offset of the first query. As V3D doesn't provide any mechanism to obtain a timestamp from the GPU, it is a job that needs CPU

[PATCH v2 12/17] drm/v3d: Create a CPU job extension for a indirect CSD job

A CPU job is a type of job that performs operations that requires CPU intervention. An indirect CSD job is a job that, when executed in the queue, will map the indirect buffer, read the dispatch parameters, and submit a regular dispatch. Therefore, it is a job that needs CPU intervention. So,

[PATCH v2 11/17] drm/v3d: Enable BO mapping

For the indirect CSD CPU job, we will need to access the internal contents of the BO with the dispatch parameters. Therefore, create methods to allow the mapping and unmapping of the BO. Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_bo.c | 18 ++

[PATCH v2 10/17] drm/v3d: Detach the CSD job BO setup

From: Melissa Wen Detach CSD job setup from CSD submission ioctl to reuse it in CPU submission ioctl for indirect CSD job. Signed-off-by: Melissa Wen Co-developed-by: Maíra Canal Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_submit.c | 52 +--- 1 file

[PATCH v2 09/17] drm/v3d: Create tracepoints to track the CPU job

Create tracepoints to track the three major events of a CPU job lifetime: 1. Submission of a `v3d_submit_cpu` IOCTL 2. Beginning of the execution of a CPU job 3. Ending of the execution of a CPU job Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_sched.c | 4 +++

[PATCH v2 08/17] drm/v3d: Use v3d_get_extensions() to parse CPU job data

Currently, v3d_get_extensions() only parses multisync data and assigns it to the `struct v3d_submit_ext`. But, to implement the CPU job with user extensions, we want v3d_get_extensions() to be able to parse CPU job data and assign it to the `struct v3d_cpu_job`. Therefore, allow the function

[PATCH v2 07/17] drm/v3d: Add a CPU job submission

From: Melissa Wen Create a new type of job, a CPU job. A CPU job is a type of job that performs operations that requires CPU intervention. The overall idea is to use user extensions to enable different types of CPU job, allowing the CPU job to perform different operations according to the type

[PATCH v2 05/17] drm/v3d: Don't allow two multisync extensions in the same job

Currently, two multisync extensions can be added to the same job and only the last multisync extension will be used. To avoid this vulnerability, don't allow two multisync extensions in the same job. Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_submit.c | 5 + 1 file changed, 5

[PATCH v2 06/17] drm/v3d: Decouple job allocation from job initiation

We want to allow the IOCTLs to allocate the job without initiating it. This will be useful for the CPU job submission IOCTL, as the CPU job has the need to use information from the user extensions. Currently, the user extensions are parsed before the job allocation, making it impossible to fill

[PATCH v2 04/17] drm/v3d: Simplify job refcount handling

From: Melissa Wen Instead of checking if the job is NULL every time we call the function, check it inside the function. Signed-off-by: Melissa Wen Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_submit.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git

[PATCH v2 02/17] drm/v3d: Move wait BO ioctl to the v3d_bo file

From: Melissa Wen IOCTLs related to BO operations reside on the file v3d_bo.c. The wait BO ioctl is the only IOCTL regarding BOs that is placed in a different file. So, move it to the v3d_bo.c file. Signed-off-by: Melissa Wen Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_bo.c | 33

[PATCH v2 03/17] drm/v3d: Detach job submissions IOCTLs to a new specific file

From: Melissa Wen We will include a new job submission type, the CPU job submission. For readability and maintability, separate the job submission IOCTLs and related operations from v3d_gem.c. Minor fix in the CSD submission kernel doc: CSD (texture formatting) -> CSD (compute shader).

[PATCH v2 00/17] drm/v3d: Introduce CPU jobs

This patchset implements the basic infrastructure for a new type of V3D job, a CPU job. A CPU job is a job that requires CPU intervention. It would be nice to perform this operations on the kernel space as we can attach multiple in/out syncobjs to it. Why we want a CPU job on the kernel?

[PATCH v2 01/17] drm/v3d: Remove unused function header

From: Melissa Wen v3d_mmu_get_offset header was added but the function was never defined. Just remove it. Signed-off-by: Melissa Wen Signed-off-by: Maíra Canal --- drivers/gpu/drm/v3d/v3d_drv.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/v3d/v3d_drv.h

Re: [GIT PULL] exynos-drm-fixes

On Tue, 21 Nov 2023 at 09:00, Inki Dae wrote: > > Hi Dave and Daniel, > >Two fixups - fixing a potential error pointer dereference and wrong >error checking. Hi Inki, This fails to build on arm32, and it seems one of the fixes is wrong [airlied@dreadlord drm-fixes]$ make ARCH=arm

Re: linux-next: manual merge of the drm-intel tree with the amdgpu tree

Hi all, On Mon, 20 Nov 2023 12:28:18 +1100 Stephen Rothwell wrote: > > Today's linux-next merge of the drm-intel tree got a conflict in: > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c > > between commits: > > a58555359a9f ("drm/amd/display: Fix DSC not Enabled on Direct

[PATCH v4 5/5] drm/todo: Add entry about implementing buffer age for damage tracking

Currently, only damage tracking for frame damage is supported. If a driver needs to do buffer damage (e.g: the framebuffer attached to plane's state has changed since the last page-flip), the damage helpers just fallback to a full plane update. Add en entry in the TODO about implementing buffer

[PATCH v4 1/5] drm: Allow drivers to indicate the damage helpers to ignore damage clips

It allows drivers to set a struct drm_plane_state .ignore_damage_clips in their plane's .atomic_check callback, as an indication to damage helpers such as drm_atomic_helper_damage_iter_init() that the damage clips should be ignored. To be used by drivers that do per-buffer (e.g: virtio-gpu)

[PATCH v4 4/5] drm/plane: Extend damage tracking kernel-doc

The "Damage Tracking Properties" section in the documentation doesn't have info about the two type of damage handling: frame damage vs buffer damage. Add it to the section and mention that helpers only support frame damage, and how drivers handling buffer damage can indicate that the damage clips

[PATCH v4 3/5] drm/vmwgfx: Disable damage clipping if FB changed since last page-flip

The driver does per-buffer uploads and needs to force a full plane update if the plane's attached framebuffer has change since the last page-flip. Suggested-by: Sima Vetter Signed-off-by: Javier Martinez Canillas Reviewed-by: Thomas Zimmermann Reviewed-by: Zack Rusin Acked-by: Sima Vetter

[PATCH v4 2/5] drm/virtio: Disable damage clipping if FB changed since last page-flip

The driver does per-buffer uploads and needs to force a full plane update if the plane's attached framebuffer has change since the last page-flip. Fixes: 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the primary plane") Cc: # v6.4+ Reported-by: nerdopolis Closes:

[PATCH v4 0/5] drm: Allow the damage helpers to handle buffer damage

Hello, This series is to fix an issue that surfaced after damage clipping was enabled for the virtio-gpu by commit 01f05940a9a7 ("drm/virtio: Enable fb damage clips property for the primary plane"). After that change, flickering artifacts was reported to be present with both weston and wlroots

Re: [PATCH v6 0/9] Fix cursor planes with virtualized drivers

On Wednesday, November 22nd, 2023 at 13:49, Javier Martinez Canillas wrote: > Any objections to merge the series ? No objections from me :)

Re: [PATCH v5 00/20] remove I2C_CLASS_DDC support

On Thu, Nov 23, 2023 at 10:40:20AM +0100, Heiner Kallweit wrote: > After removal of the legacy EEPROM driver and I2C_CLASS_DDC support in > olpc_dcon there's no i2c client driver left supporting I2C_CLASS_DDC. > Class-based device auto-detection is a legacy mechanism and shouldn't > be used in new

Re: [PATCH v2 0/4] eventfd: simplify signal helpers

On 11/22/23 5:48 AM, Christian Brauner wrote: > Hey everyone, > > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers > significantly. They can be made void and not take any unnecessary > arguments. > > I've added a few more simplifications based on Sean's suggestion. > >

Re: [PULL] drm-misc-next

On Thu, Nov 23, 2023 at 01:58:50PM +0100, Maxime Ripard wrote: > Hi, > > Here's this week drm-misc-next PR. > > It's been fairly calm, but there's one big change: the IMG GPU driver is > now merged! > > Maxime > > drm-misc-next-2023-11-23: > drm-misc-next for 6.8: > > UAPI Changes: > >

Re: [PULL] drm-intel-next

On Thu, Nov 23, 2023 at 09:03:59PM +0200, Jani Nikula wrote: > > Hi Dave & Sima - > > The first i915 feature pull towards v6.8. > > The one thing to single out are the major DP MST, UHBR, and DSC > bandwidth management improvements from Imre. > > Alas, they also need to be singled out because

Re: [PATCH 1/3] Revert "drm/prime: Unexport helpers for fd/handle conversion"

[+Alex] On 2023-11-17 16:44, Felix Kuehling wrote: This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3. These helper functions are needed for KFD to export and import DMABufs the right way without duplicating the tracking of DMABufs associated with GEM objects while ensuring that

[PULL] drm-intel-next

Hi Dave & Sima - The first i915 feature pull towards v6.8. The one thing to single out are the major DP MST, UHBR, and DSC bandwidth management improvements from Imre. Alas, they also need to be singled out because there are a number of updates in drm core and other drivers merged via

Re: [PATCH 2/3] dt-bindings: ili9881c: Add Ampire AM8001280G LCD panel

On Thu, Nov 23, 2023 at 06:08:05PM +0100, Philipp Zabel wrote: > Document the compatible value for Ampire AM8001280G LCD panels. > > Signed-off-by: Philipp Zabel Acked-by: Conor Dooley Cheers, Conor. > --- > Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + > 1

[PATCH 3/3] drm/bridge: ti-sn65dsi86: Loosen coupling of PWM to ti-sn65dsi86 core

Introduce a dedicated private data structure for the pwm aux driver provided by the sn65dsi86 driver. This way data needed for PWM operation is (to a certain degree) nicely separated and doesn't occupy memory in the ti_sn65dsi86 core's private data if the PWM isn't used. The eventual goal is to

[PATCH 2/3] drm/bridge: ti-sn65dsi86: Change parameters of ti_sn65dsi86_{read, write}_u16

This aligns the function's parameters to regmap_{read,write} and simplifies the next change that takes pwm driver data out of struct ti_sn65dsi86. Signed-off-by: Uwe Kleine-König --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 20 ++-- 1 file changed, 10 insertions(+), 10

[PATCH 0/3] drm/bridge: ti-sn65dsi86: Some updates

Hello, this is a series I created while starring at the ti-sn65dsi86 driver in the context of my pwm-lifetime series. The first patch should be fine. The last one has a few rough edges, but maybe you like the direction this is going to? The 2nd patch probably only makes sense if you also take

[PATCH 1/3] drm/bridge: ti-sn65dsi86: Simplify using pm_runtime_resume_and_get()

pm_runtime_resume_and_get() already drops the runtime PM usage counter in the error case. So a call to pm_runtime_put_sync() can be dropped. Signed-off-by: Uwe Kleine-König --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

Hi, On 2023/11/23 16:08, Dmitry Baryshkov wrote: I'm agree with the idea that drm bridges drivers involved toward to a direction that support more complex design, but I think we should also leave a way for the most frequent use case. Make it straight-forward as a canonical design. Not having

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

On Thu, 23 Nov 2023 at 19:04, Sui Jingfeng wrote: > > Hi, > > > On 2023/11/23 16:08, Dmitry Baryshkov wrote: > >>> The host can not specify the > >>> DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, it will cause a warning here. And > >>> it can not omit the flag (as otherwise the first bridge will create a

Re: [PATCH v4 2/2] drm/bridge: imx: add driver for HDMI TX Parallel Video Interface

Hi Lucas, On Thu, Sep 28, 2023 at 9:56 AM Lucas Stach wrote: > > This IP block is found in the HDMI subsystem of the i.MX8MP SoC. It has a > full timing generator and can switch between different video sources. On > the i.MX8MP however the only supported source is the LCDIF. The block > just

Re: [PATCH 0/4] drm/i915: Fix LUT rounding

On Tue, Nov 21, 2023 at 11:51:10AM +0100, Maxime Ripard wrote: > On Mon, Nov 20, 2023 at 04:30:53PM +0200, Ville Syrjälä wrote: > > On Fri, Oct 13, 2023 at 04:13:58PM +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > The current LUT rounding is generating weird results. Adjust >

Re: [PATCH 1/2] dt-bindings: display: simple: add Evervision VGG644804 panel

On Thu, Nov 23, 2023 at 11:24:03AM +0100, Michael Walle wrote: > Add Evervision VGG644804 5.7" 640x480 LVDS panel compatible string. > > Signed-off-by: Michael Walle Acked-by: Conor Dooley Cheers, Conor. > --- > .../devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ > 1

Re: [PATCH 2/4] dt-bindings: phy: add compatible for Mediatek MT8195

On Thu, Nov 23, 2023 at 02:37:47PM +0100, Michael Walle wrote: > Add the compatible string for MediaTek MT8195 SoC, using the same MIPI > D-PHY block as the MT8183. > > Signed-off-by: Michael Walle Acked-by: Conor Dooley Cheers, Conor. signature.asc Description: PGP signature

Re: [PATCH 1/4] dt-bindings: display: mediatek: dsi: add compatible for MediaTek MT8195

On Thu, Nov 23, 2023 at 02:37:46PM +0100, Michael Walle wrote: > Add the compatible string for MediaTek MT8195 SoC, using the same DSI > block as the MT8183. > > Signed-off-by: Michael Walle Acked-by: Conor Dooley signature.asc Description: PGP signature

Re: [PATCH] dt-bindings: display: mediatek: dsi: remove Xinlei's mail

On Thu, Nov 23, 2023 at 02:49:27PM +0100, Michael Walle wrote: > Xinlei Lee's mail is bouncing: > > : host mailgw02.mediatek.com[216.200.240.185] said: > 550 Relaying mail to xinlei@mediatek.com is not allowed (in reply to > RCPT TO command) Acked-by: Conor Dooley Cheers, Conor.

[PATCH 2/3] dt-bindings: ili9881c: Add Ampire AM8001280G LCD panel

Document the compatible value for Ampire AM8001280G LCD panels. Signed-off-by: Philipp Zabel --- Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml

[PATCH 3/3] drm/panel: ilitek-ili9881c: Add Ampire AM8001280G LCD panel

Add support for Ampire AM8001280G LCD panels. Signed-off-by: Philipp Zabel --- drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 223 ++ 1 file changed, 223 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c

[PATCH 1/3] drm/panel: ilitek-ili9881c: make use of prepare_prev_first

From: Marco Felsch The panel.prepare() call requires an initialized MIPI-DSI host, so set the prepare_prev_first flag to indicate that the host must be initialized first. Signed-off-by: Marco Felsch Signed-off-by: Philipp Zabel --- drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 2 ++ 1 file

[PATCH 0/3] drm/panel: ilitek-ili9881c: Support Ampire AM8001280G LCD panel

ase-commit: e4d983ac270ccee417445a69b9ed198658b1 change-id: 20231123-drm-panel-ili9881c-am8001280g-d2e2f4b30a2e Best regards, -- Philipp Zabel

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

Hi, On 2023/11/23 16:08, Dmitry Baryshkov wrote: The host can not specify the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag, it will cause a warning here. And it can not omit the flag (as otherwise the first bridge will create a connector, without consulting the second bridge). The semantics of

[PULL] drm-intel-fixes

Hi Dave & Sima - drm-intel-fixes-2023-11-23: drm/i915 fixes for v6.7-rc3: - Fix race between DP MST connectore registration and setup - Fix GT memory leak on probe error path BR, Jani. The following changes since commit 98b1cc82c4affc16f5598d4fa14b1858671b2263: Linux 6.7-rc2 (2023-11-19

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

Hi, On 2023/11/24 00:06, Dmitry Baryshkov wrote: On Thu, 23 Nov 2023 at 17:41, Sui Jingfeng wrote: Hi, On 2023/11/23 16:08, Dmitry Baryshkov wrote: The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined, No, they are not. Semantics are pretty simple: do not create the

Re: [PATCH v9 0/4] drm: Add support for atomic async page-flip

Em 23/11/2023 13:24, Simon Ser escreveu: Thanks! This iteration of the first 3 patches LGTM, I've pushed them to drm-misc-next. I've made two adjustments to make checkpatch.pl happy: Thank you! - s/uint64_t/u64/ - Fix indentation for a drm_dbg_atomic() ops :)

Re: [PATCH v9 0/4] drm: Add support for atomic async page-flip

Thanks! This iteration of the first 3 patches LGTM, I've pushed them to drm-misc-next. I've made two adjustments to make checkpatch.pl happy: - s/uint64_t/u64/ - Fix indentation for a drm_dbg_atomic()

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

Hi, On 2023/11/23 21:39, Neil Armstrong wrote: On 23/11/2023 09:08, Dmitry Baryshkov wrote: On Thu, 23 Nov 2023 at 07:05, Sui Jingfeng wrote: Hi, On 2023/11/16 19:19, Dmitry Baryshkov wrote: On Thu, 16 Nov 2023 at 12:13, Sui Jingfeng wrote: Hi, On 2023/11/16 17:30, Dmitry Baryshkov

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

On Thu, 23 Nov 2023 at 17:41, Sui Jingfeng wrote: > > Hi, > > > On 2023/11/23 16:08, Dmitry Baryshkov wrote: > >> The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined, > > No, they are not. Semantics are pretty simple: do not create the > > drm_connector instance. Pass the

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

Hi, On 2023/11/23 16:08, Dmitry Baryshkov wrote: The semantics of DRM_BRIDGE_ATTACH_NO_CONNECTOR flag are implement-defined, No, they are not. Semantics are pretty simple: do not create the drm_connector instance. Pass the flag to the next bridge in the chain. Then, my problem is that do

Re: [PATCH] drm/panfrost: Ignore core_mask for poweroff and sync interrupts

On Thu, 23 Nov 2023 16:14:12 +0100 AngeloGioacchino Del Regno wrote: > Il 23/11/23 14:51, Boris Brezillon ha scritto: > > On Thu, 23 Nov 2023 14:24:57 +0100 > > AngeloGioacchino Del Regno > > wrote: > > > > So, while I agree that it'd be slightly more readable as a diff if those >

Re: [PATCH v4 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation

Hi, > mtk_drm_find_possible_crtc_by_comp() assumed that the main path will > always have the CRTC with id 0, the ext id 1 and the third id 2. This > is only true if the paths are all available. But paths are optional > (see > also comment in mtk_drm_kms_init()), e.g. the main path might not be

Re: (subset) [PATCH v3 1/1] backlight: pwm_bl: Use dev_err_probe

On Fri, 17 Nov 2023 13:06:25 +0100, Alexander Stein wrote: > Use dev_err_probe to simplify error paths. Also let dev_err_probe handle > the -EPROBE_DEFER case and add an entry to > /sys/kernel/debug/devices_deferred when deferred. > > Applied, thanks! [1/1] backlight: pwm_bl: Use dev_err_probe

Re: [PATCH v4 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation

Hi, Michael: Michael Walle 於 2023年11月21日 週二 下午10:44寫道： > > Hi, > > > mtk_drm_find_possible_crtc_by_comp() assumed that the main path will > > always have the CRTC with id 0, the ext id 1 and the third id 2. This > > is only true if the paths are all available. But paths are optional > > (see > >

Re: [PATCH v5 1/4] pwm: rename pwm_apply_state() to pwm_apply_cansleep()

On Sat, 18 Nov 2023, Sean Young wrote: > In order to introduce a pwm api which can be used from atomic context, > we will need two functions for applying pwm changes: > > int pwm_apply_cansleep(struct pwm *, struct pwm_state *); > int pwm_apply_atomic(struct pwm *, struct pwm_state

Re: [PATCH] drm/panfrost: Ignore core_mask for poweroff and sync interrupts

Il 23/11/23 14:51, Boris Brezillon ha scritto: On Thu, 23 Nov 2023 14:24:57 +0100 AngeloGioacchino Del Regno wrote: So, while I agree that it'd be slightly more readable as a diff if those were two different commits I do have reasons against splitting. If we just need a quick fix to

Re: [PATCH v7 0/2] backlight: mp3309c: Add support for MPS MP3309C

On Thu, 16 Nov 2023 11:53:17 +0100, Flavio Suligoi wrote: > This patchset (rebased on v6.7.0-rc1 kernel version): > > - includes and updates the mps,mp3309c.yaml dt bindings file: > - Documentation/devicetree/bindings/leds/backlight/mps,mp3309c.yaml > Note: the patch related to this file

Re: [PATCH v18 15/26] drm/panfrost: Explicitly get and put drm-shmem pages

On Mon, 30 Oct 2023 02:01:54 +0300 Dmitry Osipenko wrote: > To simplify the drm-shmem refcnt handling, we're moving away from > the implicit get_pages() that is used by get_pages_sgt(). From now on > drivers will have to pin pages while they use sgt. Panfrost's shrinker > doesn't support

Re: [PATCH v18 15/26] drm/panfrost: Explicitly get and put drm-shmem pages

On Thu, 23 Nov 2023 15:24:32 +0300 Dmitry Osipenko wrote: > On 11/23/23 12:05, Boris Brezillon wrote: > > On Thu, 23 Nov 2023 01:04:56 +0300 > > Dmitry Osipenko wrote: > > > >> On 11/10/23 13:53, Boris Brezillon wrote: > >>> Hm, there was no drm_gem_shmem_get_pages_sgt() call here, why >

Re: [PATCH 3/3] drm/amd/display: Support DRM_AMD_DC_FP on RISC-V

On Tue, Nov 21, 2023 at 07:05:15PM -0800, Samuel Holland wrote: > RISC-V uses kernel_fpu_begin()/kernel_fpu_end() like several other > architectures. Enabling hardware FP requires overriding the ISA string > for the relevant compilation units. Ah yes, bringing the joy of frame-larger-than

Re: Powered off Philips TV sends corrupt EDID causing flickering

Dear Jani, Thank you for your reply. Am 22.11.23 um 11:38 schrieb Jani Nikula: On Tue, 21 Nov 2023, Paul Menzel wrote: Connecting a USB Type-C port replicator [1] to the only USB Type-C port of the Dell XPS 13 9360 with Debian sid/unstable and Debian’s Linux kernel 6.10.5, and then

Re: [PATCH v3] drm/panfrost: Ignore core_mask for poweroff and sync interrupts

On Thu, 23 Nov 2023 14:30:08 +0100 AngeloGioacchino Del Regno wrote: > Il 23/11/23 14:13, Boris Brezillon ha scritto: > > On Thu, 23 Nov 2023 13:05:21 +0100 > > AngeloGioacchino Del Regno > > wrote: > > > >> Some SoCs may be equipped with a GPU containing two core groups > >> and this is

Re: [PATCH] drm/panfrost: Ignore core_mask for poweroff and sync interrupts

On Thu, 23 Nov 2023 14:24:57 +0100 AngeloGioacchino Del Regno wrote: > >> > >> So, while I agree that it'd be slightly more readable as a diff if those > >> were two different commits I do have reasons against splitting. > > > > If we just need a quick fix to avoid PWRTRANS interrupts

[PATCH] dt-bindings: display: mediatek: dsi: remove Xinlei's mail

Xinlei Lee's mail is bouncing: : host mailgw02.mediatek.com[216.200.240.185] said: 550 Relaying mail to xinlei@mediatek.com is not allowed (in reply to RCPT TO command) Remove it. Signed-off-by: Michael Walle --- .../devicetree/bindings/display/mediatek/mediatek,dsi.yaml | 1

[PATCH v3] drm/mediatek: Stop using iommu_present()

Remove the pointless check. If an IOMMU is providing transparent DMA API ops for any device(s) we care about, the DT code will have enforced the appropriate probe ordering already. And if the IOMMU *is* entirely absent, then attempting to go ahead with CMA and either suceeding or failing

Re: [PATCH 8/8] drm/bridge: it66121: Allow link this driver as a lib

On 23/11/2023 09:08, Dmitry Baryshkov wrote: On Thu, 23 Nov 2023 at 07:05, Sui Jingfeng wrote: Hi, On 2023/11/16 19:19, Dmitry Baryshkov wrote: On Thu, 16 Nov 2023 at 12:13, Sui Jingfeng wrote: Hi, On 2023/11/16 17:30, Dmitry Baryshkov wrote: On Thu, 16 Nov 2023 at 11:14, Sui Jingfeng

[PATCH 4/4] drm/mediatek: support the DSI0 output on the MT8195 VDOSYS0

With the latest dynamic selection of the output component, we can now support different outputs. Move current output component into the dynamic routes array and add the new DSI0 output. Signed-off-by: Michael Walle --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +++- 1 file changed, 7

[PATCH 3/4] arm64: dts: mediatek: mt8195: add DSI and MIPI DPHY nodes

Add the two DSI controller node and the associated DPHY nodes. Individual boards have to enable them in the board device tree. Signed-off-by: Michael Walle --- arch/arm64/boot/dts/mediatek/mt8195.dtsi | 48 1 file changed, 48 insertions(+) diff --git

  1   2   >