On Fri, 23 Nov 2018 15:24:16 +0530 Anshuman Khandual
wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace these open encodings for an invalid node number with the
> glo
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #24 from jamespharve...@gmail.com ---
Created attachment 142603
--> https://bugs.freedesktop.org/attachment.cgi?id=142603&action=edit
journalctl of git master 7c98a4261827, with patch 259364, which gets to a black
screen
--
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #23 from jamespharve...@gmail.com ---
Don't know if comment 22 re patch 259364 was directed toward me or not. If me,
see comment 6 & 20, where I tried it. It's also applied to the journalctl I'm
about to upload, and the text of this
https://bugs.freedesktop.org/show_bug.cgi?id=105530
--- Comment #16 from Andrew Sheldon ---
Okay, so it turns out the frame dropping issue only exists for me in a PRIME
configuration. Perhaps the additional GPU copy at full load is too much for the
system to handle, and it starts dropping frames
https://bugs.freedesktop.org/show_bug.cgi?id=108852
--- Comment #1 from Richard B. Kreckel ---
There's a sample file attached to the Totem issue:
https://gitlab.gnome.org/GNOME/totem/issues/241#note_350334
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #22 from Alex Deucher ---
As noted in comment 4, please try this patch:
https://patchwork.freedesktop.org/patch/259364/
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #14 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 279635
--> https://bugzilla.kernel.org/attachment.cgi?id=279635&action=edit
test fix
Does this patch help?
--
You are receiving this mail because:
You are watchi
https://bugs.freedesktop.org/show_bug.cgi?id=108852
Bug ID: 108852
Summary: totem MPEG4 video playback color screw-up
Product: Mesa
Version: 18.2
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severi
On Thu, Nov 22, 2018 at 6:41 AM Christian König
wrote:
>
> This reverts commit 0efd2d2f68cd5dbddf4ecd974c33133257d16a8e.
>
> It's still causing problems for V3D.
>
> v2: keep rearming the timeout.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/scheduler/sche
On Thu, Nov 22, 2018 at 5:58 AM Christian König
wrote:
>
> This reverts commit 0efd2d2f68cd5dbddf4ecd974c33133257d16a8e.
>
> It's still causing problems for V3D.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 31 +
On Thu, Nov 22, 2018 at 7:23 PM Chris Rankin wrote:
>
> Hi,
>
> I have recently tried to use dpm=1 with the amdgpu driver for the 4.19.x
> kernel, but unfortunately the screen just went black. This is a regression
> from the 4.18.x kernel.
>
> I have attached the full dmesg log, but the relevant
https://bugs.freedesktop.org/show_bug.cgi?id=108350
--- Comment #4 from Alessandro ---
As of November 23, 2018 I cannot reproduce the issue!
looks like this commit
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=c33133c2af034ecedacd7ad681b6b5740fc4fc04
fixed my issue
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #49 from bmil...@gmail.com ---
(In reply to tempel.julian from comment #46)
> As a workaround, a timer job/script writing every few seconds might do the
> trick.
I tried a systemd timer but it floods my dmesg every time it triggers a
On Fri, Nov 23, 2018 at 1:13 PM Koenig, Christian
wrote:
> Am 23.11.18 um 18:36 schrieb Eric Anholt:
> > Christian König writes:
> >> Am 20.11.18 um 21:57 schrieb Eric Anholt:
> >>> Kenny Ho writes:
> Account for the number of command submitted to amdgpu by type on a per
> cgroup basi
The pull request you sent on Fri, 23 Nov 2018 11:39:44 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2018-11-23
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9b7c880c834c0a1c80a1dc6b8a0b19155361321f
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
https://bugs.freedesktop.org/show_bug.cgi?id=108832
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Driver/AMDgpu
Version|unspec
Am 23.11.18 um 14:42 schrieb Chunming Zhou:
But I've came up with something which should work. Assume the original
chain is:
136912---18
And we garbage collect everything but 6 and 18 then all we need to know
to return the correct node is what the original previous sequence nu
Am 23.11.18 um 18:36 schrieb Eric Anholt:
> Christian König writes:
>
>> Am 20.11.18 um 21:57 schrieb Eric Anholt:
>>> Kenny Ho writes:
>>>
Account for the number of command submitted to amdgpu by type on a per
cgroup basis, for the purpose of profiling/monitoring applications.
>>> For
https://bugs.freedesktop.org/show_bug.cgi?id=108814
--- Comment #6 from Domen ---
Created attachment 142598
--> https://bugs.freedesktop.org/attachment.cgi?id=142598&action=edit
another gallium dump
another dump, tried with propriery nvidia drivers. it works fine there.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=108814
Domen changed:
What|Removed |Added
Summary|VMC page fault on |[radeonsi] page fault, umr
|P
https://bugs.freedesktop.org/show_bug.cgi?id=108814
Domen changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
Version|uns
Christian König writes:
> Am 20.11.18 um 21:57 schrieb Eric Anholt:
>> Kenny Ho writes:
>>
>>> Account for the number of command submitted to amdgpu by type on a per
>>> cgroup basis, for the purpose of profiling/monitoring applications.
>> For profiling other drivers, I've used perf tracepoints
On Fri, Nov 23, 2018 at 04:55:33PM +, Ayan Halder wrote:
> On Fri, Nov 23, 2018 at 10:24:44AM +0100, Paul Kocialkowski wrote:
>
> Hi Paul,
>
> > This introduces new format helpers that use the previously-introduced
> > format info helpers for checking YUV sub-sampling.
> >
> > Only the forma
On Fri, Nov 23, 2018 at 10:24:44AM +0100, Paul Kocialkowski wrote:
Hi Paul,
> This introduces new format helpers that use the previously-introduced
> format info helpers for checking YUV sub-sampling.
>
> Only the format fourcc is required by these helpers and the formats are
> iterated from the
Hi Kieran,
On Friday, 23 November 2018 17:30:43 EET Kieran Bingham wrote:
> On 23/11/2018 14:47, Laurent Pinchart wrote:
> > On Friday, 23 November 2018 16:43:28 EET Kieran Bingham wrote:
> >> On 23/11/2018 14:34, Laurent Pinchart wrote:
> >>> Implement a .mode_valid() handler in the R-Car glue la
https://bugs.freedesktop.org/show_bug.cgi?id=108843
--- Comment #5 from alex14...@yahoo.com ---
Correction: due to the screen going blank during boot, I didn't test closing
the lid.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=108843
--- Comment #4 from alex14...@yahoo.com ---
Created attachment 142595
--> https://bugs.freedesktop.org/attachment.cgi?id=142595&action=edit
dmesg with amdgpu.dc=1
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=108843
--- Comment #3 from alex14...@yahoo.com ---
It doesn't help. In addition, the screen goes blank when KMS is engaged.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-de
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #13 from quirin.blae...@freenet.de ---
(In reply to quirin.blaeser from comment #11)
> Created attachment 279393 [details]
> config+dmesg for patched 4.19.1
>
> Bug is still alive.
> A more precise description:
> System boots and show
Hi Laurent,
On 23/11/2018 14:47, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Friday, 23 November 2018 16:43:28 EET Kieran Bingham wrote:
>> On 23/11/2018 14:34, Laurent Pinchart wrote:
>>> Implement a .mode_valid() handler in the R-Car glue layer to reject
>>> modes with an unsupported clock freq
On Fri, Nov 23, 2018 at 03:01:06PM +0200, Joonas Lahtinen wrote:
> Quoting Jonathan Gray (2018-11-23 14:28:37)
> > On Fri, Nov 23, 2018 at 12:14:00PM +0200, Joonas Lahtinen wrote:
> > > Quoting Jonathan Gray (2018-11-20 00:31:22)
> > > > On Mon, Nov 19, 2018 at 10:09:33AM -0800, Rodrigo Vivi wrote:
Hi Kieran,
On Friday, 23 November 2018 16:43:28 EET Kieran Bingham wrote:
> On 23/11/2018 14:34, Laurent Pinchart wrote:
> > Implement a .mode_valid() handler in the R-Car glue layer to reject
> > modes with an unsupported clock frequency.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
> >
Hi Laurent,
Thank you for the patch,
On 23/11/2018 14:34, Laurent Pinchart wrote:
> Implement a .mode_valid() handler in the R-Car glue layer to reject
> modes with an unsupported clock frequency.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 11 +
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #21 from Shecks ---
I'd like to report that I am have been experiencing the same issue. After
upgrading (Fedora 29) from kernel 4.18.18 to 4.19.2 my PC would no longer boot.
I have a an MSI R9 390 GPU and have been using the the fol
oid) not allowing
> a allocation failure here should be acceptable.
Given that my plan is to eventually drop omapdss_display_init(), this looks
fine to me.
Acked-by: Laurent Pinchart
> Patch was compile tested with: omap2plus_defconfig (implies OMAP_DSS_BASE=m)
>
> Patch is agains
On 23/11/2018 15:33, Laurent Pinchart wrote:
> Hi Neil,
>
> On Friday, 23 November 2018 16:29:15 EET Neil Armstrong wrote:
>> On 23/11/2018 15:25, Laurent Pinchart wrote:
>>> On Friday, 23 November 2018 16:02:14 EET Neil Armstrong wrote:
Add support for SCDC Setup for TMDS Clock > 3.4GHz and
Implement a .mode_valid() handler in the R-Car glue layer to reject
modes with an unsupported clock frequency.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c
b/dri
Hi Neil,
On Friday, 23 November 2018 16:29:15 EET Neil Armstrong wrote:
> On 23/11/2018 15:25, Laurent Pinchart wrote:
> > On Friday, 23 November 2018 16:02:14 EET Neil Armstrong wrote:
> >> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
> >> Scrambling when supported or mandat
Hi Laurent,
On 23/11/2018 15:25, Laurent Pinchart wrote:
> Hi Neil,
>
> Thank you for the patch.
>
> On Friday, 23 November 2018 16:02:14 EET Neil Armstrong wrote:
>> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
>> Scrambling when supported or mandatory.
>>
>> This patch al
Totally find to me, but can we change it a bit like:
if (size < node->hole_size) {
best = node;
rb = rb->rb_right;
} else if (size > node->hole_size){
rb = rb->rb_left;
} else {
Hi Neil,
Thank you for the patch.
On Friday, 23 November 2018 16:02:14 EET Neil Armstrong wrote:
> Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
> Scrambling when supported or mandatory.
>
> This patch also adds an helper to setup the control bit to support
> the hight TMDS
https://bugs.freedesktop.org/show_bug.cgi?id=108753
--- Comment #6 from Michel Dänzer ---
I'm glad to hear that, but it would still be good to rule out a kernel bug. Can
you bisect the kernel change which triggered the problem with the modesetting
driver?
--
You are receiving this mail because:
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixe
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/bridge
With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.
S
Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meso
Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
operation in the DW-HDMI Controller, we can enable support for the
HDMI2.0 3840x2160@60/50 RGB444 display modes.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_venc.c | 2 ++
1 file changed, 2 insertions(+)
diff
Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
Scrambling when supported or mandatory.
This patch also adds an helper to setup the control bit to support
the hight TMDS Bit Period/TMDS Clock-Period Ratio as required with
TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
T
In order to support the HDMI2.0 YUV420 display modes, this patch
adds support for the YUV420 TMDS Clock divided by 2 and the controller
passthrough mode.
This patch is based on work from Zheng Yang in
the Rockchip Linux 4.4 BSP at [1]
[1] https://github.com/rockchip-linux/kernel/tree/release-4.4
This patchset aims to add support for the following HDMI2.0 4k60 modes:
- 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4
- 297MHz TMDS frequency with YUV4:2:0 encoding
The first mode uses the SCDC helpers introduced by intel to :
- discover where the monitor support SC
From: Zheng Yang
To get input/output bus_format/enc_format dynamically, this patch
introduce following funstion in plat_data:
- get_input_bus_format
- get_output_bus_format
- get_enc_in_encoding
- get_enc_out_encoding
Signed-off-by: Zheng Yang
Signed-off-by: Neil
Hi Laurent,
Thank you for the patch.
On 23/11/2018 11:48, Laurent Pinchart wrote:
> Group start/stop is controlled by the DRES and DEN bits of DSYSR0 for
> the first group and DSYSR2 for the second group. On most DU instances,
> this maps to the first CRTC of the group. On M3-N, however, DU2 does
https://bugs.freedesktop.org/show_bug.cgi?id=105113
--- Comment #10 from Maciej S. Szmigiero ---
(In reply to Jan Vesely from comment #9)
> (In reply to Maciej S. Szmigiero from comment #8)
> > Aren't program@execute@calls-struct and program@execute@tail-calls tests
> > from comment 4 examples of
在 2018/11/23 21:27, Koenig, Christian 写道:
Am 23.11.18 um 14:15 schrieb Zhou, David(ChunMing):
在 2018/11/23 20:02, Koenig, Christian 写道:
Am 23.11.18 um 12:03 schrieb Christian König:
Am 23.11.18 um 11:56 schrieb zhoucm1:
On 2018年11月23日 18:10, Koenig, Christian wrote:
Am 23.11.18 um 03:
On Fri 23-11-18 14:15:11, Daniel Vetter wrote:
> On Fri, Nov 23, 2018 at 1:43 PM Michal Hocko wrote:
> > On Fri 23-11-18 13:30:57, Daniel Vetter wrote:
> > > On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote:
> > > > On Thu 22-11-18 17:51:04, Daniel Vetter wrote:
> > > > > Just a bit of
Am 23.11.18 um 14:15 schrieb Zhou, David(ChunMing):
>
> 在 2018/11/23 20:02, Koenig, Christian 写道:
>> Am 23.11.18 um 12:03 schrieb Christian König:
>>> Am 23.11.18 um 11:56 schrieb zhoucm1:
On 2018年11月23日 18:10, Koenig, Christian wrote:
> Am 23.11.18 um 03:36 schrieb zhoucm1:
>> On 2018
On 23/11/2018 13:12, Daniel Vetter wrote:
On Fri, Nov 23, 2018 at 1:46 PM Michal Hocko wrote:
On Fri 23-11-18 13:38:38, Daniel Vetter wrote:
On Fri, Nov 23, 2018 at 12:12:37PM +0100, Michal Hocko wrote:
On Thu 22-11-18 17:51:05, Daniel Vetter wrote:
We need to make sure implementations don
Hi Michal,
On 23/11/2018 13:57, Michal Lazo wrote:
> I would suggest same aproach as for
> "meson_hdmi_encp_mode_1080p30"
> and "meson_hdmi_encp_mode_1080p60"
>
> so duplicate "meson_hdmi_encp_mode_1080p50"
> with name "meson_hdmi_encp_mode_1080p25"
The configs are litterally the same for 1080p2
在 2018/11/23 20:02, Koenig, Christian 写道:
> Am 23.11.18 um 12:03 schrieb Christian König:
>> Am 23.11.18 um 11:56 schrieb zhoucm1:
>>>
>>> On 2018年11月23日 18:10, Koenig, Christian wrote:
Am 23.11.18 um 03:36 schrieb zhoucm1:
> On 2018年11月22日 19:30, Christian König wrote:
>> Am 22.11.1
On Fri, Nov 23, 2018 at 1:43 PM Michal Hocko wrote:
> On Fri 23-11-18 13:30:57, Daniel Vetter wrote:
> > On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote:
> > > On Thu 22-11-18 17:51:04, Daniel Vetter wrote:
> > > > Just a bit of paranoia, since if we start pushing this deep into
> > >
On Fri, Nov 23, 2018 at 1:46 PM Michal Hocko wrote:
>
> On Fri 23-11-18 13:38:38, Daniel Vetter wrote:
> > On Fri, Nov 23, 2018 at 12:12:37PM +0100, Michal Hocko wrote:
> > > On Thu 22-11-18 17:51:05, Daniel Vetter wrote:
> > > > We need to make sure implementations don't cheat and don't have a
>
Quoting Jonathan Gray (2018-11-23 14:28:37)
> On Fri, Nov 23, 2018 at 12:14:00PM +0200, Joonas Lahtinen wrote:
> > Quoting Jonathan Gray (2018-11-20 00:31:22)
> > > On Mon, Nov 19, 2018 at 10:09:33AM -0800, Rodrigo Vivi wrote:
> > > > On Sun, Nov 18, 2018 at 08:44:30PM +1100, Jonathan Gray wrote:
>
ion-next is next-20181123)
drivers/gpu/drm/omapdrm/dss/display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
b/drivers/gpu/drm/omapdrm/dss/display.c
index 34b2a4e..7dbe874 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers
Hi,
On Fri, 2018-11-23 at 11:30 +, Brian Starkey wrote:
> Hi Paul,
>
> On Fri, Nov 23, 2018 at 10:25:03AM +0100, Paul Kocialkowski wrote:
> > This introduces a dedicated ioctl for allocating buffers for the VPU
> > tiling mode. It allows setting up buffers that comply to the hardware
> > alig
On Fri 23-11-18 13:38:38, Daniel Vetter wrote:
> On Fri, Nov 23, 2018 at 12:12:37PM +0100, Michal Hocko wrote:
> > On Thu 22-11-18 17:51:05, Daniel Vetter wrote:
> > > We need to make sure implementations don't cheat and don't have a
> > > possible schedule/blocking point deeply burried where revie
On Fri 23-11-18 13:30:57, Daniel Vetter wrote:
> On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote:
> > On Thu 22-11-18 17:51:04, Daniel Vetter wrote:
> > > Just a bit of paranoia, since if we start pushing this deep into
> > > callchains it's hard to spot all places where an mmu notifie
Am 23.11.18 um 13:26 schrieb Daniel Vetter:
On Fri, Nov 23, 2018 at 12:02:41PM +, Koenig, Christian wrote:
Am 23.11.18 um 12:03 schrieb Christian König:
Am 23.11.18 um 11:56 schrieb zhoucm1:
On 2018年11月23日 18:10, Koenig, Christian wrote:
Am 23.11.18 um 03:36 schrieb zhoucm1:
On 2018年11月
On Fri, Nov 23, 2018 at 12:12:37PM +0100, Michal Hocko wrote:
> On Thu 22-11-18 17:51:05, Daniel Vetter wrote:
> > We need to make sure implementations don't cheat and don't have a
> > possible schedule/blocking point deeply burried where review can't
> > catch it.
> >
> > I'm not sure whether thi
From: Thierry Reding
The number of syncpoints on Tegra186 is 576 and therefore no longer fits
into 8 bits. Increase the size of the syncpoint ID field to 10 in order
to accomodate all syncpoints.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/hw/hw_host1x06_uclass.h | 2 +-
1 file change
From: Thierry Reding
The register region allocated per channel was decreased from 16384 bytes
to 256 bytes on Tegra186 and later. Resize the region to make sure every
channel (instead of only the first) is properly programmed.
Suggested-by: Mikko Perttunen
Signed-off-by: Thierry Reding
---
dr
From: Thierry Reding
Add the 5V HDMI regulator and hook up the VDD_1V0 and VDD_1V8HS supplies
from the PMIC to the display block. Also enable the display hub which is
responsible for instantiating the display controllers. Finally, enable
the third SOR that drives the TMDS signals to the HDMI conn
From: Thierry Reding
Tegra194 contains a display architecture very similar to that found on
the Tegra186. One notable exception is that DSI is no longer a supported
output. Instead there are four display controllers and four SORs (with a
DPAUX associated to each of them) that can drive HDMI or DP
From: Thierry Reding
The host1x hardware found on Tegra194 is very similar to the version
found on Tegra186, with the notable exceptions of the increased number
of syncpoints and mlocks. In addition, some rarely used features such
as syncpoint wait bases were dropped and some registers had to mov
From: Thierry Reding
Tegra194 has a version of VIC that is very similar to that on Tegra186.
Add the device tree node for it that is enabled by default.
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/
From: Thierry Reding
The Video Image Composer (VIC) generation found on Tegra194 is the same
as its predecessor found on Tegra186.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 1 +
drivers/gpu/drm/tegra/vic.c | 11 +++
2 files changed, 12 insertions(+)
diff --git a
On Fri, Nov 23, 2018 at 12:15:57PM +0100, Michal Hocko wrote:
> On Thu 22-11-18 17:51:04, Daniel Vetter wrote:
> > Just a bit of paranoia, since if we start pushing this deep into
> > callchains it's hard to spot all places where an mmu notifier
> > implementation might fail when it's not allowed t
On Fri, Nov 23, 2018 at 12:14:00PM +0200, Joonas Lahtinen wrote:
> Quoting Jonathan Gray (2018-11-20 00:31:22)
> > On Mon, Nov 19, 2018 at 10:09:33AM -0800, Rodrigo Vivi wrote:
> > > On Sun, Nov 18, 2018 at 08:44:30PM +1100, Jonathan Gray wrote:
> > > > On Wed, Oct 31, 2018 at 08:43:03AM +, Chr
On Fri, Nov 23, 2018 at 12:02:41PM +, Koenig, Christian wrote:
> Am 23.11.18 um 12:03 schrieb Christian König:
> > Am 23.11.18 um 11:56 schrieb zhoucm1:
> >>
> >>
> >> On 2018年11月23日 18:10, Koenig, Christian wrote:
> >>> Am 23.11.18 um 03:36 schrieb zhoucm1:
>
> On 2018年11月22日 19:30,
From: Thierry Reding
As part of commit cfea88a4d866 ("drm/nouveau: Start using new drm_dev
initialization helpers"), the initialization of the Nouveau DRM device
was reworked and along the way the platform driver initialization was
left incomplete. Add a call to nouveau_drm_device_init() to make
From: Thierry Reding
The ->alloc() callback in struct falcon_ops returns an ERR_PTR()-encoded
error code on failure, so it needs to be properly checked for, otherwise
subsequent code may dereference an invalid pointer.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/falcon.c | 6 +++---
From: Thierry Reding
Tegra supports generic PM domains on 64-bit ARM, and if that is enabled,
the power domain code will make sure that resets are asserted and
deasserted at appropriate points in time.
If generic PM domains are not implemented, such as on 32-bit Tegra, the
resets need to be asse
Am 23.11.18 um 12:03 schrieb Christian König:
> Am 23.11.18 um 11:56 schrieb zhoucm1:
>>
>>
>> On 2018年11月23日 18:10, Koenig, Christian wrote:
>>> Am 23.11.18 um 03:36 schrieb zhoucm1:
On 2018年11月22日 19:30, Christian König wrote:
> Am 22.11.18 um 07:52 schrieb zhoucm1:
>>
>> On
Hi Fabrizio,
On Thursday, 22 November 2018 18:03:44 EET Fabrizio Castro wrote:
> On 17 October 2018 07:52 Laurent Pinchart wrote:
> > On Tuesday, 16 October 2018 19:58:59 EEST Fabrizio Castro wrote:
> > > Add RZ/G1C (a.k.a. r8a77470) support to the R-Car DU driver.
> >>
> >> Signed-off-by: Fabriz
From: Thierry Reding
Before booting the Falcon processor, make sure to wait for memory
scrubbing to complete.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/falcon.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/tegra/falcon.c b/drivers/gpu/drm/tegra/falc
Hi Fabrizio,
On Thursday, 22 November 2018 17:59:32 EET Fabrizio Castro wrote:
> On 15 October 2018 23:25 Laurent Pinchart wrote:
> > On Friday, 21 September 2018 21:08:30 EEST Fabrizio Castro wrote:
> >> From: Biju Das
> >>
> >> Add support for the R8A7744 DU (which is very similar to the R8A77
/media.git tags/du-next-20181123
for you to fetch changes up to 256856efb8cc2b5468c69edf45eb0ab579833ce7:
drm: rcar-du: Reject modes that fail CRTC timing requirements (2018-11-23
13:51:23 +0200)
R-Car DU changes for v4.21:
- R
Group start/stop is controlled by the DRES and DEN bits of DSYSR0 for
the first group and DSYSR2 for the second group. On most DU instances,
this maps to the first CRTC of the group. On M3-N, however, DU2 doesn't
exist, but DSYSR2 does. There is no CRTC object there that maps to the
correct DSYSR r
Hi Paul,
On Fri, Nov 23, 2018 at 10:25:03AM +0100, Paul Kocialkowski wrote:
>This introduces a dedicated ioctl for allocating buffers for the VPU
>tiling mode. It allows setting up buffers that comply to the hardware
>alignment requirements, by aligning the stride and height to 32 bytes.
>
>Only Y
https://bugs.freedesktop.org/show_bug.cgi?id=103911
--- Comment #1 from Jonathan Gray ---
Still missing from mesa-18.3.0-rc4.tar.gz and other recent releases.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
On Thu 22-11-18 17:51:04, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
What does WARN give you more than the existing pr_info? Is really
On Fri 23-11-18 09:49:34, Daniel Vetter wrote:
> On Thu, Nov 22, 2018 at 04:53:34PM +, Chris Wilson wrote:
> > Quoting Daniel Vetter (2018-11-22 16:51:04)
> > > Just a bit of paranoia, since if we start pushing this deep into
> > > callchains it's hard to spot all places where an mmu notifier
>
On Thu 22-11-18 17:51:05, Daniel Vetter wrote:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep() callsites trigger,
Am 23.11.18 um 11:56 schrieb zhoucm1:
On 2018年11月23日 18:10, Koenig, Christian wrote:
Am 23.11.18 um 03:36 schrieb zhoucm1:
On 2018年11月22日 19:30, Christian König wrote:
Am 22.11.18 um 07:52 schrieb zhoucm1:
On 2018年11月15日 19:12, Christian König wrote:
Implement finding the right timeline p
On Tue, Nov 20, 2018 at 12:02 PM Andrzej Hajda wrote:
> Anyway more I think about it more doubts I have. hs_rate can be helpful
> for command mode panels - panel refresh rate (provided by timings)
> imposes only lower limit on the speed, max hs rate will impose upper limit.
>
> In case of video m
On 2018年11月23日 18:10, Koenig, Christian wrote:
Am 23.11.18 um 03:36 schrieb zhoucm1:
On 2018年11月22日 19:30, Christian König wrote:
Am 22.11.18 um 07:52 schrieb zhoucm1:
On 2018年11月15日 19:12, Christian König wrote:
Implement finding the right timeline point in drm_syncobj_find_fence.
Signe
On the Amlogic GXL & GXM SoCs, a bug occurs on the OSD1 primaty plane when
alpha is used where the alpha is not aligned with the pixel content.
The woraround Amlogic implemented is to reset the OSD1 plane hardware
block each time the plane is updated, solving the issue.
In the reset, we still nee
On 21.11.18 00:13, Dan Williams wrote:
> In preparation for consolidating all ZONE_DEVICE enabling via
> devm_memremap_pages(), teach it how to handle the constraints of
> MEMORY_DEVICE_PRIVATE ranges.
>
> Reviewed-by: Jérôme Glisse
> [jglisse: call move_pfn_range_to_zone for MEMORY_DEVICE_PRIVAT
https://bugs.freedesktop.org/show_bug.cgi?id=108753
--- Comment #5 from baracl...@gmail.com ---
I can confirm that the problem does not occur when I load xf86-video-amdgpu
driver.
--
You are receiving this mail because:
You are the assignee for the bug.___
On 23.11.18 10:54, Anshuman Khandual wrote:
> At present there are multiple places where invalid node number is encoded
> as -1. Even though implicitly understood it is always better to have macros
> in there. Replace these open encodings for an invalid node number with the
> global macro NUMA_NO_N
Am 23.11.18 um 09:46 schrieb Daniel Vetter:
On Thu, Nov 22, 2018 at 06:55:17PM +, Koenig, Christian wrote:
Am 22.11.18 um 17:51 schrieb Daniel Vetter:
We need to make sure implementations don't cheat and don't have a
possible schedule/blocking point deeply burried where review can't
catch i
1 - 100 of 160 matches
Mail list logo
