From: Hermes Wu
When HDCP negotiation with a repeater device.
Checking SHA V' matching must retry 3 times before restarting HDCP.
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/ite-it6505.c | 32 +++-
1 file changed, 19 insertions(+), 13 deletions(-)
diff --gi
From: Hermes Wu
When running the HDCP CTS test with UNIGRAF DPR-100.
KSV list must be read from DP_AUX_HDCP_KSV_FIFO in an AUX request,
and can not separate with multiple read requests.
The AUX operation command "CMD_AUX_GET_KSV_LIST" reads the KSV list
with AUX FIFO and is able to read DP_AUX_H
On 15/10/2024 21:35, Akhil P Oommen wrote:
> On Mon, Oct 14, 2024 at 09:40:13AM +0200, Krzysztof Kozlowski wrote:
>> On Sat, Oct 12, 2024 at 01:59:30AM +0530, Akhil P Oommen wrote:
>>> Update GPU node to include acd level values.
>>>
>>> Signed-off-by: Akhil P Oommen
>>> ---
>>> arch/arm64/boot/d
From: Hermes Wu
When starting HDCP authentication, HDCP encryption should be enabled
when R0'is checked.
Change encryption enables time at R0' ready.
The hardware HDCP engine trigger is changed and the repeater KSV fails
will restart HDCP.
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/i
From: Hermes Wu
A HDCP source device shall support max downstream to 127 devices.
Change definition MAX_HDCP_DOWN_STREAM_COUNT to 127
KSVs shall save for DRM blocked devices check.
This results in struct it6505 growth by ~0.5 KiB.
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/ite-it6505
From: Hermes Wu
DisplayPort AUX protocol supports I2C transport which is capable of
reading EDID or supports MCCS.
In drm_dp_helper, drm_dp_i2c_xfer() packs I2C requests into a
sequence of AUX requests.
it6505_aux_i2c_operation() is implemented to match drm_dp_i2c_xfer()
operactions.
it6505_aux_
This is a v6 patch-set.
There are lots of failure items while running HDCP CTS using UNIGRAF DPR-100.
In Order to fix those failures, HDCP flow needs to be changed.
The DisplayPort AUX protocol supports I2C transport.
In Order to support MCCS via the aux channel, the aux-i2c operation is added.
From: Hermes Wu
HDCP KSV list readback can choose to use AUX FIFO or
general data register.
For some DisplayPort devices, the KSV list must be read
in 5 byte boundaries.
The original AUX read command does not support these devices.
The AUX command operation control register "REG_AUX_CMD_REQ" use
From: Hermes Wu
When HDCP is activated,
a DisplayPort source receiving CP_IRQ from the sink
shall check Bstatus from DPCD and process the corresponding value
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/ite-it6505.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
dif
From: Hermes Wu
HDCP must disabled encryption and restart authentication after
waiting KSV for 5s.
The original method uses a counter in a waitting loop that may
wait much longer than it is supposed to.
Use time_after() for KSV wait timeout.
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/
From: Hermes Wu
The hardware AUX FIFO is 16 bytes
Change definition of AUX_FIFO_MAX_SIZE to 16
Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver")
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/ite-it6505.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/
From: Hermes Wu
The original AUX operation using data registers is limited to 4 bytes.
The AUX operation command CMD_AUX_I2C_EDID_READ uses AUX FIFO and
is capable of reading 16 bytes.
This improves the speed of EDID read.
Signed-off-by: Hermes Wu
---
drivers/gpu/drm/bridge/ite-it6505.c | 10 +
On 15/10/2024 21:13, Akhil P Oommen wrote:
> On Mon, Oct 14, 2024 at 09:39:01AM +0200, Krzysztof Kozlowski wrote:
>> On Sat, Oct 12, 2024 at 01:59:29AM +0530, Akhil P Oommen wrote:
>>> Add a new schema which extends opp-v2 to support a new vendor specific
>>> property required for Adreno GPUs found
On 15/10/2024 20:05, Adrián Larumbe wrote:
Hi Tvrtko,
On 10.10.2024 10:50, Tvrtko Ursulin wrote:
On 09/10/2024 23:55, Adrián Larumbe wrote:
Hi Tvrtko,
On 04.10.2024 14:41, Tvrtko Ursulin wrote:
Hi Adrian,
On 03/10/2024 00:45, Adrián Larumbe wrote:
Some drivers must allocate a considera
In commit 9f428b95ac89 ("drm/mediatek: Add new color format MACROs in
OVL"), some new color formats are defined in the MACROs to make the
switch statement more concise. That commit was intended to be a no-op
cleanup. However, there are typos in these formats MACROs, which cause
the return value to
Hi Andy, Ignore the message I'm answering to. I accidentally sent it
prematurely.
On Wednesday, October 16th, 2024 at 9:41 AM, Piotr Zalewski
wrote:
> Hi Andy,
>
> On Wednesday, October 16th, 2024 at 3:10 AM, Andy Yan andys...@163.com wrote:
>
> > Hi Piotr,
> >
> > At 2024-10-16 04:13:40,
At 2024-10-15T11:38:22-0700, Ian Rogers wrote:
> When /proc/pid/fdinfo was part of proc.5 man page the indentation made
> sense. As a standalone man page the indentation doesn't need to be so
> far over to the right.
>
> Signed-off-by: Ian Rogers
> ---
> man/man5/proc_pid_fdinfo.5 | 50 +
On 11/10/2024 16:41, Thomas Zimmermann wrote:
Include directly to get struct of_device_id.
Avoids the proxy include via
Signed-off-by: Thomas Zimmermann
Cc: Neil Armstrong
Cc: Jessica Zhang
---
drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 1 +
1 file changed, 1 insertion(+)
diff -
On 11/10/2024 16:41, Thomas Zimmermann wrote:
Include directly to get struct of_device_id.
Avoids the proxy include via
Signed-off-by: Thomas Zimmermann
Cc: Neil Armstrong
Cc: Jessica Zhang
---
drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 1 +
1 file changed, 1 insertion(+)
diff -
On 11/10/2024 16:41, Thomas Zimmermann wrote:
Include directly to get of_device_is_available(). Avoids
the proxy include via
Signed-off-by: Thomas Zimmermann
Cc: Neil Armstrong
Cc: Jessica Zhang
---
drivers/gpu/drm/drm_panel.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/g
On 11/10/2024 16:41, Thomas Zimmermann wrote:
Include directly to get device_property_read_u32().
Avoids the proxy include via
Signed-off-by: Thomas Zimmermann
Cc: Neil Armstrong
Cc: Jessica Zhang
---
drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 1 +
1 file changed, 1 insertion(+)
di
On Mon, Oct 14, 2024 at 08:52:01PM GMT, Jinjie Ruan wrote:
> As Maxime suggested, add a new helper
> drm_kunit_helper_display_mode_from_cea_vic(), it can replace
> the direct call of drm_display_mode_from_cea_vic(), and it will
> help solving the `mode` memory leaks.
>
> Suggested-by: Maxime Ripar
On Mon, Oct 14, 2024 at 08:52:02PM GMT, Jinjie Ruan wrote:
> modprobe drm_connector_test and then rmmod drm_connector_test,
> the following memory leak occurs.
>
> The `mode` allocated in drm_mode_duplicate() called by
> drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
>
On Mon, Oct 14, 2024 at 08:52:04PM GMT, Jinjie Ruan wrote:
> modprobe drm_hdmi_state_helper_test and then rmmod it, the following
> memory leak occurs.
>
> The `mode` allocated in drm_mode_duplicate() called by
> drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
>
>
On Wed, 16 Oct 2024 08:53:52 +0200
Boris Brezillon wrote:
> On Tue, 15 Oct 2024 22:29:45 +0100
> Liviu Dudau wrote:
>
> > On Tue, Oct 15, 2024 at 09:03:51AM +0200, Boris Brezillon wrote:
> > > Hi Liviu,
> > >
> > > On Tue, 15 Oct 2024 02:08:46 +0100
> > > Liviu Dudau wrote:
> > >
> > >
Hi,
On Mon, 14 Oct 2024 00:24:00 +0300, Danila Tikhonov wrote:
> This patch series adds support for the Samsung AMS581VF01 panel, used in
> the Google Pixel 4a (sm7150-google-sunfish). Unlike many other devices,
> which may use different panels in various revisions, the Pixel 4a has only
> one pos
Hi,
On Tue, 15 Oct 2024 15:34:38 +, Arnd Bergmann wrote:
> The new driver needs the dsc helper code to be available:
>
> x86_64-linux-ld: vmlinux.o: in function `s6e3ha8_amb577px01_wqhd_prepare':
> panel-samsung-s6e3ha8.c:(.text+0x16b1e65): undefined reference to
> `drm_dsc_pps_payload_pack'
On Wed, Oct 16, 2024 at 08:27:51AM +0200, Thomas Hellström wrote:
> On Wed, 2024-10-16 at 03:18 +, Matthew Brost wrote:
> > On Wed, Oct 09, 2024 at 12:50:42PM +0200, Thomas Hellström wrote:
> > > Hi, Matthew.
> > >
> > > Some comments below around migrating to SRAM.
> > >
> > >
> > > On Tue,
Il 15/10/24 15:28, Rob Herring ha scritto:
On Mon, Oct 14, 2024 at 10:51:48AM +0200, AngeloGioacchino Del Regno wrote:
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for
On Tue, Oct 08, 2024 at 01:34:57PM -0500, Lucas De Marchi wrote:
> +static int parse_device(const char __user *ubuf, size_t size, u32 *instance)
> +{
> + char buf[16];
> + ssize_t len;
> +
> + if (size > sizeof(buf) - 1)
> + return -E2BIG;
> +
> + len = strncpy_from_user
Provide a helper to shrink ttm_tt page-vectors on a per-page
basis. A ttm_backup backend could then in theory get away with
allocating a single temporary page for each struct ttm_tt.
This is accomplished by splitting larger pages before trying to
back them up.
In the future we could allow ttm_bac
Use fault-injection to test partial TTM swapout and interrupted swapin.
Return -EINTR for swapin to test the callers ability to handle and
restart the swapin, and on swapout perform a partial swapout to test that
the swapin and release_shrunken functionality.
v8:
- Use the core fault-injection sys
Following the design direction communicated here:
https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/#ma918844aa8a6efe8768fdcda0c6590d5c93850c9
Export a LRU walker for driver shrinker use. The walker
initially supports only trylocking, since that's the
method used by
https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/
Where the comment about layering
https://lore.kernel.org/linux-mm/b7491378-defd-4f1c-31e2-29e4c77e2...@amd.com/T/#ma918844aa8a6efe8768fdcda0c6590d5c93850c9
now addressed, and this version also implements shmem object
Make the interface more symmetric by providing and using a
ttm_resource_cursor_init().
v10:
- Fix a stray newline (Matthew Brost)
- Update kerneldoc (Matthew Brost)
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Brost
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c |
Initially intended for experimenting with different backup
solutions (shmem vs direct swap cache insertion), abstract
the backup destination using a virtual base class.
Also provide a sample implementation for shmem.
While when settling on a preferred backup solution, one could
perhaps skip the a
Rather than relying on the TTM watermark accounting add a shrinker
for xe_bos in TT or system memory.
Leverage the newly added TTM per-page shrinking and shmem backup
support.
Although xe doesn't fully support WONTNEED (purgeable) bos yet,
introduce and add shrinker support for purgeable ttm_tts.
The XE_PL_TT watermark was set to 50% of system memory.
The idea behind that was unclear since the net effect is that
TT memory will be evicted to TTM_PL_SYSTEM memory if that
watermark is exceeded, requiring PPGTT rebinds and dma
remapping. But there is no similar watermark for TTM_PL_1SYSTEM
memo
Add a number of helpers for shrinking that access core TTM and
core MM functionality in a way that make them unsuitable for
driver open-coding.
v11:
- New patch (split off from previous) and additional helpers.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_backup_shmem.c | 23
There is a spelling mistake in a dm_error message. Fix it.
Signed-off-by: Colin Ian King
---
.../gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c
b/d
Hi Adrián,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-misc/drm-misc-next]
[also build test ERROR on linus/master v6.12-rc3 next-20241016]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Andy,
On Wednesday, October 16th, 2024 at 3:10 AM, Andy Yan wrote:
> Hi Piotr,
>
> At 2024-10-16 04:13:40, "Piotr Zalewski" pz010001011...@proton.me wrote:
>
> > Hi Andy
> >
> > On Tuesday, October 15th, 2024 at 2:22 PM, Andy Yan andys...@163.com wrote:
> >
> > > > > > + struct vop2_video
On Wed, 2024-10-16 at 08:41 +0100, Tvrtko Ursulin wrote:
>
> On 15/10/2024 15:00, Philipp Stanner wrote:
> > > [...]
> > > How about this:
> > >
> > > """
> > > In FIFO mode (which is the default), both
> > > drm_sched_entity_push_job()
> > > and drm_sched_rq_update_fifo(), where the latter calls
On Wed Oct 16, 2024 at 11:16 AM CEST, Piotr Zalewski wrote:
> I will rework it to[1] and test it. (Have to check if hdmi out on pt2 works).
Last time I tried it, hdmi out did work.
signature.asc
Description: PGP signature
Il 15/10/24 15:48, Rob Herring ha scritto:
On Tue, Oct 15, 2024 at 10:32:22AM +0200, AngeloGioacchino Del Regno wrote:
Il 14/10/24 19:36, Rob Herring ha scritto:
On Mon, Oct 14, 2024 at 3:51 AM AngeloGioacchino Del Regno
wrote:
The display IPs in MediaTek SoCs support being interconnected wi
Hi Andy,
> >
> > static void vop2_crtc_atomic_flush(struct drm_crtc *crtc,
> > @@ -2790,7 +2945,13 @@ static int vop2_create_crtcs(struct vop2 *vop2)
> > }
> >
> > drm_crtc_helper_add(&vp->crtc, &vop2_crtc_helper_funcs);
> > + if (vop2->lut_regs && vp->crtc.dev != NULL) {
>
>
>
> There is no
Hi Diederik
On Wednesday, October 16th, 2024 at 11:20 AM, Diederik de Haas
wrote:
> On Wed Oct 16, 2024 at 11:16 AM CEST, Piotr Zalewski wrote:
>
> > I will rework it to[1] and test it. (Have to check if hdmi out on pt2
> > works).
>
>
> Last time I tried it, hdmi out did work.
Nice, thank
Hello,
On Thu, Oct 10, 2024 at 01:40:51AM +0300, Cristian Ciocaltea wrote:
> +struct platform_driver dw_hdmi_qp_rockchip_pltfm_driver = {
> + .probe = dw_hdmi_qp_rockchip_probe,
> + .remove_new = dw_hdmi_qp_rockchip_remove,
> + .driver = {
> + .name = "dwhdmiqp-rockchip",
On 15/10/2024 15:00, Philipp Stanner wrote:
On Tue, 2024-10-15 at 14:14 +0100, Tvrtko Ursulin wrote:
On 15/10/2024 12:38, Philipp Stanner wrote:
On Tue, 2024-10-15 at 09:12 +0100, Tvrtko Ursulin wrote:
On 15/10/2024 08:11, Philipp Stanner wrote:
On Mon, 2024-10-14 at 13:07 +0100, Tvrtko U
Hi Andy,
On Wednesday, October 16th, 2024 at 3:10 AM, Andy Yan wrote:
> Hi Piotr,
>
> At 2024-10-16 04:13:40, "Piotr Zalewski" pz010001011...@proton.me wrote:
>
> > Hi Andy
> >
> > On Tuesday, October 15th, 2024 at 2:22 PM, Andy Yan andys...@163.com wrote:
> >
> > > > > > + struct vop2_video
On 16/10/2024 7:49, Christoph Hellwig wrote:
The subject does not make sense. All P2P is on ZONE_DEVICE pages.
It seems like this is about device private memory?
Correct, thanks, I will change it to `mm/hmm: HMM API to enable P2P DMA
for device private pages`, on v2.
On Tue, Oct 15, 2024
Hi Jyothi,
...
> @@ -523,26 +576,49 @@ static int geni_i2c_gpi(struct geni_i2c_dev *gi2c,
> struct i2c_msg *msg,
> enum dma_transfer_direction dma_dirn;
> struct dma_async_tx_descriptor *desc;
> int ret;
> + struct gpi_multi_xfer *gi2c_gpi_xfer;
> + dma_cookie_t cookie;
On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> Create a i915 private plane property for sharing the async supported
> modifiers to the user.
> UMD related discussion requesting the same
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29618#note_2487123
>
> Signed-off-
On Wed, Oct 16, 2024 at 7:10 PM Hsin-Te Yuan wrote:
>
> In commit 9f428b95ac89 ("drm/mediatek: Add new color format MACROs in
> OVL"), some new color formats are defined in the MACROs to make the
> switch statement more concise. That commit was intended to be a no-op
> cleanup. However, there are
On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
> +/**
> + * enum drm_panthor_sync_op_flags - Synchronization operation flags.
> + */
> +enum drm_panthor_sync_op_flags {
> + /** @DRM_PANTHOR_SYNC_OP_HANDLE_TYPE_MASK: Synchronization
> handle type mask. */
> + DRM_PANTHOR_SYNC_OP_H
Am 14.10.24 um 23:56 schrieb Deucher, Alexander:
[AMD Official Use Only - AMD Internal Distribution Only]
-Original Message-
From: Zhang, Jesse(Jie)
Sent: Friday, October 11, 2024 9:45 PM
To: Koenig, Christian ; dri-
de...@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Deuche
From: Tvrtko Ursulin
Current kerneldoc for struct drm_sched_rq incompletely documents what
fields are protected by the lock.
This is not good because it is misleading.
Lets fix it by listing all the elements which are protected by the lock.
While at it, lets also re-order the members so all pr
From: Tvrtko Ursulin
Leftovers from the earlier "DRM scheduler fixes and improvements" series.
It looks the fixes have now propagated back to drm-misc-next so this should now
be mergeable.
It also needed a small rebase to account for one revert and one spelling fix
which landed in the meantime.
From: Tvrtko Ursulin
Having removed one re-lock cycle on the entity->lock in a patch titled
"drm/sched: Optimise drm_sched_entity_push_job", with only a tiny bit
larger refactoring we can do the same optimisation on the rq->lock.
(Currently both drm_sched_rq_add_entity() and
drm_sched_rq_update_f
From: Tvrtko Ursulin
It does not seem there is a need to set the current entity in FIFO mode
since ot only serves as being a "cursor" in round-robin mode. Even if
scheduling mode is changed at runtime the change in behaviour is simply
to restart from the first entity, instead of continuing in RR
From: Tvrtko Ursulin
When writing to a drm_sched_entity's run-queue, writers are protected
through the lock drm_sched_entity.rq_lock. This naming, however,
frequently collides with the separate internal lock of struct
drm_sched_rq, resulting in uses like this:
spin_lock(&entity->rq_lock)
From: Tvrtko Ursulin
In FIFO mode (which is the default), both drm_sched_entity_push_job() and
drm_sched_rq_update_fifo(), where the latter calls the former, are
currently taking and releasing the same entity->rq_lock.
We can avoid that design inelegance, and also have a miniscule
efficiency imp
On Tue, Oct 15, 2024 at 09:49:30PM -0700, Christoph Hellwig wrote:
> > + /*
> > +* Used for private (un-addressable) device memory only. Return a
> > +* corresponding struct page, that can be mapped to device
> > +* (e.g using dma_map_page)
> > +*/
> > + struct page *(*get_dma_
On Wed, Oct 16, 2024 at 04:10:53PM +1100, Alistair Popple wrote:
> On that note how is the refcounting of the returned p2pdma page expected
> to work? We don't want the driver calling hmm_range_fault() to be able
> to pin the page with eg. get_page(), so the returned p2pdma page should
> have a zer
Am 15.10.24 um 01:31 schrieb Adrián Larumbe:
Doesn't make any functional difference because generic dma_fence is the
first panfrost_fence structure member, but I guess it doesn't hurt either.
As discussed with Sima we want to push into the exactly opposite
direction because that requires that
Applied. Thanks!
On Wed, Oct 16, 2024 at 5:18 AM Colin Ian King wrote:
>
> There is a spelling mistake in a dm_error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> .../gpu/drm/amd/display/dc/link/protocols/link_dp_capability.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-
On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
> On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
> > +/**
> > + * enum drm_panthor_sync_op_flags - Synchronization operation
> > flags.
> > + */
> > +enum drm_panthor_sync_op_flags {
> > + /** @DRM_PANTHOR_SYNC_OP_HANDLE_TYPE_MAS
On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> > Create a i915 private plane property for sharing the async supported
> > modifiers to the user.
> > UMD related discussion requesting the same
> > https://gitlab.freed
On 16/10/2024 7:23, Christoph Hellwig wrote:
On Tue, Oct 15, 2024 at 06:23:44PM +0300, Yonatan Maman wrote:
From: Yonatan Maman
This patch series aims to enable Peer-to-Peer (P2P) DMA access in
GPU-centric applications that utilize RDMA and private device pages. This
enhancement is crucial
On 16/10/2024 8:12, Alistair Popple wrote:
Yonatan Maman writes:
From: Yonatan Maman
Enabling Peer-to-Peer DMA (P2P DMA) access in GPU-centric applications
is crucial for minimizing data transfer overhead (e.g., for RDMA use-
case).
This change aims to enable that capability for Nouveau
Il 16/10/24 16:00, Rob Herring ha scritto:
On Wed, Oct 16, 2024 at 4:23 AM AngeloGioacchino Del Regno
wrote:
Il 15/10/24 15:48, Rob Herring ha scritto:
On Tue, Oct 15, 2024 at 10:32:22AM +0200, AngeloGioacchino Del Regno wrote:
Il 14/10/24 19:36, Rob Herring ha scritto:
On Mon, Oct 14, 2024
On Wed, 16 Oct 2024 16:05:55 +0200
Erik Faye-Lund wrote:
> On Wed, 2024-10-16 at 15:02 +0100, Robin Murphy wrote:
> > On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
> > > On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
> > > > On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
On Wed, 2024-10-16 at 15:02 +0100, Robin Murphy wrote:
> On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
> > On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
> > > On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
> > > > +/**
> > > > + * enum drm_panthor_sync_op_flags - Synchronizatio
On 16.10.2024 15:12, Christian König wrote:
> Am 15.10.24 um 01:31 schrieb Adrián Larumbe:
> > Doesn't make any functional difference because generic dma_fence is the
> > first panfrost_fence structure member, but I guess it doesn't hurt either.
>
> As discussed with Sima we want to push into the
Hi Dave,
A few fixes for v6.12, see description below
The following changes since commit 15302579373ed2c8ada629e9e7bcf9569393a48d:
drm/msm/dpu: enable writeback on SM6350 (2024-09-02 02:53:44 +0300)
are available in the Git repository at:
https://gitlab.freedesktop.org/drm/msm.git tags/drm
On Mon, Oct 14, 2024 at 09:25:19PM +0200, Peter Zijlstra wrote:
> Let me ponder that a little bit.
So I did the thing on top of the get/put thing that would allow you to
get rid of the ->closed thing, and before I was finished I already hated
all of it :-(
The thing is, if you're going to the ef
On 10/8/24 11:10 PM, Kees Bakker wrote:
Op 03-10-2024 om 18:12 schreef Antonino Maniscalco:
Add trace points corresponding to preemption being triggered and being
completed for latency measurement purposes.
Reviewed-by: Akhil P Oommen
Tested-by: Rob Clark
Tested-by: Neil Armstrong # on SM865
On 10/16/24 13:08, Hsin-Te Yuan wrote:
In commit 9f428b95ac89 ("drm/mediatek: Add new color format MACROs in
OVL"), some new color formats are defined in the MACROs to make the
switch statement more concise. That commit was intended to be a no-op
cleanup. However, there are typos in these form
Hi all,
On Wed, 16 Oct 2024 at 02:11, Andy Yan wrote:
> At 2024-10-16 04:13:40, "Piotr Zalewski" wrote:
> >Ok I get it now. Is such rework correct? - when gamma LUT for rk356x is
> >being set, instead of disabling the LUT before the gamma LUT write for the
> >current CRTC's video port, active vi
wed-by tag
- Link to v2:
https://lore.kernel.org/r/20241016-color-v2-1-46db5c78a...@chromium.org
Changes in v2:
- Clarify that the commit get fixed was intended to be a no-op cleanup
- Fix the typo in tag
- Link to v1:
https://lore.kernel.org/r/20241015-color-v1-1-35b01fa0a...@chromium.org
On Wed, Oct 16, 2024 at 10:26 AM AngeloGioacchino Del Regno
wrote:
>
> Il 16/10/24 16:00, Rob Herring ha scritto:
> > On Wed, Oct 16, 2024 at 4:23 AM AngeloGioacchino Del Regno
> > wrote:
> >>
> >> Il 15/10/24 15:48, Rob Herring ha scritto:
> >>> On Tue, Oct 15, 2024 at 10:32:22AM +0200, AngeloGi
On Tue, Oct 15, 2024 at 03:33:00PM GMT, Krzysztof Kozlowski wrote:
> On 15/10/2024 14:07, Jyothi Kumar Seerapu wrote:
> > When high performance with multiple i2c messages in a single transfer
> > is required, employ Block Event Interrupt (BEI) to trigger interrupts
> > after specific messages trans
On 2024-10-16 2:50 pm, Erik Faye-Lund wrote:
On Wed, 2024-10-16 at 15:16 +0200, Erik Faye-Lund wrote:
On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
+/**
+ * enum drm_panthor_sync_op_flags - Synchronization operation
flags.
+ */
+enum drm_panthor_sync_op_flags {
+ /** @DRM_PANT
On Wed, 2024-10-16 at 15:47 +0200, Boris Brezillon wrote:
> On Wed, 16 Oct 2024 15:16:22 +0200
> Erik Faye-Lund wrote:
>
> > On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
> > > +/**
> > > + * enum drm_panthor_sync_op_flags - Synchronization operation
> > > flags.
> > > + */
> > > +enu
On Wed, Oct 16, 2024 at 4:23 AM AngeloGioacchino Del Regno
wrote:
>
> Il 15/10/24 15:48, Rob Herring ha scritto:
> > On Tue, Oct 15, 2024 at 10:32:22AM +0200, AngeloGioacchino Del Regno wrote:
> >> Il 14/10/24 19:36, Rob Herring ha scritto:
> >>> On Mon, Oct 14, 2024 at 3:51 AM AngeloGioacchino De
On Wed, Oct 16, 2024 at 04:54:09PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2024 at 04:30:19PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 16, 2024 at 11:06:26AM +0530, Arun R Murthy wrote:
> > > Create a i915 private plane property for sharing the async supported
> > > modifiers to the user.
On Wed, 16 Oct 2024 15:16:22 +0200
Erik Faye-Lund wrote:
> On Thu, 2024-02-29 at 17:22 +0100, Boris Brezillon wrote:
> > +/**
> > + * enum drm_panthor_sync_op_flags - Synchronization operation flags.
> > + */
> > +enum drm_panthor_sync_op_flags {
> > + /** @DRM_PANTHOR_SYNC_OP_HANDLE_TYPE_MASK:
On Mon, 2024-10-14 at 14:22 +, Matt Coster wrote:
> From: Brendan King
>
> This adds a linked list of VM contexts which is needed for the next patch
> to be able to correctly track VM contexts for destruction on file close.
>
> It is only safe for VM contexts to be removed from the list and
On Mon, 2024-10-14 at 14:23 +, Matt Coster wrote:
> From: Brendan King
>
> When remaining resources are being cleaned up on driver close,
> outstanding VM mappings may result in resources being leaked, due
> to an object reference loop, as shown below, with each object (or
> set of objects) r
As Maxime suggested, add a new helper
drm_kunit_display_mode_from_cea_vic(), it can replace the direct call
of drm_display_mode_from_cea_vic(), and it will help solving
the `mode` memory leaks.
Acked-by: Maxime Ripard
Suggested-by: Maxime Ripard
Signed-off-by: Jinjie Ruan
---
v3:
- Adjust drm/d
modprobe drm_connector_test and then rmmod drm_connector_test,
the following memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xff80cb0ee400 (size 128):
c
Fix some memory leaks in drm tests.
Changes in v3:
- Adjust drm/drm_edid.h header to drm_kunit_helpers.c.
- Drop the "helper" in the helper name.
- s/fllowing/following/
- Add Acked-by.
Changes in v2:
- Fix it with new introduced helper instead of drm_mode_destroy().
- Update the commit message.
modprobe ttm_device_test and then rmmod ttm_device_test, the following
memory leaks occurs:
The ttm->pages allocated in ttm_tt_init() is not freed after calling
ttm_tt_simple_create(), which cause the memory leak:
unreferenced object 0xff80caf27750 (size 8):
comm "kunit_try_
modprobe drm_hdmi_state_helper_test and then rmmod it, the following
memory leak occurs.
The `mode` allocated in drm_mode_duplicate() called by
drm_display_mode_from_cea_vic() is not freed, which cause the memory leak:
unreferenced object 0xff80ccd18100 (size 128):
comm "kun
On Wed, Oct 16, 2024 at 09:53:58AM +0200, Krzysztof Kozlowski wrote:
> On 15/10/2024 21:13, Akhil P Oommen wrote:
> > On Mon, Oct 14, 2024 at 09:39:01AM +0200, Krzysztof Kozlowski wrote:
> >> On Sat, Oct 12, 2024 at 01:59:29AM +0530, Akhil P Oommen wrote:
> >>> Add a new schema which extends opp-v2
Matthew Brost writes:
> On Thu, Oct 17, 2024 at 02:21:13PM +1100, Alistair Popple wrote:
>>
>> Matthew Brost writes:
>>
>> > On Thu, Oct 17, 2024 at 12:49:55PM +1100, Alistair Popple wrote:
>> >>
>> >> Matthew Brost writes:
>> >>
>> >> > On Wed, Oct 16, 2024 at 04:46:52AM +, Matthew B
Hi everyone,
Am Freitag, 27. September 2024, 01:13:57 CEST schrieb Dmitry Baryshkov:
> On Thu, Sep 26, 2024 at 04:09:03PM GMT, Alexander Stein wrote:
> > Hi Dmitry,
> >
> > Am Donnerstag, 26. September 2024, 08:05:56 CEST schrieb Dmitry Baryshkov:
> > > On Thu, Sep 26, 2024 at 07:55:51AM GMT, Ale
2250.07e1c...@canb.auug.org.au/
Cc: David Airlie
Cc: Simona Vetter
Cc: Thomas Zimmermann
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Thomas Zimmermann
---
Cc: patc...@lists.linux.dev
Documentation/gpu/drm-kms-helpers.rst |9 -
1 file changed, 9 deletions(-)
--- linux-next-202
On Wed, Oct 16, 2024 at 09:50:04AM +0200, Krzysztof Kozlowski wrote:
> On 15/10/2024 21:35, Akhil P Oommen wrote:
> > On Mon, Oct 14, 2024 at 09:40:13AM +0200, Krzysztof Kozlowski wrote:
> >> On Sat, Oct 12, 2024 at 01:59:30AM +0530, Akhil P Oommen wrote:
> >>> Update GPU node to include acd level
On 10/14/24 19:13, Matthew Brost wrote:
On Fri, Oct 11, 2024 at 04:12:41PM -0700, Lizhi Hou wrote:
Add interfaces for user application to submit command and wait for its
completion.
Co-developed-by: Min Ma
Signed-off-by: Min Ma
Signed-off-by: Lizhi Hou
---
drivers/accel/amdxdna/aie2_ctx.
1 - 100 of 168 matches
Mail list logo
