Hello All,
These 3 patches does some fixup for the cdns-mhdp8546 bridge.
- First of all, it removes the legacy !DRM_BRIDGE_ATTACH_NO_CONNECTOR
usecase.
- Then it fixes possible NULL POINTER in cdns_mhdp_modeset_retry_fn
function call where the connector mutex is called. Since we cannot
use t
On Mon, Feb 03, 2025 at 11:24:50AM +0100, Thomas Zimmermann wrote:
> Hi
>
>
> Am 14.01.25 um 00:15 schrieb Lorenzo Stoakes:
> [...]
> >
> > *** REVIEWERS NOTES: ***
> >
> > I do not have any hardware that uses fb_defio, so I'm asking for help with
> > testing this series from those who do :) I have
Hi
Am 14.01.25 um 00:15 schrieb Lorenzo Stoakes:
[...]
*** REVIEWERS NOTES: ***
I do not have any hardware that uses fb_defio, so I'm asking for help with
testing this series from those who do :) I have tested the mm side of this,
and done a quick compile smoke test of the fb_defio side but t
> +cc Kajtar, who has kindly smoke tested this series on real hardware and
> confirmed things are working ostensibly the same as before.
>
> On this basis I will be un-RFC'ing this and, if Kajtar can reply to
> confirm, will add a Tested-by tag to patch 3/3.
No problem, I'm glad I could help. Usi
+cc Kajtar, who has kindly smoke tested this series on real hardware and
confirmed things are working ostensibly the same as before.
On this basis I will be un-RFC'ing this and, if Kajtar can reply to
confirm, will add a Tested-by tag to patch 3/3.
Again to emphasise - there is some urgency here
Hi guys,
It'd be good if somebody from the drm side could look at this as you are
using fields that are deprecated and will be made unavailable (in a
non-optional fashion), and relatively soon :)
It'd be good to confirm this works on real hardware (none of mine supports
this sadly, I tried 3 sepa
Right now the only means by which we can write-protect a range using the
reverse mapping is via folio_mkclean().
However this is not always the appropriate means of doing so, specifically
in the case of the framebuffer deferred I/O logic (fb_defio enabled by
CONFIG_FB_DEFERRED_IO). There, kernel p
Extend DPU driver with experimental support for even more MDP5
platforms: MSM8937, MSM8917, MSM8953.
As with other MDP5 devices, one has to pass `msm.prefer_mdp5=false`
kernel param to test DPU driver insead of using MDP5.
Note, Luca Weiss has reported timeout issues with CMD panels. This is
not
From: Ville Syrjälä
I was pondering how I'd be able to do non-square cursor
sizes without have a massive list of them in the SIZE_HINTS
blob.
So I came up with this idea of having a 2D bitmap in
there to indicate support for (mostly) POT non-square
sizes..
What does everyone think? Is this just
Introduce and add support for a solid_fill property. When the solid_fill
property is set, and the framebuffer is set to NULL, memory fetch will be
disabled.
In addition, loosen the NULL FB checks within the atomic commit callstack
to allow a NULL FB when the solid_fill property is set and add FB c
This is the second version of the RFC following the comments given on the
first version. Nothing materially has changed in regard to how accel
devices are registered and exposed to user-space. The changes are mostly
re-factoring according to the comments.
Changes since v1:
- Instead of embedding t
Hi Daniel-san,
Thank you for your comments.
On 2022/01/13 22:44, Daniel Stone wrote:
Hi Esaki-san,
On Thu, 13 Jan 2022 at 09:44, Tomohito Esaki wrote:
Some drivers whose planes only support linear layout fb do not support format
modifiers.
These drivers should support modifiers, however the
Hi Esaki-san,
On Thu, 13 Jan 2022 at 09:44, Tomohito Esaki wrote:
> Some drivers whose planes only support linear layout fb do not support format
> modifiers.
> These drivers should support modifiers, however the DRM core should handle
> this
> rather than open-coding in every driver.
>
> In thi
Some drivers whose planes only support linear layout fb do not support format
modifiers.
These drivers should support modifiers, however the DRM core should handle this
rather than open-coding in every driver.
In this patch series, these drivers expose format modifiers based on the
following sugge
On Fri, Nov 12, 2021 at 5:40 AM Tim Harvey wrote:
>
> On Thu, Nov 11, 2021 at 2:15 AM Jagan Teki wrote:
> >
> > This series support MIPI DSI on i.MX8MM.
> >
> > The DSIM bridge still need to work to make it compatible for
> > exynos drm dsi hardware block.
> >
> > This series work directly on to
On Thu, Nov 11, 2021 at 2:15 AM Jagan Teki wrote:
>
> This series support MIPI DSI on i.MX8MM.
>
> The DSIM bridge still need to work to make it compatible for
> exynos drm dsi hardware block.
>
> This series work directly on to of linux-next with recent
> dispmix-blk-ctrl changes.
>
Jagan,
Than
This series support MIPI DSI on i.MX8MM.
The DSIM bridge still need to work to make it compatible for
exynos drm dsi hardware block.
This series work directly on to of linux-next with recent
dispmix-blk-ctrl changes.
Tested on i.Core MX8M Mini SoM with EDIMM2.2 and CTOUCH2
Carrier boards.
Requi
On Wed, Jul 8, 2020 at 10:20 AM Christian König
wrote:
>
> Am 08.07.20 um 11:49 schrieb Daniel Vetter:
> > On Wed, Jul 08, 2020 at 11:38:31AM +0200, Christian König wrote:
> >> Am 07.07.20 um 23:58 schrieb Xiong, Jianxin:
> -Original Message-
> From: Christian König
> Am 03
Am 08.07.20 um 11:49 schrieb Daniel Vetter:
On Wed, Jul 08, 2020 at 11:38:31AM +0200, Christian König wrote:
Am 07.07.20 um 23:58 schrieb Xiong, Jianxin:
-Original Message-
From: Christian König
Am 03.07.20 um 15:14 schrieb Jason Gunthorpe:
On Fri, Jul 03, 2020 at 02:52:03PM +0200, Da
On Wed, Jul 08, 2020 at 11:38:31AM +0200, Christian König wrote:
> Am 07.07.20 um 23:58 schrieb Xiong, Jianxin:
> > > -Original Message-
> > > From: Christian König
> > > Am 03.07.20 um 15:14 schrieb Jason Gunthorpe:
> > > > On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote:
>
Am 07.07.20 um 23:58 schrieb Xiong, Jianxin:
-Original Message-
From: Christian König
Am 03.07.20 um 15:14 schrieb Jason Gunthorpe:
On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote:
So maybe I'm just totally confused about the rdma model. I thought:
- you bind a pile of m
> -Original Message-
> From: Christian König
> Am 03.07.20 um 15:14 schrieb Jason Gunthorpe:
> > On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote:
> >
> >> So maybe I'm just totally confused about the rdma model. I thought:
> >> - you bind a pile of memory for various transac
On Thu, Jul 02, 2020 at 08:15:40PM +0200, Daniel Vetter wrote:
> > > > 3. rdma driver worker gets busy to restart rx:
> > > > 1. lock all dma-buf that are currently in use (dma_resv_lock).
> > > > thanks to ww_mutex deadlock avoidance this is possible
> > > Why all? Why not just loc
On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote:
> So maybe I'm just totally confused about the rdma model. I thought:
> - you bind a pile of memory for various transactions, that might
> happen whenever. Kernel driver doesn't have much if any insight into
> when memory isn't needed
Am 03.07.20 um 15:14 schrieb Jason Gunthorpe:
On Fri, Jul 03, 2020 at 02:52:03PM +0200, Daniel Vetter wrote:
So maybe I'm just totally confused about the rdma model. I thought:
- you bind a pile of memory for various transactions, that might
happen whenever. Kernel driver doesn't have much if a
On Fri, Jul 3, 2020 at 2:03 PM Jason Gunthorpe wrote:
>
> On Thu, Jul 02, 2020 at 08:15:40PM +0200, Daniel Vetter wrote:
> > > > > 3. rdma driver worker gets busy to restart rx:
> > > > > 1. lock all dma-buf that are currently in use (dma_resv_lock).
> > > > > thanks to ww_mutex de
On Thu, Jul 02, 2020 at 03:10:00PM +0200, Daniel Vetter wrote:
> On Wed, Jul 01, 2020 at 02:15:24PM -0300, Jason Gunthorpe wrote:
> > On Wed, Jul 01, 2020 at 05:42:21PM +0200, Daniel Vetter wrote:
> > > > >> All you need is the ability to stop wait for ongoing accesses to end
> > > > >> and
> > >
Daniel ; Christian
> > Koenig ; dri-
> > de...@lists.freedesktop.org
> > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
> >
> > > >
> > > > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote:
> > > > > > > Hete
On Thu, Jul 02, 2020 at 04:50:32PM +0200, Christian König wrote:
> Am 02.07.20 um 15:29 schrieb Jason Gunthorpe:
> > On Thu, Jul 02, 2020 at 03:10:00PM +0200, Daniel Vetter wrote:
> > > On Wed, Jul 01, 2020 at 02:15:24PM -0300, Jason Gunthorpe wrote:
> > > > On Wed, Jul 01, 2020 at 05:42:21PM +0200
Am 02.07.20 um 15:29 schrieb Jason Gunthorpe:
On Thu, Jul 02, 2020 at 03:10:00PM +0200, Daniel Vetter wrote:
On Wed, Jul 01, 2020 at 02:15:24PM -0300, Jason Gunthorpe wrote:
On Wed, Jul 01, 2020 at 05:42:21PM +0200, Daniel Vetter wrote:
All you need is the ability to stop wait for ongoing acce
On Wed, Jul 01, 2020 at 02:15:24PM -0300, Jason Gunthorpe wrote:
> On Wed, Jul 01, 2020 at 05:42:21PM +0200, Daniel Vetter wrote:
> > > >> All you need is the ability to stop wait for ongoing accesses to end
> > > >> and
> > > >> make sure that new ones grab a new mapping.
> > > > Swap and flush i
ug Ledford ; Sumit
> > > Semwal ; Leon Romanovsky
> > > ; Vetter, Daniel ; Christian
> > > Koenig
> > > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
> > >
> > > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote:
>
On Wed, Jul 01, 2020 at 05:42:21PM +0200, Daniel Vetter wrote:
> > >> All you need is the ability to stop wait for ongoing accesses to end and
> > >> make sure that new ones grab a new mapping.
> > > Swap and flush isn't a general HW ability either..
> > >
> > > I'm unclear how this could be useful
;>>> Sent: Tuesday, June 30, 2020 10:35 AM
> >>>> To: Xiong, Jianxin
> >>>> Cc: linux-r...@vger.kernel.org; Doug Ledford ;
> >>>> Sumit Semwal ; Leon Romanovsky
> >>>> ; Vetter, Daniel ; Christian
> >>>> Koenig
Semwal
; Leon Romanovsky
; Vetter, Daniel ; Christian Koenig
Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote:
Heterogeneous Memory Management (HMM) utilizes
mmu_interval_notifier and ZONE_DEVICE to support shared virtual
wal ; Leon Romanovsky
> > > > ; Vetter, Daniel ; Christian
> > > > Koenig
> > > > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
> > > >
> > > > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote:
> > > >
horpe
> > > Sent: Tuesday, June 30, 2020 10:35 AM
> > > To: Xiong, Jianxin
> > > Cc: linux-r...@vger.kernel.org; Doug Ledford ; Sumit
> > > Semwal ; Leon Romanovsky
> > > ; Vetter, Daniel ; Christian
> > > Koenig
> > > Subject: Re: [RF
Am 30.06.20 um 20:46 schrieb Xiong, Jianxin:
-Original Message-
From: Jason Gunthorpe
Sent: Tuesday, June 30, 2020 10:35 AM
To: Xiong, Jianxin
Cc: linux-r...@vger.kernel.org; Doug Ledford ; Sumit Semwal
; Leon Romanovsky
; Vetter, Daniel ; Christian Koenig
Subject: Re: [RFC PATCH v2
tter, Daniel ; Christian
> > Koenig
> > Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
> >
> > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote:
> > > > > Heterogeneous Memory Management (HMM) utilizes
> > > > > mmu_interval_not
top.org
> Subject: Re: [RFC PATCH v2 0/3] RDMA: add dma-buf support
>
> > >
> > > On Tue, Jun 30, 2020 at 05:21:33PM +, Xiong, Jianxin wrote:
> > > > > > Heterogeneous Memory Management (HMM) utilizes
> > > > > > mmu_interval_notifier
n Romanovsky ; Vetter, Daniel
>
> Subject: [RFC PATCH v2 0/3] RDMA: add dma-buf support
>
> When enabled, an RDMA capable NIC can perform peer-to-peer transactions
> over PCIe to access the local memory located on another device. This can
> often lead to better performance than usin
> -Original Message-
> From: Jason Gunthorpe
> Sent: Tuesday, June 30, 2020 10:35 AM
> To: Xiong, Jianxin
> Cc: linux-r...@vger.kernel.org; Doug Ledford ; Sumit
> Semwal ; Leon Romanovsky
> ; Vetter, Daniel ; Christian Koenig
>
> Subject: Re: [RFC PATC
Hi,
This is the second round of RFC for adding a bunch of new YUV formats
for Mali/AFBC. I've included a proper AFBC documentation file too, for
posterity.
Some of the new formats don't have an integer number of
bytes-per-pixel, so I've added a bpp field to drm_format_info
(patch 1), keen to hear
Hi!
This series adds support for an 8-bit clut mode in the atmel-hlcdc
driver.
I have only tested it with the fbdev interface, and am therefore not
really sure if it works w/o patch 2 and 3. One significant reason for
that is that the modetest test program in libdrm does not support clut
modes li
The full name of PSR is Panel Self Refresh, panel device could refresh
itself with the hardware framebuffer in panel, this would make a lots
of sense to save the power consumption.
For example, when desktop haven't change the context for a long time,
then we could refresh the data to the hardware
45 matches
Mail list logo
