在 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
> > >
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
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
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
在 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:
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
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
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
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
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
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
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
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:
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
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 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
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
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
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
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
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
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 +
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
> >
> > ---
> >
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 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
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
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://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 #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._
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=108814
Domen changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
Version|uns
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
--- 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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=108832
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Driver/AMDgpu
Version|unspec
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
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
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
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
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
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 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
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
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=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://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=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=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=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
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
101 - 160 of 160 matches
Mail list logo
