https://bugzilla.kernel.org/show_bug.cgi?id=204559
--- Comment #11 from Christopher Snowhill (kod...@gmail.com) ---
Oops, I neglected to mention: The system is non-responsive to input devices, as
the USB input appears to all be completely powered off after the GPU crashes,
but the network interfac
https://bugzilla.kernel.org/show_bug.cgi?id=204559
Christopher Snowhill (kod...@gmail.com) changed:
What|Removed |Added
CC||kod...@gmail.com
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #86 from Paul Ezvan ---
I was also impacted by this bug (amdgpu hangs on random conditions with similar
messages as the one exposed) with any kernel/mesa version combination other
than the ones on Debian Stretch (any other distro or
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #11 from Julien Isorce ---
Hi Michel, I confirm the attached patch fixes the issues for me too.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mail
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #97 from Rodney A Morris ---
Created attachment 145290
--> https://bugs.freedesktop.org/attachment.cgi?id=145290&action=edit
dmesg for crash
dmesg from crash while playing Hearts of Iron IV using Steam. Related to
comment #96.
-
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #96 from Rodney A Morris ---
(In reply to Mauro Gaspari from comment #90)
I am experiencing periodic lockups with various games, including Hearts of Iron
IV, BATTLETECH, and Stellaris all being played through Steam. Below is the
mo
On Thu, Sep 5, 2019 at 3:30 PM Rob Clark wrote:
>
> On Thu, Sep 5, 2019 at 12:05 PM Rob Clark wrote:
> >
> > On Thu, Sep 5, 2019 at 10:03 AM Rob Clark wrote:
> > >
> > > On Wed, Sep 4, 2019 at 11:06 AM Robin Murphy wrote:
> > > >
> > > > On 04/09/2019 01:12, Rob Clark wrote:
> > > > > On Tue, S
On Fri, Sep 6, 2019 at 3:16 PM Marek Olšák wrote:
>
> + dri-devel
>
> On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote:
>>
>> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc passing
>> it to user space
>> instead of unused DRM driver name descriptor.
>>
>> Change-Id: I809f6
On 9/6/19 10:47 AM, Daniel Vetter wrote:
> I missed that when extending the lockdep annotations to the
> nonblocking case.
>
> I missed this while testing since in the i915 mmu notifiers is hitting
> a nice lockdep splat already before the point of going into oom killer
> mode :-/
>
> Reported-by
+ dri-devel
On Tue, Sep 3, 2019 at 5:41 PM Jiang, Sonny wrote:
> Add DRM device name and use DRM_IOCTL_VERSION ioctl drmVersion::desc
> passing it to user space
> instead of unused DRM driver name descriptor.
>
> Change-Id: I809f6d3e057111417efbe8fa7cab8f0113ba4b21
> Signed-off-by: Sonny Jiang
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 4 insertions(+)
diff --git a/dri
From: Rob Clark
Avoid attaching any non-driver managed domain if the driver indicates
that it manages the iommu directly.
Signed-off-by: Rob Clark
---
drivers/iommu/iommu.c| 2 +-
drivers/iommu/of_iommu.c | 3 +++
include/linux/device.h | 3 ++-
3 files changed, 6 insertions(+), 2 deleti
From: Rob Clark
One of the challenges we have to enable the aarch64 laptops upstream
is dealing with the fact that the bootloader enables the display and
takes the corresponding SMMU context-bank out of BYPASS. Unfortunately,
currently, the IOMMU framework attaches a DMA (or potentially an
IDENT
https://bugs.freedesktop.org/show_bug.cgi?id=109389
--- Comment #8 from Czcibor Bohusz-Dobosz ---
Created attachment 145289
--> https://bugs.freedesktop.org/attachment.cgi?id=145289&action=edit
DRM/AMDgpu glxgears memleak log
For comparison, I attach the bcc memleak log of glxgears taken with
https://bugs.freedesktop.org/show_bug.cgi?id=109389
--- Comment #7 from Czcibor Bohusz-Dobosz ---
Created attachment 145288
--> https://bugs.freedesktop.org/attachment.cgi?id=145288&action=edit
DRM/Radeon glxgears memleak log
Took a while to perform some more tests, and it turns out that runni
>
> On Tue, 6 Aug 2019 21:00:10 +0300 From: Jaak Ristioja
> > Hello!
> >
> > I'm writing to report a crash in the QXL / DRM code in the Linux kernel.
> > I originally filed the issue on LaunchPad and more details can be found
> > there, although I doubt whether these details are useful.
> >
>
https://bugzilla.kernel.org/show_bug.cgi?id=204683
--- Comment #7 from Soeren Grunewald (soeren.grunew...@gmx.net) ---
Created attachment 284869
--> https://bugzilla.kernel.org/attachment.cgi?id=284869&action=edit
Kernel trace
It seems I have the same issue. I run on fedora 30 with testing-upda
dpu_kms.dev will never be NULL, so don't bother checking.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 8 -
.../drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 4 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 30 +--
3 files changed,
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h
index 4c889aabdaf9..6ceba33a179e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.
msm_drm_private.kms will only be NULL in the dummy headless case, so
there is no need to check it in the dpu display driver.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 23 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 12 +++---
d
drm_crtc.dev will never be NULL, so no need to check it.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 6 +++---
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/d
drm_device.dev_private is set to a non-NULL msm_drm_private
struct in msm_drm_init. Successful initialization of msm means
that dev_private is non-NULL so there is no need to check it
everywhere.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 6 --
dri
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c| 5 -
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 7 ---
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
index ce59adff06aa
Add very trivial allocation and import test for dma-heaps,
utilizing the vgem driver as a test importer.
A good chunk of this code taken from:
tools/testing/selftests/android/ion/ionmap_test.c
Originally by Laura Abbott
Cc: Benjamin Gaignard
Cc: Sumit Semwal
Cc: Liam Mark
Cc: Pratik Patel
This adds a CMA heap, which allows userspace to allocate
a dma-buf of contiguous memory out of a CMA region.
This code is an evolution of the Android ION implementation, so
thanks to its original author and maintainters:
Benjamin Gaignard, Laura Abbott, and others!
Cc: Laura Abbott
Cc: Benjami
This patch adds system heap to the dma-buf heaps framework.
This allows applications to get a page-allocator backed dma-buf
for non-contiguous memory.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cr
Add generic helper dmabuf ops for dma heaps, so we can reduce
the amount of duplicative code for the exported dmabufs.
This code is an evolution of the Android ION implementation, so
thanks to its original authors and maintainters:
Rebecca Schultz Zavin, Colin Cross, Laura Abbott, and others!
C
From: "Andrew F. Davis"
This framework allows a unified userspace interface for dma-buf
exporters, allowing userland to allocate specific types of memory
for use in dma-buf sharing.
Each heap is given its own device node, which a user can allocate
a dma-buf fd from using the DMA_HEAP_IOC_ALLOC.
Here is yet another pass at the dma-buf heaps patchset Andrew
and I have been working on which tries to destage a fair chunk
of ION functionality.
The patchset implements per-heap devices which can be opened
directly and then an ioctl is used to allocate a dmabuf from the
heap.
The interface is s
On Fri, Sep 06, 2019 at 05:13:00PM +0200, Arnd Bergmann wrote:
> This function lost its only call site as part of
> earlier dead code removal, so remove it as well:
>
> drivers/video/fbdev/sa1100fb.c:975:21: error: unused function
> 'sa1100fb_min_dma_period' [-Werror,-Wunused-function]
>
> Fixes
On Fri, Sep 06, 2019 at 02:20:52PM +0200, Thomas Zimmermann wrote:
> Generic fbdev emulation maps and unmaps the console BO for updating it's
> content from the shadow buffer. If this involves an actual mapping
> operation (instead of reusing an existing mapping), lots of debug messages
> may be pr
On Fri, Sep 06, 2019 at 04:26:15PM +0100, Daniel Stone wrote:
> On Fri, 6 Sep 2019 at 16:19, Daniel Vetter wrote:
> > On Fri, Sep 6, 2019 at 4:45 PM Daniel Vetter wrote:
> > > We forgot that.
> > >
> > > Proof is the one igt testcase we have:
> > >
> > > https://gitlab.freedesktop.org/drm/igt-gpu
On Fri, Sep 06, 2019 at 07:11:14PM +0100, Colin King wrote:
> From: Colin Ian King
>
> Don't populate the array wtst_xlat on the stack but instead make it
> static const. Makes the object code smaller by 89 bytes.
>
> Before:
>text data bss dec hex filename
> 14347
From: Colin Ian King
Don't populate the array wtst_xlat on the stack but instead make it
static const. Makes the object code smaller by 89 bytes.
Before:
textdata bss dec hex filename
14347 840 0 151873b53 fbdev/matrox/matroxfb_misc.o
After:
textdata
I missed that when extending the lockdep annotations to the
nonblocking case.
I missed this while testing since in the i915 mmu notifiers is hitting
a nice lockdep splat already before the point of going into oom killer
mode :-/
Reported-by: syzbot+aaedc50d99a03250f...@syzkaller.appspotmail.com
F
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #75 from tempel.jul...@gmail.com ---
Is it possible that Wine or the affected programs in Wine are the clients that
are at fault for this?
As it happens with my Arch Plasma setup and also a fresh Fedora Gnome
installation, it seems im
On Fri, 2019-09-06 at 14:27 +0300, Ville Syrjälä wrote:
> On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza
> wrote:
> > From: Dhinakaran Pandiyan
> >
> > Currently we restrict the number of encoders that can be linked to
> > a connector to 3, increase it to match the maximum number
Hello,
syzbot found the following crash on:
HEAD commit:6d028043 Add linux-next specific files for 20190830
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16cbf22a60
kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69
dashboard
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #10 from Michel Dänzer ---
(In reply to Julien Isorce from comment #9)
> gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse !
> vaapih264dec ! vaapipostproc ! videoconvert ! ximagesink
>
> (with and without vaapipostpro
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Attachment #144933|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Attachment #144932|0 |1
is obsolete|
From: Markus Elfring
Date: Fri, 6 Sep 2019 18:40:48 +0200
Simplify these function implementations by using a known function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 6 +-
drivers/gpu/drm/omapdrm
https://bugs.freedesktop.org/show_bug.cgi?id=111021
erhar...@mailbox.org changed:
What|Removed |Added
Summary|[kernel 5.2.1][amdgpu][CIK] |[kernel
|BUG: K
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #74 from Nicholas Kazlauskas ---
(In reply to Michel Dänzer from comment #73)
> Looks like some client repeatedly calls XForceScreenSaver (probably to
> prevent the monitors from blanking), which results in the DPMS property
> gettin
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #73 from Michel Dänzer ---
Looks like some client repeatedly calls XForceScreenSaver (probably to prevent
the monitors from blanking), which results in the DPMS property getting re-set
over and over. Nicholas, maybe the kernel could
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #9 from Julien Isorce ---
Hi Michel, nice catch!
Instead of using totem which has other issues can you try:
gst-launch-1.0 filesrc location=test.mp4 ! qtdemux ! h264parse ! vaapih264dec !
vaapipostproc ! videoconvert ! ximagesink
On Fri, Sep 06, 2019 at 10:56:10AM +0300, Jani Nikula wrote:
> On Fri, 06 Sep 2019, Maxime Ripard wrote:
> > The commit 3764137906a5 ("drm/modes: Introduce a whitelist for the named
> > modes") introduced a whitelist in the named modes lookup code in order to
> > be a bit more robust.
> >
> > Howe
Hi Dave,
This time around:
+ move msm8998 (snapdragon 835) display support
+ dpu fixes/cleanup
+ better async commit support for cursor updates
(for dpu for now, I'll add mdp5 and possibly
mdp4 once the movers deliver boxes full of my
older hardware, so for v5.5)
The following change
The pull request you sent on Fri, 6 Sep 2019 17:18:34 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-09-06
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/08d433d8121598f7c2a45f3461c534746b1ed05b
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
Hello, Daniel.
On Fri, Sep 06, 2019 at 05:34:16PM +0200, Daniel Vetter wrote:
> > Hmm... what'd be the fundamental difference from slab or socket memory
> > which are handled through memcg? Is system memory used by GPUs have
> > further global restrictions in addition to the amount of physical
>
Hello, Daniel.
On Fri, Sep 06, 2019 at 05:36:02PM +0200, Daniel Vetter wrote:
> Block devices are a great example I think. How do you handle the
> partitions on that? For drm we also have a main minor interface, and
cgroup IO controllers only distribute hardware IO capacity and are
blind to parti
On Fri, Sep 6, 2019 at 5:29 PM Tejun Heo wrote:
>
> Hello,
>
> On Wed, Sep 04, 2019 at 10:54:34AM +0200, Daniel Vetter wrote:
> > Anyway, I don't think reusing the drm_minor registration makes sense,
> > since we want to be on the drm_device, not on the minor. Which is a bit
> > awkward for cgroup
On Fri, Sep 6, 2019 at 5:23 PM Tejun Heo wrote:
>
> Hello, Daniel.
>
> On Tue, Sep 03, 2019 at 09:48:22PM +0200, Daniel Vetter wrote:
> > I think system memory separate from vram makes sense. For one, vram is
> > like 10x+ faster than system memory, so we definitely want to have
> > good control o
From: Colin Ian King
Don't populate the arrays on the stack but instead make them
static const. Makes the object code smaller by 1329 bytes.
Before:
textdata bss dec hex filename
55811488 6471331bdd drivers/staging/fbtft/fb_hx8340bn.o
54441264
Hello,
On Wed, Sep 04, 2019 at 10:54:34AM +0200, Daniel Vetter wrote:
> Anyway, I don't think reusing the drm_minor registration makes sense,
> since we want to be on the drm_device, not on the minor. Which is a bit
> awkward for cgroups, which wants to identify devices using major.minor
> pairs.
On Fri, 6 Sep 2019 at 16:19, Daniel Vetter wrote:
> On Fri, Sep 6, 2019 at 4:45 PM Daniel Vetter wrote:
> > We forgot that.
> >
> > Proof is the one igt testcase we have:
> >
> > https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280
> >
> > While at it also document
On 04/09/2019 13:30, Mark Brown wrote:
> The panfrost driver requests a supply using regulator_get_optional()
> but both the name of the supply and the usage pattern suggest that it is
> being used for the main power for the device and is not at all optional
> for the device for function, there is
Hello, Daniel.
On Tue, Sep 03, 2019 at 09:48:22PM +0200, Daniel Vetter wrote:
> I think system memory separate from vram makes sense. For one, vram is
> like 10x+ faster than system memory, so we definitely want to have
> good control on that. But maybe we only want one vram bucket overall
> for t
On Fri, Sep 6, 2019 at 4:45 PM Daniel Vetter wrote:
>
> We forgot that.
>
> Proof is the one igt testcase we have:
>
> https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280
>
> While at it also document that we have immutable zpos properties in
> some cases.
>
> Repo
This function lost its only call site as part of
earlier dead code removal, so remove it as well:
drivers/video/fbdev/sa1100fb.c:975:21: error: unused function
'sa1100fb_min_dma_period' [-Werror,-Wunused-function]
Fixes: 390e5de11284 ("fbdev/sa1100fb: Remove dead code")
Signed-off-by: Arnd Bergm
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #72 from tempel.jul...@gmail.com ---
Created attachment 145280
--> https://bugs.freedesktop.org/attachment.cgi?id=145280&action=edit
2nd gdb backtrace log, now with debug symbols
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #71 from tempel.jul...@gmail.com ---
Hope this helps:
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
On 06/09/2019 11:55, Mark Brown wrote:
[...]
>>> However you're probably better off hiding all this stuff with the
>>> generic OPP code rather than open coding it - this already has much
>>> better handling for this, it supports voltage ranges rather than single
>>> voltages and optional regulators
We forgot that.
Proof is the one igt testcase we have:
https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280
While at it also document that we have immutable zpos properties in
some cases.
Reported-by: Pekka Paalanen
Cc: Pekka Paalanen
Reviewed-by: Pekka Paalane
Hi Jacopo,
On Fri, Sep 06, 2019 at 03:50:12PM +0200, Jacopo Mondi wrote:
> Expand comment in the 'vsps' parsing routine to specify the LIF
> channel index defaults to 0 in case the second cell of the property
> is not specified to remain compatible with older DT bindings.
>
> Reviewed-by: Laurent
On Wed, Sep 04, 2019 at 10:05:09PM +0200, Daniel Vetter wrote:
> On Wed, Sep 4, 2019 at 9:58 PM Souza, Jose wrote:
> >
> > On Wed, 2019-09-04 at 16:39 +0200, Daniel Vetter wrote:
> > > - it's what we recommend in our docs:
> > >
> > > https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommen
Hi Wen,
On Thu, Aug 22, 2019 at 10:11:35AM +0800, Wen He wrote:
> Configure the display Quality of service (QoS) levels priority if the
> optional property node "arm,malidp-aqros-value" is defined in DTS file.
>
> QoS signaling using AQROS and AWQOS AXI interface signals, the AQROS is
> driven fr
Hi
Am 06.09.19 um 15:05 schrieb Daniel Vetter:
> On Fri, Sep 6, 2019 at 12:24 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 06.09.19 um 11:28 schrieb Daniel Vetter:
>>> On Fri, Sep 06, 2019 at 10:52:13AM +0200, Thomas Zimmermann wrote:
This patch prepares VRAM helpers for lazy unmapping of b
Am Fr., 6. Sept. 2019 um 12:55 Uhr schrieb Lucas Stach :
>
> On Fr, 2019-09-06 at 12:03 +0200, Christian Gmeiner wrote:
> > Might be useful when debugging MMU exceptions.
> >
> > Signed-off-by: Christian Gmeiner
> > ---
> > drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26
> > ++
Add device tree bindings documentation for the Renesas R-Car Display
Unit Color Management Module.
CMM is the image enhancement module available on each R-Car DU video
channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded).
Signed-off-by: Jacopo Mondi
---
.../bindings/display/renesas,cmm.ya
Document the newly added 'cmms' property which accepts a list of phandle
and channel index pairs that point to the CMM units available for each
Display Unit output video channel.
Signed-off-by: Jacopo Mondi
Reviewed-by: Laurent Pinchart
---
Documentation/devicetree/bindings/display/renesas,du.t
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #70 from Michel Dänzer ---
(In reply to tempel.julian from comment #68)
> I did it, but it stopped after hitting the two breakpoints the first time
> without me having moved the mouse at all. I suppose this isn't enough? Would
> it b
Add a driver for the R-Car Display Unit Color Correction Module.
In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
to perform image enhancement and color correction.
Add support for CMM through a driver that supports configuration of
the 1-dimensional LUT table. More advanc
Implement device tree parsing to collect the available CMM instances
described by the 'renesas,cmms' property. Associate CMMs with CRTCs and
store a mask of active CMMs in the DU group for later enablement.
Enforce the probe and suspend/resume ordering of DU and CMM by creating
a stateless device
Add CMM to the list of supported features for Gen3 SoCs that provide it:
- R8A7795
- R8A7796
- R8A77965
- R8A7799x
Leave R8A77970 out as V3M and V3H are the only Gen3 SoCs that do not
support CMM.
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/
Enable the GAMMA_LUT KMS property using the framework helpers to
register the property and set the associated gamma table maximum size.
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 4
1 file changed, 4 ins
[ Ugh, sorry for the double sending, but I forgot --cc-cover to git-send
email and the series has not been delivered to the mailing lists.
Sorry about that. ]
Hello, new iteration of CMM support, with quite a few changes compared to
v3:
References:
A reference to the v1 cover letter, with som
Add CMM units to Renesas R-Car Gen3 SoC that support it, and reference them
from the Display Unit they are connected to.
Sort the 'vsps' and 'renesas,cmm' entries in the DU unit consistently
in all the involved DTS.
Signed-off-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 40
Enable/disable the CMM associated with a CRTC at CRTC start and stop
time and enable the CMM unit through the Display Extensional Functions
register at group setup time.
Reviewed-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_du_crtc
Update CMM settings at in the atomic commit tail helper method.
The CMM is updated with new gamma values provided to the driver
in the GAMMA_LUT blob property.
When resuming from system suspend, the DU driver is responsible for
reprogramming and enabling the CMM unit if it was in use at the time t
Expand comment in the 'vsps' parsing routine to specify the LIF
channel index defaults to 0 in case the second cell of the property
is not specified to remain compatible with older DT bindings.
Reviewed-by: Laurent Pinchart
Signed-off-by: Jacopo Mondi
---
This trivial change is a leftover from a
Hello, new iteration of CMM support, with quite a few changes compared to
v3:
References:
A reference to the v1 cover letter, with some background on the CMM is
available here:
https://lkml.org/lkml/2019/6/6/583
v2:
https://lore.kernel.org/linux-renesas-soc/20190706140746.29132-10-jacopo+rene...@j
On Fri, Sep 6, 2019 at 7:43 AM Ville Syrjälä
wrote:
>
> On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
> >
> >
> > >-Original Message-
> > >From: Ilia Mirkin
> > >Sent: Tuesday, September 3, 2019 6:12 PM
> > >To: Mun, Gwan-gyeong
> > >Cc: Intel Graphics Development ; Shank
On Fri, Sep 6, 2019 at 2:13 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > I think if we do an mmap callback, it should replace all the mmap handling
> > (except the drm_gem_object_get) that drm_gem_mmap_obj does. So maybe
> > something like the below:
>
> [ snip ]
>
> > Since I remember quite a few disc
On Fri, Sep 6, 2019 at 12:24 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 06.09.19 um 11:28 schrieb Daniel Vetter:
> > On Fri, Sep 06, 2019 at 10:52:13AM +0200, Thomas Zimmermann wrote:
> >> This patch prepares VRAM helpers for lazy unmapping of buffer objects.
> >>
> >> Signed-off-by: Thomas Zimmerm
On 06/09/2019 12:10, Rob Herring wrote:
> On Thu, Sep 5, 2019 at 1:11 PM Steven Price wrote:
>>
>> When handling a GPU page fault addr_to_drm_mm_node() is used to
>> translate the GPU address to a buffer object. However it is possible for
>> the buffer object to be freed after the function has ret
This patch prepares VRAM helpers for lazy unmapping of buffer objects.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_vram_mm_helper.c | 12
include/drm/drm_vram_mm_helper.h | 4
2 files changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c
Generic fbdev emulation maps and unmaps the console BO for updating it's
content from the shadow buffer. If this involves an actual mapping
operation (instead of reusing an existing mapping), lots of debug messages
may be printed, such as
x86/PAT: Overlap at 0xd000-0xd100
x86/PAT: rese
The implementation of vmap() is a combined pin() and kmap(). As both
functions share the same lock, we can make vmap() slightly faster by
acquiring the lock only once for both operations. Same for the inverse,
vunmap().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c |
The kmap and kunmap operations of GEM VRAM buffers can now be called
in interleaving pairs. The first call to drm_gem_vram_kmap() maps the
buffer's memory to kernel address space and the final call to
drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these
functions increment or decrem
Frequent mapping and unmapping a buffer object adds overhead for
modifying the page table and creates debug output. Unmapping a buffer
is only required when the memory manager evicts the buffer from its
current location.
v4:
* WARN_ON if buffer is still mapped during BO cleanup
Signed-off
Hi,
> I think if we do an mmap callback, it should replace all the mmap handling
> (except the drm_gem_object_get) that drm_gem_mmap_obj does. So maybe
> something like the below:
[ snip ]
> Since I remember quite a few discussions where the default vma flag
> wrangling we're doing is seriousl
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #69 from tempel.jul...@gmail.com ---
Created attachment 145278
--> https://bugs.freedesktop.org/attachment.cgi?id=145278&action=edit
1st gdb log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #68 from tempel.jul...@gmail.com ---
I did it, but it stopped after hitting the two breakpoints the first time
without me having moved the mouse at all. I suppose this isn't enough? Would it
be possible to provide me with a short hint
On Fri, Sep 06, 2019 at 11:31:55AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ilia Mirkin
> >Sent: Tuesday, September 3, 2019 6:12 PM
> >To: Mun, Gwan-gyeong
> >Cc: Intel Graphics Development ; Shankar,
> >Uma
> >; dri-devel
> >Subject: Re: [PATCH v4 3/7] drm: Add D
>-Original Message-
>From: Ilia Mirkin
>Sent: Tuesday, September 3, 2019 6:12 PM
>To: Mun, Gwan-gyeong
>Cc: Intel Graphics Development ; Shankar, Uma
>; dri-devel
>Subject: Re: [PATCH v4 3/7] drm: Add DisplayPort colorspace property
>
>So how would this work with a DP++ connector? Shou
On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza wrote:
> From: Dhinakaran Pandiyan
>
> Currently we restrict the number of encoders that can be linked to
> a connector to 3, increase it to match the maximum number of encoders
> that can be initialized(32).
>
> To more effiently d
On Fri, Sep 06, 2019 at 12:37:47PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 06.09.19 um 11:39 schrieb Gerd Hoffmann:
> >> +void drm_gem_vram_bo_driver_move_notify(struct ttm_buffer_object *bo,
> >> + bool evict,
> >> + struct ttm
On Thu, Sep 5, 2019 at 1:11 PM Steven Price wrote:
>
> When handling a GPU page fault addr_to_drm_mm_node() is used to
> translate the GPU address to a buffer object. However it is possible for
> the buffer object to be freed after the function has returned resulting
> in a use-after-free of the B
On Thu, Sep 05, 2019 at 07:51:59PM +, Siqueira, Rodrigo wrote:
> Hi Ville,
>
> First of all, thank you very much for the review.
>
> I added some comments below.
>
> On 09/05, Wentland, Harry wrote:
> > On 2019-09-05 1:29 p.m., Ville Syrjälä wrote:
> > > On Wed, Sep 04, 2019 at 07:02:18PM +0
1 - 100 of 137 matches
Mail list logo
