Re: [PATCH 2/2] drm:amdgpu: add firmware information of all IP's

On 3/14/2024 2:06 AM, Alex Deucher wrote: On Tue, Mar 12, 2024 at 8:42 AM Sunil Khatri wrote: Add firmware version information of each IP and each instance where applicable. Is there a way we can share some common code with devcoredump, debugfs, and the info IOCTL? All three places need

Re: [PATCH 04/11] drm/mediatek: Rename "mtk_drm_gem" to "mtk_gem"

Re: [PATCH 1/2] drm/amdgpu: add the IP information of the soc

On 3/14/2024 1:58 AM, Alex Deucher wrote: On Tue, Mar 12, 2024 at 8:41 AM Sunil Khatri wrote: Add all the IP's information on a SOC to the devcoredump. Signed-off-by: Sunil Khatri --- drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 19 +++ 1 file changed, 19 insertions(+)

Re: [PATCH] drm/sun4i: tcon: Support keeping dclk rate upon ancestor clock changes

On 2024-03-13 at 19:11:37 +0100, Jernej Škrabec wrote: Hi Jernej, Thank you for your having a thorough look at this! > Hi Frank! > > Thanks on tackling this issue. > > Dne nedelja, 10. marec 2024 ob 14:32:29 CET je Frank Oltmanns napisal(a): >> Allow the dclk to reset its rate when a rate

RE: [PATCH] drm/i915/gt: Report full vm address range

Commit 9bb66c179f50 ("drm/i915: Reserve some kernel space per vm") has reserved an object for kernel space usage. Userspace, though, needs to know the full address range. Fixes: 9bb66c179f50 ("drm/i915: Reserve some kernel space per vm") Signed-off-by: Andi Shyti Cc: Andrzej Hajda Cc: Chris

Re: [PATCH 03/11] drm/mediatek: Rename "mtk_drm_plane" to "mtk_plane"

Re: [PATCH 02/11] drm/mediatek: Rename "mtk_drm_ddp_comp" to "mtk_ddp_comp"

Re: [git pull] drm for 6.9-rc1

On Thu, 14 Mar 2024 at 11:49, Linus Torvalds wrote: > > On Tue, 12 Mar 2024 at 21:07, Dave Airlie wrote: > > > > I've done a trial merge into your tree from a few hours ago, there > > are definitely some slighty messy conflicts, I've pushed a sample > > branch here: > > I appreciate your sample

Re: [PATCH 01/11] drm/mediatek: Rename "mtk_drm_crtc" to "mtk_crtc"

RE: [PATCH AUTOSEL 5.15 3/5] drm/amdgpu: Enable gpu reset for S3 abort cases on Raven series

[AMD Official Use Only - General] > From: Alex Deucher > Sent: Thursday, March 14, 2024 4:46 AM > To: Kuehling, Felix > Cc: Sasha Levin ; linux-ker...@vger.kernel.org; > sta...@vger.kernel.org; Liang, Prike ; Deucher, > Alexander ; Koenig, Christian > ; Pan, Xinhui ; > airl...@gmail.com;

Re: [git pull] drm for 6.9-rc1

The pull request you sent on Wed, 13 Mar 2024 14:06:52 +1000: > https://gitlab.freedesktop.org/drm/kernel.git tags/drm-next-2024-03-13 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/480e035fc4c714fb5536e64ab9db04fedc89e910 Thank you! -- Deet-doot-dot, I am a bot.

Re: [git pull] drm for 6.9-rc1

On Tue, 12 Mar 2024 at 21:07, Dave Airlie wrote: > > I've done a trial merge into your tree from a few hours ago, there > are definitely some slighty messy conflicts, I've pushed a sample > branch here: I appreciate your sample merges since I like verifying my end result, but I think your merge

[PATCH] nouveau/gsp: don't check devinit disable on GSP.

From: Dave Airlie GSP should be handling this and I can see no evidence in opengpu driver that this register should be touched. Fixed acceleration on 2080 Ti GPUs. Fixes: 15740541e8f0 ("drm/nouveau/devinit/tu102-: prepare for GSP-RM") Signed-off-by: Dave Airlie ---

[PATCH v3 5/5] drm/msm/dpu: drop dpu_core_perf_params::max_per_pipe_ib

The max_per_pipe_ib is a constant across all CRTCs and is read from the catalog. Drop corresponding calculations and read the value directly at icc_set_bw() time. Suggested-by: Konrad Dybcio Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 17

[PATCH v3 3/5] drm/msm/dpu: handle perf mode in _dpu_core_perf_crtc_update_bus()

Move perf mode handling for the bandwidth to _dpu_core_perf_crtc_update_bus() rather than overriding per-CRTC data and then aggregating known values. Note, this changes the fix_core_ab_vote. Previously it would be multiplied per the CRTC number, now it will be used directly for interconnect

[PATCH v3 2/5] drm/msm/dpu: core_perf: extract bandwidth aggregation function

In preparation to refactoring the dpu_core_perf debugfs interface, extract the bandwidth aggregation function from _dpu_core_perf_crtc_update_bus(). Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 45 +++ 1 file changed, 25

[PATCH v3 4/5] drm/msm/dpu: rework core_perf debugfs overrides

Currently debugfs provides separate 'modes' to override calculated MDP_CLK rate and interconnect bandwidth votes. Change that to allow overriding individual values (e.g. one can override just clock or just average bandwidth vote). Signed-off-by: Dmitry Baryshkov ---

[PATCH v3 1/5] drm/msm/dpu: don't allow overriding data from catalog

The data from catalog is marked as const, so it is a part of the RO segment. Allowing userspace to write to it through debugfs can cause protection faults. Set debugfs file mode to read-only for debug entries corresponding to perf_cfg coming from catalog. Fixes: abda0d925f9c ("drm/msm/dpu: Mark

[PATCH v3 0/5] drm/msm/dpu: rework debugfs interface of dpu_core_perf

Bring back a set of patches extracted from [1] per Abhinav's suggestion. Rework debugging overrides for the bandwidth and clock settings. Instead of specifying the 'mode' and some values, allow one to set the affected value directly. [1] https://patchwork.freedesktop.org/series/119552/#rev2

Re: [PATCH v4 00/13] drm/msm/dpu: support virtual wide planes

On Thu, 14 Mar 2024 at 02:02, Dmitry Baryshkov wrote: > > As promised in the basic wide planes support ([1]) here comes a series > supporting 2*max_linewidth for all the planes. > > Note: Unlike v1 and v2 this series finally includes support for > additional planes - having more planes than the

[PATCH v4 05/13] drm/msm/dpu: move scaling limitations out of the hw_catalog

Max upscale / downscale factors are constant between platforms. In preparation to adding support for virtual planes and allocating SSPP blocks on demand move max scaling factors out of the HW catalog and handle them in the dpu_plane directly. If any of the scaling blocks gets different

[PATCH v4 10/13] drm/msm/dpu: allow sharing SSPP between planes

Since SmartDMA planes provide two rectangles, it is possible to use them to drive two different DRM planes, first plane getting the rect_0, another one using rect_1 of the same SSPP. The sharing algorithm is pretty simple, it requires that each of the planes can be driven by the single rectangle

[PATCH v4 12/13] drm/msm/dpu: allow sharing of blending stages

It is possible to slightly bend the limitations of the HW blender. If two rectangles are contiguous (like two rectangles of a single plane) they can be blended using a single LM blending stage, allowing one to blend more planes via a single LM. Signed-off-by: Dmitry Baryshkov ---

[PATCH v4 08/13] drm/msm/dpu: add support for virtual planes

Only several SSPP blocks support such features as YUV output or scaling, thus different DRM planes have different features. Properly utilizing all planes requires the attention of the compositor, who should prefer simpler planes to YUV-supporting ones. Otherwise it is very easy to end up in a

[PATCH v4 06/13] drm/msm/dpu: split dpu_plane_atomic_check()

Split dpu_plane_atomic_check() function into two pieces: dpu_plane_atomic_check_nopipe() performing generic checks on the pstate, without touching the associated pipe, and dpu_plane_atomic_check_pipes(), which takes into account used pipes. Signed-off-by: Dmitry Baryshkov ---

[PATCH v4 13/13] drm/msm/dpu: include SSPP allocation state into the dumped state

Make dpu_rm_print_state() also output the SSPP allocation state. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c index

[PATCH v4 11/13] drm/msm/dpu: create additional virtual planes

Since we have enabled sharing of SSPP blocks between two planes, it is now possible to use twice as much planes as there are hardware SSPP blocks. Create additional overlay planes. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 12 1 file changed, 12

[PATCH v4 03/13] drm/msm/dpu: move pstate->pipe initialization to dpu_plane_atomic_check

In preparation for virtualized planes support, move pstate->pipe initialization from dpu_plane_reset() to dpu_plane_atomic_check(). In case of virtual planes the plane's pipe will not be known up to the point of atomic_check() callback. Signed-off-by: Dmitry Baryshkov ---

[PATCH v4 09/13] drm/msm/dpu: allow using two SSPP blocks for a single plane

Virtual wide planes give high amount of flexibility, but it is not always enough: In parallel multirect case only the half of the usual width is supported for tiled formats. Thus the whole width of two tiled multirect rectangles can not be greater than max_linewidth, which is not enough for some

[PATCH v4 02/13] drm/msm/dpu: use drm_rect_fp_to_int()

Use the drm_rect_fp_to_int() helper instead of using the hand-written code. Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c

[PATCH v4 04/13] drm/msm/dpu: drop virt_formats from SSPP subblock configuration

The virt_formats / virt_num_formats are not used by the current driver and are not going to be used in future since formats for virtual planes are handled in a different way, by forbidding unsupported combinations during atomic_check. Drop those fields now. Signed-off-by: Dmitry Baryshkov ---

[PATCH v4 07/13] drm/msm/dpu: move rot90 checking to dpu_plane_atomic_check_pipe()

Move a call to dpu_plane_check_inline_rotation() to the dpu_plane_atomic_check_pipe() function, so that the rot90 constraints are checked for both pipes. Also move rotation field from struct dpu_plane_state to struct dpu_sw_pipe_cfg. Signed-off-by: Dmitry Baryshkov ---

[PATCH v4 01/13] drm/msm/dpu: take plane rotation into account for wide planes

Take into account the plane rotation and flipping when calculating src positions for the wide plane parts. This is not an issue yet, because rotation is only supported for the UBWC planes and wide UBWC planes are rejected anyway because in parallel multirect case only the half of the usual width

[PATCH v4 00/13] drm/msm/dpu: support virtual wide planes

As promised in the basic wide planes support ([1]) here comes a series supporting 2*max_linewidth for all the planes. Note: Unlike v1 and v2 this series finally includes support for additional planes - having more planes than the number of SSPP blocks. Note: this iteration features handling of

Re: [v9,23/27] drm/vc4: hdmi: Switch to HDMI connector

Hi, LGTM, On 2024/3/11 22:49, Maxime Ripard wrote: The new HDMI connector infrastructure allows us to remove a lot of boilerplate, so let's switch to it. Signed-off-by: Maxime Ripard Acked-by: Sui Jingfeng -- Best regards, Sui

Re: [v9,01/27] drm/connector: Introduce an HDMI connector initialization function

Hi, On 2024/3/11 22:49, Maxime Ripard wrote: A lot of the various HDMI drivers duplicate some logic that depends on the HDMI spec itself and not really a particular hardware implementation. Output BPC or format selection, infoframe generation are good examples of such areas. This creates a

[PATCH v3] Fix divide-by-zero regression on DP MST unplug with nouveau

Fix a regression when using nouveau and unplugging a StarTech MSTDP122DP DisplayPort 1.2 MST hub (the same regression does not appear when using a Cable Matters DisplayPort 1.4 MST hub). Trace: divide error: [#1] PREEMPT SMP PTI CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744

Re: [PATCH] backlight: lp8788: Drop support for platform data

Hello, On Wed, Mar 13, 2024 at 01:48:27PM +0100, Uwe Kleine-König wrote: > diff --git a/drivers/video/backlight/lp8788_bl.c > b/drivers/video/backlight/lp8788_bl.c > index 31f97230ee50..f3a89677c31c 100644 > --- a/drivers/video/backlight/lp8788_bl.c > +++ b/drivers/video/backlight/lp8788_bl.c >

[PATCH] drm/sched: fix null-ptr-deref in init entity

From: Vitaly Prosyak The bug can be triggered by sending an amdgpu_cs_wait_ioctl to the AMDGPU DRM driver on any ASICs with valid context. The bug was reported by Joonkyo Jung . For example the following code: static void Syzkaller2(int fd) { union drm_amdgpu_ctx arg1;

[PATCH] drm/scheduler: fix null-ptr-deref in init entity

From: Vitaly Prosyak The bug can be triggered by sending an amdgpu_cs_wait_ioctl to the AMDGPU DRM driver on any ASICs with valid context. The bug was reported by Joonkyo Jung . For example the following code: static void Syzkaller2(int fd) { union drm_amdgpu_ctx arg1;

[PATCH] drm/panel: atna33xc20: Fix unbalanced regulator in the case HPD doesn't assert

From: Douglas Anderson When the atna33xc20 driver was first written the resume code never returned an error. If there was a problem waiting for HPD it just printed a warning and moved on. This changed in response to review feedback [1] on a future patch but I accidentally didn't account for

Re: [PATCH AUTOSEL 5.15 3/5] drm/amdgpu: Enable gpu reset for S3 abort cases on Raven series

On Wed, Mar 13, 2024 at 4:12 PM Felix Kuehling wrote: > > On 2024-03-11 11:14, Sasha Levin wrote: > > From: Prike Liang > > > > [ Upstream commit c671ec01311b4744b377f98b0b4c6d033fe569b3 ] > > > > Currently, GPU resets can now be performed successfully on the Raven > > series. While GPU reset is

Re: [PATCH 1/3] drm/msm/dp: Avoid a long timeout for AUX transfer if nothing connected

On 3/12/2024 5:13 PM, Douglas Anderson wrote: As documented in the description of the transfer() function of "struct drm_dp_aux", the transfer() function can be called at any time regardless of the state of the DP port. Specifically if the kernel has the DP AUX character device enabled and

Re: [PATCH 2/2] drm:amdgpu: add firmware information of all IP's

On Tue, Mar 12, 2024 at 8:42 AM Sunil Khatri wrote: > > Add firmware version information of each > IP and each instance where applicable. > Is there a way we can share some common code with devcoredump, debugfs, and the info IOCTL? All three places need to query this information and the same

Re: [PATCH 1/2] drm/amdgpu: add the IP information of the soc

On Tue, Mar 12, 2024 at 8:41 AM Sunil Khatri wrote: > > Add all the IP's information on a SOC to the > devcoredump. > > Signed-off-by: Sunil Khatri > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_reset.c | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git

[PATCH v6 3/3] drm/i915/gt: Enable only one CCS for compute workload

Enable only one CCS engine by default with all the compute sices allocated to it. While generating the list of UABI engines to be exposed to the user, exclude any additional CCS engines beyond the first instance. This change can be tested with igt i915_query. Fixes: d2eae8e98d59 ("drm/i915/dg2:

[PATCH v6 2/3] drm/i915/gt: Do not generate the command streamer for all the CCS

We want a fixed load CCS balancing consisting in all slices sharing one single user engine. For this reason do not create the intel_engine_cs structure with its dedicated command streamer for CCS slices beyond the first. Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement")

[PATCH v6 1/3] drm/i915/gt: Disable HW load balancing for CCS

The hardware should not dynamically balance the load between CCS engines. Wa_14019159160 recommends disabling it across all platforms. Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop force_probe requirement") Signed-off-by: Andi Shyti Cc: Chris Wilson Cc: Joonas Lahtinen Cc: Matt Roper Cc: # v6.2+

[PATCH v6 0/3] Disable automatic load CCS load balancing

Hi, this series does basically two things: 1. Disables automatic load balancing as adviced by the hardware workaround. 2. Assigns all the CCS slices to one single user engine. The user will then be able to query only one CCS engine >From v5 I have created a new file,

Re: [PATCH AUTOSEL 5.15 3/5] drm/amdgpu: Enable gpu reset for S3 abort cases on Raven series

On 2024-03-11 11:14, Sasha Levin wrote: From: Prike Liang [ Upstream commit c671ec01311b4744b377f98b0b4c6d033fe569b3 ] Currently, GPU resets can now be performed successfully on the Raven series. While GPU reset is required for the S3 suspend abort case. So now can enable gpu reset for S3

Re: [PATCH 1/2] drm/msm/dp: fix runtime PM leak on disconnect

On 3/13/2024 9:43 AM, Johan Hovold wrote: Make sure to put the runtime PM usage count (and suspend) also when receiving a disconnect event while in the ST_MAINLINK_READY state. This specifically avoids leaking a runtime PM usage count on every disconnect with display servers that do not

Re: [PATCH 2/2] drm:amdgpu: add firmware information of all IP's

[AMD Official Use Only - General] Gentle reminder Regards Sunil Get Outlook for Android From: Sunil Khatri Sent: Tuesday, March 12, 2024 6:11:48 PM To: Deucher, Alexander ; Koenig, Christian ; Sharma, Shashank Cc:

Re: [PATCH 1/2] drm/amdgpu: add the IP information of the soc

[AMD Official Use Only - General] Gentle reminder for review. Regards Sunil Get Outlook for Android From: Sunil Khatri Sent: Tuesday, March 12, 2024 6:11:47 PM To: Deucher, Alexander ; Koenig, Christian ; Sharma, Shashank Cc:

Re: [PATCH 1/2] drm/amdgpu: add the IP information of the soc

[AMD Official Use Only - General] Gentle Reminder for review. Regards, Sunil Get Outlook for Android From: Sunil Khatri Sent: Tuesday, March 12, 2024 6:11:47 PM To: Deucher, Alexander ; Koenig, Christian ; Sharma, Shashank Cc:

[PATCH] drm/i915/gt: Report full vm address range

Commit 9bb66c179f50 ("drm/i915: Reserve some kernel space per vm") has reserved an object for kernel space usage. Userspace, though, needs to know the full address range. Fixes: 9bb66c179f50 ("drm/i915: Reserve some kernel space per vm") Signed-off-by: Andi Shyti Cc: Andrzej Hajda Cc: Chris

Re: [PATCH v5 11/16] drm/vkms: Add YUV support

Hi, On 3/13/24 10:45, Louis Chauvet wrote: > From: Arthur Grillo > > > Signed-off-by: Arthur Grillo > [Louis Chauvet: > - Adapted Arthur's work > - Implemented the read_line_t callbacks for yuv > - add struct conversion_matrix > - remove struct pixel_yuv_u8 > - update the commit message > -

Re: [PATCH v5 05/16] drm/vkms: Add dummy pixel_read/pixel_write callbacks to avoid NULL pointers

On 3/13/24 10:44, Louis Chauvet wrote: > Introduce two callbacks which does nothing. They are used in replacement > of NULL and it avoid kernel OOPS if this NULL is called. > > If those callback are used, it means that there is a mismatch between > what formats are announced by atomic_check

Re: [PATCH v5 03/16] drm/vkms: write/update the documentation for pixel conversion and pixel write functions

Hi, On 3/13/24 10:44, Louis Chauvet wrote: > Add some documentation on pixel conversion functions. > Update of outdated comments for pixel_write functions. > > Signed-off-by: Louis Chauvet > --- > drivers/gpu/drm/vkms/vkms_composer.c | 7 > drivers/gpu/drm/vkms/vkms_drv.h | 13

Re: [PATCH 1/7] drm: Fix drm_fixp2int_round() making it add 0.5

On 12/03/24 15:27, Melissa Wen wrote: > On 03/06, Arthur Grillo wrote: >> As well noted by Pekka[1], the rounding of drm_fixp2int_round is wrong. >> To round a number, you need to add 0.5 to the number and floor that, >> drm_fixp2int_round() is adding 0.076. Make it add 0.5. >> >> [1]: >>

[PATCH v2] dt-bindings: display: samsung, exynos5-dp: convert to DT Schema

Convert Samsung Exynos5250/5420 SoC Display Port Controller bindings to DT schema with a change: add power-domains, already used in DTS. This Display Port controller is actually variant of Analogix Display Port bridge, however new DT Schema does not reference analogix,dp.yaml, because of

Re: [PATCH] dt-bindings: display: samsung,exynos5-dp: convert to DT Schema

On 13/03/2024 19:21, Krzysztof Kozlowski wrote: > Convert Samsung Exynos5250/5420 SoC Display Port Controller bindings to > DT schema with changes: > 1. Drop samsung,hpd-gpio, because it is not used by Linux driver. >Existing usage in DTS is going to be fixed. My bad, samsung,hpd-gpio is

[PATCH] dt-bindings: display: samsung, exynos5-dp: convert to DT Schema

Convert Samsung Exynos5250/5420 SoC Display Port Controller bindings to DT schema with changes: 1. Drop samsung,hpd-gpio, because it is not used by Linux driver. Existing usage in DTS is going to be fixed. 2. Add power-domains, already used in DTS. This Display Port controller is actually

Re: [PATCH v4 5/5] arm64: dts: allwinner: a64: Run GPU at 432 MHz

Dne nedelja, 10. marec 2024 ob 14:21:15 CET je Frank Oltmanns napisal(a): > The Allwinner A64's GPU has currently three operating points. However, > the BSP runs the GPU fixed at 432 MHz. In addition, at least one of the > devices using that SoC - the pinephone - shows unstabilities (see link) >

Re: [PATCH v4 2/5] clk: sunxi-ng: a64: Set minimum and maximum rate for PLL-MIPI

Dne nedelja, 10. marec 2024 ob 14:21:12 CET je Frank Oltmanns napisal(a): > When the Allwinner A64's TCON0 searches the ideal rate for the connected > panel, it may happen that it requests a rate from its parent PLL-MIPI > which PLL-MIPI does not support. > > This happens for example on the

Re: [PATCH v4 1/5] clk: sunxi-ng: common: Support minimum and maximum rate

Dne nedelja, 10. marec 2024 ob 14:21:11 CET je Frank Oltmanns napisal(a): > The Allwinner SoC's typically have an upper and lower limit for their > clocks' rates. Up until now, support for that has been implemented > separately for each clock type. > > Implement that functionality in the

Re: [PATCH 2/2] drm/msm/dp: fix runtime PM leak on connect failure

On 3/13/2024 9:43 AM, Johan Hovold wrote: Make sure to balance the runtime PM usage counter (and suspend) before returning on connect failures (e.g. DPCD read failures after a spurious connect event or if link training fails). Fixes: 5814b8bf086a ("drm/msm/dp: incorporate pm_runtime

Re: [PATCH] drm/sun4i: tcon: Support keeping dclk rate upon ancestor clock changes

Hi Frank! Thanks on tackling this issue. Dne nedelja, 10. marec 2024 ob 14:32:29 CET je Frank Oltmanns napisal(a): > Allow the dclk to reset its rate when a rate change is initiated from an > ancestor clock. This makes it possible to no longer to get an exclusive > lock. As a consequence, it is

Re: [PATCH 2/6] backlight/omap1-bl: Remove unused struct omap_backlight_config.set_power

On Wed, Mar 13, 2024 at 04:45:01PM +0100, Thomas Zimmermann wrote: > The callback set_power in struct omap_backlight_config is not > implemented anywhere. Remove it from the structure and driver. > > Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg > --- >

Re: [PATCH 1/6] auxdisplay/ht16k33: Replace use of fb_blank with backlight helper

On Wed, Mar 13, 2024 at 04:45:00PM +0100, Thomas Zimmermann wrote: > Replace the use of struct backlight_properties.fb_blank with a > call to backlight_get_brightness(). The helper implement the same > logic as the driver's function. > > Signed-off-by: Thomas Zimmermann > Cc: Robin van der

Re: [PATCH 3/6] backlight/omap1-bl: Replace FB_BLANK_ states with simple on/off

Hi Thomas, On Wed, Mar 13, 2024 at 04:45:02PM +0100, Thomas Zimmermann wrote: > The backlight is on for fb_blank eq FB_BLANK_UNBLANK, or off for > any other value in fb_blank. But the field fb_blank in struct > backlight_properties is deprecated and should not be used any > longer. > > Replace

Re: [PATCH] vmwgfx: Create debugfs ttm_resource_manager entry only if needed

On Tue, Mar 12, 2024 at 5:36 AM Jocelyn Falempe wrote: > > The driver creates /sys/kernel/debug/dri/0/mob_ttm even when the > corresponding ttm_resource_manager is not allocated. > This leads to a crash when trying to read from this file. > > Add a check to create mob_ttm, system_mob_ttm, and

Re: [PATCH 1/6] auxdisplay/ht16k33: Replace use of fb_blank with backlight helper

Hi Miguel. On Wed, Mar 13, 2024 at 05:08:08PM +0100, Miguel Ojeda wrote: > Hi Thomas, > > Thanks for this! > > Cc'ing Andy and Geert -- the new maintainer and reviewer. > > Also, a couple quick notes below since I am here... > > On Wed, Mar 13, 2024 at 4:49 PM Thomas Zimmermann wrote: > > >

[PATCH v5 09/16] drm/vkms: Introduce pixel_read_direction enum

The pixel_read_direction enum is useful to describe the reading direction in a plane. It avoids using the rotation property of DRM, which not practical to know the direction of reading. This patch also introduce two helpers, one to compute the pixel_read_direction from the DRM rotation property,

[PATCH v5 15/16] drm/vkms: Add how to run the Kunit tests

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

[PATCH v5 16/16] drm/vkms: Add support for DRM_FORMAT_R*

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/ Signed-off-by: Louis Chauvet

[PATCH v5 14/16] drm/vkms: Create KUnit tests for YUV conversions

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. Signed-off-by: Arthur Grillo [Louis Chauvet: - fix minor formating

[PATCH v5 13/16] drm/vkms: Drop YUV formats TODO

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

[PATCH v5 07/16] drm/vkms: Update pixels accessor to support packed and multi-plane formats.

Introduce the usage of block_h/block_w to compute the offset and the pointer of a pixel. The previous implementation was specialized for planes with block_h == block_w == 1. To avoid confusion and allow easier implementation of tiled formats. It also remove the usage of the deprecated format field

[PATCH v5 10/16] drm/vkms: Re-introduce line-per-line composition algorithm

Re-introduce a line-by-line composition algorithm for each pixel format. This allows more performance by not requiring an indirection per pixel read. This patch is focused on readability of the code. Line-by-line composition was introduced by [1] but rewritten back to pixel-by-pixel algorithm in

[PATCH v5 12/16] drm/vkms: Add range and encoding properties to the plane

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] Signed-off-by: Louis Chauvet ---

[PATCH v5 11/16] drm/vkms: Add YUV support

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 floats and the drm_fixed helpers. To do the conversion, a specific matrix

[PATCH v5 08/16] drm/vkms: Avoid computing blending limits inside pre_mul_alpha_blend

The pre_mul_alpha_blend is dedicated to blending, so to avoid mixing different concepts (coordinate calculation and color management), extract the x_limit and x_dst computation outside of this helper. It also increases the maintainability by grouping the computation related to coordinates in the

[PATCH v5 03/16] drm/vkms: write/update the documentation for pixel conversion and pixel write functions

Add some documentation on pixel conversion functions. Update of outdated comments for pixel_write functions. Signed-off-by: Louis Chauvet --- drivers/gpu/drm/vkms/vkms_composer.c | 7 drivers/gpu/drm/vkms/vkms_drv.h | 13 drivers/gpu/drm/vkms/vkms_formats.c | 62

[PATCH v5 04/16] drm/vkms: Add typedef and documentation for pixel_read and pixel_write functions

Introduce two typedefs: pixel_read_t and pixel_write_t. It allows the compiler to check if the passed functions take the correct arguments. Such typedefs will help ensuring consistency across the code base in case of update of these prototypes. Rename input/output variable in a consistent way

[PATCH v5 06/16] drm/vkms: Use const for input pointers in pixel_read an pixel_write functions

As the pixel_read and pixel_write function should never modify the input buffer, mark those pointers const. Signed-off-by: Louis Chauvet --- drivers/gpu/drm/vkms/vkms_drv.h | 4 ++-- drivers/gpu/drm/vkms/vkms_formats.c | 24 2 files changed, 14 insertions(+), 14

[PATCH v5 00/16] drm/vkms: Reimplement line-per-line pixel conversion for plane reading

l.org/all/20240110-vkms-yuv-v2-7-952fcaa5a...@riseup.net/ [8]: https://lore.kernel.org/r/20240313-new_rotation-v2-0-6230fd5ca...@bootlin.com [9]: https://lore.kernel.org/dri-devel/20240306-louis-vkms-conv-v1-1-5bfe7d129...@riseup.net/ To: Rodrigo Siqueira To: Melissa Wen To: Maíra Canal T

[PATCH v5 05/16] drm/vkms: Add dummy pixel_read/pixel_write callbacks to avoid NULL pointers

Introduce two callbacks which does nothing. They are used in replacement of NULL and it avoid kernel OOPS if this NULL is called. If those callback are used, it means that there is a mismatch between what formats are announced by atomic_check and what is realy supported by atomic_update.

[PATCH v5 02/16] drm/vkms: Use drm_frame directly

From: Arthur Grillo Remove intermidiary variables and access the variables directly from drm_frame. These changes should be noop. Signed-off-by: Arthur Grillo Signed-off-by: Louis Chauvet --- drivers/gpu/drm/vkms/vkms_drv.h | 3 --- drivers/gpu/drm/vkms/vkms_formats.c | 12

[PATCH v5 01/16] drm/vkms: Code formatting

Few no-op changes to remove double spaces and fix wrong alignments. Signed-off-by: Louis Chauvet --- drivers/gpu/drm/vkms/vkms_composer.c | 10 +- drivers/gpu/drm/vkms/vkms_crtc.c | 6 ++ drivers/gpu/drm/vkms/vkms_drv.c | 3 +-- drivers/gpu/drm/vkms/vkms_plane.c| 8

Re: [PATCH 1/6] auxdisplay/ht16k33: Replace use of fb_blank with backlight helper

On Wed, Mar 13, 2024 at 6:11 PM Dan Carpenter wrote: > > Is there an advantage to making this const? Not much in this case -- it is more about trying to be const-correct where possible. Cheers, Miguel

Re: [PATCH v3 0/3] panel-simple: add support for Crystal Clear CMT430B19N00

From: Neil Armstrong Hi, On Wed, 13 Mar 2024 18:20:13 +0100, Jérémie Dautheribes wrote: > This patch series add support for the Crystal Clear Technology > CMT430B19N00 4.3" 480x272 TFT-LCD panel. > It also adds Crystal Clear Technology to vendor-prefixes.yaml. > > Please note that

Re: [PATCH 0/6] backlight: Remove struct backlight_properties.fb_blank

I was only going to comment on the staging bits but, heck, I reviewed the whole series. Reviewed-by: Dan Carpenter regards, dan carpenter

Re: [PATCH 1/6] auxdisplay/ht16k33: Replace use of fb_blank with backlight helper

On Wed, Mar 13, 2024 at 04:45:00PM +0100, Thomas Zimmermann wrote: > Replace the use of struct backlight_properties.fb_blank with a > call to backlight_get_brightness(). The helper implement the same > logic as the driver's function. If you end up resending there is a typo

Re: [PATCH 5/6] staging/fbtft: Remove reference to fb_blank

On Wed, Mar 13, 2024 at 04:45:04PM +0100, Thomas Zimmermann wrote: > The field fb_blank in struct backlight_properties is deprecated and > should not be used. Don't output its value in the driver's debug print. > > Signed-off-by: Thomas Zimmermann > --- > drivers/staging/fbtft/fb_ssd1351.c | 4

Re: [PATCH v3 3/3] drm/panel: simple: add CMT430B19N00 LCD panel support

On 13/03/2024 18:20, Jérémie Dautheribes wrote: Add support for Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel. Suggested-by: Maxime Ripard Signed-off-by: Jérémie Dautheribes --- drivers/gpu/drm/panel/panel-simple.c | 29 1 file changed, 29

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

On Wed, Mar 13, 2024 at 06:11:50PM +0100, Alexandre Mergnat wrote: > On 26/02/2024 17:09, Mark Brown wrote: > > > index ..13e95c227114 > > > --- /dev/null > > > +++ b/sound/soc/codecs/mt6357.c > > > @@ -0,0 +1,1805 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + *

Re: [PATCH] drm/msm/dp: move link_ready out of HPD event thread

On 3/13/2024 1:18 AM, Johan Hovold wrote: On Tue, Mar 12, 2024 at 10:39:46AM -0700, Abhinav Kumar wrote: On 3/12/2024 9:59 AM, Johan Hovold wrote: Heh. This is getting ridiculous. I just tried running with this patch and it again breaks hotplug detect in a VT console and in X (where I

Re: [PATCH 12/18] ASoC: codecs: mt6357: add MT6357 codec

On Tue, Mar 12, 2024 at 07:03:25PM +0100, Alexandre Mergnat wrote: > On 26/02/2024 17:09, Mark Brown wrote: > > > + case MT6357_ZCD_CON2: > > > + regmap_read(priv->regmap, MT6357_ZCD_CON2, ); > > > + priv->ana_gain[ANALOG_VOLUME_HPOUTL] = > > > + (reg &

Re: [PATCH] drm/amdgpu: fix deadlock while reading mqd from debugfs

Hello Johannes, On 07/03/2024 23:07, Johannes Weiner wrote: An errant disk backup on my desktop got into debugfs and triggered the following deadlock scenario in the amdgpu debugfs files. The machine also hard-resets immediately after those lines are printed (although I wasn't able to reproduce

[PATCH v3 3/3] drm/panel: simple: add CMT430B19N00 LCD panel support

Add support for Crystal Clear Technology CMT430B19N00 4.3" 480x272 TFT-LCD panel. Suggested-by: Maxime Ripard Signed-off-by: Jérémie Dautheribes --- drivers/gpu/drm/panel/panel-simple.c | 29 1 file changed, 29 insertions(+) diff --git

  1   2   >