On Wed, Aug 14, 2024 at 02:07:44PM +0530, Nilawar, Badal wrote:
>
> Hi Andi,
>
> On 09-08-2024 15:46, Andi Shyti wrote:
> > Hi Badal,
> >
> > > > +static int
> > > > +hwm_fan_read(struct hwm_drvdata *ddat, u32 attr, long *val)
> > > > +{
> > > > + struct i915_hwmon *hwmon = ddat->hwmon;
>
Adding the per-frame lp function of mt8188, which can keep HFP in HS and
reduce the time required for each line to enter and exit low power.
Per Frame LP:
|<--One Active Frame>|
--_____
^HSA+HBP^^RGB^^HFP^^HSA+HBP^^RGB^^HFP
Add dmabuf information to page_pool stats:
$ ./cli.py --spec ../netlink/specs/netdev.yaml --dump page-pool-get
...
{'dmabuf': 10,
'id': 456,
'ifindex': 3,
'inflight': 1023,
'inflight-mem': 4190208},
{'dmabuf': 10,
'id': 455,
'ifindex': 3,
'inflight': 1023,
'inflight-mem': 4190208
ncdevmem is a devmem TCP netcat. It works similarly to netcat, but it
sends and receives data using the devmem TCP APIs. It uses udmabuf as
the dmabuf provider. It is compatible with a regular netcat running on
a peer, or a ncdevmem running on a peer.
In addition to normal netcat support, ncdevmem
Add documentation outlining the usage and details of devmem TCP.
Signed-off-by: Mina Almasry
Reviewed-by: Bagas Sanjaya
Reviewed-by: Donald Hunter
---
v16:
- Add documentation on unbinding the NIC from dmabuf (Donald).
- Add note that any dmabuf should work (Donald).
v9:
https://lore.kernel
Make skb_frag_page() fail in the case where the frag is not backed
by a page, and fix its relevant callers to handle this case.
Signed-off-by: Mina Almasry
Reviewed-by: Eric Dumazet
---
v10:
- Fixed newly generated kdoc warnings found by patchwork. While we're
at it, fix the Return section
For device memory TCP, we expect the skb headers to be available in host
memory for access, and we expect the skb frags to be in device memory
and unaccessible to the host. We expect there to be no mixing and
matching of device memory frags (unaccessible) with host memory frags
(accessible) in the
Add an interface for the user to notify the kernel that it is done
reading the devmem dmabuf frags returned as cmsg. The kernel will
drop the reference on the frags to make them available for reuse.
Signed-off-by: Willem de Bruijn
Signed-off-by: Kaiyuan Zhang
Signed-off-by: Mina Almasry
Reviewe
In tcp_recvmsg_locked(), detect if the skb being received by the user
is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
flag - pass it to tcp_recvmsg_devmem() for custom handling.
tcp_recvmsg_devmem() copies any data in the skb header to the linear
buffer, and returns a cmsg
Implement a memory provider that allocates dmabuf devmem in the form of
net_iov.
The provider receives a reference to the struct netdev_dmabuf_binding
via the pool->mp_priv pointer. The driver needs to set this pointer for
the provider in the net_iov.
The provider obtains a reference on the netde
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. The entries in the sg_table from
mapping will be inserted into a genpool
Implement netdev devmem allocator. The allocator takes a given struct
netdev_dmabuf_binding as input and allocates net_iov from that
binding.
The allocation simply delegates to the binding's genpool for the
allocation logic and wraps the returned memory region in a net_iov
struct.
Signed-off-by:
Convert netmem to be a union of struct page and struct netmem. Overload
the LSB of struct netmem* to indicate that it's a net_iov, otherwise
it's a page.
Currently these entries in struct page are rented by the page_pool and
used exclusively by the net stack:
struct {
unsigned long pp_mag
API takes the dma-buf fd as input, and binds it to the netdevice. The
user can specify the rx queues to bind the dma-buf to.
Suggested-by: Stanislav Fomichev
Signed-off-by: Mina Almasry
Reviewed-by: Donald Hunter
Reviewed-by: Jakub Kicinski
---
v16:
- Use subset-of: queue queue-id instead of
Add netdev_rx_queue_restart(), which resets an rx queue using the
queue API recently merged[1].
The queue API was merged to enable the core net stack to reset individual
rx queues to actuate changes in the rx queue's configuration. In later
patches in this series, we will use netdev_rx_queue_resta
v20: https://patchwork.kernel.org/project/netdevbpf/list/?series=879373&state=*
v20 aims to resolve a couple of bug reports against v19, and addresses
some review comments around the page_pool_check_memory_provider
mechanism.
Major changes:
- Test edge cases such as header split disabled in
i.MX93 SoC mediamix blk-ctrl contains one DISPLAY_MUX register which
configures parallel display format by using the "PARALLEL_DISP_FORMAT"
field. Document the Parallel Display Format Configuration(PDFC) subnode
and add the subnode to example.
Signed-off-by: Liu Ying
Reviewed-by: Conor Dooley
--
NXP i.MX93 mediamix blk-ctrl contains one DISPLAY_MUX register which
configures parallel display format by using the "PARALLEL_DISP_FORMAT"
field. Add a DRM bridge driver to support the display format configuration.
Signed-off-by: Liu Ying
---
v3->v4:
* Use dev_err_probe() in imx93_pdfc_bridge_pr
Hi,
This patch set aims to add NXP i.MX93 parallel display format configuration
DRM bridge driver support. i.MX93 mediamix blk-ctrl contains one
DISPLAY_MUX register which configures parallel display format by using
the "PARALLEL_DISP_FORMAT" field. i.MX93 LCDIF display controller's
parallel outpu
Hi all,
After merging the amdgpu tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c: In function 'amdgpu_job_timedout':
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c:90:33: error: too many arguments to
function 'drm_sched_start'
90 |
The RK3588 SoC family integrates the newer Synopsys DesignWare HDMI 2.1
Quad-Pixel (QP) TX controller IP and a HDMI/eDP TX Combo PHY based on a
Samsung IP block.
Add just the basic support for now, i.e. RGB output up to 4K@60Hz,
without audio, CEC or any of the HDMI 2.1 specific features.
Co-deve
Rockchip RK3588 SoC integrates the Synopsys DesignWare HDMI 2.1
Quad-Pixel (QP) TX controller IP.
Since this is a new IP block, quite different from those used in the
previous generations of Rockchip SoCs, add a dedicated binding file.
Signed-off-by: Cristian Ciocaltea
---
.../display/rockchip/
The Synopsys DesignWare HDMI 2.1 Quad-Pixel (QP) TX Controller IP
supports the following features, among others:
* Fixed Rate Link (FRL)
* Display Stream Compression (DSC)
* 4K@120Hz and 8K@60Hz video modes
* Variable Refresh Rate (VRR) including Quick Media Switching (QMS), aka
Cinema VRR
* Fas
Add dt-binding schema containing the common properties for the Synopsys
DesignWare HDMI QP TX controller.
Note this is not a full dt-binding specification, but is meant to be
referenced by platform-specific bindings for this IP core.
Signed-off-by: Cristian Ciocaltea
---
.../display/bridge/syno
The Rockchip RK3588 SoC family integrates the Synopsys DesignWare HDMI
2.1 Quad-Pixel (QP) TX controller, which is a new IP block, quite
different from those used in the previous generations of Rockchip SoCs.
The controller supports the following features, among others:
* Fixed Rate Link (FRL)
*
On Mon, 19 Aug 2024, at 1:40 AM, Chen-Yu Tsai wrote:
Hi Chen-Yu, thanks for the reviews!
>> +#include
> Still incorrect.
Whoops, only fixed the changelog it seems. Will correct.
Ryan
Hi Thomas,
Thank you for the patch.
On Fri, Aug 16, 2024 at 02:23:14PM +0200, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> Signed-off-
Hi Thomas,
Thank you for the patch.
On Fri, Aug 16, 2024 at 02:23:02PM +0200, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> Signed-off-
Hi Thomas,
Thank you for the patch.
On Fri, Aug 16, 2024 at 02:23:00PM +0200, Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> The rcar-du
Hi Thomas,
Thank you for the patch.
On Fri, Aug 16, 2024 at 02:22:30PM +0200, Thomas Zimmermann wrote:
> DRM may support multiple in-kernel clients that run as soon as a DRM
> driver has been registered. To select the client(s) in a single place,
> introduce drm_client_setup().
>
> Drivers that
On Aug 17 13:11, Barry Song wrote:
> On Thu, Aug 8, 2024 at 2:20 AM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Aug 07, 2024 at 01:56:38PM +, Daniel Gomez wrote:
> > > On Wed, Aug 07, 2024 at 01:01:08PM GMT, Greg Kroah-Hartman wrote:
> > > > On Wed, Aug 07, 2024 at 01:09:14AM +0200, Daniel Gom
Hi Thomas,
Thank you for the patch.
On Fri, Aug 16, 2024 at 02:22:27PM +0200, Thomas Zimmermann wrote:
> The color mode specified on the kernel command line gives the user's
> preferred color depth and number of bits per pixel. Move the
> color-mode-to-format conversion form fbdev helpers into a
On 18/08/2024 19:51, Laurent Pinchart wrote:
> On Sun, Aug 18, 2024 at 07:44:22PM +0200, Krzysztof Kozlowski wrote:
>> On 18/08/2024 19:41, Laurent Pinchart wrote:
>>> Hi Krzysztof,
>>>
>>> Thank you for the patch.
>>>
>>> On Sun, Aug 18, 2024 at 07:30:02PM +0200, Krzysztof Kozlowski wrote:
Ea
On Sun, Aug 18, 2024 at 07:44:22PM +0200, Krzysztof Kozlowski wrote:
> On 18/08/2024 19:41, Laurent Pinchart wrote:
> > Hi Krzysztof,
> >
> > Thank you for the patch.
> >
> > On Sun, Aug 18, 2024 at 07:30:02PM +0200, Krzysztof Kozlowski wrote:
> >> Each variable-length property like interrupts or
Hi Krzysztof,
Thank you for the patch.
On Sun, Aug 18, 2024 at 07:30:03PM +0200, Krzysztof Kozlowski wrote:
> Properties with variable number of items per each device are expected to
> have widest constraints in top-level "properties:" block and further
> customized (narrowed) in "if:then:". Add
On 18/08/2024 19:41, Laurent Pinchart wrote:
> Hi Krzysztof,
>
> Thank you for the patch.
>
> On Sun, Aug 18, 2024 at 07:30:02PM +0200, Krzysztof Kozlowski wrote:
>> Each variable-length property like interrupts or resets must have fixed
>> constraints on number of items for given variant in bind
Hi Krzysztof,
Thank you for the patch.
On Sun, Aug 18, 2024 at 07:30:02PM +0200, Krzysztof Kozlowski wrote:
> Each variable-length property like interrupts or resets must have fixed
> constraints on number of items for given variant in binding. The
> clauses in "if:then:" block should define bot
Properties with variable number of items per each device are expected to
have widest constraints in top-level "properties:" block and further
customized (narrowed) in "if:then:". Add missing top-level constraints
for clocks, clock-names, interrupts, resets, reset-names, renesas,cmms
and renesas,vs
Each variable-length property like interrupts or resets must have fixed
constraints on number of items for given variant in binding. The
clauses in "if:then:" block should define both limits: upper and lower.
Signed-off-by: Krzysztof Kozlowski
---
.../bindings/display/renesas,du.yaml |
bool dac_load_detect;
bool detected_by_load; /* if the connection status was determined by
load */
@@ -843,7 +842,7 @@ radeon_get_crtc_scanout_position(struct drm_crtc *crtc,
bool in_vblank_irq,
const struct drm_display_mode *mode);
extern bool radeon_combios_check_hardcoded_edid(struct radeon_device *rdev);
-extern struct edid *
+extern const struct drm_edid *
radeon_bios_get_hardcoded_edid(struct radeon_device *rdev);
extern bool radeon_atom_get_clock_info(struct drm_device *dev);
extern bool radeon_combios_get_clock_info(struct drm_device *dev);
---
base-commit: 19cff16559a4f2d763faf4f8392bf86d3a21b93c
change-id: 20240818-radeon-drm_edid-9f0cec36e227
Best regards,
--
Thomas Weißschuh
On Wed, Aug 14, 2024 at 6:13 AM 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. The entri
On Wed, 24 Jul 2024 17:29:39 +0800, Liu Ying wrote:
> i.MX8qxp Display Controller(DC) is comprised of three main components that
> include a blit engine for 2D graphics accelerations, display controller for
> display output processing, as well as a command sequencer.
>
> Signed-off-by: Liu Ying
On Sun, Aug 18, 2024 at 7:08 AM Ryan Walklin wrote:
>
> The Allwinner H616 and variants have a new display engine revision
> (DE33).
>
> Add a clock binding for the DE33.
>
> Signed-off-by: Ryan Walklin
Reviewed-by: Chen-Yu Tsai
On Sun, Aug 18, 2024 at 7:08 AM Ryan Walklin wrote:
>
> The Allwinner H616 and variants have a new display engine revision
> (DE33).
>
> The mixer configuration registers are significantly different to the DE3
> and DE2 revisions, being split into separate top and display blocks,
> therefore a fal
On Sun, Aug 18, 2024 at 7:08 AM Ryan Walklin wrote:
>
> The Allwinner H616 and variants have a new display engine revision
> (DE33).
>
> Add a display engine bus binding for the DE33.
>
> Signed-off-by: Ryan Walklin
> Acked-by: Conor Dooley
Reviewed-by: Chen-Yu Tsai
>
> --
> Changelog v1..v2:
On Sun, Aug 18, 2024 at 7:06 AM Ryan Walklin wrote:
>
> From: Jernej Skrabec
>
> drm_universal_plane_init() can already call some callbacks, like
> format_mod_supported, during initialization. Because of that, fields
> should be initialized beforehand.
>
> Signed-off-by: Jernej Skrabec
> Co-deve
On Sun, Aug 18, 2024 at 7:08 AM Ryan Walklin wrote:
>
> From: Jernej Skrabec
>
> The DE33 is a newer version of the Allwinner Display Engine IP block,
> found in the H616, H618, H700 and T507 SoCs. DE2 and DE3 are already
> supported by the mainline driver.
>
> The DE33 in the H616 has mixer0 and
Fix the following warnings while building the docs :-
./include/linux/jbd2.h:1303: warning: Function parameter or struct member
'j_transaction_overhead_buffers' not described in 'journal_s'
./include/linux/jbd2.h:1303: warning: Excess struct member
'j_transaction_ov
The callers of dc_link_add_remote_sink() are using 'struct edid' which
they all need to cast to uint8_t *.
Allow the direct passing of 'struct edid' to avoid these cast and also
move the length calculation so it does not need to be duplicated
everywhere.
Signed-off-by: Thomas Weißschuh
---
drive
The argument edid is passed in as const.
Preserve this constness through the edid_buf variable and the used
helper functions.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/
The custom "struct dc_edid" can be replaced by the standard "struct
drm_edid.
Rename the member to make sure that no usage sites are missed,
as "struct drm_edid" has some restrictions, for example it can not be
used with kfree().
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/a
Reduce the number of casts needed by reusing the edid_buf variable.
Also initialize edid_buf after the !edid case has been handled to avoid
the ternary expression.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 8 +---
1 file changed, 5 insert
"struct drm_edid" is the safe and recommended alternative to "struct edid".
Rename the member to make sure that no usage sites are missed,
as "struct drm_edid" has some restrictions, for example it can not be
used with kfree().
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/amdgpu/amdg
drm_edid_is_valid() does not modify its argument, so mark it as const.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/drm_edid.c | 2 +-
include/drm/drm_edid.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
The parsing functions do not modify their edid argument.
Mark the const to reflect this to the caller.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +++---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 +-
2 files changed, 8 insertio
"struct drm_edid" is the safe and recommended alternative to "struct edid".
Now that all callers of dc_link_add_remote_sink() have access to a
validate struct drm_edid, pass it around directly.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +-
"struct drm_edid" is the safe and recommended alternative to "struct edid".
Rename the member to make sure that no usage sites are missed,
as "struct drm_edid" has some restrictions, for example it can not be
used with kfree().
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/amd
As struct drm_edid is opaque, drivers can't directly memcmp() the
contained data. Add a helper to provide this functionality.
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/drm_edid.c | 18 ++
include/drm/drm_edid.h | 1 +
2 files changed, 19 insertions(+)
diff --git a
The prototype is the whole content of commit
575d0df6dae4 ("drm/amd/display: refine the EDID override").
Apparently the definition was never added.
Fixes: 575d0df6dae4 ("drm/amd/display: refine the EDID override")
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/dc/dm_helpers.h |
All usages of these fields have been removed.
Fixes: 7c7f5b15be65 ("drm/amd/display: Refactor edid read.")
Signed-off-by: Thomas Weißschuh
---
drivers/gpu/drm/amd/display/dc/dc_ddc_types.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/dc_ddc_types.h
b/dri
around some code.
The remaining patches perform the actual conversion in steps.
[0]
https://lore.kernel.org/lkml/20240818-amdgpu-min-backlight-quirk-v5-0-b6c0ead0c...@weissschuh.net/
Signed-off-by: Thomas Weißschuh
---
Thomas Weißschuh (12):
drm/amd/display: remove spurious definition for
d
On Fri, Aug 16, 2024 at 2:54 PM Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> The mcde driver specifies a preferred color mode of 32. As
On Fri, Aug 16, 2024 at 2:54 PM Thomas Zimmermann wrote:
> Call drm_client_setup() to run the kernel's default client setup
> for DRM. Set fbdev_probe in struct drm_driver, so that the client
> setup can start the common fbdev client.
>
> Signed-off-by: Thomas Zimmermann
> Cc: Linus Walleij
Th
: 8befe8fa5a4e4b30787b17e078d9d7b5cb92ea19
patch link:
https://lore.kernel.org/r/20240816125612.1003295-4-jfalempe%40redhat.com
patch subject: [PATCH v2 3/5] drm/log: Introduce a new boot logger to draw the
kmsg on the screen
config: arm-randconfig-r121-20240818
(https://download.01.org/0day-ci/archive/20240818
Hi Yafang,
On Sun, Aug 18, 2024 at 10:27:01AM GMT, Yafang Shao wrote:
> On Sat, Aug 17, 2024 at 4:39 PM Alejandro Colomar wrote:
> >
> > Hi Yafang,
> >
> > On Sat, Aug 17, 2024 at 10:56:20AM GMT, Yafang Shao wrote:
> > > Let's explicitly ensure the destination string is NUL-terminated. This
> >
In ch7006_encoder_get_modes(), the return value of drm_mode_duplicate() is
used directly in drm_mode_probed_add(), which will lead to a NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
Cc: sta...@vger.kernel.org
Fixes: 6ee738610f41 ("drm/nouveau: Add DRM drive
Changes the mantix-mlaf057we51 panel to use multi style functions for
improved error handling.
Signed-off-by: Tejas Vipin
---
.../gpu/drm/panel/panel-mantix-mlaf057we51.c | 79 +++
1 file changed, 27 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-mantix
在 2024-06-28星期五的 16:39 +0200，Barnabás Czémán写道：
> From: Konrad Dybcio
>
> Add support for MSM8996, which - fun fact - was the SoC that this
> driver
> (or rather SDE, its downstream origin) was meant for and first tested
> on.
>
> It has some hardware that differs from the modern SoCs, so not a
68 matches
Mail list logo
