On Mon, 26 Jun 2023 21:02:14 -0700, Belgaumkar, Vinay wrote:
>
>
> On 6/26/2023 8:17 PM, Dixit, Ashutosh wrote:
> > On Mon, 26 Jun 2023 19:12:18 -0700, Vinay Belgaumkar wrote:
> >> GuC load takes longer sometimes due to GT frequency not ramping up.
> >> Add perf_limit_reasons to the existing warn p
On 2023-06-27 08:24:41, Krzysztof Kozlowski wrote:
> On 26/06/2023 20:53, Marijn Suijten wrote:
> > On 2023-06-26 20:51:38, Marijn Suijten wrote:
> >
> >>> Not really, binding also defines the list of clocks - their order and
> >>> specific entries. This changes.
> >>
> >> And so it does in "dt-bi
Hi David,
> 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 f
On 26/06/2023 20:53, Marijn Suijten wrote:
> On 2023-06-26 20:51:38, Marijn Suijten wrote:
>
>>> Not really, binding also defines the list of clocks - their order and
>>> specific entries. This changes.
>>
>> And so it does in "dt-bindings: clock: qcom,dispcc-sm6125: Remove unused
>> GCC_DISP_AHB_
Hi Linus,
please pull some fbdev fixes & cleanups for kernel 6.5-rc1.
Includes is a fix for a potential out-of-bound memory access in
fast_imageblit() and the switch of the VIA fbdev driver to use GPIO
descriptors.
Thanks!
Helge
--
The following changes since commit 9561de3a55bed6bd
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
Fixes: 8716a6473e6c ("drm/panel: S
Smatch complains:
drivers/gpu/drm/msm/adreno/a5xx_gpu.c:1753
a5xx_gpu_init() warn: variable dereferenced before
check 'pdev' (see line 1746)
When no device is defined, dereferencing pdev is a NULL dereference.
Fix this by dereferencing pdev to get the config post the NULL c
On 6/26/2023 8:17 PM, Dixit, Ashutosh wrote:
On Mon, 26 Jun 2023 19:12:18 -0700, Vinay Belgaumkar wrote:
GuC load takes longer sometimes due to GT frequency not ramping up.
Add perf_limit_reasons to the existing warn print to see if frequency
is being throttled.
Signed-off-by: Vinay Belgaumka
From: Zack Rusin
Atomic modesetting support mouse cursor offsets via the hotspot
properties that are creates on cursor planes. All drivers which
support hotspot are atomic and the legacy code has been implemented
in terms of the atomic properties as well.
Due to the above the lagacy cursor hotsp
From: Zack Rusin
Atomic modesetting code lacked support for specifying mouse cursor
hotspots. The legacy kms DRM_IOCTL_MODE_CURSOR2 had support for setting
the hotspot but the functionality was not implemented in the new atomic
paths.
Due to the lack of hotspots in the atomic paths userspace com
From: Zack Rusin
Virtualized drivers place additional restrictions on the cursor plane
which breaks the contract of universal planes. To allow atomic
modesettings with virtualized drivers the clients need to advertise
that they're capable of dealing with those extra restrictions.
To do that intr
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Cc: Hans de Goede
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/vboxvideo/vbox_mode.
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Cc: Martin Krastev
Cc: Maaz Mombasawala
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 9 ++---
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Reviewed-by: Gerd Hoffmann
Cc: David Airlie
Cc: Gurchetan Singh
Cc: Chia-I Wu
Cc: Daniel Vett
From: Zack Rusin
Atomic modesetting got support for mouse hotspots via the hotspot
properties. Port the legacy kms hotspot handling to the new properties
on cursor planes.
Signed-off-by: Zack Rusin
Reviewed-by: Gerd Hoffmann
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: virtualizat...@lists.linux-fo
From: Zack Rusin
Cursor planes on virtualized drivers have special meaning and require
that the clients handle them in specific ways, e.g. the cursor plane
should react to the mouse movement the way a mouse cursor would be
expected to and the client is required to set hotspot properties on it
in
From: Zack Rusin
v3: Renames, fixes and cleanups suggested by Daniel, Simon and Pekka
after v2. There's no major changes in functionality. Please let me know
if I missed anything, it's been a while since v2.
Virtualized drivers have had a lot of issues with cursor support on top
of atomic modese
On Mon, 26 Jun 2023 19:12:18 -0700, Vinay Belgaumkar wrote:
>
> GuC load takes longer sometimes due to GT frequency not ramping up.
> Add perf_limit_reasons to the existing warn print to see if frequency
> is being throttled.
>
> Signed-off-by: Vinay Belgaumkar
> ---
> drivers/gpu/drm/i915/gt/u
GuC load takes longer sometimes due to GT frequency not ramping up.
Add perf_limit_reasons to the existing warn print to see if frequency
is being throttled.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/driver
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
include/drm/gpu_scheduler.h
between commit:
db8b4968a8d0 ("drm/sched: Call drm_sched_fence_set_parent() from
drm_sched_fence_scheduled()")
from the drm-misc-fixes tree and commit:
539f9ee4b52a ("drm/scheduler: properly
On Tue, 27 Jun 2023 at 03:45, Jessica Zhang wrote:
>
>
>
> On 6/26/2023 5:06 PM, Dmitry Baryshkov wrote:
> > On 27/06/2023 02:02, Jessica Zhang wrote:
> >>
> >>
> >> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
> >>> On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
> Introduce an
On 6/26/2023 5:06 PM, Dmitry Baryshkov wrote:
On 27/06/2023 02:02, Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill
On Mon, Jun 26, 2023 at 03:02:22PM +0200, Greg KH wrote:
> 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 t
On 27/06/2023 02:02, Jessica Zhang wrote:
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer is set
to NULL,
On 11/7/2022 11:37 AM, Ville Syrjälä wrote:
On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:
Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer is set
to NULL, memory fetch will be disabled.
Thinking
Benjamin,
On Thu, Jun 8, 2023 at 8:37 AM Benjamin Tissoires
wrote:
>
> > +static const struct drm_panel_follower_funcs
> > i2c_hid_core_panel_follower_funcs = {
> > + .panel_prepared = i2c_hid_core_panel_prepared,
> > + .panel_unpreparing = i2c_hid_core_panel_unpreparing,
> > +};
>
> Can
On 26.06.2023 22:28, Marijn Suijten wrote:
> On 2023-06-26 20:57:51, Konrad Dybcio wrote:
>> On 26.06.2023 19:54, Marijn Suijten wrote:
>>> 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:
>>>
> > As pointed out by Christian, this would optimize the "get all mappings
> > backed by a specific BO from a given VM" use case.
> >
> > The question for me is, do other drivers than amdgpu commonly need this?
>
> I have no idea.
>
> >
> > And what does amdgpu need this for? Maybe amdgpu does some
Hi,
On 6/26/23 11:33, André Almeida wrote:
> 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(+)
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to hashed-waitqueue wait, assuming an input 'ret' in
___wait_var_event() macro is used as a timeout value.
Signed-off-by: Byungchul Park
---
include/linux/wait_bit.h | 2 +-
1 file changed, 1 insertion(+), 1 del
The current code records all the waits for later use to track relation
between waits and events in each context. However, since the same class
is handled the same way, it'd be okay to record only one on behalf of
the others if they all have the same class.
Even though it's the ideal to search the
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to wait_for_completion()/complete().
Signed-off-by: Byungchul Park
---
include/linux/completion.h | 4 ++--
kernel/sched/completion.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/inclu
Makes Dept able to track dependencies by waitqueue waits.
Signed-off-by: Byungchul Park
---
include/linux/wait.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index a0307b516b09..ff349e609da7 100644
--- a/include/linux/wait.h
+++ b/include/lin
cb92173d1f0 ("locking/lockdep, cpu/hotplug: Annotate AP thread") was
introduced to make lockdep_assert_cpus_held() work in AP thread.
However, the annotation is too strong for that purpose. We don't have to
use more than try lock annotation for that.
Furthermore, now that Dept was introduced, fal
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to waitqueue wait, assuming an input 'ret' in
___wait_event() macro is used as a timeout value.
Signed-off-by: Byungchul Park
---
include/linux/wait.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff
Wrapped the base APIs for easier annotation on wait and event. Start
with supporting waiters on each single event. More general support for
multiple events is a future work. Do more when the need arises.
How to annotate (the simplest way):
1. Initaialize a map for the interesting wait.
/*
Yes. How to place Dept in here looks so ugly. But it's inevitable as
long as relying on Lockdep. The way should be enhanced gradually.
1. Basically relies on Lockdep to track typical locks and IRQ things.
2. Dept fails to recognize IRQ situation so it generates false alarms
when raw_l
There is a case where total maps for its wait/event is so large in size.
For instance, struct page for PG_locked and PG_writeback is the case.
The additional memory size for the maps would be 'the # of pages *
sizeof(struct dept_map)' if each struct page keeps its map all the way,
which might be to
It'd be useful to show Dept internal stats and dependency graph on
runtime via proc for better information. Introduced the knobs.
Signed-off-by: Byungchul Park
---
kernel/dependency/Makefile| 1 +
kernel/dependency/dept.c | 24 +++-
kernel/dependency/dept_internal.h | 26 ++
Makes Dept able to track dependencies by PG_{locked,writeback} waits.
Signed-off-by: Byungchul Park
---
mm/filemap.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/mm/filemap.c b/mm/filemap.c
index c4d4ace9cc70..adc49cb59db6 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -42,6
Workqueue already provides concurrency control. By that, any wait in a
work doesn't prevents events in other works with the control enabled.
Thus, each work would better be considered a different context.
So let Dept assign a different context id to each work.
Signed-off-by: Byungchul Park
---
Makes Dept able to track dependencies by
wait_for_completion()/complete().
Signed-off-by: Byungchul Park
---
include/linux/completion.h | 30 +-
1 file changed, 25 insertions(+), 5 deletions(-)
diff --git a/include/linux/completion.h b/include/linux/completion.h
inde
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to dma fence wait.
Signed-off-by: Byungchul Park
---
drivers/dma-buf/dma-fence.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
Makes Dept able to track dependencies by hashed-waitqueue waits.
Signed-off-by: Byungchul Park
---
include/linux/wait_bit.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/wait_bit.h b/include/linux/wait_bit.h
index 7725b7579b78..fe89282c3e96 100644
--- a/include/linux/wait_
CURRENT STATUS
--
Lockdep tracks acquisition order of locks in order to detect deadlock,
and IRQ and IRQ enable/disable state as well to take accident
acquisitions into account.
Lockdep should be turned off once it detects and reports a deadlock
since the data structure and algorithm a
Dept engine works in a constrained environment. For example, Dept cannot
make use of dynamic allocation e.g. kmalloc(). So Dept has been using
static pools to keep memory chunks Dept uses.
However, Dept would barely work once any of the pools gets run out. So
implemented a mechanism for the refill
Currently, Dept only tracks the real waits of PG_{locked,writeback} that
actually happened having gone through __schedule() to avoid false
positives. However, it ends in limited capacity for deadlock detection,
because anyway there might be still way more potential dependencies by
the waits that ha
Now that CONFIG_DEPT_AGGRESSIVE_TIMEOUT_WAIT was introduced, apply the
consideration to swait, assuming an input 'ret' in ___swait_event()
macro is used as a timeout value.
Signed-off-by: Byungchul Park
---
include/linux/swait.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a
llist_head and llist_node can be used by very primitives. For example,
Dept for tracking dependency uses llist things in its header. To avoid
header dependency, move those to types.h.
Signed-off-by: Byungchul Park
---
include/linux/llist.h | 8
include/linux/types.h | 8
2 file
Makes Dept able to track dma fence waits.
Signed-off-by: Byungchul Park
---
drivers/dma-buf/dma-fence.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c
index 406b4e26f538..1db4bc0e8adc 100644
--- a/drivers/dma-buf/dma-fence.c
+++
It enters kernel mode on each syscall and each syscall handling should
be considered independently from the point of view of Dept. Otherwise,
Dept may wrongly track dependencies across different syscalls.
That might be a real dependency from user mode. However, now that Dept
just started to work,
>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://lore.kernel.org/lkml/6383cde5-cf4b-facf-6e07-1378a4856...@i-love.sakura.ne.j
Makes Dept able to track dependencies by swaits.
Signed-off-by: Byungchul Park
---
include/linux/swait.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/linux/swait.h b/include/linux/swait.h
index 6a8c22b8c2a5..02848211cef5 100644
--- a/include/linux/swait.h
+++ b/include/linux/sw
Waits with valid timeouts don't actually cause deadlocks. However, Dept
has been reporting the cases as well because it's worth informing the
circular dependency for some cases where, for example, timeout is used
to avoid a deadlock but not meant to be expired.
However, yes, there are also a lot o
Wrapped the base APIs for easier annotation on typical lock.
Signed-off-by: Byungchul Park
---
include/linux/dept_ldt.h | 77
1 file changed, 77 insertions(+)
create mode 100644 include/linux/dept_ldt.h
diff --git a/include/linux/dept_ldt.h b/include/li
Hi Manikandan,
On Tue, Jun 13, 2023 at 12:34:23PM +0530, Manikandan Muralidharan wrote:
> - XLCDC in SAM9X7 has different sets of registers and additional
> configuration bits when compared to previous HLCDC IP. Read/write
> operation on the controller registers is now separated using the
> XLCDC
On 2023-06-26 20:57:51, Konrad Dybcio wrote:
> On 26.06.2023 19:54, Marijn Suijten wrote:
> > 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:
Hi Manikandan,
On Tue, Jun 13, 2023 at 12:34:20PM +0530, Manikandan Muralidharan wrote:
> Add the LCD controller layer definition and descriptor structure for SAM9X7
> for the following layers,
> - Base Layer
> - Overlay1 Layer
> - Overlay2 Layer
> - High End Overlay
>
> Signed-off-by: Manikandan
On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> 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
> > requ
Also return -ENOMEM if such a failure happens, the implement should take
responsibility for the error handling.
Signed-off-by: Sui Jingfeng
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
On 26.06.2023 19:54, Marijn Suijten wrote:
> 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
On 2023-06-26 20:51:38, Marijn Suijten wrote:
> > Not really, binding also defines the list of clocks - their order and
> > specific entries. This changes.
>
> And so it does in "dt-bindings: clock: qcom,dispcc-sm6125: Remove unused
> GCC_DISP_AHB_CLK"?
Never mind: it is the last item so the ord
On 2023-06-26 20:29:37, Krzysztof Kozlowski wrote:
> 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 w
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
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
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
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
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:
>>
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.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
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
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
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
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: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 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:
> >>>
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 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
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
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 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
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
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 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
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 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
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 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);
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 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 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, 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
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, 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
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: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
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 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
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.
1 - 100 of 164 matches
Mail list logo
