On 7/16/24 16:40, Jason Gunthorpe wrote:
> On Sun, Jul 14, 2024 at 10:18:12AM +, Omer Shpigelman wrote:
>> On 7/12/24 16:08, Jason Gunthorpe wrote:
>>> [You don't often get email from j...@ziepe.ca. Learn why this is important
>>> at https://aka.ms/LearnAboutSenderIdentification ]
>>>
>>> On F
GitHub Dependabot has issued the following alert:
"Upgrade setuptools to version 70.0.0 or later.
A vulnerability in the package_index module of pypa/setuptools
versions up to 69.1.1 allows for remote code execution via its
download functions. These functions, which are used to download
packa
On Wed, Jul 17, 2024 at 08:48:29AM GMT, Dragan Simic wrote:
> Hello all,
>
> On 2024-07-17 08:29, Dragan Simic wrote:
> > From: Ondrej Jirman
> >
> > After a suspend and resume cycle, ISP1 stops receiving data, as observed
> > on the Pine64 PinePhone Pro, which is based on the Rockchip RK3399 So
在 2024/7/16 20:07, Christian König 写道:
Am 16.07.24 um 11:31 schrieb Daniel Vetter:
On Tue, Jul 16, 2024 at 10:48:40AM +0800, Huan Yang wrote:
I just research the udmabuf, Please correct me if I'm wrong.
在 2024/7/15 20:32, Christian König 写道:
Am 15.07.24 um 11:11 schrieb Daniel Vetter:
On T
On Wed, Jul 17, 2024 at 07:08:59AM +, Omer Shpigelman wrote:
> On 7/16/24 16:40, Jason Gunthorpe wrote:
> > On Sun, Jul 14, 2024 at 10:18:12AM +, Omer Shpigelman wrote:
> >> On 7/12/24 16:08, Jason Gunthorpe wrote:
> >>> [You don't often get email from j...@ziepe.ca. Learn why this is
> >>
Hello Ondrej,
On 2024-07-17 09:32, Ondřej Jirman wrote:
On Wed, Jul 17, 2024 at 08:48:29AM GMT, Dragan Simic wrote:
Hello all,
On 2024-07-17 08:29, Dragan Simic wrote:
> From: Ondrej Jirman
>
> After a suspend and resume cycle, ISP1 stops receiving data, as observed
> on the Pine64 PinePhone
https://bugzilla.kernel.org/show_bug.cgi?id=201497
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
https://bugzilla.kernel.org/show_bug.cgi?id=201497
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
URL||https://gitlab.freedes
When proposing to enable DRM_PANIC on Fedora, some users raised concern about
the need to disable VT_CONSOLE.
So this is my new attempt to avoid fbcon/vt_console to overwrite the panic
screen.
This time it doesn't involve any locking, so it should be safe.
I added a skip_panic option in struct fb
It allows to check if the drm device supports drm_panic.
Prepare the work to have better integration with fbcon and vtconsole.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_panic.c | 20
include/drm/drm_panic.h | 2 ++
2 files changed, 22 insertions(+)
diff --
This is required to avoid conflict between DRM_PANIC, and fbcon. If
a drm device already handle panic with drm_panic, it should set
the skip_panic field in fb_info, so that fbcon will stay quiet, and
not overwrite the panic_screen.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_fb_helper
Now that fbcon has the skip_panic option, there is no more conflicts
between drm_panic and fbcon.
Remove the build time dependency, so they can be both enabled.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/
Well that approach was discussed before and seemed to be to complicated.
But I totally agree that the AMDGPU_GEM_CREATE_GFX12_DCC flag is a bad
idea. This isn't anything userspace should need to specify in the first
place.
All we need is a hardware workaround which kicks in all the time while
On Thu, Jul 11, 2024 at 11:10 AM Vladimir Lypak
wrote:
>
> There are several issues with preemption on Adreno A5XX GPUs which
> render system unusable if more than one priority level is used. Those
> issues include persistent GPU faults and hangs, full UI lockups with
> idling GPU.
>
> ---
> Vladi
On 7/16/24 10:31 PM, Dmitry Baryshkov wrote:
> On Tue, Jul 16, 2024 at 07:01:17PM GMT, Tejas Vipin wrote:
>> Introduce 2 new macros, DSI_CTX_NO_OP and MIPI_DSI_ADD_MULTI_VARIANT.
>>
>> DSI_CTX_NO_OP calls a function only if the context passed to it hasn't
>> encountered any errors. It is a gener
Jocelyn Falempe writes:
Hello Jocelyn,
> It allows to check if the drm device supports drm_panic.
> Prepare the work to have better integration with fbcon and vtconsole.
>
> Signed-off-by: Jocelyn Falempe
> ---
> drivers/gpu/drm/drm_panic.c | 20
> include/drm/drm_panic.h
On Wed, 17 Jul 2024 at 12:58, Tejas Vipin wrote:
>
>
>
> On 7/16/24 10:31 PM, Dmitry Baryshkov wrote:
> > On Tue, Jul 16, 2024 at 07:01:17PM GMT, Tejas Vipin wrote:
> >> Introduce 2 new macros, DSI_CTX_NO_OP and MIPI_DSI_ADD_MULTI_VARIANT.
> >>
> >> DSI_CTX_NO_OP calls a function only if the conte
Jocelyn Falempe writes:
> This is required to avoid conflict between DRM_PANIC, and fbcon. If
> a drm device already handle panic with drm_panic, it should set
> the skip_panic field in fb_info, so that fbcon will stay quiet, and
> not overwrite the panic_screen.
>
> Signed-off-by: Jocelyn Falemp
Jocelyn Falempe writes:
> Now that fbcon has the skip_panic option, there is no more conflicts
> between drm_panic and fbcon.
> Remove the build time dependency, so they can be both enabled.
>
> Signed-off-by: Jocelyn Falempe
> ---
> drivers/gpu/drm/Kconfig | 2 +-
> 1 file changed, 1 insertion
On Mon, Jul 15, 2024 at 8:00 PM wrote:
>
> On Mon, Jul 15, 2024 at 4:05 AM Łukasz Bartosik wrote:
> >
> > On Sat, Jul 13, 2024 at 11:45 PM wrote:
> > >
> > > On Fri, Jul 12, 2024 at 9:44 AM Łukasz Bartosik
> > > wrote:
> > > >
> > > > On Wed, Jul 3, 2024 at 12:14 AM wrote:
> > > > >
> > > > >
On 7/17/24 10:36, Leon Romanovsky wrote:
> On Wed, Jul 17, 2024 at 07:08:59AM +, Omer Shpigelman wrote:
>> On 7/16/24 16:40, Jason Gunthorpe wrote:
>>> On Sun, Jul 14, 2024 at 10:18:12AM +, Omer Shpigelman wrote:
On 7/12/24 16:08, Jason Gunthorpe wrote:
> [You don't often get email
On 16/07/2024 05:37, WangYuli wrote:
GitHub Dependabot has issued the following alert:
"Upgrade setuptools to version 70.0.0 or later.
A vulnerability in the package_index module of pypa/setuptools
versions up to 69.1.1 allows for remote code execution via its
download functions. These
On 02/07/2024 14:26, Jocelyn Falempe wrote:
kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
callback.
This patch adds a new struct kmsg_dump_detail, that will hold the
reason and description, and pass it to the dump() callback.
To avoid updating all kmsg_dump() call, it ad
On Wed, Jul 17, 2024 at 10:51:03AM +, Omer Shpigelman wrote:
> The only place we have an ops structure is in the device driver,
> similarly to Jason's example. In our code it is struct
> hbl_aux_dev. What
No, hbl_aux_dev is an 'struct auxiliary_device', not a 'struct
device_driver', it is dif
Adding TEE mailing list and maintainers to the CC list.
Amirreza, please include them in future even if you are not going to use
the framework.
On Wed, Jul 10, 2024 at 09:16:48AM GMT, Amirreza Zarrabi wrote:
>
>
> On 7/3/2024 9:36 PM, Dmitry Baryshkov wrote:
> > On Tue, Jul 02, 2024 at 10:57:3
On Wed, Jul 17, 2024 at 10:51:03AM +, Omer Shpigelman wrote:
> On 7/17/24 10:36, Leon Romanovsky wrote:
> > On Wed, Jul 17, 2024 at 07:08:59AM +, Omer Shpigelman wrote:
> >> On 7/16/24 16:40, Jason Gunthorpe wrote:
> >>> On Sun, Jul 14, 2024 at 10:18:12AM +, Omer Shpigelman wrote:
> >>>
As discussed on irc, we rather improve the in-kernel DRM client's
support for cloned outputs (for fbcon) and then remove the hacks from
the ast and mgag200 drivers. Userspace compositors need to support
cloned outputs to a minimum.
https://dri.freedesktop.org/~cbrill/dri-log/index.php?channel=
Hi,
On Mon, Jul 15, 2024 at 09:33:02AM GMT, Dmitry Baryshkov wrote:
> Document that DRM_MODE_PROP_IMMUTABLE must be set for the properties
> that are immutable by definition - e.g. ranges with min == max or enums
> with a single value. This matches the behaviour of the IGT tests, see
> kms_propert
Il 17/07/24 07:24, Hsiao Chien Sung via B4 Relay ha scritto:
From: Hsiao Chien Sung
Support "Pre-multiplied" alpha blending mode on in OVL.
Before this patch, only the "coverage" mode is supported.
As whether OVL_CON_CLRFMT_MAN bit is enabled, (3 << 12)
means different formats in the datasheet
Il 17/07/24 07:24, Hsiao Chien Sung via B4 Relay ha scritto:
From: Hsiao Chien Sung
Support "None" alpha blending mode on MediaTek's chips.
Reviewed-by: CK Hu
Signed-off-by: Hsiao Chien Sung
Reviewed-by: AngeloGioacchino Del Regno
On Thu, Jul 11, 2024 at 02:26:55PM GMT, Cristian Ciocaltea wrote:
> The recent switch to drmm allocation in drm_bridge_connector_init() may
> cause double free on bridge_connector in some of the error handling
> paths.
>
> Drop the explicit kfree() calls on bridge_connector.
>
> Fixes: c12907be57
On Wed, Jul 17, 2024 at 03:42:46PM GMT, Maxime Ripard wrote:
> Hi,
>
> On Mon, Jul 15, 2024 at 09:33:02AM GMT, Dmitry Baryshkov wrote:
> > Document that DRM_MODE_PROP_IMMUTABLE must be set for the properties
> > that are immutable by definition - e.g. ranges with min == max or enums
> > with a sin
This series adds a new panic screen, with the kmsg data embedded in a QR code.
The main advantage of QR code, is that you can copy/paste the debug data to a
bug report.
The QR code encoder is written in rust, and is very specific to drm panic.
The reason is that it is called in a panic handler,
Add a parameter to the blit function, to upscale the image.
This is necessary to draw a QR code, otherwise, the pixels are
usually too small to be readable by most QR code reader.
It can also be used later for drawing fonts on high DPI display.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/
Check if two rectangles overlap.
It's a bit similar to drm_rect_intersect() but this won't modify
the rectangle.
Simplifies a bit drm_panic.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_panic.c | 3 +--
include/drm/drm_rect.h | 15 +++
2 files changed, 16 insertions(+
This patch adds a new panic screen, with a QR code and the kmsg data
embedded.
If DRM_PANIC_SCREEN_QR_CODE_URL is set, then the kmsg data will be
compressed with zlib and encoded as a numerical segment, and appended
to the URL as a URL parameter. This allows to save space, and put
about ~7500 bytes
Move logo rectangle initialisation, and logo drawing in separate
functions, so they can be re-used by different panic screens.
It prepares the introduction of the QR code panic screen.
Signed-off-by: Jocelyn Falempe
---
drivers/gpu/drm/drm_panic.c | 57 +
1 fi
The overall control flow of the driver ensures that it never reads
EDID or sets display state on unconnected outputs. Therefore remove
all tests for Hot Plug Detection from these helpers. Also rename
the register constants.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_dp.c | 12
Power up the ASTDP connector for connection status detection if the
connector is not active. Keep it powered if a display is attached.
This fixes a bug where the connector does not come back after
disconnecting the display. The encoder's atomic_disable turns off
power on the physical connector. Fu
Test for running ASTDP firmware during probe. Do not bother testing
this later. We cannot do much anyway if the firmware fails. Do not
initialize the ASTDP conenctor if the test fails during device probing.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_dp.c | 41 +---
Simplify ast_astdp_read_edid(). Rename register constants. Drop
unnecessary error handling. On success, the helper returns 0; an
error code otherwise.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_dp.c | 93 ---
drivers/gpu/drm/ast/ast_reg.h | 12 +
The place for link training is in the encoder's atomic_enable
helper. Remove all related tests from other helper ASTDP functions;
especially ast_astdp_is_connected(), which tests HPD status.
DP link training is controlled by the firmware. A status flag reports
success or failure. The process can b
Here are a number of updates for ast's ASTDP transmitter code.
So far the ast driver required the DisplayPort to be connected
at boot. Later detection was not supported. Re-connecting the
cable was also not supported. Once atomic_disable powered off
the physical ASTDP connector, there was no way o
Hi Christian,
Can we use the below combination flags to kick in hardware workaround
while pinning BO's for this specific hw generation.
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) &&
(amdgpu_ip_version(adev, GC_HWIP, 0) == IP_VERSION(12, 0, 0) ||
amdgpu_ip_version(adev, GC_HWIP, 0) == IP_VERSIO
As far as I know, yes.
Regards,
Christian.
Am 17.07.24 um 16:38 schrieb Paneer Selvam, Arunpravin:
Hi Christian,
Can we use the below combination flags to kick in hardware workaround
while pinning BO's for this specific hw generation.
if (place->flags & TTM_PL_FLAG_CONTIGUOUS) &&
(amdgpu_ip
Hi,
On Wed, Jul 10, 2024 at 1:17 AM Amirreza Zarrabi
wrote:
>
>
>
> On 7/3/2024 9:36 PM, Dmitry Baryshkov wrote:
> > On Tue, Jul 02, 2024 at 10:57:35PM GMT, Amirreza Zarrabi wrote:
> >> Qualcomm TEE hosts Trusted Applications (TAs) and services that run in
> >> the secure world. Access to these r
Am 16.07.24 um 23:53 schrieb Matthew Brost:
On Tue, Jul 16, 2024 at 02:35:11PM +0200, Christian König wrote:
Instead of a TTM reference grab a GEM reference whenever necessary.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 8
drivers/gpu/drm/amd/am
Hi,
On Wed, Jul 17, 2024 at 2:39 AM Terry Hsiao
wrote:
>
> The 6 panels are used on Mediatek MT8186 Chromebooks
> - B116XAT04.1 (06AF/B4C4)
> - NV116WHM-A4D (09E5/FA0C)
> - N116BCP-EA2 (0DAE/6111)
> - B116XTN02.3 (06AF/AA73)
> - B116XAN06.1 (06AF/99A1)
> - N116BCA-EA2 (0DAE/5D11)
>
> Signed-
On 7/16/2024 3:34 PM, Matthew Auld wrote:
On 16/07/2024 10:50, Paneer Selvam, Arunpravin wrote:
Hi Matthew,
On 7/10/2024 6:20 PM, Matthew Auld wrote:
On 10/07/2024 07:03, Paneer Selvam, Arunpravin wrote:
Thanks Alex.
Hi Matthew,
Any comments?
Do we not pass the required address alignmen
On Wed, Jul 17, 2024 at 10:48:40AM +0200, Jocelyn Falempe wrote:
> This is required to avoid conflict between DRM_PANIC, and fbcon. If
> a drm device already handle panic with drm_panic, it should set
> the skip_panic field in fb_info, so that fbcon will stay quiet, and
> not overwrite the panic_sc
On Wed, Jul 17, 2024 at 10:48:39AM +0200, Jocelyn Falempe wrote:
> It allows to check if the drm device supports drm_panic.
> Prepare the work to have better integration with fbcon and vtconsole.
>
> Signed-off-by: Jocelyn Falempe
> ---
> drivers/gpu/drm/drm_panic.c | 20
>
On Wed, Jul 17, 2024 at 12:09:46PM +0200, Javier Martinez Canillas wrote:
> Jocelyn Falempe writes:
>
> > Now that fbcon has the skip_panic option, there is no more conflicts
> > between drm_panic and fbcon.
> > Remove the build time dependency, so they can be both enabled.
> >
> > Signed-off-by:
On Tue, Jul 16, 2024 at 06:14:48PM +0800, Huan Yang wrote:
>
> 在 2024/7/16 17:31, Daniel Vetter 写道:
> > [你通常不会收到来自 daniel.vet...@ffwll.ch 的电子邮件。请访问
> > https://aka.ms/LearnAboutSenderIdentification，以了解这一点为什么很重要]
> >
> > On Tue, Jul 16, 2024 at 10:48:40AM +0800, Huan Yang wrote:
> > > I just rese
On Tue, Jul 16, 2024 at 02:07:20PM +0200, Christian König wrote:
> Am 16.07.24 um 11:31 schrieb Daniel Vetter:
> > On Tue, Jul 16, 2024 at 10:48:40AM +0800, Huan Yang wrote:
> > > I just research the udmabuf, Please correct me if I'm wrong.
> > >
> > > 在 2024/7/15 20:32, Christian König 写道:
> > >
Am 05.07.24 um 13:47 schrieb Thomas Zimmermann:
There's no VBLANK interrupt on Matrox chipsets. The workaround that is
being used here and in other free Matrox drivers is to program
to the value of and enable the VLINE interrupt. This triggers
an interrupt at the time when VBLANK begins.
VL
On Mon, Jul 15, 2024 at 05:46:38PM -0400, Aurabindo Pillai wrote:
>
>
> On 7/12/24 1:45 PM, Abhishek Tamboli wrote:
> > Add detail description for the read_mpcc_state function in the
> > mpc_funcs struct to resolve the documentation warning.
> >
> > A kernel-doc warning was addressed:
> > ./driv
On Thu, Nov 2, 2023 at 8:06 PM Alex Deucher wrote:
>
> On Thu, Nov 2, 2023 at 3:00 PM Hamza Mahfooz wrote:
> >
> > On 11/1/23 17:36, Alex Deucher wrote:
> > > On Wed, Nov 1, 2023 at 5:01 PM Hamza Mahfooz
> > > wrote:
> > >>
> > >> Without this fix the 5120x1440@240 timing of these monitors
> >
On Wed, Jul 17, 2024 at 10:40:26AM +0100, Connor Abbott wrote:
> On Thu, Jul 11, 2024 at 11:10 AM Vladimir Lypak
> wrote:
> >
> > There are several issues with preemption on Adreno A5XX GPUs which
> > render system unusable if more than one priority level is used. Those
> > issues include persiste
From: Rob Clark
This series extends io-pgtable-arm with a method to retrieve the page
table entries traversed in the process of address translation, and then
beefs up drm/msm gpu devcore dump to include this (and additional info)
in the devcore dump.
This is a respin of https://patchwork.freedes
From: Rob Clark
Add an io-pgtable method to walk the pgtable returning the raw PTEs that
would be traversed for a given iova access.
Signed-off-by: Rob Clark
Acked-by: Joerg Roedel
---
drivers/iommu/io-pgtable-arm.c | 36 +-
include/linux/io-pgtable.h | 17
From: Rob Clark
In the case of iova fault triggered devcore dumps, include additional
debug information based on what we think is the current page tables,
including the TTBR0 value (which should match what we have in
adreno_smmu_fault_info unless things have gone horribly wrong), and
the pagetabl
Hi
Am 08.07.24 um 14:46 schrieb Jocelyn Falempe:
On 05/07/2024 13:47, Thomas Zimmermann wrote:
There's no VBLANK interrupt on Matrox chipsets. The workaround that is
being used here and in other free Matrox drivers is to program
to the value of and enable the VLINE interrupt. This trigger
On Wed, Jul 17, 2024 at 5:33 PM Vladimir Lypak wrote:
>
> On Wed, Jul 17, 2024 at 10:40:26AM +0100, Connor Abbott wrote:
> > On Thu, Jul 11, 2024 at 11:10 AM Vladimir Lypak
> > wrote:
> > >
> > > There are several issues with preemption on Adreno A5XX GPUs which
> > > render system unusable if mo
On 7/2/2024 5:26 AM, Jocelyn Falempe wrote:
> kmsg_dump doesn't forward the panic reason string to the kmsg_dumper
> callback.
> This patch adds a new struct kmsg_dump_detail, that will hold the
> reason and description, and pass it to the dump() callback.
>
> To avoid updating all kmsg_dump() cal
On Wed, Jul 17, 2024 at 04:53:16PM +0200, Christian König wrote:
> Am 16.07.24 um 23:53 schrieb Matthew Brost:
> > On Tue, Jul 16, 2024 at 02:35:11PM +0200, Christian König wrote:
> > > Instead of a TTM reference grab a GEM reference whenever necessary.
> > >
> > > Signed-off-by: Christian König
On Tue, Jul 16, 2024 at 02:35:19PM +0200, Christian König wrote:
> Prevent drivers from using this directly.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/ttm/ttm_bo_internal.h | 10 ++
> include/drm/ttm/ttm_bo.h | 10 --
>
On Tue, Jul 16, 2024 at 02:35:17PM +0200, Christian König wrote:
> This reverts commit 24dc64c1ba5c3ef0463d59fef6df09336754188d.
>
> Shouldn't be needed by drivers any more.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/ttm/ttm_bo.c | 1 +
>
On Tue, Jul 16, 2024 at 02:35:18PM +0200, Christian König wrote:
> Instead of a TTM reference grab a GEM reference whenever necessary for a
> VM mapping.
>
> Signed-off-by: Christian König
Reviewed-by: Matthew Brost
> ---
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 14 +++---
> 1 file changed
On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
The struct dpu_hw_fmt_layout defines hardware data layout (addresses,
sizes and pitches. Drop format field from this structure as it's not a
Missing closing brace ")" here?
part of the data layout.
Its a bit subjective IMO whether you conside
On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
Instead of passing width / height / pitches, pass drm_framebuffer
directly. This allows us to drop the useless check for !pitches, since
an array can not be NULL.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c |
From: Rob Clark
Just a guess on the panel timings, but they appear to work.
Signed-off-by: Rob Clark
---
This adds the panel I have on my lenovo yoga slim 7x laptop. I couldn't
find any datasheet so timings is just a guess. But AFAICT everything
works fine.
drivers/gpu/drm/panel/panel-edp.c
On Wed, 17 Jul 2024 at 23:15, Abhinav Kumar wrote:
>
>
>
> On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
> > The struct dpu_hw_fmt_layout defines hardware data layout (addresses,
> > sizes and pitches. Drop format field from this structure as it's not a
> Missing closing brace ")" here?
>
> > part
On Wed, Jul 17, 2024 at 02:58:46PM GMT, Rob Clark wrote:
> From: Rob Clark
>
> Just a guess on the panel timings, but they appear to work.
>
> Signed-off-by: Rob Clark
> ---
> This adds the panel I have on my lenovo yoga slim 7x laptop. I couldn't
> find any datasheet so timings is just a gues
On 6/24/2024 2:13 PM, Dmitry Baryshkov wrote:
The _dpu_format_get_plane_sizes_linear() already compares pitches of
the framebuffer with the calculated pitches. Move the check to the same
place, demoting DPU_ERROR to DPU_DEBUG to prevent user from spamming the
kernel log.
Signed-off-by: Dmitry
Before building an image, the build script looks to see if there are fixes
to apply from an upstream repository. The link for the upstream repository
git://anongit.freedesktop.org/drm/drm became obsolete with the move to
Gitlab server in March 2024. Until recently, this obsolete link was
harmless b
Hi,
On Wed, Jul 17, 2024 at 2:58 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Just a guess on the panel timings, but they appear to work.
>
> Signed-off-by: Rob Clark
> ---
> This adds the panel I have on my lenovo yoga slim 7x laptop. I couldn't
> find any datasheet so timings is just a guess.
Conor (and/or) Krzysztof and Rob,
On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley wrote:
>
> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote:
> > The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight
> > control over the DP AUX channel. While it works almost correctl
On Wed, Jul 17, 2024 at 5:19 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jul 17, 2024 at 2:58 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Just a guess on the panel timings, but they appear to work.
> >
> > Signed-off-by: Rob Clark
> > ---
> > This adds the panel I have on my lenovo yoga
在 2024/7/18 1:03, Christoph Hellwig 写道:
[Some people who received this message don't often get email from
h...@infradead.org. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
On Wed, Jul 17, 2024 at 05:15:07PM +0200, Daniel Vetter wrote:
I'm talking about memfd
Suspend will disable pcie device. Thus, resume should do full hw
initialization again.
Add some APIs to ast_drm_thaw() before ast_post_gpu() to fix the issue.
Fixes: 5b71707dd13 ("drm/ast: Enable and unlock device access early during
init")
Signed-off-by: Jammy Huang
---
drivers/gpu/drm/ast/ast
在 2024/7/18 11:08, Christoph Hellwig 写道:
[Some people who received this message don't often get email from
h...@infradead.org. Learn why this is important at
https://aka.ms/LearnAboutSenderIdentification ]
On Thu, Jul 18, 2024 at 09:51:39AM +0800, Huan Yang wrote:
Yes, actually, if dma-buf
On 18/07/2024 02:21, Doug Anderson wrote:
> Conor (and/or) Krzysztof and Rob,
>
> On Mon, Jul 15, 2024 at 8:31 AM Conor Dooley wrote:
>>
>> On Mon, Jul 15, 2024 at 02:15:37PM +0200, Stephan Gerhold wrote:
>>> The Samsung ATNA45AF01 panel is an AMOLED eDP panel that has backlight
>>> control over
(Cary, this looks like it fixes the problem you reported.)
Hi Jammy
Am 18.07.24 um 05:03 schrieb Jammy Huang:
Suspend will disable pcie device. Thus, resume should do full hw
initialization again.
Add some APIs to ast_drm_thaw() before ast_post_gpu() to fix the issue.
Fixes: 5b71707dd13 ("drm/
On 7/17/24 15:33, Leon Romanovsky wrote:
> On Wed, Jul 17, 2024 at 10:51:03AM +, Omer Shpigelman wrote:
>> On 7/17/24 10:36, Leon Romanovsky wrote:
>>> On Wed, Jul 17, 2024 at 07:08:59AM +, Omer Shpigelman wrote:
On 7/16/24 16:40, Jason Gunthorpe wrote:
> On Sun, Jul 14, 2024 at 10
86 matches
Mail list logo
