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
>
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=edit
journalctl of git master 7c98a4261827, with patch 259364, which gets to a black
screen
--
You are
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
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
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
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=edit
test fix
Does this patch help?
--
You are receiving this mail because:
You are watching the
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
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
> ---
>
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
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=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
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
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://bugs.freedesktop.org/show_bug.cgi?id=108832
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Driver/AMDgpu
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
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=edit
another gallium dump
another dump, tried with propriery nvidia drivers. it works fine there.
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=108814
Domen changed:
What|Removed |Added
Summary|VMC page fault on |[radeonsi] page fault, umr
https://bugs.freedesktop.org/show_bug.cgi?id=108814
Domen changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
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
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
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
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
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
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=edit
dmesg with amdgpu.dc=1
--
You are receiving this mail because:
You are the assignee for the
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.___
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
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
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
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
rns void) 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
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
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
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
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
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
---
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.
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
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.
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]
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
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:
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
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
在 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
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
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
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
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
在 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
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
> >
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
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
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
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
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
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
---
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
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
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
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
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
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
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 +,
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
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:
>>
>>
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:
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
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
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:
- R8A7744
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
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
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
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
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
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.
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
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
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
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
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
1 - 100 of 160 matches
Mail list logo
