On Thu, Oct 24, 2019 at 03:06:37PM +, Harry Wentland wrote:
> On 2019-10-23 8:00 p.m., Manasi Navare wrote:
> > Adaptive Sync is a VESA feature so add a DRM core helper to parse
> > the EDID's detailed descritors to obtain the adaptive sync monitor range.
> > Store this info as part fo drm_disp
On Wed, 23 Oct 2019 17:45:11 +0200, Boris Brezillon wrote:
> The LTA089AC29000 and LT089AC29000 are not exactly the same. Let's add
> a new compatible for the LTA variant.
>
> Signed-off-by: Boris Brezillon
> ---
> .../bindings/display/panel/toshiba,lt089ac29000.txt | 5 -
> 1 file
Applied. Thanks!
Alex
On Wed, Oct 23, 2019 at 11:09 AM Harry Wentland wrote:
>
> On 2019-10-19 3:32 a.m., Wambui Karuga wrote:
> > Remove unnecessary assignment for return value and have the
> > function return the required value directly.
> > Issue found by coccinelle:
> > @@
> > local idexpre
https://bugs.freedesktop.org/show_bug.cgi?id=112134
--- Comment #1 from Alex Deucher ---
You can grab the missing firmware from the linux firmware tree:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/amdgpu
--
You are receiving this mail because:
You are the as
Hi Dave, Daniel,
More new stuff for 5.5. I tested a back merge and it was clean.
The following changes since commit 1cd4d9eead73c004d08a58536dc726bd172eaaec:
drm/amdkfd: update for drmP.h removal (2019-10-09 12:04:48 -0500)
are available in the Git repository at:
git://people.freedesktop.
This binding specifies which CMA regions should be added to the
dmabuf heaps interface.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian Starkey
Cc: Andrew F. Davis
Cc: Chenbo Feng
Cc: Alistair Strachan
Cc:
In earlier versions of the dmabuf CMA heap, we added all CMA
areas as CMA heaps. Andrew noted this might not be desired,
and so we changed the code to only add the default CMA area.
This patch extends the earlier effort so that devices can
specifiy which CMA areas they want to add as dmabuf heaps
Adds example test entry to create and expose a camera cma region
via the dmabuf heaps interface
This isn't a patch I'm submitting to merge, but just an example
of how this functionality can be used, which I've used for
testing.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Laura Abbott
Cc: Benjamin Gai
Now that the dmabuf heaps core code has been queued, I wanted to
submit for initial review some of the changes I have pending.
In previous versions, the dmabuf CMA heap added all CMA areas to
the dmabuf heaps interface. However, Andrew noted this may not
be desirable, so I've come up with a DT bin
Now that the DMA BUF heaps core code has been queued, I wanted
to send out some of the pending changes that I've been working
on.
For use with Android and their GKI effort, it is desired that
DMA BUF heaps are able to be loaded as modules. This is required
for migrating vendors off of ION which wa
From: Sandeep Patil
Export cma_get_name, cma_alloc, cma_release, cma_for_each_area
and dma_contiguous_default_area so that we can use these from
the dmabuf cma heap when it is built as module.
Cc: Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
Cc: Brian S
Allow loading system and cma heap as a module instead of just as
a statically built in heap.
Since there isn't a good mechanism for dmabuf lifetime tracking
it isn't safe to allow the heap drivers to be unloaded, so these
drivers do not implement any module unloading functionality and
will show up
On Fri, Oct 25, 2019 at 4:32 PM Rob Herring wrote:
>
> On Fri, Oct 25, 2019 at 5:51 PM John Stultz wrote:
> >
> > This binding specifies which CMA regions should be added to the
> > dmabuf heaps interface.
>
> Is this an ION DT binding in disguise? I thought I killed that. ;)
Maybe? I may not ha
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #176 from L.S.S. ---
Unfortunately this still happens with Nemo on 5.4-rc4 kernel (official), after
switching to Manjaro Testing channel.
The same ring sdma0 timeout error appears. An interesting phenomenon is that
when the screen f
Reviewed-by: Huang Rui
-Original Message-
From: amd-gfx On Behalf Of Christian
König
Sent: Thursday, October 24, 2019 7:17 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; Zhou,
David(ChunMing)
Subject: [PATCH] drm/ttm: use the parent resv for ghost objects v3
T
On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
> introduced a GEM object mmap() hook which is expected to subtract the
> fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
> a fake offset.
>
> To f
On Fri, Oct 25, 2019 at 11:56:48AM +0530, Bhanusree wrote:
> This patch series clears the checkpatch.pl warnings
> [PATCH 1/2]:Fix Missing blank line after declarations
> [PATCH 2/2]:Fix Memory barrier without comment
>
> Bhanusree (2):
> drm/gpu: Fix Missing blank line after declarations
> dr
On Fri, Oct 25, 2019 at 11:57:38AM +0530, Bhanusree wrote:
> -Issue found using checkpatch.pl
> -Insert comments for memory barrier usage
>
> Signed-off-by: Bhanusree
Thanks for your patch, applied.
-Daniel
> ---
> drivers/gpu/drm/drm_cache.c | 8
> 1 file changed, 4 insertions(+), 4
On Fri, Oct 25, 2019 at 11:57:13AM +0530, Bhanusree wrote:
> -Insert a blank line after the declarations.
> -Issue found using checkpatch.pl
>
> Signed-off-by: Bhanusree
Applied, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_cache.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> d
On Thu, Oct 24, 2019 at 04:42:33PM +0200, Thomas Zimmermann wrote:
> Unmapping the BO memory with udl_gem_vunmap() creates a dangling pointer
> in struct udl_gem_object.vmapping. This can crash udl_handle_damage(),
> which check the pointer's value for NULL. Clear the pointer to NULL and
> let udl_
On Thu, Oct 24, 2019 at 04:42:35PM +0200, Thomas Zimmermann wrote:
> Implementing vmap() and vunmap() of struct drm_gem_object_funcs is
> required by generic fbdev emulation. Supporting free() is easy as
> well. More udl-specific interfaces can probably be replaced by GEM
> object functions in late
On Thu, Oct 24, 2019 at 04:42:37PM +0200, Thomas Zimmermann wrote:
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/udl/udl_drv.c | 3 +
> drivers/gpu/drm/udl/udl_drv.h | 4 -
> drivers/gpu/drm/udl/udl_fb.c | 263 +-
> drivers/gpu/drm/udl/udl
Hi
Am 25.10.19 um 09:40 schrieb Daniel Vetter:
> On Thu, Oct 24, 2019 at 04:42:35PM +0200, Thomas Zimmermann wrote:
>> Implementing vmap() and vunmap() of struct drm_gem_object_funcs is
>> required by generic fbdev emulation. Supporting free() is easy as
>> well. More udl-specific interfaces can p
On Fri, Oct 25, 2019 at 09:47:46AM +0200, Daniel Vetter wrote:
> On Thu, Oct 24, 2019 at 04:42:37PM +0200, Thomas Zimmermann wrote:
> > Signed-off-by: Thomas Zimmermann
> > ---
> > drivers/gpu/drm/udl/udl_drv.c | 3 +
> > drivers/gpu/drm/udl/udl_drv.h | 4 -
> > drivers/gpu/drm/udl/ud
Hi
Am 25.10.19 um 09:47 schrieb Daniel Vetter:
> On Thu, Oct 24, 2019 at 04:42:37PM +0200, Thomas Zimmermann wrote:
>> Signed-off-by: Thomas Zimmermann
>> ---
>> drivers/gpu/drm/udl/udl_drv.c | 3 +
>> drivers/gpu/drm/udl/udl_drv.h | 4 -
>> drivers/gpu/drm/udl/udl_fb.c | 263 +-
24.10.2019 16:35, Dmitry Osipenko пишет:
> 24.10.2019 14:50, Thierry Reding пишет:
>> On Sun, Jun 23, 2019 at 08:37:41PM +0300, Dmitry Osipenko wrote:
>>> On ARM32 we don't want any of the clients device to be backed by the
>>> implicit domain, simply because we can't afford such a waste on older
>
24.10.2019 18:56, Thierry Reding пишет:
> On Thu, Oct 24, 2019 at 06:47:23PM +0300, Dmitry Osipenko wrote:
>> 24.10.2019 16:50, Thierry Reding пишет:
>>> On Thu, Oct 24, 2019 at 04:28:41PM +0300, Dmitry Osipenko wrote:
24.10.2019 14:58, Thierry Reding пишет:
> On Sun, Jun 23, 2019 at 08:37
24.10.2019 14:58, Thierry Reding пишет:
> On Sun, Jun 23, 2019 at 08:37:42PM +0300, Dmitry Osipenko wrote:
>> This should should fire up on the DRM's driver module re-loader because
>> there won't be enough available domains on older Tegra SoCs.
>>
>> Cc: stable
>> Fixes: 0c407de5ed1a ("drm/tegra:
-Insert a blank line after the declarations.
-Issue found using checkpatch.pl
Signed-off-by: Bhanusree
---
drivers/gpu/drm/drm_cache.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index e574261..12f8d1b 100644
--- a/drivers/gpu/d
-Issue found using checkpatch.pl
-Insert comments for memory barrier usage
Signed-off-by: Bhanusree
---
drivers/gpu/drm/drm_cache.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 12f8d1b..03e01b0 100644
So, I'm not sure what the action items are here. It seems like we might
have uncovered a potentially icky race condition in Linux, but that this
protocol is not really affected.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.free
24.10.2019 20:28, Thierry Reding пишет:
> On Thu, Oct 24, 2019 at 07:31:19PM +0300, Dmitry Osipenko wrote:
>> 24.10.2019 19:21, Dmitry Osipenko пишет:
>>> 24.10.2019 19:09, Dmitry Osipenko пишет:
24.10.2019 18:57, Dmitry Osipenko пишет:
> 24.10.2019 18:56, Thierry Reding пишет:
>> On T
24.10.2019 19:09, Dmitry Osipenko пишет:
> 24.10.2019 18:57, Dmitry Osipenko пишет:
>> 24.10.2019 18:56, Thierry Reding пишет:
>>> On Thu, Oct 24, 2019 at 06:47:23PM +0300, Dmitry Osipenko wrote:
24.10.2019 16:50, Thierry Reding пишет:
> On Thu, Oct 24, 2019 at 04:28:41PM +0300, Dmitry Osi
Hi,
Thanks for your review and comments. Please see inline below.
On Thu, Oct 24, 2019 at 4:20 AM Thierry Reding wrote:
>
> On Tue, Oct 22, 2019 at 05:12:06PM -0700, Rajat Jain wrote:
> > Certain laptops now come with panels that have integrated privacy
> > screens on them. This patch adds suppo
24.10.2019 16:50, Thierry Reding пишет:
> On Thu, Oct 24, 2019 at 04:28:41PM +0300, Dmitry Osipenko wrote:
>> 24.10.2019 14:58, Thierry Reding пишет:
>>> On Sun, Jun 23, 2019 at 08:37:42PM +0300, Dmitry Osipenko wrote:
This should should fire up on the DRM's driver module re-loader because
>>>
24.10.2019 18:57, Dmitry Osipenko пишет:
> 24.10.2019 18:56, Thierry Reding пишет:
>> On Thu, Oct 24, 2019 at 06:47:23PM +0300, Dmitry Osipenko wrote:
>>> 24.10.2019 16:50, Thierry Reding пишет:
On Thu, Oct 24, 2019 at 04:28:41PM +0300, Dmitry Osipenko wrote:
> 24.10.2019 14:58, Thierry Re
24.10.2019 16:47, Thierry Reding пишет:
> On Thu, Oct 24, 2019 at 04:35:13PM +0300, Dmitry Osipenko wrote:
>> 24.10.2019 14:50, Thierry Reding пишет:
>>> On Sun, Jun 23, 2019 at 08:37:41PM +0300, Dmitry Osipenko wrote:
On ARM32 we don't want any of the clients device to be backed by the
i
Hi Steve,
How do you find the format problem? I have set noexpandtab in
vim ;-)
I will send a v3 patch with tabstop=8, please review later :)
Thanks a lot.
> On 22/10/2019 04:02, Yi Wang wrote:
> > We get these warnings when build kernel W=1:
> > drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6:
On Thu, Oct 24, 2019 at 07:31:37PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The ->load() and ->unload() drivers are midlayers and should be avoided
> in modern drivers. Fix this by moving the code into the driver ->probe()
> and ->remove() implementations, respectively.
>
> v2: ki
24.10.2019 14:50, Thierry Reding пишет:
> On Sun, Jun 23, 2019 at 08:37:41PM +0300, Dmitry Osipenko wrote:
>> On ARM32 we don't want any of the clients device to be backed by the
>> implicit domain, simply because we can't afford such a waste on older
>> Tegra SoCs that have very few domains availa
On Tue 2019-10-22 17:12:06, Rajat Jain wrote:
> Certain laptops now come with panels that have integrated privacy
> screens on them. This patch adds support for such panels by adding
> a privacy-screen property to the drm_connector for the panel, that
> the userspace can then use to control and che
We get these warnings when build kernel W=1:
drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous
prototype for ‘panfrost_perfcnt_clean_cache_done’ [-Wmissing-prototypes]
drivers/gpu/drm/panfrost/panfrost_perfcnt.c:40:6: warning: no previous
prototype for ‘panfrost_perfcnt_sampl
Fix misspellings of "connector" and "connection"
Signed-off-by: Geert Uytterhoeven
---
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +-
include/uapi/drm/exynos_drm.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
b/d
24.10.2019 19:21, Dmitry Osipenko пишет:
> 24.10.2019 19:09, Dmitry Osipenko пишет:
>> 24.10.2019 18:57, Dmitry Osipenko пишет:
>>> 24.10.2019 18:56, Thierry Reding пишет:
On Thu, Oct 24, 2019 at 06:47:23PM +0300, Dmitry Osipenko wrote:
> 24.10.2019 16:50, Thierry Reding пишет:
>> On T
24.10.2019 21:15, Michał Mirosław пишет:
> On Thu, Oct 24, 2019 at 07:31:37PM +0200, Thierry Reding wrote:
>> From: Thierry Reding
>>
>> The ->load() and ->unload() drivers are midlayers and should be avoided
>> in modern drivers. Fix this by moving the code into the driver ->probe()
>> and ->remo
This patch series clears the checkpatch.pl warnings
[PATCH 1/2]:Fix Missing blank line after declarations
[PATCH 2/2]:Fix Memory barrier without comment
Bhanusree (2):
drm/gpu: Fix Missing blank line after declarations
drm/gpu: Fix Memory barrier without comment Issue
drivers/gpu/drm/drm_cac
On Fri, Oct 25, 2019 at 10:20 AM Bhanusree Mahesh
wrote:
>
> Sure. I shall take care of it from next patches. Shall I resend them
> with outreachy group in cc?
Already applied both, let's to that for the next round.
-Daniel
>
> Thanks®ards,
> Bhanusree Pola.
>
> On Fri, 25 Oct 2019 at 13:04, Dan
Am 24.10.19 um 21:57 schrieb Andrey Grodzovsky:
Problem:
When run_job fails and HW fence returned is NULL we still signal
the s_fence to avoid hangs but the user has no way of knowing if
the actual HW job was ran and finished.
Fix:
Allow .run_job implementations to return ERR_PTR in the fence po
On 25/10/2019 02:30, Yi Wang wrote:
> We get these warnings when build kernel W=1:
> drivers/gpu/drm/panfrost/panfrost_perfcnt.c:35:6: warning: no previous
> prototype for ‘panfrost_perfcnt_clean_cache_done’ [-Wmissing-prototypes]
> drivers/gpu/drm/panfrost/panfrost_perfcnt.c:40:6: warning: no pre
The current documentation wrt. defio support needs an update. There
are no more users of drm_fb_helper_defio_init(), so we can remove this
interface.
Thomas Zimmermann (2):
drm/fb-helper: Remove drm_fb_helper_defio_init() and update docs
drm/todo: Clarify situation around fbdev and defio
Doc
The TODO item is misleading and makes it seem that fbdev emulation
cannot be used with SHMEM. Rephrase the text to describe the current
situation more correctly.
Signed-off-by: Thomas Zimmermann
---
Documentation/gpu/todo.rst | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --
There are no users of drm_fb_helper_defio_init(), so we can remove
it. The documenation around defio support is a bit misleading and
should mention compatibility issues with SHMEM helpers. Clarify this.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_fb_helper.c | 61 +++
On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann wrote
>
> Hi
>
> Am 25.10.19 um 09:40 schrieb Daniel Vetter:
> > On Thu, Oct 24, 2019 at 04:42:35PM +0200, Thomas Zimmermann wrote:
> >> Implementing vmap() and vunmap() of struct drm_gem_object_funcs is
> >> required by generic fbdev emulation. Su
Am Do., 24. Okt. 2019 um 18:25 Uhr schrieb Steven Price :
>
> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
> it is called as the condition of wait_event_interruptible() it must not
> sleep. Unfortuantly some free callbacks (notibly for Panfrost) do sleep.
>
> Instead let
Am 24.10.19 um 18:24 schrieb Steven Price:
> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
> it is called as the condition of wait_event_interruptible() it must not
> sleep. Unfortuantly some free callbacks (notibly for Panfrost) do sleep.
>
> Instead let's rename drm_sch
On 25/10/2019 10:43, Christian Gmeiner wrote:
> Am Do., 24. Okt. 2019 um 18:25 Uhr schrieb Steven Price
> :
>>
>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>> it is called as the condition of wait_event_interruptible() it must not
>> sleep. Unfortuantly some free cal
On Fri, 25 Oct 2019, Wambui Karuga wrote:
> Replace open coded divisor calculations with the DIV_ROUND_UP kernel
> macro for better readability.
> Issue found using coccinelle:
> @@
> expression n,d;
> @@
> (
> - ((n + d - 1) / d)
> + DIV_ROUND_UP(n,d)
> |
> - ((n + (d - 1)) / d)
> + DIV_ROUND_U
Hi
Am 25.10.19 um 11:28 schrieb Daniel Vetter:
> On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann wrote
>>
>> Hi
>>
>> Am 25.10.19 um 09:40 schrieb Daniel Vetter:
>>> On Thu, Oct 24, 2019 at 04:42:35PM +0200, Thomas Zimmermann wrote:
Implementing vmap() and vunmap() of struct drm_gem_object
On 25/10/2019 10:49, Koenig, Christian wrote:
> Am 24.10.19 um 18:24 schrieb Steven Price:
>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>> it is called as the condition of wait_event_interruptible() it must not
>> sleep. Unfortuantly some free callbacks (notibly for P
Am 25.10.19 um 12:26 schrieb Steven Price:
> On 25/10/2019 10:49, Koenig, Christian wrote:
>> Am 24.10.19 um 18:24 schrieb Steven Price:
>>> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
>>> it is called as the condition of wait_event_interruptible() it must not
>>> sleep
https://bugs.freedesktop.org/show_bug.cgi?id=112133
Bug ID: 112133
Summary: AMD Radeon 5700 / Navi: VAAPI encoding generates
garbled output
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (A
etnaviv_iommuv2_dump_size(..) returns the number of PTE * SZ_4K but
etnaviv_iommuv2_dump(..)
increments buf pointer even if there is no PTE. This results in a bad buf
pointer which gets
used for memcpy(..).
[ 264.408474] 8<--- cut here ---
[ 264.412048] Unable to handle kernel paging request a
Am Mi., 16. Okt. 2019 um 16:27 Uhr schrieb Lucas Stach :
>
> The GPU coredump function violates the locking order by holding the MMU
> context lock while trying to acquire the etnaviv_gem_object lock. This
> results in a possible ABBA deadlock with other codepaths which follow
> the established loc
drm_sched_cleanup_jobs() attempts to free finished jobs, however because
it is called as the condition of wait_event_interruptible() it must not
sleep. Unfortunately some free callbacks (notably for Panfrost) do sleep.
Instead let's rename drm_sched_cleanup_jobs() to
drm_sched_get_cleanup_job() an
https://bugs.freedesktop.org/show_bug.cgi?id=112134
Bug ID: 112134
Summary: Failed to load firmware on Raven Ridge
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severit
Am 25.10.19 um 12:51 schrieb Steven Price:
> drm_sched_cleanup_jobs() attempts to free finished jobs, however because
> it is called as the condition of wait_event_interruptible() it must not
> sleep. Unfortunately some free callbacks (notably for Panfrost) do sleep.
>
> Instead let's rename drm_sc
On Fri, Oct 25, 2019 at 12:10:49AM +0300, Dmitry Osipenko wrote:
> 24.10.2019 21:15, Michał Mirosław пишет:
> > On Thu, Oct 24, 2019 at 07:31:37PM +0200, Thierry Reding wrote:
> >> From: Thierry Reding
> >>
> >> The ->load() and ->unload() drivers are midlayers and should be avoided
> >> in modern
In the highly unlikely event that we fail to allocate the "radeon-crtc"
workqueue, we should bail cleanly rather than blindly march on with a
NULL pointer installed for the 'flip_queue' field of the 'radeon_crtc'
structure.
This was reported previously by Nicolas, but I don't think his fix was
cor
Den 25.10.2019 10.00, skrev Daniel Vetter:
> On Fri, Oct 25, 2019 at 09:47:46AM +0200, Daniel Vetter wrote:
>> On Thu, Oct 24, 2019 at 04:42:37PM +0200, Thomas Zimmermann wrote:
>>> Signed-off-by: Thomas Zimmermann
>>> ---
>>> drivers/gpu/drm/udl/udl_drv.c | 3 +
>>> drivers/gpu/drm/udl/u
On Fri, 25 Oct 2019 at 11:26, Sumit Semwal wrote:
>
> Hi John,
>
> On Tue, 22 Oct 2019 at 00:33, John Stultz wrote:
> >
> > Lucky number 13! :)
> >
> > Last week in v12 I had re-added some symbol exports to support
> > later patches I have pending to enable loading heaps from
> > modules. He remi
On Thu, Oct 24, 2019 at 01:45:16PM -0700, Rajat Jain wrote:
> Hi,
>
> Thanks for your review and comments. Please see inline below.
>
> On Thu, Oct 24, 2019 at 4:20 AM Thierry Reding
> wrote:
> >
> > On Tue, Oct 22, 2019 at 05:12:06PM -0700, Rajat Jain wrote:
> > > Certain laptops now come with
Hi Noralf
Am 25.10.19 um 13:22 schrieb Noralf Trønnes:
>
>
> Den 25.10.2019 10.00, skrev Daniel Vetter:
>> On Fri, Oct 25, 2019 at 09:47:46AM +0200, Daniel Vetter wrote:
>>> On Thu, Oct 24, 2019 at 04:42:37PM +0200, Thomas Zimmermann wrote:
Signed-off-by: Thomas Zimmermann
---
d
Den 25.10.2019 12.12, skrev Thomas Zimmermann:
> Hi
>
> Am 25.10.19 um 11:28 schrieb Daniel Vetter:
>> On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann wrote
>>>
>>> Hi
>>>
>>> Am 25.10.19 um 09:40 schrieb Daniel Vetter:
On Thu, Oct 24, 2019 at 04:42:35PM +0200, Thomas Zimmermann wrote:
>
Den 25.10.2019 13.44, skrev Noralf Trønnes:
>
>
> Den 25.10.2019 12.12, skrev Thomas Zimmermann:
>> Hi
>>
>> Am 25.10.19 um 11:28 schrieb Daniel Vetter:
>>> On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann
>>> wrote
Hi
Am 25.10.19 um 09:40 schrieb Daniel Vetter:
> On
On Thu, Oct 24, 2019 at 09:46:58PM +0300, Dmitry Osipenko wrote:
> 24.10.2019 20:28, Thierry Reding пишет:
> > On Thu, Oct 24, 2019 at 07:31:19PM +0300, Dmitry Osipenko wrote:
> >> 24.10.2019 19:21, Dmitry Osipenko пишет:
> >>> 24.10.2019 19:09, Dmitry Osipenko пишет:
> 24.10.2019 18:57, Dmitr
On Thu, Oct 24, 2019 at 02:38:53PM +0200, Daniel Vetter wrote:
> On Thu, Oct 24, 2019 at 11:48:01AM +0100, Colin King wrote:
> > From: Colin Ian King
> >
> > Two different fixes have addressed the same memory leak of bin and
> > this now causes a double free of bin. While the individual memory
>
https://bugs.freedesktop.org/show_bug.cgi?id=108941
--- Comment #3 from brai...@gmail.com ---
Patch https://patchwork.freedesktop.org/patch/314322/ fixes this issue for me.
--
You are receiving this mail because:
You are the assignee for the bug.___
dr
(cc: Gerd)
Hi
Am 25.10.19 um 13:44 schrieb Noralf Trønnes:
>
>
> Den 25.10.2019 12.12, skrev Thomas Zimmermann:
>> Hi
>>
>> Am 25.10.19 um 11:28 schrieb Daniel Vetter:
>>> On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann
>>> wrote
Hi
Am 25.10.19 um 09:40 schrieb Daniel Ve
Hi Rob,
On Fri, Jul 5, 2019 at 6:46 PM Rob Herring wrote:
> Convert the common panel bindings to DT schema consolidating scattered
> definitions to a single schema file.
>
> The 'simple-panel' binding just a collection of properties and not a
> complete binding itself. All of the 'simple-panel' p
https://bugs.freedesktop.org/show_bug.cgi?id=111481
L.S.S. changed:
What|Removed |Added
Attachment #145807|0 |1
is obsolete|
On Fri, Oct 25, 2019 at 12:33 AM Maxime Ripard wrote:
>
> On Thu, Oct 24, 2019 at 01:28:28PM +0530, Jagan Teki wrote:
> > On Thu, Oct 17, 2019 at 3:22 PM Maxime Ripard wrote:
> > >
> > > On Wed, Oct 16, 2019 at 02:19:44PM +0530, Jagan Teki wrote:
> > > > On Wed, Oct 16, 2019 at 1:33 PM Maxime Rip
On 23/10/2019 17:44, Boris Brezillon wrote:
> Change the prefix of bridge helpers targeting a bridge chain from
> drm_bridge_ to drm_bridge_chain_ to better reflect the fact that
> the operation will happen on all elements of chain, starting at the
> bridge passed in argument.
>
> Signed-off-by: B
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #164 from L.S.S. ---
EDIT: Did some analysis myself about the GCVM_L2_PROTECTION_FAULT errors...
In the errors last time contained this:
src_id:0 ring:40 vmid:7 pasid:32769
GCVM_L2_PROTECTION_FAULT_STATUS:0x00741A51 (only on first
On 23/10/2019 17:44, Boris Brezillon wrote:
> We are about to replace the single-linked bridge list by a double-linked
> one based on list.h, leading to the suppression of the encoder->bridge
> field. But before we can do that we must provide a
> drm_bridge_chain_get_first_bridge() bridge helper an
On 23/10/2019 17:44, Boris Brezillon wrote:
> And use it in drivers accessing the bridge->next field directly.
> This is part of our attempt to make the bridge chain a double-linked list
> based on the generic list helpers.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * Inline drm_
On 23/10/2019 17:44, Boris Brezillon wrote:
> To iterate over all bridges attached to a specific encoder.
>
> Suggested-by: Laurent Pinchart
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * None
>
> Changes in v2:
> * New patch
> ---
> include/drm/drm_bridge.h | 11 +++
> 1
Hi,
> > I had a flag to set this in the initial version of the shmem helper
> > modeled after udl, but Thomas Hellstrom brought up a question and it was
> > dropped. The issue was beyond my understanding:
> >
> > [PATCH v3 0/2] drm: Add shmem GEM library
> > https://lists.freedesktop.org/archiv
On 23/10/2019 17:44, Boris Brezillon wrote:
> So that each element in the chain can easily access its predecessor.
> This will be needed to support bus format negotiation between elements
> of the bridge chain.
>
> Signed-off-by: Boris Brezillon
> ---
> Changes in v3:
> * None
>
> Changes in v2:
Instead of tracking per-slot utilisation track a single value for the
entire GPU. Ultimately it doesn't matter if the GPU is busy with only
vertex or a combination of vertex and fragment processing - if it's busy
then it's busy and devfreq should be scaling appropriately.
This also makes way for b
The devfreq implementation in panfrost is unnecessarily open coded. It
also tracks utilisation metrics per slot which isn't very useful. Let's
tidy it up!
Changes since v1:
http://lkml.kernel.org/r/20190912112804.10104-1-steven.price%40arm.com
* Rebased onto latest drm-misc-next, specifically af
Use dev_pm_opp_set_rate() instead of open coding the devfreq
integration, simplifying the code.
Reviewed-by: Mark Brown
Reviewed-by: Tomeu Vizoso
Acked-by: Alyssa Rosenzweig
Signed-off-by: Steven Price
---
drivers/gpu/drm/panfrost/panfrost_devfreq.c | 60 -
drivers/gpu/drm
Den 25.10.2019 14.20, skrev Thomas Zimmermann:
> (cc: Gerd)
>
> Hi
>
> Am 25.10.19 um 13:44 schrieb Noralf Trønnes:
>>
>>
>> Den 25.10.2019 12.12, skrev Thomas Zimmermann:
>>> Hi
>>>
>>> Am 25.10.19 um 11:28 schrieb Daniel Vetter:
On Fri, Oct 25, 2019 at 9:59 AM Thomas Zimmermann
wr
From: Emily Deng
[ Upstream commit 526c654a8a0641d4289bf65effde4d6095bd8384 ]
Issue:
Will have follow error when reload driver:
[ 3986.567739] sysfs: cannot create duplicate filename
'/devices/pci:00/:00:07.0/drm_dp_aux_dev'
[ 3986.567743] CPU: 6 PID: 1767 Comm: modprobe Tainted: G
From: Rob Clark
[ Upstream commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c ]
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generat
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
cfg8
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
cfg8
From: Rob Clark
[ Upstream commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c ]
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generat
From: Rob Clark
[ Upstream commit 0036bc73ccbe7e600a3468bf8e8879b122252274 ]
Recently splats like this started showing up:
WARNING: CPU: 4 PID: 251 at drivers/iommu/dma-iommu.c:451
__iommu_dma_unmap+0xb8/0xc0
Modules linked in: ath10k_snoc ath10k_core fuse msm ath mac80211 uvcvideo
cfg8
From: Rob Clark
[ Upstream commit 3de433c5b38af49a5fc7602721e2ab5d39f1e69c ]
[subject was: drm/msm: shake fist angrily at dma-mapping]
So, using dma_sync_* for our cache needs works out w/ dma iommu ops, but
it falls appart with dma direct ops. The problem is that, depending on
display generat
On Wed, Oct 23, 2019 at 06:56:17PM +0200, Stephan Gerhold wrote:
> The DSI PHY regulator supports two regulator modes: LDO and DCDC.
> This mode can be selected using the "qcom,dsi-phy-regulator-ldo-mode"
> device tree property.
>
> However, at the moment only the 20nm PHY driver actually implemen
1 - 100 of 157 matches
Mail list logo
