Hi Peter,
>
> On Fri, Jun 23, 2023 at 06:13:02AM +, Kasireddy, Vivek wrote:
> > Hi David,
> >
> > > > The first patch ensures that the mappings needed for handling mmap
> > > > operation would be managed by using the pfn instead of struct page.
> > > > The second patch restores support for ma
On Fri, 23 Jun 2023 14:37:57 -0400
Luben Tuikov wrote:
> On 2023-06-23 04:03, Boris Brezillon wrote:
> > On Fri, 23 Jun 2023 09:52:04 +0200
> > Boris Brezillon wrote:
> >
> >> Drivers that can delegate waits to the firmware/GPU pass the scheduled
> >> fence to drm_sched_job_add_dependency(),
On Sun, 25 Jun 2023, Sui Jingfeng wrote:
> As this function can be replaced with drm_dev_unregister() + drm_dev_put(),
> it is already marked as deprecated, so remove it. No functional change.
>
> Signed-off-by: Sui Jingfeng
> ---
> drivers/gpu/drm/drm_drv.c | 28 --
Hi
Am 25.06.23 um 07:09 schrieb Sui Jingfeng:
As this function can be replaced with drm_dev_unregister() + drm_dev_put(),
it is already marked as deprecated, so remove it. No functional change.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/drm_drv.c | 28 -
Am 22.06.23 um 11:27 schrieb Geert Uytterhoeven:
Use the drm_crtc_helper_atomic_check() helper instead of open-coding the
same operation.
Signed-off-by: Geert Uytterhoeven
Reviewed-by: Thomas Zimmermann
---
Compile-tested only.
---
drivers/gpu/drm/udl/udl_modeset.c | 13 ++---
Am 22.06.23 um 12:18 schrieb Sui Jingfeng:
else is not generally useful after return
Signed-off-by: Sui Jingfeng
Reviewed-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu
Hi Arnd,
On Thu, Jun 22, 2023 at 12:18:41PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> The mchbar_addr variable is only used inside of an #ifdef:
>
> drivers/gpu/drm/i915/soc/intel_gmch.c:41:6: error: variable 'mchbar_addr' set
> but not used [-Werror,-Wunused-but-set-variable]
>
>
On Sat, 24 Jun 2023 18:48:08 -0300
Maira Canal wrote:
> Hi Arthur,
>
> Thanks for working on this feature for the VKMS!
>
> On 6/21/23 16:41, Arthur Grillo wrote:
> > Support a 1D gamma LUT with interpolation for each color channel on the
> > VKMS driver. Add a check for the LUT length by creat
There is a spelling mistake in a drm_dbg_kms message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/display/intel_pmdemand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_pmdemand.c
b/drivers/gpu/drm/i915/display/intel_pm
On 20/06/2023 14:23, Ira Weiny wrote:
Sumitra Sharma wrote:
On Sun, Jun 18, 2023 at 11:11:08AM -0700, Ira Weiny wrote:
Sumitra Sharma wrote:
kmap() has been deprecated in favor of the kmap_local_page()
due to high cost, restricted mapping space, the overhead of a
global lock for synchronizat
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
A couple of ttm fixes for issues that either were hit while developing the
xe driver or, for the resource leak patches, discovered during code
inspection.
v2:
- Avoid a goto in patch 3 (Andi Shyti)
- Add som
The value of pos->first was not updated when the first resource of the
range was moved. This could lead to errors like the one below.
Fix this by updating pos->first when needed.
<3> [218.963342] BUG: KASAN: null-ptr-deref in ttm_lru_bulk_move_del+0xc5/0x180
[ttm]
<3> [218.963456] Read of size 8
ttm_bo_swapout() shadows the ttm operation context which may cause
major confusion in driver callbacks when swapping out !TTM_PL_SYSTEM
memory. Fix this by reusing the operation context argument to
ttm_bo_swapout().
Cc: "Christian König"
Cc: Roger He
Cc:
Cc:
Cc: # v4.16+
Fixes: dc947770cf34 (
On eviction errors other than -EMULTIHOP we were leaking a resource.
Fix.
v2:
- Avoid yet another goto (Andi Shyti)
Fixes: 403797925768 ("drm/ttm: Fix multihop assert on eviction.")
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Christian Koenig
Cc: Huang Rui
Cc: dri-devel@lists.freedesktop.or
If moving the bo to system for swapout failed, we were leaking
a resource. Fix.
Fixes: bfa3357ef9ab ("drm/ttm: allocate resource object instead of embedding it
v2")
Cc: Christian König
Cc: "Christian König"
Cc: dri-devel@lists.freedesktop.org
Cc: # v5.14+
Signed-off-by: Thomas Hellström
Revie
Hi Julia,
On Fri, Jun 23, 2023 at 11:14:47PM +0200, Julia Lawall wrote:
> Use array_size to protect against multiplication overflows.
>
> The changes were done using the following Coccinelle semantic patch:
>
> //
> @@
> expression E1, E2;
> constant C1, C2;
> identifier alloc = {vm
Hello,
> Correct many spelling errors in Documentation/ as reported by codespell.
>
> Maintainers of specific kernel subsystems are only Cc-ed on their
> respective patches, not the entire series.
>
> These patches are based on linux-next-20230209.
>
[...]
> [PATCH 13/24] Documentation: PCI: c
On 25.06.2023 22:19, Marijn Suijten wrote:
> On 2023-06-24 03:47:27, Konrad Dybcio wrote:
>> On 24.06.2023 02:41, Marijn Suijten wrote:
>>> Add definitions for the display hardware used on the Qualcomm SM6125
>>> platform.
>>>
>>> Signed-off-by: Marijn Suijten
>>> ---
>> [...]
>>
>>> +static const
Hi Dmitry,
On Tue, 30 May 2023 01:39:35 +0300
Dmitry Osipenko wrote:
> Replace all drm-shmem locks with a GEM reservation lock. This makes locks
> consistent with dma-buf locking convention where importers are responsible
> for holding reservation lock for all operations performed over dma-bufs,
On 25.06.2023 21:18, Marijn Suijten wrote:
> On 2023-06-24 03:42:46, Konrad Dybcio wrote:
>> On 24.06.2023 02:40, Marijn Suijten wrote:
>>> Bring up the SM6125 DPU now that all preliminary series (such as INTF
>>> TE) have been merged (for me to test the hardware properly)
>> We should not repeat t
On 25.06.2023 21:48, Marijn Suijten wrote:
> On 2023-06-24 03:45:02, Konrad Dybcio wrote:
>> On 24.06.2023 02:41, Marijn Suijten wrote:
>>> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
>>> be passed from DT, and should be required by the bindings.
>>>
>>> Fixes: 8397c9c0c2
On 25.06.2023 22:23, Marijn Suijten wrote:
> On 2023-06-24 03:49:25, Konrad Dybcio wrote:
>> On 24.06.2023 02:41, Marijn Suijten wrote:
>>> SM6125 features only a single PHY (despite a secondary PHY PLL source
>>> being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
>>> sources
On Mon, 26 Jun 2023 11:40:14 +0200
Boris Brezillon wrote:
> Hi Dmitry,
>
> On Tue, 30 May 2023 01:39:35 +0300
> Dmitry Osipenko wrote:
>
> > Replace all drm-shmem locks with a GEM reservation lock. This makes locks
> > consistent with dma-buf locking convention where importers are responsible
I've already pushed the version from Teddy to drm-misc-fixes last week.
So no need for that one any more.
Christian.
Am 26.06.23 um 11:14 schrieb Thomas Hellström:
The value of pos->first was not updated when the first resource of the
range was moved. This could lead to errors like the one bel
Am Samstag, dem 24.06.2023 um 23:53 +0800 schrieb Sui Jingfeng:
> Hi,
>
> On 2023/6/21 18:16, Lucas Stach wrote:
> > Am Mittwoch, dem 21.06.2023 um 17:20 +0800 schrieb Sui Jingfeng:
> > > Hi,
> > >
> > > On 2023/6/21 17:07, Lucas Stach wrote:
> > > > Am Dienstag, dem 20.06.2023 um 17:47 +0800 sch
Hi,
Am Sonntag, dem 25.06.2023 um 11:51 +0800 schrieb Sui Jingfeng:
> Hi,
>
> On 2023/6/22 01:45, Lucas Stach wrote:
> > Am Donnerstag, dem 22.06.2023 um 01:21 +0800 schrieb Sui Jingfeng:
> > > Hi,
> > >
> > > On 2023/6/21 23:58, Lucas Stach wrote:
> > > > Am Mittwoch, dem 21.06.2023 um 23:30 +0
Hi Thomas,
On Mon, Jun 26, 2023 at 11:14:49AM +0200, Thomas Hellström wrote:
> On eviction errors other than -EMULTIHOP we were leaking a resource.
> Fix.
>
> v2:
> - Avoid yet another goto (Andi Shyti)
>
> Fixes: 403797925768 ("drm/ttm: Fix multihop assert on eviction.")
> Cc: Andrey Grodzovsky
Am 26.06.23 um 11:14 schrieb Thomas Hellström:
On eviction errors other than -EMULTIHOP we were leaking a resource.
Fix.
v2:
- Avoid yet another goto (Andi Shyti)
Fixes: 403797925768 ("drm/ttm: Fix multihop assert on eviction.")
Cc: Andrey Grodzovsky
Cc: Christian König
Cc: Christian Koenig
Am 26.06.23 um 11:14 schrieb Thomas Hellström:
If moving the bo to system for swapout failed, we were leaking
a resource. Fix.
Fixes: bfa3357ef9ab ("drm/ttm: allocate resource object instead of embedding it
v2")
Cc: Christian König
Cc: "Christian König"
Cc: dri-devel@lists.freedesktop.org
Cc:
On Mon, Jun 26, 2023 at 11:26:55AM +0200, Andi Shyti wrote:
> > diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> > index 4ec85308379a..df52385ad436 100644
> > --- a/drivers/gpu/drm/i915/gvt/gtt.c
> > +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> > @@ -1969,14 +1969,16 @@ stat
Move code drm_gem_shmem_{get,put}_pages() code to
drm_gem_shmem_{pin,unpin}_locked().
Signed-off-by: Boris Brezillon
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Emil Velikov
Cc: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 108 ++---
1 file changed, 41 ins
Hello,
As mentioned here [1], after rebasing some of my work on
drm-misc-next this morning I noticed that the
drm_gem_shmem_get_pages() I was using to pin pages to a GEM no longer
exists, so I ended up looking at 21aa27ddc582 ("drm/shmem-helper: Switch
to reservation lock") and came up with a few
dma_resv lock should be held in both the dma_buf and native GEM case,
so let's just move the dma_resv_assert_held() check out of the !dma-buf
block.
Signed-off-by: Boris Brezillon
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Emil Velikov
Cc: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_h
Drivers are not supposed to call these functions directly when they
want to map/unamp a GEM in kernel space. They should instead go
through drm_gem_v[un]map[_unlocked]() that will forward the request
to drm_gem_object_funcs::v[un]map() which in turn will call
drm_gem_shmem_v[un]map().
Let's clarif
We want to get rid of this helper function, so let's use
drm_gem_shmem_unpin() and move this call out of the
dma_resv-locked section.
Signed-off-by: Boris Brezillon
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Emil Velikov
Cc: Dmitry Osipenko
Cc: Rob Herring
Cc: Steven Price
---
drivers/gpu
The last user (panfrost) moved to drm_gem_shmem_unpin(), so it's now
safe to make this function private.
Signed-off-by: Boris Brezillon
Cc: Daniel Vetter
Cc: Thomas Zimmermann
Cc: Emil Velikov
Cc: Dmitry Osipenko
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 5 +++--
include/drm/drm_gem_shmem
On 25.06.2023 13:42, Dmitry Baryshkov wrote:
> Port Qualcomm QMP HDMI PHY to the generic PHY framework. Split the
> generic part and the msm8996 part. When adding support for msm8992/4 and
> msm8998 (which also employ QMP for HDMI PHY), one will have to provide
> the PLL programming part only.
>
>
Because the setting of hproch is too small, there will be warning in
kernel log[1]. After fine tune the HFP and HBP, this warning can be
solved. The actual measurement frame rate is 60.1Hz.
[1]: WARNING kernel:[drm] HFP + HBP less than d-phy, FPS will under 60Hz
Signed-off-by: Cong Yang
---
dri
Hi, Christian,
Will you take a look at 2/4 as well? Will you merge these?
Thanks,
Thomas
On 6/26/23 13:33, Christian König wrote:
Am 26.06.23 um 11:14 schrieb Thomas Hellström:
If moving the bo to system for swapout failed, we were leaking
a resource. Fix.
Fixes: bfa3357ef9ab ("drm/ttm: al
Thomas Zimmermann writes:
> Pass the hardware device to the DMA helpers dma_alloc_coherent() and
> dma_free_coherent(). The fbdev device that is currently being used is
> a software device and does not provide DMA memory. Also update the
> related dev_*() output statements similarly.
>
> Signed-o
On 2023-06-20 00:25:04, Dmitry Baryshkov wrote:
> There is always a single MDP TOP block. Drop the mdp_count field and
> stop declaring dpu_mdp_cfg instances as arrays.
>
> Tested-by: Marijn Suijten
> Signed-off-by: Dmitry Baryshkov
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.h
> b
Hi,
On Tue, Jun 20, 2023 at 06:18:31PM +0200, Thomas Zimmermann wrote:
> Am 20.06.23 um 18:06 schrieb Sui Jingfeng:
> > Hi,
> >
> > On 2023/6/20 22:43, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 20.06.23 um 06:08 schrieb Sui Jingfeng:
> > > > ping ?
> > > >
> > > > On 2023/3/14 20:53, Sui
On Fri, Jun 23, 2023 at 01:28:24PM -0400, Peter Xu wrote:
> On Fri, Jun 23, 2023 at 01:37:58PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote:
> >
> > > It seems the previous concern on using gup was majorly fork(), if this is
> > > it:
> > >
> > > htt
On Mon, Jun 26, 2023 at 08:56:35PM +0900, Byungchul Park wrote:
> >From now on, I can work on LKML again! I'm wondering if DEPT has been
> helping kernel debugging well even though it's a form of patches yet.
>
> I'm happy to see that DEPT reports a real problem in practice. See:
>
>
> https:
On 6/26/23 12:40, Boris Brezillon wrote:
> Same problem with this renaming: it's confusing because this function
> was previously taking care of the locking, and it's no longer the case.
> That's actually true for other public functions your patching, but I
> won't go over all of them.
>
> I know
On 6/26/23 12:40, Boris Brezillon wrote:
> I think here is the major problem I have with this patch: you've made
> drm_gem_shmem_{get_pages,pin}() private, which forces me to call
> drm_gem_shmem_pin() in a path where I already acquired the resv lock
> (using the drm_exec infra proposed by Christia
On Fri, Jun 23, 2023 at 04:38:34AM +0800, Sui Jingfeng wrote:
> On 2023/6/8 15:39, Maxime Ripard wrote:
> > On Thu, Jun 08, 2023 at 01:18:38AM +0800, Sui Jingfeng wrote:
> > > Hi,
> > >
> > > On 2023/6/8 00:12, Paul Cercueil wrote:
> > > > Hi Sui,
> > > >
> > > > Le mercredi 07 juin 2023 à 22:38
On 6/26/23 15:02, Boris Brezillon wrote:
> -err_pages:
> - drm_gem_shmem_put_pages(&bo->base);
> err_unlock:
> dma_resv_unlock(obj->resv);
> +
> + if (ret && pinned)
> + drm_gem_shmem_unpin(&bo->base);
The drm_gem_shmem_unpin() was supposed to be used only in conjunction
Hi,
On 2023/6/26 20:32, Maxime Ripard wrote:
Hi,
On Tue, Jun 20, 2023 at 06:18:31PM +0200, Thomas Zimmermann wrote:
Am 20.06.23 um 18:06 schrieb Sui Jingfeng:
Hi,
On 2023/6/20 22:43, Thomas Zimmermann wrote:
Hi
Am 20.06.23 um 06:08 schrieb Sui Jingfeng:
ping ?
On 2023/3/14 20:53, Sui Jin
Hi Adam,
On Sat, 2023-06-17 at 07:48 -0500, Adam Ford wrote:
> On Tue, Jun 13, 2023 at 10:20 AM Sarah Walker wrote:
> > Read the GPU ID register at probe time and select the correct
> > features/quirks/enhancements. Use the GPU ID to form the firmware
> > file name and load the firmware.
>
> I h
Hi Linus,
On Fri, 2023-06-16 at 14:10 +0200, Linus Walleij wrote:
> On Tue, Jun 13, 2023 at 5:20 PM Sarah Walker wrote:
>
> > From: Matt Coster
> >
> > Signed-off-by: Matt Coster
>
> Looks useful.
> Reviewed-by: Linus Walleij
Thank you for the review!
Frank
>
> Yours,
> Linus Walleij
Hi Linus,
On Fri, 2023-06-16 at 14:29 +0200, Linus Walleij wrote:
> Hi Sarah,
>
> thanks for starting this long awaited work!
>
> On Tue, Jun 13, 2023 at 5:20 PM Sarah Walker wrote:
>
> > This patch series adds the initial DRM driver for Imagination Technologies
> > PowerVR
> > GPUs, starting
On Mon, 26 Jun 2023 16:20:53 +0300
Dmitry Osipenko wrote:
> On 6/26/23 15:02, Boris Brezillon wrote:
> > -err_pages:
> > - drm_gem_shmem_put_pages(&bo->base);
> > err_unlock:
> > dma_resv_unlock(obj->resv);
> > +
> > + if (ret && pinned)
> > + drm_gem_shmem_unpin(&bo->base);
Hi,
On 26/06/2023 14:07, Cong Yang wrote:
Because the setting of hproch is too small, there will be warning in
kernel log[1]. After fine tune the HFP and HBP, this warning can be
solved. The actual measurement frame rate is 60.1Hz.
[1]: WARNING kernel:[drm] HFP + HBP less than d-phy, FPS will u
Hi Nikolaus,
On Fri, 2023-06-16 at 16:06 +0200, H. Nikolaus Schaller wrote:
> Hi Linus,
> thanks for sharing this conversation with me.
>
> > Am 16.06.2023 um 14:29 schrieb Linus Walleij :
> >
> > Hi Sarah,
> >
> > thanks for starting this long awaited work!
> >
> > On Tue, Jun 13, 2023 at 5:2
On 24/06/2023 03:41, Marijn Suijten wrote:
SM6125 is identical to SM6375 except that while downstream also defines
a throttle clock, its presence results in timeouts whereas SM6375
requires it to not observe any timeouts.
I see that the vendor DTS still references this clock.
Abhinav, Tanya, d
On 2023-06-26 11:41:39, Konrad Dybcio wrote:
> On 25.06.2023 21:18, Marijn Suijten wrote:
> > On 2023-06-24 03:42:46, Konrad Dybcio wrote:
> >> On 24.06.2023 02:40, Marijn Suijten wrote:
> >>> Bring up the SM6125 DPU now that all preliminary series (such as INTF
> >>> TE) have been merged (for me t
On 26.06.2023 16:17, Marijn Suijten wrote:
> On 2023-06-26 11:41:39, Konrad Dybcio wrote:
>> On 25.06.2023 21:18, Marijn Suijten wrote:
>>> On 2023-06-24 03:42:46, Konrad Dybcio wrote:
On 24.06.2023 02:40, Marijn Suijten wrote:
> Bring up the SM6125 DPU now that all preliminary series (suc
On 2023-06-26 11:43:39, Konrad Dybcio wrote:
> On 25.06.2023 21:48, Marijn Suijten wrote:
> > On 2023-06-24 03:45:02, Konrad Dybcio wrote:
> >> On 24.06.2023 02:41, Marijn Suijten wrote:
> >>> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
> >>> be passed from DT, and should
On Mon, Jun 19, 2023 at 05:02:49PM +0100, Mans Rullgard wrote:
> The led_access lock must be held when calling led_sysfs_enable() and
> led_sysfs_disable(). This fixes warnings such as this:
>
> [2.432495] [ cut here ]
> [2.437316] WARNING: CPU: 0 PID: 22 at drivers
Return -ENOMEM if tegra_bo_mmap() fails.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/tegra/gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index dea38892d6e6..0ce22935fbd3 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/dri
else is not generally useful after return
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/tegra/gem.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 0ce22935fbd3..26d64f4545bd 100644
--- a/d
On Wed, Jun 14, 2023 at 09:08:52PM +0200, Maximilian Weigand wrote:
> From: Maximilian Weigand
>
> The led driver supports changing the switching frequency of the boost
> converter by two means: the base switching frequency can be changed from
> 500 kHz to 1 MHz, and a frequency shift can be activ
Because using the 'depends on' is easy to understand and more obvious.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/tegra/Kconfig | 6 ++
drivers/gpu/host1x/Kconfig| 5 +
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm
Hi Dmitry,
Sorry for chiming in only now :-/.
On Tue, 14 Mar 2023 05:26:52 +0300
Dmitry Osipenko wrote:
> And new pages_pin_count field to struct drm_gem_shmem_object that will
> determine whether pages are evictable by memory shrinker. The pages will
> be evictable only when pages_pin_count=0.
On Thu, Jun 08, 2023 at 04:11:14PM +0200, Philipp Zabel wrote:
> The initial PWM state returned by pwm_init_state() has a duty cycle
> of 0 ns. To avoid backlight flicker when taking over an enabled
> display from the bootloader, skip the initial pwm_apply_state()
> and leave the PWM be until backl
Am 26.06.23 um 11:14 schrieb Thomas Hellström:
ttm_bo_swapout() shadows the ttm operation context which may cause
major confusion in driver callbacks when swapping out !TTM_PL_SYSTEM
memory. Fix this by reusing the operation context argument to
ttm_bo_swapout().
Cc: "Christian König"
Cc: Roger
On Mon, 2023-06-26 at 17:15 +0200, Christian König wrote:
> Am 26.06.23 um 11:14 schrieb Thomas Hellström:
> > ttm_bo_swapout() shadows the ttm operation context which may cause
> > major confusion in driver callbacks when swapping out
> > !TTM_PL_SYSTEM
> > memory. Fix this by reusing the operatio
On Mon, 26 Jun 2023 17:04:57 +0200
Boris Brezillon wrote:
> Hi Dmitry,
>
> Sorry for chiming in only now :-/.
>
> On Tue, 14 Mar 2023 05:26:52 +0300
> Dmitry Osipenko wrote:
>
> > And new pages_pin_count field to struct drm_gem_shmem_object that will
> > determine whether pages are evictable
On Mon, 2023-06-26 at 17:18 +0200, Thomas Hellström wrote:
> On Mon, 2023-06-26 at 17:15 +0200, Christian König wrote:
> > Am 26.06.23 um 11:14 schrieb Thomas Hellström:
> > > ttm_bo_swapout() shadows the ttm operation context which may
> > > cause
> > > major confusion in driver callbacks when swa
Hi Christian,
Thanks for the information! I am not very familiar with the inner
workings of DRM, so I'm not really in a position to make any large or
systematic changes to the test regarding the points you made. I am
mainly trying to allow the tests to be run on more diverse hardware.
>From the lo
On Mon, 19 Jun 2023, Mans Rullgard wrote:
> The led_access lock must be held when calling led_sysfs_enable() and
> led_sysfs_disable(). This fixes warnings such as this:
>
> [2.432495] [ cut here ]
> [2.437316] WARNING: CPU: 0 PID: 22 at drivers/leds/led-core.c:34
On 6/26/23 18:21, Boris Brezillon wrote:
> On Mon, 26 Jun 2023 17:04:57 +0200
> Boris Brezillon wrote:
>
>> Hi Dmitry,
>>
>> Sorry for chiming in only now :-/.
>>
>> On Tue, 14 Mar 2023 05:26:52 +0300
>> Dmitry Osipenko wrote:
>>
>>> And new pages_pin_count field to struct drm_gem_shmem_object t
On Mon, 26 Jun 2023 14:02:45 +0200
Boris Brezillon wrote:
> Move code drm_gem_shmem_{get,put}_pages() code to
> drm_gem_shmem_{pin,unpin}_locked().
After having a closer look at 'Add generic memory shrinker to VirtIO-GPU
and Panfrost DRM drivers', I realize that's not what we want. We must
diff
On Mon, Jun 26, 2023 at 8:22 AM Frank Binns wrote:
>
> Hi Adam,
>
> On Sat, 2023-06-17 at 07:48 -0500, Adam Ford wrote:
> > On Tue, Jun 13, 2023 at 10:20 AM Sarah Walker
> > wrote:
> > > Read the GPU ID register at probe time and select the correct
> > > features/quirks/enhancements. Use the GPU
On Mon, 26 Jun 2023 16:20:53 +0300
Dmitry Osipenko wrote:
> On 6/26/23 15:02, Boris Brezillon wrote:
> > -err_pages:
> > - drm_gem_shmem_put_pages(&bo->base);
> > err_unlock:
> > dma_resv_unlock(obj->resv);
> > +
> > + if (ret && pinned)
> > + drm_gem_shmem_unpin(&bo->base);
ly after you drop gpu_usecount
> and use only pin_count to check whether a GEM object can be evicted or
> not.
See the drm_gem_evict() [1], it checks whether GEM is busy, preventing
BO eviction while it is in-use by GPU. Note that in case of Panfrost,
shrinker isn't enabled for growable BOs.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/drm_gem.c?h=next-20230626#n1495
--
Best regards,
Dmitry
On 25/06/2023 21:48, Marijn Suijten wrote:
> On 2023-06-24 11:08:54, Krzysztof Kozlowski wrote:
>> On 24/06/2023 03:45, Konrad Dybcio wrote:
>>> On 24.06.2023 02:41, Marijn Suijten wrote:
The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
be passed from DT, and should
On 6/25/23 18:36, Geert Uytterhoeven wrote:
> Hi Dmitry,
>
> On Sun, Jun 25, 2023 at 2:41 PM Dmitry Osipenko
> wrote:
>> On 6/25/23 11:47, Geert Uytterhoeven wrote:
>>> On Sun, Apr 16, 2023 at 1:55 PM Dmitry Osipenko
>>> wrote:
Add sync object DRM UAPI support to VirtIO-GPU driver. Sync obj
On 26/06/2023 16:26, Marijn Suijten wrote:
> On 2023-06-26 11:43:39, Konrad Dybcio wrote:
>> On 25.06.2023 21:48, Marijn Suijten wrote:
>>> On 2023-06-24 03:45:02, Konrad Dybcio wrote:
On 24.06.2023 02:41, Marijn Suijten wrote:
> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the dr
Em 22/06/2023 05:12, Pekka Paalanen escreveu:
On Wed, 21 Jun 2023 13:28:34 -0300
André Almeida wrote:
Em 21/06/2023 04:58, Pekka Paalanen escreveu:
On Tue, 20 Jun 2023 21:57:16 -0300
André Almeida wrote:
Create a section that specifies how to deal with DRM device resets for
kernel and u
On 25/06/2023 21:52, Marijn Suijten wrote:
> On 2023-06-24 11:12:52, Krzysztof Kozlowski wrote:
>> On 24/06/2023 02:41, Marijn Suijten wrote:
>>> SM6125 is identical to SM6375 except that while downstream also defines
>>> a throttle clock, its presence results in timeouts whereas SM6375
>>> require
On Mon, 26 Jun 2023 19:06:55 +0300
Dmitry Osipenko wrote:
> On 6/26/23 18:43, Boris Brezillon wrote:
> > On Mon, 26 Jun 2023 16:20:53 +0300
> > Dmitry Osipenko wrote:
> >
> >> On 6/26/23 15:02, Boris Brezillon wrote:
> >>> -err_pages:
> >>> - drm_gem_shmem_put_pages(&bo->base);
> >>> err_u
Because vmap() function could fail.
Also don't let omap_gem_vaddr() function signature (declaration) dangling
there, as it will only get defined when CONFIG_DRM_FBDEV_EMULATION=y.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/omapdrm/omap_fbdev.c | 10 --
drivers/gpu/drm/omapdrm/omap_g
On 6/8/2023 5:59 AM, Manivannan Sadhasivam wrote:
On Fri, May 19, 2023 at 10:39:00AM -0600, Jeffrey Hugo wrote:
With the QAIC driver in -next, I'd like to suggest some MHI changes that
specific to AIC100 devices, but perhaps provide a framework for other
device oddities.
AIC100 devices technica
On Mon, Jun 26, 2023 at 05:31:59AM +, manikanda...@microchip.com wrote:
> On 21/06/23 13:17, Nicolas Ferre wrote:
> > On 16/06/2023 at 08:44, Manikandan M - I67131 wrote:
> >> On 14/06/23 20:10, Nicolas Ferre wrote:
> >>> On 13/06/2023 at 20:21, Conor Dooley wrote:
> On Tue, Jun 13, 2023 a
Hi Pekka,
On 6/26/23 05:17, Pekka Paalanen wrote:
On Sat, 24 Jun 2023 18:48:08 -0300
Maira Canal wrote:
Hi Arthur,
Thanks for working on this feature for the VKMS!
On 6/21/23 16:41, Arthur Grillo wrote:
Support a 1D gamma LUT with interpolation for each color channel on the
VKMS driver. Ad
On 2023-06-26 18:15:13, Krzysztof Kozlowski wrote:
> On 26/06/2023 16:26, Marijn Suijten wrote:
> > On 2023-06-26 11:43:39, Konrad Dybcio wrote:
> >> On 25.06.2023 21:48, Marijn Suijten wrote:
> >>> On 2023-06-24 03:45:02, Konrad Dybcio wrote:
> On 24.06.2023 02:41, Marijn Suijten wrote:
> >>>
On 2023-06-26 18:10:44, Krzysztof Kozlowski wrote:
> On 25/06/2023 21:48, Marijn Suijten wrote:
> > On 2023-06-24 11:08:54, Krzysztof Kozlowski wrote:
> >> On 24/06/2023 03:45, Konrad Dybcio wrote:
> >>> On 24.06.2023 02:41, Marijn Suijten wrote:
> The "gcc_disp_gpll0_div_clk_src" clock is con
On Mon, Jun 26, 2023 at 07:45:37AM +, Kasireddy, Vivek wrote:
> Hi Peter,
>
> >
> > On Fri, Jun 23, 2023 at 06:13:02AM +, Kasireddy, Vivek wrote:
> > > Hi David,
> > >
> > > > > The first patch ensures that the mappings needed for handling mmap
> > > > > operation would be managed by usin
On 2023-06-26 18:16:58, Krzysztof Kozlowski wrote:
> On 25/06/2023 21:52, Marijn Suijten wrote:
> > On 2023-06-24 11:12:52, Krzysztof Kozlowski wrote:
> >> On 24/06/2023 02:41, Marijn Suijten wrote:
> >>> SM6125 is identical to SM6375 except that while downstream also defines
> >>> a throttle clock
The vmap function called in the tegra_fbdev_probe() function could fail,
It doesn't matther. But if the error handling is necessary, it should
also free the resources allocated by drm_fb_helper_alloc_info() function
and the gem buffer object allocated by tegra_bo_create().
Signed-off-by: Sui Jingf
Hi,
On Tue, Jun 13, 2023 at 11:41 AM Stephen Boyd wrote:
>
> Quoting Douglas Anderson (2023-06-13 06:58:13)
> > Memory for the "struct device" for any given device isn't supposed to
> > be released until the device's release() is called. This is important
> > because someone might be holding a ko
On 26.06.23 19:52, Peter Xu wrote:
On Mon, Jun 26, 2023 at 07:45:37AM +, Kasireddy, Vivek wrote:
Hi Peter,
On Fri, Jun 23, 2023 at 06:13:02AM +, Kasireddy, Vivek wrote:
Hi David,
The first patch ensures that the mappings needed for handling mmap
operation would be managed by using
On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> So we might have to implement the same page migration as gup does on
> FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> require that handling when simply taking pages out of the memfd, believing
> th
On 26/06/2023 19:49, Marijn Suijten wrote:
> On 2023-06-26 18:10:44, Krzysztof Kozlowski wrote:
>> On 25/06/2023 21:48, Marijn Suijten wrote:
>>> On 2023-06-24 11:08:54, Krzysztof Kozlowski wrote:
On 24/06/2023 03:45, Konrad Dybcio wrote:
> On 24.06.2023 02:41, Marijn Suijten wrote:
>>
This v4 removes the common DRM ioctl, and adds just the documentation for now,
giving the lack of a common "DRM context" infrascture make it hard to implement.
v3: https://lore.kernel.org/lkml/20230621005719.836857-1-andrealm...@igalia.com/
Changes:
- Drop the ioctl
- Addresed comments com Pek
Create a section that specifies how to deal with DRM device resets for
kernel and userspace drivers.
Signed-off-by: André Almeida
---
Documentation/gpu/drm-uapi.rst | 68 ++
1 file changed, 68 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentat
Hello dri maintainers/developers,
This is a 31-day syzbot report for the dri subsystem.
All related reports/information can be found at:
https://syzkaller.appspot.com/upstream/s/dri
During the period, 3 new issues were detected and 0 were fixed.
In total, 7 issues are still open and 30 have been
Hi Frank,
I have added Merlijn who is doing a lot with PVRSGX for Maemo-Leste and the
phone-devel list since most SoC we find using a PVRSGX are smartphone
processors.
> Am 26.06.2023 um 15:45 schrieb Frank Binns :
>
> Hi Nikolaus,
>
>>
>> Some questions to the author of the new driver:
>> - a
1 - 100 of 164 matches
Mail list logo