Am 21.08.23 um 13:16 schrieb Christian König:
Am 21.08.23 um 12:14 schrieb Arunpravin Paneer Selvam:
The way now contiguous requests are implemented such that
the size rounded up to power of 2 and the corresponding order
block picked from the freelist.
In addition to the older method, the new
Am 22.08.23 um 20:27 schrieb Philip Yang:
On 2023-08-22 05:43, Christian König wrote:
Am 21.08.23 um 22:02 schrieb Philip Yang:
Without unsigned long typecast, the size is passed in as zero if page
array size >= 4GB, nr_pages >= 0x10, then sg list converted will
have the first and the
Hi Hsia-Jun,
On Tue, Aug 22, 2023 at 8:14 PM Hsia-Jun Li wrote:
>
> Hello
>
> I would like to introduce a usage of SHMEM slimier to DMA-buf, the major
> purpose of that is sharing metadata or just a pure container for cross
> drivers.
>
> We need to exchange some sort of metadata between
On 8/23/23 03:55, Nicolas Dufresne wrote:
CAUTION: Email originated externally, do not click links or open attachments
unless you recognize the sender and know the content is safe.
Hi,
Le mardi 22 août 2023 à 19:14 +0800, Hsia-Jun Li a écrit :
Hello
I would like to introduce a usage of
On Mon, Aug 21, 2023 at 03:17:29PM +0200, Christian König wrote:
> Am 18.08.23 um 15:13 schrieb Matthew Brost:
> > On Fri, Aug 18, 2023 at 07:27:33AM +0200, Christian König wrote:
> > > Am 17.08.23 um 19:54 schrieb Matthew Brost:
> > > > On Thu, Aug 17, 2023 at 03:39:40PM +0200, Christian König
[Public]
Thanks, Lyude!
Should I push another version to fix the indention?
> -Original Message-
> From: Lyude Paul
> Sent: Friday, August 18, 2023 6:17 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org;
> amd-...@lists.freedesktop.org
> Cc: jani.nik...@intel.com;
[AMD Official Use Only - General]
> -Original Message-
> From: Imre Deak
> Sent: Saturday, August 19, 2023 1:46 AM
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;
> ly...@redhat.com; jani.nik...@intel.com; ville.syrj...@linux.intel.com;
> Wentland,
Hi Daniel,
On 2023/8/22 21:56, Daniel Vetter wrote:
On Mon, Aug 07, 2023 at 07:09:31PM +0800, Qi Zheng wrote:
Currently, the synchronize_shrinkers() is only used by TTM pool. It only
requires that no shrinkers run in parallel.
After we use RCU+refcount method to implement the lockless slab
On Tue, Aug 22, 2023 at 6:41 PM Danilo Krummrich wrote:
> Currently, NO_PREFETCH is passed implicitly through
> drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len.
>
> Since this is a direct representation of how the HW is programmed it
> isn't really future proof for a uAPI.
On Tuesday, August 22, 2023 7:47 PM Maxime Ripard wrote:
>
> Hi,
Hi Maxime,
Thanks for your review.
>
> On Tue, Aug 22, 2023 at 04:59:44PM +0800, Liu Ying wrote:
> > This patch adds bindings for i.MX8qxp/qm Display Processing Unit.
> >
> > Reviewed-by: Rob Herring
> > Signed-off-by: Liu
On Fri, 2023-06-09 at 11:35 +0300, Jani Nikula wrote:
> On Fri, 09 Jun 2023, Animesh Manna wrote:
> > For DP alt mode display driver get the information
> > about cable speed and cable type through TCSS_DDI_STATUS
> > register which will be updated by type-c platform driver.
> > Accodingly Update
`strncpy` is deprecated for use on NUL-terminated destination strings [1].
A suitable replacement is `strscpy` [2] due to the fact that it
guarantees NUL-termination on its destination buffer argument which is
_not_ the case for `strncpy`!
There is likely no bug happening in this case since
On Tue, Aug 22, 2023 at 06:21:34PM +0200, Thomas Hellström wrote:
> Implement pinning of userptrs between VM_BIND and VM_UNBIND, which will
> facilitate avoiding long hangs on non-preemptible workloads. But don't
> hook it up to userspace just yet.
>
> v2:
> - Avoid marking userptr VMAs as
Currently, NO_PREFETCH is passed implicitly through
drm_nouveau_gem_pushbuf_push::length and drm_nouveau_exec_push::va_len.
Since this is a direct representation of how the HW is programmed it
isn't really future proof for a uAPI. Hence, fix this up for the new
uAPI and split up the va_len field
On Tue, Aug 22, 2023 at 5:24 AM Jesper Dangaard Brouer
wrote:
>
>
>
> On 22/08/2023 08.05, Mina Almasry wrote:
> > On Sat, Aug 19, 2023 at 2:51 AM Jesper Dangaard Brouer
> > wrote:
> >>
> >> On 10/08/2023 03.57, Mina Almasry wrote:
> >>> Overload the LSB of struct page* to indicate that it's a
On Mon, 2023-08-21 at 14:00 -0700, Ceraolo Spurio, Daniele wrote:
>
>
> On 8/21/2023 9:22 AM, Jani Nikula wrote:
> > On Mon, 21 Aug 2023, "Ricardo B. Marliere"
> > wrote:
> > > This patch fixes the following sphinx warnings in the htmldocs
> > > make target:
> > >
> > >
Quoting Kees Cook (2023-08-17 13:30:22)
> Prepare for the coming implementation by GCC and Clang of the __counted_by
> attribute. Flexible array members annotated with __counted_by can have
> their accesses bounds-checked at run-time checking via CONFIG_UBSAN_BOUNDS
> (for array indexing) and
On 8/22/2023 3:52 AM, Stanislaw Gruszka wrote:
From: Karol Wachowski
Buttress spec requires that the interrupt status is cleared at
the source first (before clearing MTL_BUTTRESS_INTERRUPT_STAT),
that implies that we have to mask out the global interrupt while
handling buttress interrupts.
Hi,
Le mardi 22 août 2023 à 19:14 +0800, Hsia-Jun Li a écrit :
> Hello
>
> I would like to introduce a usage of SHMEM slimier to DMA-buf, the major
> purpose of that is sharing metadata or just a pure container for cross
> drivers.
>
> We need to exchange some sort of metadata between
On Tue, Aug 22, 2023 at 11:48 AM Rafael J. Wysocki wrote:
>
> On Tue, Aug 22, 2023 at 8:02 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > In the process of adding lockdep annotation for drm GPU scheduler's
> > job_run() to detect potential deadlock against shrinker/reclaim, I hit
> > this
On 2023-08-22 06:01, Jani Nikula wrote:
Over the past years I've been trying to unify the override and firmware
EDID handling as well as EDID property updates. It won't work if drivers
do their own random things.
Let's check how to replace these references by appropriate ones or fork
the
On 8/11/2023 11:20, Zhanjun Dong wrote:
This attempts to avoid circular locking dependency between flush delayed
work and intel_gt_reset.
When intel_gt_reset was called, task will hold a lock.
To cacel delayed work here, the _sync version will also acquire a lock,
which might trigger the
On Tue, Aug 22, 2023 at 8:02 PM Rob Clark wrote:
>
> From: Rob Clark
>
> In the process of adding lockdep annotation for drm GPU scheduler's
> job_run() to detect potential deadlock against shrinker/reclaim, I hit
> this lockdep splat:
>
>
On 2023-08-22 05:43, Christian König
wrote:
Am 21.08.23 um 22:02 schrieb Philip Yang:
Without unsigned long typecast, the size
is passed in as zero if page
array size >= 4GB, nr_pages >= 0x10, then sg
From: Rob Clark
Now that the runpm/qos/interconnect lockdep vs reclaim issues are
solved, we can enable the fence signalling annotations without lockdep
making it's immediate displeasure known.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_ringbuffer.c | 1 +
1 file changed, 1
From: Rob Clark
Based on
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
but made to be optional.
Signed-off-by: Rob Clark
Reviewed-by: Luben Tuikov
---
drivers/gpu/drm/scheduler/sched_main.c | 9 +
include/drm/gpu_scheduler.h| 2 ++
2
From: Rob Clark
Move runpm enable to just before we enqueue the job to the scheduler,
rather than job_run(). This has the disadvantage of potentially
powering up the GPU before waiting for fences, but it is the only
feasible way to move things like clk_prepare() out of the fence
signalling
From: Rob Clark
The locking is unneeded here as runpm provides sufficient serialization.
Fixes:
==
WARNING: possible circular locking dependency detected
6.4.3-debug+ #16 Not tainted
From: Rob Clark
Teach lockdep that icc_bw_lock is needed in code paths that could
deadlock if they trigger reclaim.
Signed-off-by: Rob Clark
---
drivers/interconnect/core.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/core.c
From: Rob Clark
For cases where icc_bw_set() can be called in callbaths that could
deadlock against shrinker/reclaim, such as runpm resume, we need to
decouple the icc locking. Introduce a new icc_bw_lock for cases where
we need to serialize bw aggregation and update to decouple that from
paths
From: Rob Clark
In the process of adding lockdep annotation for drm GPU scheduler's
job_run() to detect potential deadlock against shrinker/reclaim, I hit
this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
Similar to the previous patch, move the allocation out from under
dev_pm_qos_mtx, by speculatively doing the allocation and handle
any race after acquiring dev_pm_qos_mtx by freeing the redundant
allocation.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 13
From: Rob Clark
Annotate dev_pm_qos_mtx to teach lockdep to scream about allocations
that could trigger reclaim under dev_pm_qos_mtx.
Signed-off-by: Rob Clark
---
drivers/base/power/qos.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/base/power/qos.c
From: Rob Clark
This will make it easier to catch places doing allocations that can
trigger reclaim under devfreq->lock.
Because devfreq->lock is held over various devfreq_dev_profile
callbacks, there might be some fallout if those callbacks do allocations
that can trigger reclaim, but I've
From: Rob Clark
In the process of adding lockdep annotation for GPU job_run() path to
catch potential deadlocks against the shrinker/reclaim path, I turned
up this lockdep splat:
==
WARNING: possible circular locking dependency detected
From: Rob Clark
Inspired by
https://lore.kernel.org/dri-devel/20200604081224.863494-10-daniel.vet...@ffwll.ch/
it seemed like a good idea to get rid of memory allocation in job_run()
fence signaling path, and use lockdep annotations to yell at us about
anything that could deadlock against
> -Original Message-
> From: Ruhl, Michael J
> Sent: August 22, 2023 7:44 AM
> To: Felix Kuehling ; Zeng, Oak ;
> Dave Airlie
> Cc: Brost, Matthew ; Thomas Hellström
> ; Philip Yang ;
> Welty, Brian ; dri-devel@lists.freedesktop.org;
> Christian
> König ; Vishwanathapura, Niranjana
> ;
DSI 6G v2.5.x+ and DPU support a data-bus widen mode that allows DSI
to send 48 bits of compressed data per pclk instead of 24.
For all chipsets that support this mode, enable it whenever DSC is
enabled as recommended by the hardware programming guide.
Only enable this for command mode as we are
DSI 6G v2.5.x+ supports a data-bus widen mode that allows DSI to send
48 bits of compressed data instead of 24.
Enable this mode whenever DSC is enabled for supported chipsets.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi.c | 2 +-
drivers/gpu/drm/msm/dsi/dsi.h | 1
Add a DATABUS_WIDEN bit to the MDP_CTRL2 register to allow DSI to enable
databus widen mode.
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h
Move the setting of dpu_enc::wide_bus_en to
dpu_encoder_virt_atomic_enable() so that it mirrors how dpu_enc::dsc
is being set.
Since wide bus for DSI is related to DSC, having it mirror how DSC
is set in DPU will also make it easier to accommodate for the possibility
of DSC for DSI being set
DPU supports a data-bus widen mode for DSI INTF.
Enable this mode for all supported chipsets if widebus is enabled for DSI.
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 2 ++
On 2023-08-22 13:03, Hamza Mahfooz wrote:
> As made mention of in commit 099303e9a9bd ("drm/amd/display: eDP
> intermittent black screen during PnP"), we need to turn off the
> display's backlight before powering off an eDP display. Not doing so
> will result in undefined behaviour according to
On 22/08/2023 16:54, Vinod Koul wrote:
> On 17-08-23, 13:05, Dmitry Baryshkov wrote:
>> On 08/08/2023 11:32, Sandor Yu wrote:
>>> Allow HDMI PHYs to be configured through the generic
>>> functions through a custom structure added to the generic union.
>>>
>>> The parameters added here are based on
On Tue, Aug 22, 2023 at 6:01 AM Christian König
wrote:
>
> Am 18.08.23 um 16:59 schrieb Rob Clark:
> > From: Rob Clark
> >
> > If a signal callback releases the sw_sync fence, that will trigger a
> > deadlock as the timeline_fence_release recurses onto the fence->lock
> > (used both for
As made mention of in commit 099303e9a9bd ("drm/amd/display: eDP
intermittent black screen during PnP"), we need to turn off the
display's backlight before powering off an eDP display. Not doing so
will result in undefined behaviour according to the eDP spec. So, set
DCN301's
On Tue, Aug 22, 2023 at 4:51 AM Christian König
wrote:
> Am 21.08.23 um 21:46 schrieb Faith Ekstrand:
>
> On Mon, Aug 21, 2023 at 1:13 PM Christian König
> wrote:
>
>> [SNIP]
>> So as long as nobody from userspace comes and says we absolutely need to
>> optimize this use case I would rather not
Account these pages against RLIMIT_MEMLOCK following how RDMA does this
with CAP_IPC_LOCK bypassing the limit.
v2:
- Change the naming of the accounting functions and WARN if we try
to account anything but userptr pages. (Matthew Brost)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew
Support pinning of vmas using XE_VM_BIND_FLAG_PIN, initially for userptr
only. Pinned memory becomes accounted against RLIMIT_MEMLOCK and processes
with CAP_IPC_LOCK will not apply the limit. This is pretty similar to
mlock()'ing userptr memory with the added benefit that the driver is
aware and
This series adds a flag at VM_BIND time to pin the memory backing a VMA.
Initially this is needed for long-running workloads on hardware that
neither support mid-thread preemption nor pagefaults, since without it
the userptr MMU notifier will wait for preemption until preemption times
out.
Moving
Implement pinning of userptrs between VM_BIND and VM_UNBIND, which will
facilitate avoiding long hangs on non-preemptible workloads. But don't
hook it up to userspace just yet.
v2:
- Avoid marking userptr VMAs as invalid in the mmu invalidation notifier.
(Matthew Brost)
- Add an WARN that we
Use onion error unwind since that makes the function easier to read
and extend. No functional change.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Brost
---
drivers/gpu/drm/xe/xe_vm.c | 37 +++--
1 file changed, 19 insertions(+), 18 deletions(-)
diff
The Toshiba documentation talks about HSByteClk when referring to the
DSI HS byte clock, whereas the driver uses 'dsibclk' name. Also, in a
few places the driver calculates the byte clock from the DSI clock, even
if the byte clock is already available in a variable.
To align the driver with the
The driver debug prints DSI related timings as raw register values in
hex. It is much more useful to see the "logical" value of the timing,
not the register value.
Change the prints to print the values separately, in case a single
register contains multiple values, and use %u to have it in a more
The TC358768 documentation uses HFP, HBP, etc. values to deal with the
video mode, while the driver currently uses the DRM display mode
(htotal, hsync_start, etc).
Change the driver to convert the DRM display mode to struct videomode,
which then allows us to use the same units the documentation
The tc358768_ns_to_cnt() is, most likely, supposed to do a div-round-up
operation, but it misses subtracting one from the dividend.
Fix this by just using DIV_ROUND_UP().
Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Reviewed-by: Peter Ujfalusi
Signed-off-by: Tomi Valkeinen
---
Simplify the code by capturing the priv->dev value to dev variable, and
use it.
Reviewed-by: Peter Ujfalusi
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358768.c | 41 ---
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git
The driver defines TC358768_PRECISION as 1000, and uses "nsk" to refer
to clock periods. The original author does not remember where all this
came from. Effectively the driver is using picoseconds as the unit for
clock periods, yet referring to them by "nsk".
Clean this up by just saying the
The DSI horizontal timing calculations done by the driver seem to often
lead to underflows or overflows, depending on the videomode.
There are two main things the current driver doesn't seem to get right:
DSI HSW and HFP, and VSDly. However, even following Toshiba's
documentation it seems we
From: Thierry Reding
The polarities of the V- and H-sync signals are encoded as flags in the
display mode, so use the existing information to setup the signals for
the RGB interface.
Signed-off-by: Thierry Reding
Cc: Thierry Reding
[tomi.valkei...@ideasonboard.com: default to positive sync]
As is quite common, some of TC358768's PLL register fields are to be
programmed with (value - 1). Specifically, the FBD and PRD, multiplier
and divider, are such fields.
However, what the driver currently does is that it considers that the
formula used for PLL rate calculation is:
RefClk * [(FBD
As the TC358768 is a DPI to DSI bridge, the DSI side does not need to
define h/v sync polarities. This means that sometimes we have a mode
without defined sync polarities, which does not work on the DPI side.
Add a mode_fixup hook to default to positive sync polarities.
Reviewed-by: Peter
The driver has a few places where it does:
if (thing_is_enabled_in_config)
update_thing_bit_in_hw()
This means that if the thing is _not_ enabled, the bit never gets
cleared. This affects the h/vsyncs and continuous DSI clock bits.
Fix the driver to always update the bit.
Fixes:
smatch reports:
drivers/gpu/drm/bridge/tc358768.c:223 tc358768_update_bits() error:
uninitialized symbol 'orig'.
Fix this by bailing out from tc358768_update_bits() if the
tc358768_read() produces an error.
Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver")
Reviewed-by: Peter Ujfalusi
This series contains various fixes and cleanups for TC358768. The target
of this work is to get TC358768 working on Toradex's AM62 based board,
which has the following display pipeline:
AM62 DPI -> TC358768 -> LT8912B -> HDMI connector
The main thing the series does is to improve the DSI HSW,
Hi Laurent and all,
Gentle ping. Are we happy with this patch series?
I will send follow up fixes if we find any issues later.
Cheers,
Biju
> Subject: RE: [PATCH v10 0/4] Add RZ/{G2L,G2LC} and RZ/V2L Display Unit
> support
>
> Hi Laurent and all,
>
> Gentle ping. Are we ok this patch series?
On 22/08/2023 01:22, Maxim Schwalm wrote:
Hi Tomi,
On 16.08.23 13:25, Tomi Valkeinen wrote:
The driver has a few places where it does:
if (thing_is_enabled_in_config)
update_thing_bit_in_hw()
This means that if the thing is _not_ enabled, the bit never gets
cleared. This affects the
On 22/08/2023 10:20, Pekka Paalanen wrote:
On Mon, 21 Aug 2023 17:55:33 +0200
Maxime Ripard wrote:
Hi Pekka,
Thanks for answering
On Fri, Aug 18, 2023 at 04:24:15PM +0300, Pekka Paalanen wrote:
On Thu, 10 Aug 2023 09:45:27 +0200
Maxime Ripard wrote:
On Mon, Aug 07, 2023 at 03:45:15PM
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:37 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com;
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com;
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:37 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com;
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com;
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com;
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com;
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com;
[Public]
> -Original Message-
> From: Sasha Levin
> Sent: Tuesday, August 22, 2023 7:36 AM
> To: linux-ker...@vger.kernel.org; sta...@vger.kernel.org
> Cc: Deucher, Alexander ; Kuehling, Felix
> ; Koenig, Christian ;
> Mike Lothian ; Sasha Levin ; Pan,
> Xinhui ; airl...@gmail.com;
On Tue, Aug 22, 2023 at 05:51:39PM +0300, Jani Nikula wrote:
> On Tue, 22 Aug 2023, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, Aug 22, 2023 at 04:16:08PM +0200, Daniel Vetter wrote:
> >> On Mon, Aug 14, 2023 at 03:56:12PM +0200, Maxime Ripard wrote:
> >> > Here's a series that creates a
On Tue, 22 Aug 2023, Maxime Ripard wrote:
> Hi,
>
> On Tue, Aug 22, 2023 at 04:16:08PM +0200, Daniel Vetter wrote:
>> On Mon, Aug 14, 2023 at 03:56:12PM +0200, Maxime Ripard wrote:
>> > Here's a series that creates a subclass of drm_connector specifically
>> > targeted at HDMI controllers.
>> >
On Tue, Aug 22, 2023 at 04:35:55PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Tue, Aug 22, 2023 at 04:16:08PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 14, 2023 at 03:56:12PM +0200, Maxime Ripard wrote:
> > > Here's a series that creates a subclass of drm_connector specifically
> > > targeted at
Hi,
On Tue, Aug 22, 2023 at 04:16:08PM +0200, Daniel Vetter wrote:
> On Mon, Aug 14, 2023 at 03:56:12PM +0200, Maxime Ripard wrote:
> > Here's a series that creates a subclass of drm_connector specifically
> > targeted at HDMI controllers.
> >
> > The idea behind this series came from a recent
On Tue, Aug 22, 2023 at 02:14:28PM +, Dong, Zhanjun wrote:
>
>
> > -Original Message-
> > From: Daniel Vetter
> > Sent: August 22, 2023 9:51 AM
> > To: Dong, Zhanjun
> > Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> > Harrison,
> > John C ; Andi Shyti ;
>
On 22/08/2023 16:19, Laurent Pinchart wrote:
On Tue, Aug 22, 2023 at 05:17:37PM +0300, Laurent Pinchart wrote:
Hi Dmitry,
Thank you for the patches.
On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote:
Supporting DP/USB-C can result in a chain of several transparent
bridges
On Tue, Aug 22, 2023 at 05:17:37PM +0300, Laurent Pinchart wrote:
> Hi Dmitry,
>
> Thank you for the patches.
>
> On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote:
> > Supporting DP/USB-C can result in a chain of several transparent
> > bridges (PHY, redrivers, mux, etc). This
> -Original Message-
> From: Daniel Vetter
> Sent: August 22, 2023 9:51 AM
> To: Dong, Zhanjun
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> Harrison,
> John C ; Andi Shyti ;
> Daniel Vetter
> Subject: Re: [PATCH v5] drm/i915: Avoid circular locking
Hi Dmitry,
Thank you for the patches.
On Thu, Aug 17, 2023 at 05:55:13PM +0300, Dmitry Baryshkov wrote:
> Supporting DP/USB-C can result in a chain of several transparent
> bridges (PHY, redrivers, mux, etc). This results in drivers having
> similar boilerplate code for such bridges.
What do
On Mon, Aug 14, 2023 at 03:56:12PM +0200, Maxime Ripard wrote:
> Hi,
>
> Here's a series that creates a subclass of drm_connector specifically
> targeted at HDMI controllers.
>
> The idea behind this series came from a recent discussion on IRC during
> which we discussed infoframes generation of
Ok. So it is already completed.
I have to find something else...
Thanks and regards,
Sharique
Am Di., 22. Aug. 2023 um 14:46 Uhr schrieb Jani Nikula <
jani.nik...@linux.intel.com>:
> On Tue, 22 Aug 2023, Sharq Mohammad wrote:
> > Hello All,
> >
> > I am a usual kernel developer, and wanted to
On 21/08/23 10:46, Matthew Auld wrote:
Hi,
On 21/08/2023 11:14, Arunpravin Paneer Selvam wrote:
The way now contiguous requests are implemented such that
the size rounded up to power of 2 and the corresponding order
block picked from the freelist.
In addition to the older method, the new
On Mon, Aug 07, 2023 at 07:09:31PM +0800, Qi Zheng wrote:
> Currently, the synchronize_shrinkers() is only used by TTM pool. It only
> requires that no shrinkers run in parallel.
>
> After we use RCU+refcount method to implement the lockless slab shrink,
> we can not use shrinker_rwsem or
On 17-08-23, 13:05, Dmitry Baryshkov wrote:
> On 08/08/2023 11:32, Sandor Yu wrote:
> > Allow HDMI PHYs to be configured through the generic
> > functions through a custom structure added to the generic union.
> >
> > The parameters added here are based on HDMI PHY
> > implementation practices.
On 17-08-23, 17:55, Dmitry Baryshkov wrote:
> Switch to using the new DRM_AUX_BRIDGE helper to create the
> transparent DRM bridge device instead of handcoding corresponding
> functionality.
Acked-by: Vinod Koul
--
~Vinod
On Fri, Aug 11, 2023 at 11:20:11AM -0700, Zhanjun Dong wrote:
> This attempts to avoid circular locking dependency between flush delayed
> work and intel_gt_reset.
> When intel_gt_reset was called, task will hold a lock.
> To cacel delayed work here, the _sync version will also acquire a lock,
>
śr., 16 sie 2023 o 11:08 Lukasz Majczak napisał(a):
>
> czw., 3 sie 2023 o 11:23 Lukasz Majczak napisał(a):
> >
> > Check mgr->mst_primary, before passing it to
> > the get_mst_branch_device_by_guid_helper(), otherwise NULL dereference
> > may occur in the call to memcpy() and cause:
> >
> >
On Fri, 18 Aug 2023, Ankit Nautiyal wrote:
> DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh.
> Fix the DSC RECEIVER CAP SIZE accordingly.
>
> Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define
> and missing SHIFT")
> Cc: Anusha Srivatsa
> Cc: Manasi Navare
Add spinlock protection to avoid race condition on vblank event
between mtk_drm_crtc_atomic_begin() and mtk_drm_finish_page_flip().
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Jason-JH.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 5 +
1
Am 18.08.23 um 16:59 schrieb Rob Clark:
From: Rob Clark
If a signal callback releases the sw_sync fence, that will trigger a
deadlock as the timeline_fence_release recurses onto the fence->lock
(used both for signaling and the the timeline tree).
To avoid that, temporarily hold an extra
Hi,
Aside from the discussion on the binding and the general architecture, I
have some comments there.
On Tue, Aug 22, 2023 at 04:59:48PM +0800, Liu Ying wrote:
> +int dpu_cf_init(struct dpu_soc *dpu, unsigned int index,
> + unsigned int id, enum dpu_unit_type type,
> +
On 8/22/2023 6:24 PM, Lazar, Lijo wrote:
On 8/22/2023 5:52 PM, Yadav, Arvind wrote:
On 8/22/2023 12:01 PM, Lazar, Lijo wrote:
On 8/21/2023 12:17 PM, Arvind Yadav wrote:
This patch adds a suspend function that will clear the GPU
power profile before going into suspend state.
v2:
- Add
On 8/22/2023 5:52 PM, Yadav, Arvind wrote:
On 8/22/2023 12:01 PM, Lazar, Lijo wrote:
On 8/21/2023 12:17 PM, Arvind Yadav wrote:
This patch adds a suspend function that will clear the GPU
power profile before going into suspend state.
v2:
- Add the new suspend function based on review
On Tue, 22 Aug 2023, Sharq Mohammad wrote:
> Hello All,
>
> I am a usual kernel developer, and wanted to contribute to the open source.
> I saw a small TODO list in the DRM graphics subsystem, with some tasks.
> So, just wanted to ask, is anyone working on the task:
> *Replace
1 - 100 of 180 matches
Mail list logo
