Address the FIXME in cea_db_payload_len
Transition to passing struct cea_db * everywhere
Precompute the payload length in drm_parse_cea_ext and pass to
individual parsers to avoid casting struct cea_db pointer to u8
pointer where length is needed.
Since the type of payload length is incon
On Thu, 10 Oct 2024 12:05:38 -0700 Mina Almasry wrote:
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 083d438d8b6f..cb3d8b19de14 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1071,11 +1071,11 @@ sock_devmem_dontneed(struct sock *sk,
> sockptr_t optval, unsigned int optlen)
On 10/10/2024 11:31 AM, Jakob Hauser wrote:
This initial part of the panel driver was mostly generated by the
"linux-mdss-dsi-panel-driver-generator" tool [1], reading downstream
Android kernel file "dsi_panel_S6E88A0_AMS427AP24_qhd_octa_video.dtsi" [2].
On top of the generic output of the to
On Thu, 2024-10-10 at 10:00 +0200, Christian König wrote:
> Am 09.10.24 um 16:17 schrieb Thomas Hellström:
> > On Wed, 2024-10-09 at 15:39 +0200, Thomas Hellström wrote:
> > > On Mon, 2024-10-07 at 11:08 +0200, Christian König wrote:
> > > > Hi Thomas,
> > > >
> > > > I'm on sick leave, but I will
On 10/10/2024 11:31 AM, Jakob Hauser wrote:
The way of implementing a flip option follows the existing
panel-samsung-s6e8aa0.c [1][2][3].
The value to flip the screen is taken from a downstream kernel file of
a similar but older panel [4]. The mipi clock [5] for the new panel
samsung-s6e88a0-
Hi Boris,
On 09.10.2024 09:10, Steven Price wrote:
> On 08/10/2024 09:47, Boris Brezillon wrote:
> > The system and GPU MMU page size might differ, which becomes a
> > problem for FW sections that need to be mapped at explicit address
> > since our PAGE_SIZE alignment might cover a VA range that's
Progress! My system now boots. But there's one WARN_ON dump along the way to
the "login:" prompt.
Thanks
-Tony
---
[ 33.111505] Console: switching to colour dummy device 80x25
[ 33.119581] mgag200 :08:00.0: vgaarb: deactivate vga console
[ 33.139574] [drm] Initialized mgag200 1.0.0 f
Only enable the merge_3d block for the video phys encoder when the 3d
blend mode is not *_NONE since there is no need to activate the merge_3d
block for cases where merge_3d is not needed.
Fixes: 3e79527a33a8 ("drm/msm/dpu: enable merge_3d support on sm8150/sm8250")
Suggested-by: Abhinav Kumar
Si
If the importer has allow_peer2peer set to true, then we can expect that
it would be able to handle VRAM addresses. Therefore, in this specific
case and only while running in VF mode, do not migrate the BO to System
RAM before exporting it.
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/xe/x
While testing [1] and [2] with a SRIOV enabled dGPU, it was noticed
that migrating a BO to System RAM before exporting it as a dmabuf
results in considerable performance degradation while running in a
Guest VM. For example, running a simple 3D app such as weston-simple-egl
would yield ~50 FPS inste
Functions of the same PCI device (such as a PF and a VF) share the
same bus and have a common root port and typically, the PF provisions
resources for the VF. Therefore, they can be considered compatible
as far as P2P access is considered.
Currently, although the distance (2) is correctly calculat
To properly import a dmabuf that is associated with a VF (or that
originates in a Guest VM that includes a VF), we need to know where
in LMEM the VF's allocated region starts. The function introduced
in this patch does just that by returning the DPA associated with
the BO that backs the VF's region
For BOs of type ttm_bo_type_sg, that are backed by PCI BAR addresses
associated with a VF, we need to adjust and translate these addresses
to LMEM addresses to make the BOs usable by the PF. Otherwise, the BOs
(i.e, PCI BAR addresses) are only accessible by the CPU and not by
the GPU.
In order to
If a BO's is_devmem_external flag is set, it means that it is an
imported dmabuf BO that has a backing store in VRAM. Therefore, we
need to add XE_PPGTT_PTE_DM to the PTE flags as part of vm_bind.
Signed-off-by: Vivek Kasireddy
---
drivers/gpu/drm/xe/xe_pt.c | 5 +++--
1 file changed, 3 insertio
On 10/11/2024, Maxime Ripard wrote:
> On Mon, Sep 30, 2024 at 03:55:30PM GMT, Liu Ying wrote:
>> On 09/30/2024, Maxime Ripard wrote:
>>> On Mon, Sep 30, 2024 at 01:28:59PM GMT, Liu Ying wrote:
Multiple display modes could be read from a display device's EDID.
Use clk_round_rate() to valid
On Fri, Oct 11, 2024 at 07:40:26PM -0700, Vivek Kasireddy wrote:
> For BOs of type ttm_bo_type_sg, that are backed by PCI BAR addresses
> associated with a VF, we need to adjust and translate these addresses
> to LMEM addresses to make the BOs usable by the PF. Otherwise, the BOs
> (i.e, PCI BAR ad
Hi,
This series addresses string format safety issues that are
flagged by tooling in files touched by recent patches.
I do not believe that any of these issues are bugs.
Rather, I am providing these updates as I think there is a value
in addressing such warnings so real problems stand out.
---
S
From: Thomas Zimmermann
squashed patch of v3 of drm: Introduce DRM client library
https://patchwork.freedesktop.org/series/139219/
---
Documentation/gpu/drm-client.rst | 3 +
drivers/gpu/drm/Kconfig | 41 +++-
drivers/gpu/drm/Makefile |
Move the color conversions, blit and fill functions to drm_draw.c,
so that they can be re-used by drm_log.
drm_draw is internal to the drm subsystem, and shouldn't be used by
gpu drivers.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/Kconfig | 5 +
drivers/gpu/drm/Makefile| 1 +
drm_log is a simple logger that uses the drm_client API to print the
kmsg boot log on the screen. This is not a full replacement to fbcon,
as it will only print the kmsg. It will never handle user input, or a
terminal because this is better done in userspace.
Design decisions:
* It uses the drm_c
The console is already suspended in printk.c.
Just make sure we don't write to the framebuffer while the graphic
driver is suspended.
It may lose a few messages between graphic suspend and console
suspend.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_log.c | 26
Add a module parameter, to increase the font size for HiDPI screen.
Even with CONFIG_FONT_TER16x32, it can still be a bit small to read.
In this case, adding drm_log.scale=2 to your kernel command line will
double the character size.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_log.c |
Color the timesamp prefix, similar to dmesg.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_log.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_log.c b/drivers/gpu/drm/drm_log.c
index 226e206e8b6a..635dff7b37ce 100644
When userspace takes drm_master, the drm_client buffer is no more
visible, so drm_log shouldn't waste CPU cycle to draw on it.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_log.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_log.c b/d
Applied to drm-misc-next
On 10/4/2024 6:25 PM, Maciej Falkowski wrote:
> This patchset adds initial support for 5th generation Intel NPU
> that is going to be present in the upcoming Panther Lake CPUs.
>
> Maciej Falkowski (1):
> accel/ivpu: Add initial Panther Lake support
>
> Wachowski, Karo
Hi Dave & Sima -
Here's the first i915 feature pull towards v6.13.
drm-intel-next-2024-10-11:
drm/i915 features for v6.13:
Features and functionality:
- Enable BMG and LNL+ ultra joiner support to join 2+2 pipes (Ankit, Stan)
- Enable 10bpc+CCS scanout for ICL+ and fp16+CCS scanout for TGL+ (V
On Mon, Sep 30, 2024 at 03:55:30PM GMT, Liu Ying wrote:
> On 09/30/2024, Maxime Ripard wrote:
> > On Mon, Sep 30, 2024 at 01:28:59PM GMT, Liu Ying wrote:
> >> Multiple display modes could be read from a display device's EDID.
> >> Use clk_round_rate() to validate the "ldb" clock rate for each mode
On Fri, 11 Oct 2024, Jocelyn Falempe wrote:
> Add a module parameter, to increase the font size for HiDPI screen.
> Even with CONFIG_FONT_TER16x32, it can still be a bit small to read.
> In this case, adding drm_log.scale=2 to your kernel command line will
> double the character size.
>
> Signed-o
2024. 10. 10. 23:17 keltezéssel, Lyude Paul írta:
Hi - how did you send this message? This patch comes out looking quite strange
on my machine, perhaps you don't have the encoding set to UTF-8 or aren't
using git send-email?
On Mon, 2024-09-23 at 22:18 +0200, Szőke Benjamin wrote:
s=201
101 - 129 of 129 matches
Mail list logo
