On 3/28/2024 8:23 PM, Dmitry Baryshkov wrote:
On Fri, 29 Mar 2024 at 04:16, Abhinav Kumar wrote:
On 3/28/2024 5:10 PM, Dmitry Baryshkov wrote:
On Fri, 29 Mar 2024 at 01:42, Abhinav Kumar wrote:
On 3/28/2024 3:50 PM, Dmitry Baryshkov wrote:
On Thu, 28 Mar 2024 at 23:21, Abhinav
Hi David,
>
> On 25.02.24 08:56, Vivek Kasireddy wrote:
> > Currently, some drivers (e.g, Udmabuf) that want to longterm-pin
> > the pages/folios associated with a memfd, do so by simply taking a
> > reference on them. This is not desirable because the pages/folios
> > may reside in Movable zone
On Fri, 29 Mar 2024 at 06:02, Bjorn Andersson wrote:
>
> Now that the connector_type is dynamically determined, the
> connector_type of the struct msm_dp_desc is unused. Clean it up.
>
> Signed-off-by: Bjorn Andersson
> ---
> This cleans up after, and hence depends on,
>
On Wed, Mar 20, 2024 at 10:48:50PM +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> A better alternative is strscpy() as it guarantees NUL-termination on
>
On Wed, Mar 20, 2024 at 11:04:44PM +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> We expect v86d_path to be NUL-terminated based on its use with the
>
On Wed, Mar 20, 2024 at 11:22:02PM +, Justin Stitt wrote:
> strncpy() is deprecated for use on NUL-terminated destination strings
> [1] and as such we should prefer more robust and less ambiguous string
> interfaces.
>
> It looks like the main use of strncpy() here is to limit the amount of
>
: 8780048e8c13990129e67c097ef580c3ae456650
change-id: 20240328-dp-connector-type-cleanup-af6501e374b3
Best regards,
--
Bjorn Andersson
On Fri, 29 Mar 2024 at 04:47, Jun Nie wrote:
>
> Dmitry Baryshkov 于2024年3月28日周四 23:05写道：
> >
> > On Thu, 28 Mar 2024 at 13:12, Jun Nie wrote:
> > >
> > > Fix DSC timing and control configurations in DPU for DSI video mode.
> > > Only compression ratio 3:1 is handled and tested.
> > >
> > > This
On Fri, 29 Mar 2024 at 04:16, Abhinav Kumar wrote:
>
>
>
> On 3/28/2024 5:10 PM, Dmitry Baryshkov wrote:
> > On Fri, 29 Mar 2024 at 01:42, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 3/28/2024 3:50 PM, Dmitry Baryshkov wrote:
> >>> On Thu, 28 Mar 2024 at 23:21, Abhinav Kumar
> >>> wrote:
Dmitry Baryshkov 于2024年3月28日周四 23:05写道：
>
> On Thu, 28 Mar 2024 at 13:12, Jun Nie wrote:
> >
> > Fix DSC timing and control configurations in DPU for DSI video mode.
> > Only compression ratio 3:1 is handled and tested.
> >
> > This patch is modified from patchs of Jonathan Marek.
> >
> >
On 3/28/2024 6:46 PM, Bjorn Andersson wrote:
On Thu, Mar 28, 2024 at 02:21:14PM -0700, Abhinav Kumar wrote:
On 3/28/2024 1:58 PM, Stephen Boyd wrote:
Quoting Abhinav Kumar (2024-03-28 13:24:34)
+ Johan and Bjorn for FYI
On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
For internal HPD case,
On 3/28/2024 5:10 PM, Dmitry Baryshkov wrote:
On Fri, 29 Mar 2024 at 01:42, Abhinav Kumar wrote:
On 3/28/2024 3:50 PM, Dmitry Baryshkov wrote:
On Thu, 28 Mar 2024 at 23:21, Abhinav Kumar wrote:
On 3/28/2024 1:58 PM, Stephen Boyd wrote:
Quoting Abhinav Kumar (2024-03-28 13:24:34)
On Thu, Mar 28, 2024 at 02:21:14PM -0700, Abhinav Kumar wrote:
>
>
> On 3/28/2024 1:58 PM, Stephen Boyd wrote:
> > Quoting Abhinav Kumar (2024-03-28 13:24:34)
> > > + Johan and Bjorn for FYI
> > >
> > > On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
> > > > For internal HPD case, hpd_event_thread is
Hi Dave and Sima,
Here goes our first PR of this round.
Our CI is not working as I would expect:
https://intel-gfx-ci.01.org/tree/drm-intel-fixes/index.html?
Well, at least it caught some build failures on runds 832 and 833.
But after I fixed those, the 834 (with v6.9-rc1) and the 835 (with
all
On Thu, Mar 28, 2024 at 3:31 PM Ian Forbes wrote:
>
> These pointers are frequently the same and memcmp does not compare the
> pointers
> before comparing their contents so this was wasting cycles comparing 16 KiB of
> memory which will always be equal.
>
> Fixes: bb6780aa5a1d9 ("drm/vmwgfx:
Hi Krzysztof,
Thank you for the feedback.
> -Original Message-
> From: Krzysztof Kozlowski
> Sent: Saturday, March 23, 2024 3:21 AM
> To: Klymenko, Anatoliy ; Laurent Pinchart
> ; Maarten Lankhorst
> ; Maxime Ripard
> ; Thomas Zimmermann ;
> David Airlie ; Daniel Vetter ; Simek,
>
Quoting Kuogee Hsieh (2024-03-28 14:07:15)
> diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> index 36632fa..884973a 100644
> --- a/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> +++ b/drivers/phy/qualcomm/phy-qcom-qmp-combo.c
> @@ -2754,6
On Fri, 29 Mar 2024 at 01:42, Abhinav Kumar wrote:
>
>
>
> On 3/28/2024 3:50 PM, Dmitry Baryshkov wrote:
> > On Thu, 28 Mar 2024 at 23:21, Abhinav Kumar
> > wrote:
> >>
> >>
> >>
> >> On 3/28/2024 1:58 PM, Stephen Boyd wrote:
> >>> Quoting Abhinav Kumar (2024-03-28 13:24:34)
> + Johan and
On Thu, Mar 28, 2024 at 7:53 AM Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin
>
> There is no point in compiling in the list and mutex operations which are
> only used from the dma-buf debugfs code, if debugfs is not compiled in.
>
> Put the code in questions behind some kconfig guards and so
Hi Benjamin,
Am 27.03.24 um 12:03 schrieb Benjamin Tissoires:
On Mar 26 2024, Werner Sembach wrote:
Hi all,
Am 26.03.24 um 16:39 schrieb Benjamin Tissoires:
On Mar 26 2024, Werner Sembach wrote:
Hi all,
Am 25.03.24 um 19:30 schrieb Hans de Goede:
[snip]
If the kernel already handles the
On 3/28/2024 3:50 PM, Dmitry Baryshkov wrote:
On Thu, 28 Mar 2024 at 23:21, Abhinav Kumar wrote:
On 3/28/2024 1:58 PM, Stephen Boyd wrote:
Quoting Abhinav Kumar (2024-03-28 13:24:34)
+ Johan and Bjorn for FYI
On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
For internal HPD case,
On Thu, 28 Mar 2024 at 23:21, Abhinav Kumar wrote:
>
>
>
> On 3/28/2024 1:58 PM, Stephen Boyd wrote:
> > Quoting Abhinav Kumar (2024-03-28 13:24:34)
> >> + Johan and Bjorn for FYI
> >>
> >> On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
> >>> For internal HPD case, hpd_event_thread is created to
On Thu, 28 Mar 2024 at 23:36, Abhinav Kumar wrote:
>
>
>
> On 3/28/2024 2:07 PM, Kuogee Hsieh wrote:
> > Currently qmp_combo_dp_power_on() always return 0 in regardless of
> > return value of cfg->configure_dp_phy(). This patch propagate
> > return value of cfg->configure_dp_phy() all the way
e(ptdev, csg_id);
> csg_slot = >csg_slots[csg_id];
> - csg_mod_mask |= BIT(csg_id);
> group_bind_locked(group, csg_id);
> csg_slot_prog_locked(ptdev, csg_id, new_csg_prio--);
> csgs_upd_ctx_queue_reqs(
On 3/28/2024 2:07 PM, Kuogee Hsieh wrote:
Currently qmp_combo_dp_power_on() always return 0 in regardless of
return value of cfg->configure_dp_phy(). This patch propagate
return value of cfg->configure_dp_phy() all the way back to caller.
This is good. But I am also thinking if we should
On 3/28/2024 1:58 PM, Stephen Boyd wrote:
Quoting Abhinav Kumar (2024-03-28 13:24:34)
+ Johan and Bjorn for FYI
On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
For internal HPD case, hpd_event_thread is created to handle HPD
interrupts generated by HPD block of DP controller. It converts
HPD
Currently qmp_combo_dp_power_on() always return 0 in regardless of
return value of cfg->configure_dp_phy(). This patch propagate
return value of cfg->configure_dp_phy() all the way back to caller.
Signed-off-by: Kuogee Hsieh
---
drivers/phy/qualcomm/phy-qcom-qmp-combo.c | 5 +++--
1 file
Quoting Abhinav Kumar (2024-03-28 13:24:34)
> + Johan and Bjorn for FYI
>
> On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
> > For internal HPD case, hpd_event_thread is created to handle HPD
> > interrupts generated by HPD block of DP controller. It converts
> > HPD interrupts into events and executed
On Thu, Mar 28, 2024 at 10:42:45AM +0100, Luca Weiss wrote:
> Document the displayport controller subnode of the SM6350 MDSS.
>
> Signed-off-by: Luca Weiss
> ---
> .../devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml | 10
> ++
> 1 file changed, 10 insertions(+)
>
> diff
On Thu, 28 Mar 2024 10:42:44 +0100, Luca Weiss wrote:
> Add the compatible string for the DisplayPort controller on SM6350 which
> is compatible with the one on SM8350.
>
> Signed-off-by: Luca Weiss
> ---
> Documentation/devicetree/bindings/display/msm/dp-controller.yaml | 1 +
> 1 file
On 2024-03-28 12:03, Tvrtko Ursulin wrote:
Hi Felix,
I had one more thought while browsing around the amdgpu CRIU plugin.
It appears it relies on the KFD support being compiled in and /dev/kfd
present, correct? AFAICT at least, it relies on that to figure out the
amdgpu DRM node.
In
On 24-03-28 13:04:05, Kuogee Hsieh wrote:
> At current x1e80100 interface table, interface #3 is wrongly
> connected to DP controller #0 and interface #4 wrongly connected
> to DP controller #2. Fix this problem by connect Interface #3 to
> DP controller #0 and interface #4 connect to DP
On Thu, Mar 28, 2024 at 11:55:23AM -0700, Mina Almasry wrote:
> On Thu, Mar 28, 2024 at 11:28 AM Simon Horman wrote:
> >
> > On Tue, Mar 26, 2024 at 03:50:35PM -0700, Mina Almasry wrote:
> > > Add a netdev_dmabuf_binding struct which represents the
> > > dma-buf-to-netdevice binding. The netlink
+ Johan and Bjorn for FYI
On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
For internal HPD case, hpd_event_thread is created to handle HPD
interrupts generated by HPD block of DP controller. It converts
HPD interrupts into events and executed them under hpd_event_thread
context. For external HPD
On 3/28/2024 1:04 PM, Kuogee Hsieh wrote:
At current x1e80100 interface table, interface #3 is wrongly
connected to DP controller #0 and interface #4 wrongly connected
to DP controller #2. Fix this problem by connect Interface #3 to
DP controller #0 and interface #4 connect to DP controller
For internal HPD case, hpd_event_thread is created to handle HPD
interrupts generated by HPD block of DP controller. It converts
HPD interrupts into events and executed them under hpd_event_thread
context. For external HPD case, HPD events is delivered by way of
dp_bridge_hpd_notify() under thread
At current x1e80100 interface table, interface #3 is wrongly
connected to DP controller #0 and interface #4 wrongly connected
to DP controller #2. Fix this problem by connect Interface #3 to
DP controller #0 and interface #4 connect to DP controller #1.
Also add interface #6, #7 and #8 connections
These pointers are frequently the same and memcmp does not compare the pointers
before comparing their contents so this was wasting cycles comparing 16 KiB of
memory which will always be equal.
Fixes: bb6780aa5a1d9 ("drm/vmwgfx: Diff cursors when using cmds")
Signed-off-by: Ian Forbes
---
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[Why]
DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to the
other (output encoder).
Each DCN pipe has the ability to blend in a cursor early on
> -Original Message-
> From: Julien Panis
> Sent: Thursday, March 28, 2024 2:57 PM
> To: David S. Miller ; Eric Dumazet
> ; Jakub Kicinski ; Paolo Abeni
> ; Russell King ; Alexei Starovoitov
> ; Daniel Borkmann ; Jesper Dangaard
> Brouer ; John Fastabend ;
> Sumit Semwal ; Christian
On 2024-03-28 at 14:56:42, Julien Panis (jpa...@baylibre.com) wrote:
> This patch adds XDP (eXpress Data Path) support to TI AM65 CPSW
> Ethernet driver. The following features are implemented:
> - NETDEV_XDP_ACT_BASIC (XDP_PASS, XDP_TX, XDP_DROP, XDP_ABORTED)
> - NETDEV_XDP_ACT_REDIRECT
Hi,
I just took a quick look and commented on the things that stuck
out to me. Some general things:
- several `unsafe` blocks have missing SAFETY comments,
- missing documentation and examples.
On 22.03.24 23:03, Lyude Paul wrote:
> Signed-off-by: Lyude Paul
> ---
>
On Tue, Mar 19, 2024 at 01:53:04PM +0530, Akhil R wrote:
>
> +struct tegra_sha_reqctx {
> + struct ahash_request fallback_req;
This doesn't work because ahash_request is dynamically sized.
So you'll end up clobbering the rest of the struct if a fallback
ends up being used.
You should place
On Tue, Mar 19, 2024 at 01:53:04PM +0530, Akhil R wrote:
>
> + .alg.skcipher.op.do_one_request = tegra_aes_do_one_req,
> + .alg.skcipher.base = {
> + .init = tegra_aes_cra_init,
> + .exit = tegra_aes_cra_exit,
> +
On 22.03.24 23:03, Lyude Paul wrote:
> diff --git a/drivers/gpu/drm/rvkms/connector.rs
> b/drivers/gpu/drm/rvkms/connector.rs
> new file mode 100644
> index 0..40f84d38437ee
> --- /dev/null
> +++ b/drivers/gpu/drm/rvkms/connector.rs
> @@ -0,0 +1,55 @@
> +// TODO: License and stuff
>
On Thu, Mar 28, 2024 at 11:54 AM Simon Ser wrote:
>
> On Thursday, March 28th, 2024 at 19:47, Rob Clark wrote:
>
> > any chance I could talk you into pushing to drm-misc-fixes?
>
> Oh sorry, I thought you had access… Pushed with a minor edit to remove
> unnecessary parentheses to make checkpatch
On Thu, Mar 28, 2024 at 11:28 AM Simon Horman wrote:
>
> On Tue, Mar 26, 2024 at 03:50:35PM -0700, Mina Almasry wrote:
> > Add a netdev_dmabuf_binding struct which represents the
> > dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> > rx queues on the netdevice. On the
On Thursday, March 28th, 2024 at 19:47, Rob Clark wrote:
> any chance I could talk you into pushing to drm-misc-fixes?
Oh sorry, I thought you had access… Pushed with a minor edit to remove
unnecessary parentheses to make checkpatch happy!
On Tue, Mar 26, 2024 at 2:15 AM Simon Ser wrote:
>
> Makes sense to me!
>
> Reviewed-by: Simon Ser
Thanks.. any chance I could talk you into pushing to drm-misc-fixes?
BR,
-R
On Tue, Mar 26, 2024 at 03:50:35PM -0700, Mina Almasry wrote:
> Add a netdev_dmabuf_binding struct which represents the
> dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
> rx queues on the netdevice. On the binding, the dma_buf_attach
> & dma_buf_map_attachment will occur.
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: a6bd6c997f5a0e2667d4d82fef8c970108f2 Add linux-next specific
files for 20240328
Error/Warning: (recently discovered and may have been fixed)
ERROR: modpost: "memcpy&quo
On Fri, Mar 01, 2024 at 12:29:58PM +0100, Philipp Stanner wrote:
> When the PCI devres API was introduced to this driver, it was wrongly
> assumed that initializing the device with pcim_enable_device() instead
> of pci_enable_device() will make all PCI functions managed.
>
> This is wrong and was
On Thu, Mar 28, 2024 at 11:27:35AM +0100, Marek Vasut wrote:
> Document support for Innolux CheMei 12" G121XCE-L01 XGA LVDS display.
>
> G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of
> a TFT LCD panel, a driver circuit, and LED backlight system. The screen
> format is
On 28 Mar 17:49, Greg Kroah-Hartman wrote:
> On Thu, Mar 28, 2024 at 09:46:01AM -0300, Ricardo B. Marliere wrote:
> > On 28 Mar 13:01, Greg Kroah-Hartman wrote:
> > > On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote:
> > > > On Tue, 05 Mar 2024, Ricardo B. Marliere wrote:
> > > >
> > > >
On 3/28/24 03:43, Dave Airlie wrote:
From: Dave Airlie
dEQP-VK.sparse_resources.image_rebind.2d_array.r64i.128_128_8
was causing a remap operation like the below.
op_remap: prev: 003fffed 000f a5abd18a
op_remap: next:
op_remap: unmap:
On 3/15/24 10:09, Colin Ian King wrote:
There is a statement with two semicolons. Remove the second one, it
is redundant.
Signed-off-by: Colin Ian King
Applied, thanks!
---
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Thu, Mar 28, 2024 at 09:46:01AM -0300, Ricardo B. Marliere wrote:
> On 28 Mar 13:01, Greg Kroah-Hartman wrote:
> > On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote:
> > > On Tue, 05 Mar 2024, Ricardo B. Marliere wrote:
> > >
> > > > This is a simple and straight forward cleanup series
On 28/03/2024 16:07, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
On 3/26/2024 11:39 PM, Matthew Auld wrote:
On 18/03/2024 21:40, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in
On 22/03/2024 16:45, Christian Hewitt wrote:
> Increase the timeout value to prevent system logs on Amlogic boards flooding
> with power transition warnings:
>
> [ 13.047638] panfrost ffe4.gpu: shader power transition timeout
> [ 13.048674] panfrost ffe4.gpu: l2 power transition
gt;csg_slots[csg_id];
> - csg_mod_mask |= BIT(csg_id);
> group_bind_locked(group, csg_id);
> csg_slot_prog_locked(ptdev, csg_id, new_csg_prio--);
> csgs_upd_ctx_queue_reqs(ptdev, _ctx, csg_id,
>
> ---
> base-commit: d180649238f04183950d9c8a7d8a2c2f1788a89c
> change-id: 20240328-panthor-drop-csg_mod_mask-b4bbe317d690
>
> Best regards,
In the case where `conn_routes` is true we allocate an extra slot in
the `ddp_comp` array but mtk_drm_crtc_create() never seemed to
initialize it in the test case I ran. For me, this caused a later
crash when we looped through the array in mtk_drm_crtc_mode_valid().
This showed up for me when I
---
base-commit: d180649238f04183950d9c8a7d8a2c2f1788a89c
change-id: 20240328-panthor-drop-csg_mod_mask-b4bbe317d690
Best regards,
--
Nathan Chancellor
Hi Matthew,
On 3/26/2024 11:39 PM, Matthew Auld wrote:
On 18/03/2024 21:40, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each
Hi Felix,
I had one more thought while browsing around the amdgpu CRIU plugin. It
appears it relies on the KFD support being compiled in and /dev/kfd
present, correct? AFAICT at least, it relies on that to figure out the
amdgpu DRM node.
In would be probably good to consider designing
On 2024-03-28 11:48, Robert Mader wrote:
Hi,
On 15.03.24 18:09, sunpeng...@amd.com wrote:
From: Leo Li
[Why]
DCN is the display hardware for amdgpu. DRM planes are backed by DCN
hardware pipes, which carry pixel data from one end (memory), to the
other (output encoder).
Each DCN pipe
Hi Nathan,
On Thu, 28 Mar 2024 08:38:09 -0700
Nathan Chancellor wrote:
> Hi Boris,
>
> On Thu, Feb 29, 2024 at 05:22:24PM +0100, Boris Brezillon wrote:
>
> > ---
> > drivers/gpu/drm/panthor/panthor_sched.c | 3502 +++
> > drivers/gpu/drm/panthor/panthor_sched.h | 50 +
>
Hi Adrián,
Appologies for the delay in reviewing this.
On Tue, Mar 05, 2024 at 09:05:49PM +, Adrián Larumbe wrote:
> These values are sampled by the firmware right before jumping into the UM
> command stream and immediately after returning from it, and then kept inside a
> per-job accounting
On Wed, Mar 27, 2024 at 01:41:12PM +0100, Krzysztof Kozlowski wrote:
> virtio core already sets the .owner, so driver does not need to.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Depends on the first patch.
> ---
> drivers/rpmsg/virtio_rpmsg_bus.c | 1 -
> 1 file changed, 1
Hi Boris,
On Thu, Feb 29, 2024 at 05:22:24PM +0100, Boris Brezillon wrote:
> ---
> drivers/gpu/drm/panthor/panthor_sched.c | 3502 +++
> drivers/gpu/drm/panthor/panthor_sched.h | 50 +
> 2 files changed, 3552 insertions(+)
> create mode 100644
On Fri, 15 Mar 2024 13:09:58 -0400
wrote:
> From: Leo Li
>
> [Why]
>
> Compositors have different ways of assigning surfaces to DRM planes for
> render offloading. It may decide between various strategies: overlay,
> underlay, or a mix of both
>
> One way for compositors to implement the
On Fri, 15 Mar 2024 13:09:57 -0400
wrote:
> From: Leo Li
>
> [Why]
>
> DCN is the display hardware for amdgpu. DRM planes are backed by DCN
> hardware pipes, which carry pixel data from one end (memory), to the
> other (output encoder).
>
> Each DCN pipe has the ability to blend in a cursor
On Thu, 28 Mar 2024 at 11:43, Luca Weiss wrote:
>
> Add the node for the DisplayPort controller found on the SM6350 SoC.
>
> Signed-off-by: Luca Weiss
> ---
> arch/arm64/boot/dts/qcom/sm6350.dtsi | 88
>
> 1 file changed, 88 insertions(+)
>
Reviewed-by:
On Thu, 28 Mar 2024 at 13:12, Jun Nie wrote:
>
> Enable display compression (DSC v1.2) for 1080x2400 Visionox
> VTDR6130 AMOLED DSI panel. DTS property is needed to enable DSC.
> Default configuration is video mode + non-DSC for any back
> compatibility.
The changelog talks about the DSC only,
On Thu, 28 Mar 2024 at 13:12, Jun Nie wrote:
>
> Add DSI mode property and compression mode property
>
> Signed-off-by: Jun Nie
> ---
> .../bindings/display/panel/visionox,vtdr6130.yaml | 8
> 1 file changed, 8 insertions(+)
>
> diff --git
>
On Thu, 28 Mar 2024 at 13:12, Jun Nie wrote:
>
> Fix DSC timing and control configurations in DPU for DSI video mode.
> Only compression ratio 3:1 is handled and tested.
>
> This patch is modified from patchs of Jonathan Marek.
>
> Signed-off-by: Jun Nie
This almost looks like a joke, except it
On 3/28/24 14:33, Thomas Zimmermann wrote:
Am 28.03.24 um 12:04 schrieb Helge Deller:
On 3/27/24 21:41, Thomas Zimmermann wrote:
The per-architecture video helpers do not depend on struct fb_info
or anything else from fbdev. Remove it from the interface and replace
fb_is_primary_device() with
On Thu, 28 Mar 2024 at 16:35, Bjorn Andersson wrote:
>
> From: Bjorn Andersson
>
> The members of struct dp_debug are no longer used, so the only purpose
> of this struct is as a type of the return value of dp_debug_get(), to
> signal success/error.
>
> Drop the struct in favor of signalling the
On 3/12/24 18:45, Thomas Zimmermann wrote:
> Implement fbdev emulation with fbdev-shmem. Avoids the overhead of
> fbdev-generic's additional shadow buffering. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> Cc: David Airlie
> Cc: Gerd Hoffmann
> Cc: Gurchetan Singh
> Cc: Chia-I
From: Tvrtko Ursulin
There is no point in compiling in the list and mutex operations which are
only used from the dma-buf debugfs code, if debugfs is not compiled in.
Put the code in questions behind some kconfig guards and so save some text
and maybe even a pointer per object at runtime when
From: Bjorn Andersson
Throughout the Qualcomm Displayport driver a number of defines and
struct members has become unused, but lingers in the code. Remove these.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_audio.c | 5 -
From: Bjorn Andersson
The "desc" member of struct dp_panel is zero-initialized during
allocation and never assigned, resulting in dp_ctrl_use_fixed_nvid()
never returning true. This returned boolean value is passed around but
never acted upon.
Perform constant propagation and remove the traces
From: Bjorn Andersson
The dp_audio read and write operations uses members in struct dp_catalog
for passing arguments and return values. This adds unnecessary
complexity to the implementation, as it turns out after detangling the
logic that no state is actually held in these variables.
Clean
From: Bjorn Andersson
The dp_aux write operations takes the data to be operated on through a
member of struct dp_catalog, rather than as an argument to the function.
No state is maintained other than across the calling of the functions,
so replace this member with a function argument.
From: Bjorn Andersson
dp_catalog_panel_timing_cfg() takes 4 arguments, which are passed from
the calling function through members of struct dp_catalog.
No state is maintained other than across this call, so switch to
function arguments to clean up the code.
Reviewed-by: Dmitry Baryshkov
From: Bjorn Andersson
The members of struct dp_debug are no longer used, so the only purpose
of this struct is as a type of the return value of dp_debug_get(), to
signal success/error.
Drop the struct in favor of signalling the result of initialization
using an int, then merge dp_debug_get()
Spring is in the air, clean out some dust that has accumulated in the
Qualcomm DP driver.
Signed-off-by: Bjorn Andersson
---
Changes in v2:
- Merge dp_debug_get() and dp_debug_init()
- Link to v1:
https://lore.kernel.org/r/20240326-msm-dp-cleanup-v1-0-e775556ec...@quicinc.com
---
Bjorn
On Fri, 15 Mar 2024 13:09:56 -0400
wrote:
> From: Leo Li
>
> These patches aim to make the amdgpgu KMS driver play nicer with compositors
> when building multi-plane scanout configurations. They do so by:
>
> 1. Making cursor behavior more sensible.
> 2. Allowing placement of DRM OVERLAY
On Thu, Mar 28, 2024 at 11:18 AM Maxime Ripard wrote:
>
> "a while ago" here being 2 hours before your message :)
Ah, I meant the original reports that Nathan mentioned in his message.
Yeah, the message itself from Nathan happened right before :)
> I've added a Closes tag for that report too.
>
On Wed, 13 Mar 2024 18:45:10 +0100
Louis Chauvet wrote:
> 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]:
>
The pointer file->driver_priv was dereferenced without checking
against NULL, but in the "virtio_gpu_transfer_to_host_ioctl" function
it was checked against NULL after calling virtio_gpu_create_context
function.
Found by Security Code and Linux Verification Center(linuxtesting.org)
Fixes:
Hi Dave, Sima,
this is the weekly PR for drm-misc-fixes.
Best regards
Thomas
drm-misc-fixes-2024-03-28:
Short summary of fixes pull:
bridge:
- select DRM_KMS_HELPER
dma-buf:
- fix NULL-pointer deref
dp:
- fix div-by-zero in DP MST unplug code
fbdev:
- select FB_IOMEM_FOPS for SBus
nouveau:
On Wed, Mar 20, 2024 at 10:11:41PM +0200, Imre Deak wrote:
> Fix the calculation of the DSC line buffer depth. This is limited both
> by the source's and sink's maximum line buffer depth, but the former one
> was not taken into account. On all Intel platform's the source's maximum
> buffer depth
Hi
Am 28.03.24 um 12:04 schrieb Helge Deller:
On 3/27/24 21:41, Thomas Zimmermann wrote:
The per-architecture video helpers do not depend on struct fb_info
or anything else from fbdev. Remove it from the interface and replace
fb_is_primary_device() with video_is_primary_device(). The new
On Mon, 25 Mar 2024 11:34:17 -0300
Maíra Canal wrote:
> On 3/13/24 14:45, Louis Chauvet wrote:
> > 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
Hi
Am 28.03.24 um 13:51 schrieb Arnd Bergmann:
On Thu, Mar 28, 2024, at 13:46, Helge Deller wrote:
On 3/27/24 21:41, Thomas Zimmermann wrote:
+++ b/arch/arc/include/asm/video.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_VIDEO_H_
+#define _ASM_VIDEO_H_
+
+#include
Hi
Am 28.03.24 um 13:39 schrieb Helge Deller:
On 3/27/24 21:41, Thomas Zimmermann wrote:
Various Kconfig options selected the per-architecture helpers for
fbdev. But none of the contained code depends on fbdev. Standardize
on CONFIG_VIDEO, which will allow to add more general helpers for
video
Hi Thomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.9-rc1 next-20240328]
[cannot apply to tip/x86/core deller-parisc/for-next arnd-asm-generic/master]
[If your patch is applied to the wrong git tree, kindly drop us
On Thu, Mar 28, 2024, at 13:46, Helge Deller wrote:
> On 3/27/24 21:41, Thomas Zimmermann wrote:
>> +++ b/arch/arc/include/asm/video.h
>> @@ -0,0 +1,8 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +
>> +#ifndef _ASM_VIDEO_H_
>> +#define _ASM_VIDEO_H_
>> +
>> +#include
>> +
>> +#endif /*
On 3/27/24 21:41, Thomas Zimmermann wrote:
The per-architecture fbdev code has no dependencies on fbdev and can
be used for any video-related subsystem. Rename the files to 'video'.
Use video-sti.c on parisc as the source file depends on CONFIG_STI_CORE.
Further update all includes statements,
On 28 Mar 13:01, Greg Kroah-Hartman wrote:
> On Thu, Mar 28, 2024 at 11:41:31AM +, Lee Jones wrote:
> > On Tue, 05 Mar 2024, Ricardo B. Marliere wrote:
> >
> > > This is a simple and straight forward cleanup series that aims to make the
> > > class structures in backlight constant. This has
1 - 100 of 176 matches
Mail list logo
