On 2023-02-16 04:22:13, Dmitry Baryshkov wrote:
> On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
> wrote:
> >
> > DPU's catalog never assigned dpu_scaler_blk::version leading to
> > initialization code in dpu_hw_setup_scaler3 to wander the wrong
> > codepaths. Instead of hardcoding the correct QSEE
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/John-C-Harrison-Intel-com/drm-i915-Don-t-use-stolen-memory-for-ring-buffers-with-LLC/20230216-082552
base: git://anongit.freedesktop.org
On 2023-02-16 05:02:32, Dmitry Baryshkov wrote:
> On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
> wrote:
> >
> > Random inspection of the SSPP code surfaced that the version field of
> > dpu_scaler_blk was never assigned in the catalog, resulting in wrong
> > codepaths to be taken within dpu_hw_set
On Wed, 15 Feb 2023 17:03:54 +
Simon Ser wrote:
> On Wednesday, February 15th, 2023 at 14:41, Pekka Paalanen
> wrote:
>
> > I didn't know it was at all possible to have different GEM handles
> > pointing to the same object. DMABUF import is guaranteed to return the
> > existing GEM handle,
Hi Dave, Daniel,
Here's this week drm-misc-fixes PR.
Maxime
drm-misc-fixes-2023-02-16:
Multiple fixes in vc4 to address issues with YUV planes, HDMI and CRTC;
an invalid page access fix for fbdev, mark dynamic debug as broken, a
double free and refcounting fix for vmwgfx.
The following changes s
From: Tvrtko Ursulin
As the logic for selecting the register and corresponsing values grew, the
code become a bit unsightly. Consolidate by storing the required values at
engine init time in the engine itself, and by doing so minimise the amount
of invariant platform and engine checks during each
On Thursday, February 16th, 2023 at 10:11, Pekka Paalanen
wrote:
> Btw. does this also mean that if you use GETFB2 to get handle A, you
> export that as dmabuf and import in the same open device instance, you
> again get handle A?
I haven't tested it, but I believe that is correct.
> IOW, you
On Thu, 26 Jan 2023 18:05:46 +0100, Maxime Ripard wrote:
> In order to accomodate the Pi0-3 using the clk-bcm2835 and the Pi4 using the
> clk-raspberrypi clock drivers for the HDMI clocks, we piled a number of
> workarounds over the years.
>
> Since 6.2, we've switched the Pi0-3 to the clk-raspber
The 2023 X.Org Foundation elections are rapidly approaching. We will be
forwarding the election schedule and nominating process to the
membership shortly.
Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
u
hi,
On 2/15/23 00:43, Sascha Hauer wrote:
On Mon, Feb 13, 2023 at 04:11:46PM +0900, FUKAUMI Naoki wrote:
hi,
on my rk3399 boards(ROCK Pi 4B+ and ROCK 4C+), fb0 is configured as
1920x1080, and nothing is displayed... "no signal" on display.
I can confirm this.
First of all there is a stupid
From 4fe34831e2e7677b1c9616356f0a2e0a36ec092f Mon Sep 17 00:00:00 2001
From: Jesper Juhl
Date: Thu, 16 Feb 2023 02:33:05 +0100
Subject: [PATCH] Don't test for NULL firmware before releasing
release_firmware() tests for a NULL pointer itself, no need to do it up-front.
Signed-off-by: Jesper Juh
From: Alexandr Sapozhnikov
After having been compared to NULL value at cirrus.c:455, pointer
'pipe->plane.state->fb' is passed as
1st parameter in call to function 'cirrus_fb_blit_rect' at cirrus.c:461, where
it is dereferenced at cirrus.c:316.
Found by Linux Verification Center (linuxtesting.
We are seeking nominations for candidates for election to the X.Org
Foundation Board of Directors. All X.Org Foundation members are eligible
for election to the board.
Nominations for the 2023 election are now open and will remain open
until 23:59 UTC on 19 March 2023.
The Board consists of direc
The driver checks if the pixel clock of the given mode matches an entry
in the mpll config table. At least for the Synopsys phy the frequencies
in the mpll table are meant as a frequency range up to which the entry
works, not as a frequency that must match the pixel clock. Return
MODE_OK when the p
One small fix compared to the last version, when checking for valid
resolutions I accidently compared the current mode width with the
maximum allowed height which resulted in wrong resolutions being
discarded.
Changes since v5:
- Fix wrong check width vs. height
Changes since v4:
- Use struct vop
This adds the PLL/phy settings to support higher resolutions like 4k@30.
The values were taken from the Rockchip downstream Kernel.
Tested-by: Michael Riesch
Link: https://lore.kernel.org/r/20220926080435.259617-3-s.ha...@pengutronix.de
Tested-by: Nicolas Frattaroli
Tested-by: Dan Johansen
Link
The different VOP variants support different maximum resolutions. Reject
resolutions that are not supported by a specific variant.
This hasn't been a problem in the upstream driver so far as 1920x1080
has been the maximum resolution supported by the HDMI driver and that
resolution is supported by
The Rockchip PLL drivers are currently table based and support only
the most common pixelclocks. Discard all modes we cannot achieve
at all. Normally the desired pixelclocks have an exact match in the
PLL driver, nevertheless allow for a 0.1% error just in case.
Tested-by: Nicolas Frattaroli
Test
Hi
On Sun, Feb 12, 2023 at 10:44:45PM +0200, Oded Gabbay wrote:
> irqreturn_t hl_irq_handler_user_interrupt(int irq, void *arg)
> +{
> + return IRQ_WAKE_THREAD;
> +}
This is not needed. You can pass NULL to request_threaded_irq() and
the irq core will use irq_default_primary_handler() which
kobj);
> }
>
> -static struct kobj_type kobj_engine_type = {
> +static const struct kobj_type kobj_engine_type = {
> .release = kobj_engine_release,
> .sysfs_ops = &kobj_sysfs_ops
> };
>
> ---
> base-commit: 033c40a89f55525139fd5b6342281b09b97d05bf
> change-id: 20230216-kobj_type-i915-886bebc36129
>
> Best regards,
--
Jani Nikula, Intel Open Source Graphics Center
Hi Dave and Daniel,
here's the PR for drm-misc-next-fixes for this week.
Best regards
Thomas
drm-misc-next-fixes-2023-02-16:
Short summary of fixes pull:
Contains fixes for DP MST and the panel orientation on an Lenovo
IdeaPad model.
The following changes since commit 467fbc77f673ecc9dcf4e58ffc
On Sun, Feb 12, 2023 at 10:44:45PM +0200, Oded Gabbay wrote:
> - rc = request_irq(irq, irq_handler, 0, gaudi2_irq_name(i),
> &hdev->user_interrupt[j]);
> + rc = request_threaded_irq(irq, irq_handler,
> hl_irq_user_interrupt_thread_handler,
> + I
On Sun, Feb 12, 2023 at 22:45 Oded Gabbay wrote:
> Move the cdev creation code from the main hdev init function to
> a separate function. This will make the code more readable once we
> add the accel registration code (instead/in addition to legacy
> cdev).
>
> Signed-off-by: Oded Gabbay
Review
On Sun, Feb 12, 2023 at 22:45 Oded Gabbay wrote:
> It is more concise than to pass it to device init. Once we will add the
> accel class, then we won't need to change the function signatures.
>
> Signed-off-by: Oded Gabbay
Reviewed-by: Tomer Tayar
On Sun, Feb 12, 2023 at 22:45 Oded Gabbay wrote:
> Make it easier to later add support for accel device.
>
> Signed-off-by: Oded Gabbay
Reviewed-by: Tomer Tayar
On Sun, Feb 12, 2023 at 10:44:28PM +0200, Oded Gabbay wrote:
> @@ -3178,11 +3181,12 @@ static int ts_buff_get_kernel_ts_record(struct
> hl_mmap_mem_buf *buf,
>
> /* irq handling in the middle give it time to finish */
> spin_unlock_irqrestore(wait_list
From: Tvrtko Ursulin
In i915 we have this concept of "wait boosting" where we give a priority boost
for instance to fences which are actively waited upon from userspace. This has
it's pros and cons and can certainly be discussed at lenght. However fact is
some workloads really like it.
Problem i
From: Tvrtko Ursulin
Use the previously added initialization helper to ensure correct operation
of the common code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 2 +-
drivers/gpu/drm/i915/i915_active.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --g
From: Tvrtko Ursulin
Unhide some i915 helpers which are used for splitting the signalled
check vs notification stages during en masse fence processing.
Signed-off-by: Tvrtko Ursulin
---
drivers/dma-buf/dma-fence.c | 35 +++--
drivers/gpu/drm/i915/gt/intel_breadc
From: Tvrtko Ursulin
Use the previously added initialization helper to ensure correct operation
of the common code.
Signed-off-by: Tvrtko Ursulin
Cc: Zack Rusin
---
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx
From: Tvrtko Ursulin
In preparation of adding a new field to struct dma_fence_cb we will need
an initialization helper for those callers who add callbacks by open-
coding. That will ensure they initialize all the fields so common code
does not get confused by potential garbage in some fields.
Si
From: Tvrtko Ursulin
Track how many callers are explicity waiting on a fence to signal and
allow querying that via new dma_fence_wait_count() API.
This provides infrastructure on top of which generic "waitboost" concepts
can be implemented by individual drivers. Wait-boosting is any reactive
act
From: Tvrtko Ursulin
Use the previously added dma-fence API to mark the direct i915 waits as
explicit. This has no significant effect apart from following the new
pattern.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
From: Tvrtko Ursulin
Use the newly added dma-fence API to apply waitboost not only requests
which have been marked with I915_WAIT_PRIORITY by i915, but which may be
waited upon by others (such as for instance buffer sharing in multi-GPU
scenarios).
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu
From: Tvrtko Ursulin
Use the previously added dma-fence tracking of explicit waiters.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_syncobj.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 0c
From: Tvrtko Ursulin
Userspace waits coming via the drm_syncobj route have so far been
bypassing the waitboost mechanism.
Use the previously added dma-fence wait tracking API and apply the
same waitboosting logic which applies to other entry points.
This should fix the perfomance regressions ex
The stuff never really worked, and leads to lots of fun because it
out-of-order frees atomic states. Which upsets KASAN, among other
things.
For async updates we now have a more solid solution with the
->atomic_async_check and ->atomic_async_commit hooks. Support for that
for msm and vc4 landed. n
On 14/02/2023 19:14, Rob Clark wrote:
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
In i915 we have this concept of "wait boosting" where we give a priority boost
for instance to fences which are actively waited upon from userspace. This has
it's pros and cons
On Thu, 16 Feb 2023 09:25:38 +
Simon Ser wrote:
> On Thursday, February 16th, 2023 at 10:11, Pekka Paalanen
> wrote:
>
> > Btw. does this also mean that if you use GETFB2 to get handle A, you
> > export that as dmabuf and import in the same open device instance, you
> > again get handle A?
On Thu, Feb 16, 2023 at 10:59:12AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In i915 we have this concept of "wait boosting" where we give a priority boost
> for instance to fences which are actively waited upon from userspace. This has
> it's pros and cons and can certainly be disc
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> The mutex was completely pointless in the first place since any
> parallel adding of files to this list would result in random
> behavior since the list is filled and consumed multiple times.
>
> Completely drop that approach and j
On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote:
> Set the VGA bit for unblanking with macro constants instead of magic
> values. No functional changes.
blank/unblank should work simliar to bochs (see commit 250e743915d4),
that is maybe a nice thing to add of you modernize the dr
On Thu, Feb 09, 2023 at 03:06:10PM +0100, Christian König wrote:
> Am 09.02.23 um 14:06 schrieb Maíra Canal:
> > On 2/9/23 09:13, Christian König wrote:
> > > Am 09.02.23 um 12:23 schrieb Maíra Canal:
> > > > On 2/9/23 05:18, Christian König wrote:
> > > > > Hello everyone,
> > > > >
> > > > > the
On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > The mutex was completely pointless in the first place since any
> > parallel adding of files to this list would result in random
> > behavior since the list is fille
On Sun, Feb 12, 2023 at 10:44:33PM +0200, Oded Gabbay wrote:
> From: Tomer Tayar
>
> The same mutex lock/unlock and counter decrementing in
> hl_release_dmabuf() is already done in the memhash_node_export_put()
> helper function.
>
> Signed-off-by: Tomer Tayar
> Reviewed-by: Oded Gabbay
> Sign
On 19.01.2023 17:32, Konrad Dybcio wrote:
> From: Konrad Dybcio
>
> Add support for the Sony TD4353 JDI 2160x1080 display panel used in
> some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics
> of smartphone manufacturing, it is impossible to retrieve a better name
> for this
Hi,
thanks for taking a look at the patches.
Am 16.02.23 um 12:33 schrieb Gerd Hoffmann:
On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote:
Set the VGA bit for unblanking with macro constants instead of magic
values. No functional changes.
blank/unblank should work simliar to
On Mon, Jan 30, 2023 at 03:02:10PM +0300, Dmitry Osipenko wrote:
> On 1/27/23 11:13, Gerd Hoffmann wrote:
> > On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote:
> >> Hello Thomas and Gerd,
> >>
> >> On 1/9/23 00:04, Dmitry Osipenko wrote:
> >>> This series:
> >>>
> >>> 1. Makes mino
On Tue, Jan 17, 2023 at 04:06:05AM +0300, Dmitry Osipenko wrote:
> 16.01.2023 18:11, Christian König пишет:
> >
> >
> >> mmapping the memory with that new offset should still work. The
> >> imported BO is created with ttm_bo_type_sg, and AFAICT ttm_bo_vm.c
> >> supports mapping of
On Sun, Feb 12, 2023 at 10:44:35PM +0200, Oded Gabbay wrote:
> From: Tomer Tayar
>
> When user closes the device file descriptor, it is checked whether the
> device is still in use, and a message is printed if it is.
I guess this is only for debugging your user-space component?
Because kernel dr
On Thu, 16 Feb 2023 at 12:59, Konrad Dybcio wrote:
>
>
>
> On 19.01.2023 17:32, Konrad Dybcio wrote:
> > From: Konrad Dybcio
> >
> > Add support for the Sony TD4353 JDI 2160x1080 display panel used in
> > some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics
> > of smartphone man
On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote:
> Hi,
>
> thanks for taking a look at the patches.
>
> Am 16.02.23 um 12:33 schrieb Gerd Hoffmann:
> > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote:
> > > Set the VGA bit for unblanking with macro constants in
Hi,
On Thu, 16 Feb 2023 at 09:25, Simon Ser wrote:
> On Thursday, February 16th, 2023 at 10:11, Pekka Paalanen
> wrote:
> > Btw. does this also mean that if you use GETFB2 to get handle A, you
> > export that as dmabuf and import in the same open device instance, you
> > again get handle A?
>
>
On Thu, 16 Feb 2023 at 10:25, Simon Ser wrote:
>
> On Thursday, February 16th, 2023 at 10:11, Pekka Paalanen
> wrote:
>
> > Btw. does this also mean that if you use GETFB2 to get handle A, you
> > export that as dmabuf and import in the same open device instance, you
> > again get handle A?
>
>
On 16/02/2023 13:32, Daniel Vetter wrote:
On Thu, 16 Feb 2023 at 12:59, Konrad Dybcio wrote:
On 19.01.2023 17:32, Konrad Dybcio wrote:
From: Konrad Dybcio
Add support for the Sony TD4353 JDI 2160x1080 display panel used in
some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the speci
On Thu, 16 Feb 2023 at 13:47, Neil Armstrong wrote:
>
> On 16/02/2023 13:32, Daniel Vetter wrote:
> > On Thu, 16 Feb 2023 at 12:59, Konrad Dybcio
> > wrote:
> >>
> >>
> >>
> >> On 19.01.2023 17:32, Konrad Dybcio wrote:
> >>> From: Konrad Dybcio
> >>>
> >>> Add support for the Sony TD4353 JDI 21
On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote:
> Hi,
>
> thanks for taking a look at the patches.
>
> Am 16.02.23 um 12:33 schrieb Gerd Hoffmann:
> > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote:
> >> Set the VGA bit for unblanking with macro constants ins
Il 16/02/23 13:15, Daniel Vetter ha scritto:
On Mon, Jan 30, 2023 at 03:02:10PM +0300, Dmitry Osipenko wrote:
On 1/27/23 11:13, Gerd Hoffmann wrote:
On Thu, Jan 26, 2023 at 01:55:09AM +0300, Dmitry Osipenko wrote:
Hello Thomas and Gerd,
On 1/9/23 00:04, Dmitry Osipenko wrote:
This series:
Signed-off-by: Simon Ser
Cc: Daniel Vetter
Cc: Pekka Paalanen
Cc: Daniel Stone
---
include/uapi/drm/drm.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
index 4cb956a52aee..54b2313c8332 100644
--- a/include/uapi/drm/drm.h
This is a bit tricky, because of the ref'counting considerations.
See also [1] for more discussion about this topic. Since this is
kernel docs, I've decided to elaborate a bit less on the user-space
details.
[1]: https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
Signed-off-by: Simon Se
Since the DSI autodetection is bound to work correctly on 6115 now,
switch to using the correct per-SoC + generic fallback compatible
combo.
Signed-off-by: Konrad Dybcio
---
Depends on (and should have been a part of):
https://lore.kernel.org/linux-arm-msm/20230213121012.1768296-1-konrad.dyb...@
Hi
On Thu, Feb 16, 2023 at 02:37:15AM +0100, Jesper Juhl wrote:
> From 4fe34831e2e7677b1c9616356f0a2e0a36ec092f Mon Sep 17 00:00:00 2001
> From: Jesper Juhl
> Date: Thu, 16 Feb 2023 02:33:05 +0100
> Subject: [PATCH] Don't test for NULL firmware before releasing
>
> release_firmware() tests for a
On Thu, Feb 16, 2023 at 02:52:51PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote:
> > Hi,
> >
> > thanks for taking a look at the patches.
> >
> > Am 16.02.23 um 12:33 schrieb Gerd Hoffmann:
> > > On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Z
Hi
Am 16.02.23 um 13:52 schrieb Ville Syrjälä:
On Thu, Feb 16, 2023 at 01:03:02PM +0100, Thomas Zimmermann wrote:
Hi,
thanks for taking a look at the patches.
Am 16.02.23 um 12:33 schrieb Gerd Hoffmann:
On Wed, Feb 15, 2023 at 05:15:17PM +0100, Thomas Zimmermann wrote:
Set the VGA bit for u
On Thu, Feb 16, 2023 at 12:28 PM Stanislaw Gruszka
wrote:
>
> Hi
>
> On Sun, Feb 12, 2023 at 10:44:45PM +0200, Oded Gabbay wrote:
>
> > irqreturn_t hl_irq_handler_user_interrupt(int irq, void *arg)
> > +{
> > + return IRQ_WAKE_THREAD;
> > +}
>
> This is not needed. You can pass NULL to reques
On Thu, Feb 16, 2023 at 12:39 PM Stanislaw Gruszka
wrote:
>
> On Sun, Feb 12, 2023 at 10:44:45PM +0200, Oded Gabbay wrote:
> > - rc = request_irq(irq, irq_handler, 0, gaudi2_irq_name(i),
> > &hdev->user_interrupt[j]);
> > + rc = request_threaded_irq(irq, irq_handler,
> >
Move drm_fb_helper_unprepare() from drm_fb_helper_fini() into the
calling fbdev implementation. Avoids a possible stale mutex with
generic fbdev code.
As indicated by its name, drm_fb_helper_prepare() prepares struct
drm_fb_helper before setting up the fbdev support with a call to
drm_fb_helper_in
Hi,
On 06.02.2023 16:41, Jeffrey Hugo wrote:
> Add the QAIC driver uapi file and core driver file that binds to the PCIe
> device. The core driver file also creates the accel device and manages
> all the interconnections between the different parts of the driver.
>
> The driver can be built as a
Hi,
On 15.02.2023 16:41, Jeffrey Hugo wrote:
> On 2/14/2023 4:08 AM, Jacek Lawrynowicz wrote:
>> Hi,
>
> Thank you for the review.
>
>> On 06.02.2023 16:41, Jeffrey Hugo wrote:
>>> The Qualcomm Cloud AI 100 (AIC100) device is an Artificial Intelligence
>>> accelerator PCIe card. It contains a n
Hi Dave and Daniel,
Only 1 gen11 workaround fix.
Here goes drm-intel-fixes-2023-02-16:
- Moving gen11 hw wa to the right place. (Matt)
Thanks,
Rodrigo.
The following changes since commit ceaa837f96adb69c0df0397937cd74991d5d821a:
Linux 6.2-rc8 (2023-02-12 14:10:17 -0800)
are available in the
On Thu, Feb 16, 2023 at 2:25 PM Stanislaw Gruszka
wrote:
>
> On Sun, Feb 12, 2023 at 10:44:35PM +0200, Oded Gabbay wrote:
> > From: Tomer Tayar
> >
> > When user closes the device file descriptor, it is checked whether the
> > device is still in use, and a message is printed if it is.
>
> I guess
On Thu, Feb 16, 2023 at 12:53 PM Stanislaw Gruszka
wrote:
>
> On Sun, Feb 12, 2023 at 10:44:28PM +0200, Oded Gabbay wrote:
> > @@ -3178,11 +3181,12 @@ static int ts_buff_get_kernel_ts_record(struct
> > hl_mmap_mem_buf *buf,
> >
> > /* irq handling in the middle give it time
On Thu, Feb 16, 2023 at 13:48 Stanislaw Gruszka
wrote:
> > The same mutex lock/unlock and counter decrementing in
> > hl_release_dmabuf() is already done in the memhash_node_export_put()
> > helper function.
> >
> > Signed-off-by: Tomer Tayar
> > Reviewed-by: Oded Gabbay
> > Signed-off-by: Oded
On Thu, Feb 16, 2023 at 03:47:44PM +0200, Oded Gabbay wrote:
> On Thu, Feb 16, 2023 at 12:28 PM Stanislaw Gruszka
> wrote:
> >
> > Hi
> >
> > On Sun, Feb 12, 2023 at 10:44:45PM +0200, Oded Gabbay wrote:
> >
> > > irqreturn_t hl_irq_handler_user_interrupt(int irq, void *arg)
> > > +{
> > > + r
On Thu, Jan 26, 2023 at 03:30:31PM +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 26.01.23 um 11:28 schrieb Christian König:
> > We reference dump buffers both by their handle as well as their
> > object. The problem is now that when anybody iterates over the DRM
> > framebuffers and exports the unde
On Sun, Feb 12, 2023 at 10:44:46PM +0200, Oded Gabbay wrote:
> From: Ofir Bitton
>
> In order for interrupt timestamp to be more accurate we should
> capture it during the interrupt handling rather than in threaded
> irq context.
Why this is important to have this timestamp more accurate ?
What
On Thu, Feb 16, 2023 at 02:26:50PM +, Tomer Tayar wrote:
> > This looks suspicious, I think hnode can be not-NULL here and has
> > hnode->vaddr different than searched addr, in case there is
> > hash collision and we iterate over hlist where there is no
> > searched addr. Not 100% sure about th
On Mon, Feb 13, 2023 at 9:12 AM Stanislaw Gruszka
wrote:
>
> On Wed, Feb 08, 2023 at 07:54:50AM -0800, Tom Rix wrote:
> > Building with clang W=2 has several similar warnings
> > drivers/accel/habanalabs/common/decoder.c:46:51: error: declaration shadows
> > a variable in the global scope [-Werro
On Mon, Feb 13, 2023 at 10:57 AM Colin Ian King wrote:
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/accel/habanalabs/common/command_submission.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acc
On Mon, Feb 13, 2023 at 4:48 PM Tom Rix wrote:
>
> smatch reports
> drivers/accel/habanalabs/common/device.c:2619:6: warning:
> symbol 'hl_capture_hw_err' was not declared. Should it be static?
> drivers/accel/habanalabs/common/device.c:2641:6: warning:
> symbol 'hl_capture_fw_err' was not dec
On Wed, Feb 15, 2023 at 6:38 AM Hans de Goede wrote:
>
> The parent for the backlight device should be the drm-connector object,
> not the PCI device.
>
> Userspace relies on this to be able to detect which backlight class device
> to use on hybrid gfx devices where there may be multiple native (r
This series (or at least the suballocator helper) is a prerequisite
for the new Xe driver.
A variant of the series has been on review before, making the
suballocator used by the amdgpu driver the generic one. However we
ran into a number of issues on Xe when using it for context-less
allocations
Initially we tried to leverage the amdgpu suballocation manager.
It turnes out, however, that it tries extremely hard not to enable
signalling on the fences that hold the memory up for freeing, which makes
it hard to understand and to fix potential issues with it.
So in a simplification effort, in
From: Maarten Lankhorst
Now that we have a generic suballocation helper, Use it in amdgpu.
The debug output is slightly different and suballocation may be
slightly more cpu-hungry.
Signed-off-by: Maarten Lankhorst
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
---
drivers/
From: Maarten Lankhorst
Use the generic suballocation helper.
Note that the generic suballocator only allows a single alignment,
so we may waste a few more bytes for radeon_semaphore, shouldn't
be a big deal, could be re-added if needed. Also, similar to amdgpu,
debug output changes slightly and
On Thu, Feb 16, 2023 at 8:45 AM Orlando Chamberlain
wrote:
>
> Commit 3840c5bcc245 ("drm/amdgpu: disentangle runtime pm and
> vga_switcheroo") made amdgpu only register a vga_switcheroo client for
> GPU's with PX, however AMD GPUs in dual gpu Apple Macbooks do need to
> register, but don't have PX
On Thu, Feb 16, 2023 at 04:21:48PM +0200, Oded Gabbay wrote:
> On Thu, Feb 16, 2023 at 2:25 PM Stanislaw Gruszka
> wrote:
> >
> > On Sun, Feb 12, 2023 at 10:44:35PM +0200, Oded Gabbay wrote:
> > > From: Tomer Tayar
> > >
> > > When user closes the device file descriptor, it is checked whether the
On 2/16/2023 7:18 AM, Jacek Lawrynowicz wrote:
Hi,
On 15.02.2023 16:41, Jeffrey Hugo wrote:
On 2/14/2023 4:08 AM, Jacek Lawrynowicz wrote:
Hi,
Thank you for the review.
On 06.02.2023 16:41, Jeffrey Hugo wrote:
The Qualcomm Cloud AI 100 (AIC100) device is an Artificial Intelligence
acceler
On Sun, Jan 8, 2023 at 1:13 PM Dmitry Osipenko
wrote:
>
> drm_gem_shmem_mmap() doesn't own reference in error code path, resulting
> in the dma-buf shmem GEM object getting prematurely freed leading to a
> later use-after-free.
>
> Fixes: f49a51bfdc8e ("drm/shme-helpers: Fix dma_buf_mmap forwardin
On Thu, Feb 16, 2023 at 09:21:23AM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> As the logic for selecting the register and corresponsing values grew, the
> code become a bit unsightly. Consolidate by storing the required values at
> engine init time in the engine itself, and by doing
On Thu, Feb 16, 2023 at 3:19 AM Tvrtko Ursulin
wrote:
>
>
> On 14/02/2023 19:14, Rob Clark wrote:
> > On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> In i915 we have this concept of "wait boosting" where we give a priority
> >> boost
> >> for i
Am 16.02.23 um 12:33 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
The mutex was completely pointless in the first place since any
parallel adding of files to this list would result in random
behavior since the list is filled and consumed multiple times.
A slightly unusual cover letter for a single patch.
The page table walker is currently used by the xe driver only,
but the code is generic so we can be good citizens and add it to drm
as a helper, for possible use by other drivers,
If so we can merge the commit when we merge the xe driver.
The qu
Add a gpu page table walker similar in functionality to the cpu page-table
walker in mm/pagewalk.c. This is made a drm helper in the hope that it
might prove useful to other drivers, but we could of course make it
single-driver only and rename the functions initially.
Also if remaining a DRM helpe
Am 16.02.23 um 12:34 schrieb Daniel Vetter:
On Thu, Feb 09, 2023 at 03:06:10PM +0100, Christian König wrote:
Am 09.02.23 um 14:06 schrieb Maíra Canal:
On 2/9/23 09:13, Christian König wrote:
Am 09.02.23 um 12:23 schrieb Maíra Canal:
On 2/9/23 05:18, Christian König wrote:
Hello everyone,
On 16/02/2023 10:31, Marijn Suijten wrote:
On 2023-02-16 04:22:13, Dmitry Baryshkov wrote:
On Thu, 16 Feb 2023 at 01:02, Marijn Suijten
wrote:
DPU's catalog never assigned dpu_scaler_blk::version leading to
initialization code in dpu_hw_setup_scaler3 to wander the wrong
codepaths. Instead of
On 16/02/2023 01:50, Rob Clark wrote:
From: Rob Clark
The error path cleanup expects that chain and syncobj are either NULL or
valid pointers. But post_deps was not allocated with __GFP_ZERO.
Fixes: ab723b7a992a ("drm/msm: Add syncobj support.")
Signed-off-by: Rob Clark
Reviewed-by: Dmitry
On Thu, 16 Feb 2023, Christian König wrote:
> Am 16.02.23 um 12:33 schrieb Daniel Vetter:
>> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
>>> The mutex was completely pointless in the first place since any
>>> parallel adding of files to this list would result in random
>>> beh
On Thu, Feb 16, 2023 at 12:33:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2023 at 09:18:38AM +0100, Christian König wrote:
> > The mutex was completely pointless in the first place since any
> > parallel adding of files to this list would result in random
> > behavior since the list is fille
On 06/02/2023 21:07, Abhinav Kumar wrote:
On 2/3/2023 10:21 AM, Dmitry Baryshkov wrote:
Now as all accesses to pipe_cfg and pstate have been cleaned, re-add
struct dpu_hw_pipe_cfg back to dpu_plane_state, so that
dpu_plane_atomic_check() and dpu_plane_atomic_update() do not have a
chance to di
1 - 100 of 169 matches
Mail list logo
