https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #10 from Alex Deucher ---
(In reply to L.S.S. from comment #9)
> Just tested... it seems if I connect to the monitor directly the problem
> doesn't occur.
>
> Guess the KVM does play a part in this. However, I still need the KVM as
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #69 from Bastian ---
Distro/Kernel: Ubuntu 18.04.2/5.0.2
GPU AMD: Readon RX570 - Mesa 19.0
Display: Iiyama G23530HSU 75hz
Desktop: Gnome
video: https://www.youtube.com/watch?v=gNJ2kJ8hsHA
Have the same problem
drm_format_horz_chroma_subsampling and drm_format_vert_chroma_subsampling
are basically a lookup in the drm_format_info table plus an access to the
hsub and vsub fields of the appropriate entry.
Most drivers are using this function while having access to the entry
already, which means that we
Start converting the DRM drivers by changing the struct drm_framebuffer
structure to hold a pointer to image_format_info instead, and converting
everyone that depends on it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig | 1 +-
Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/ipu-v3/ipu-pre.c | 3 ++-
drivers/gpu/ipu-v3/ipu-prg.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git
So far, the drm_format_plane_height/width functions were operating on the
format's fourcc and was doing a lookup to retrieve the drm_format_info
structure and return the cpp.
However, this is inefficient since in most cases, we will have the
drm_format_info pointer already available so we
Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_ipp.h| 4 +++-
Bump, sorry to bug you but is there any update on this or any information you
still need from me which would help get this upstream?
On Wed, 2019-03-13 at 18:25 -0400, Lyude Paul wrote:
> [note to David Ober: you -should- be able to reply to this, hopefully, but I
> haven't actually tested that
On 2019-03-18 5:58 p.m., Paul Menzel wrote:
>
> Dear Harry,
>
... snip ...
>>
>> Michel, do you know if this is supposed to work with
>> xf86-video-amdgpu? When I've tried it before I didn't have any luck but
>> didn't have time to look into it.
>
> Sorry, what is your question. With the
https://bugs.freedesktop.org/show_bug.cgi?id=110142
--- Comment #8 from Peter Easton ---
Great, I'll go try it on 5.0.2 and report back, thanks!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
V4L2 uses different fourcc's than DRM, and has a different set of formats.
For now, let's add the v4l2 fourcc's for the already existing formats.
Signed-off-by: Maxime Ripard
---
include/linux/image-formats.h | 9 +-
lib/image-formats.c | 67 -
On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis wrote:
>
> On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> > Le mer. 13 mars 2019 à 23:31, John Stultz a écrit :
> >>
> >> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark wrote:
> >>> On Tue, 5 Mar 2019, John Stultz wrote:
>
> Eventual TODOS:
Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 9 +
drivers/gpu/drm/omapdrm/omap_fb.c | 7 ---
2 files changed, 9 insertions(+), 7
V4L2 drivers typically need a few more helpers compared to DRM drivers, so
let's add them.
Signed-off-by: Maxime Ripard
---
include/linux/image-formats.h | 4 +++-
lib/image-formats.c | 42 -
2 files changed, 46 insertions(+)
diff --git
drm_format_num_planes() is basically a lookup in the drm_format_info table
plus an access to the num_planes field of the appropriate entry.
Most drivers are using this function while having access to the entry
already, which means that we will perform an unnecessary lookup. Removing
the call to
Hi,
DRM comes with an extensive format support to retrieve the various
parameters associated with a given format (such as the subsampling, or the
bits per pixel), as well as some helpers and utilities to ease the driver
development.
v4l2, on the other side, doesn't provide such facilities,
Move the DRM formats API to turn this into a more generic image formats API
to be able to leverage it into some other places of the kernel, such as
v4l2 drivers.
Signed-off-by: Maxime Ripard
---
include/linux/image-formats.h | 240 +++-
lib/Kconfig | 7 +-
Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 6 --
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 3 ++-
Now that we have a generic image format libary, let's convert the rest of
the DRM core to use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_client.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_sprite.c | 4 ++--
2 files changed, 4 insertions(+), 4
So far, the drm_format_plane_cpp function was operating on the format's
fourcc and was doing a lookup to retrieve the drm_format_info structure and
return the cpp.
However, this is inefficient since in most cases, we will have the
drm_format_info pointer already available so we shouldn't have to
drm_get_format_info directly calls into drm_format_info, but takes directly
a struct drm_mode_fb_cmd2 pointer, instead of the fourcc directly. It's
shorter to not dereference it, and we can customise the behaviour at the
driver level if we want to, so let's switch to it where it makes sense.
Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/arm/malidp_drv.c | 3 ++-
drivers/gpu/drm/arm/malidp_hw.c | 4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff
Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
Now that we have a generic image format libary, let's convert drivers to
use it so that we can deprecate the old DRM one.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tegra/plane.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/plane.c
Now that all the clients of the old drm_format* API have been converted to
the generic one, let's remove it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/Kconfig | 1 +-
drivers/gpu/drm/drm_fourcc.c| 253 +
The image format API allows us to remove some of the computation we need to
handle the various video formats.
Signed-off-by: Maxime Ripard
---
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c | 88 +++
drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.h | 46 +
2 files
On Tue, Mar 19, 2019 at 2:58 PM Rob Clark wrote:
>
> On Tue, Mar 19, 2019 at 1:00 PM Andrew F. Davis wrote:
> >
> > On 3/19/19 11:54 AM, Benjamin Gaignard wrote:
> > > Le mer. 13 mars 2019 à 23:31, John Stultz a
> > > écrit :
> > >>
> > >> On Wed, Mar 13, 2019 at 1:11 PM Liam Mark wrote:
> >
https://bugs.freedesktop.org/show_bug.cgi?id=110199
Bug ID: 110199
Summary: [amdgpu] Screen flickering when using a 75Hz monitor
paired with an RX 480 GPU
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=110199
Maxim Ivanov changed:
What|Removed |Added
Priority|medium |high
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=110142
--- Comment #9 from Peter Easton ---
(In reply to Michel Dänzer from comment #7)
> Please try https://patchwork.freedesktop.org/patch/292720/ , it should fix
> the problem.
Splice the mainbrace! It worked like a charm!
It worked, xfce4
https://bugs.freedesktop.org/show_bug.cgi?id=110201
--- Comment #1 from Kovid Goyal ---
Created attachment 143737
--> https://bugs.freedesktop.org/attachment.cgi?id=143737=edit
api trace output of running kitty on mesa 19
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110201
Bug ID: 110201
Summary: mesa 19.0.0 breaks rendering in kitty
Product: Mesa
Version: 19.0
Hardware: Other
OS: All
Status: NEW
Severity: normal
these two enumerated types are same for now. both of them might change in the
future.
I have not used clang, but would .block_id = (int)head->block fix your
warning? If such change is acceptable, I can make one then.
Thanks
xinhui
-Original Message-
From: Nathan Chancellor
Sent:
v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal
operation,
so add check condition for that.
v4: remove v3 change and add checking to prevent out-of-order
Signed-off-by: Chunming Zhou
Signed-off-by: Chunming Zhou
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8a0732088640..4d8db87048d3 100644
---
syncobj wait/signal operation is appending in command submission.
v2: separate to two kinds in/out_deps functions
v3: fix checking for timeline syncobj
Signed-off-by: Chunming Zhou
Cc: Tobias Hector
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: Chris Wilson
Cc: Lionel Landwerlin
---
user mode can query timeline payload.
v2: check return value of copy_to_user
v3: handle querying entry by entry
v4: rebase on new chain container, simplify interface
v5: query last signaled timeline point, not last point.
v6: add unorder point check
Signed-off-by: Chunming Zhou
Cc: Tobias Hector
Hi, Hsin-yi:
On Mon, 2019-03-18 at 12:09 +0800, Hsin-Yi Wang wrote:
> mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
> needs
> ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
> ovl irq will be disabled. If drm_crtc_wait_one_vblank() is
1. clear cmd buffer
2. make amdgpu_memcpy_dispatch_test static
3. tab/space fix
Change-Id: Idf55f8881f66458b585092eccb55b6042520e4ad
Signed-off-by: Flora Cui
---
tests/amdgpu/basic_tests.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git
On 2019年03月19日 19:54, Lionel Landwerlin wrote:
On 15/03/2019 12:09, Chunming Zhou wrote:
v2: individually allocate chain array, since chain node is free
independently.
v3: all existing points must be already signaled before cpu perform
signal operation,
so add check condition for that.
From: Christian König
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev reference during garbage collection if it's
From: Christian König
Use the dma_fence_chain object to create a timeline of fence objects
instead of just replacing the existing fence.
v2: rebase and cleanup
v3: fix garbage collection parameters
v4: add unorder point check, print a warn calltrace
Signed-off-by: Christian König
Cc: Lionel
From: Christian König
Implement finding the right timeline point in drm_syncobj_find_fence.
v2: return -EINVAL when the point is not submitted yet.
v3: fix reference counting bug, add flags handling as well
v4: add timeout for find fence
Signed-off-by: Christian König
Cc: Lionel Landwerlin
we need to import/export timeline point.
v2: unify to one transfer ioctl
Signed-off-by: Chunming Zhou
Cc: Lionel Landwerlin
---
drivers/gpu/drm/drm_internal.h | 2 +
drivers/gpu/drm/drm_ioctl.c| 2 +
drivers/gpu/drm/drm_syncobj.c | 74 ++
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
v4:
rebase
v5:
add comment for
On Mon, Jan 21, 2019 at 07:13:07PM +0100, Jernej Škrabec wrote:
> Dne ponedeljek, 21. januar 2019 ob 14:34:33 CET je Priit Laes napisal(a):
> > On Mon, Jan 21, 2019 at 08:37:29AM +, Priit Laes wrote:
> > > On Fri, Jan 18, 2019 at 10:51:10PM +0100, Jernej Škrabec wrote:
> > > > Dne četrtek, 17.
Hi Neil,
On Fri, Feb 1, 2019 at 1:08 PM Neil Armstrong wrote:
>
> 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
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/omapdrm/displays/panel-dsi-cm.c | 18 ++
1 file changed, 6
We should get 'driver_data' from 'struct device' directly. Going via
platform_device is an unneeded step back and forth.
Signed-off-by: Wolfram Sang
---
Build tested only. buildbot is happy.
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|
From: Shile Zhang
To fix following divide-by-zero error found by Syzkaller:
divide error: [#1] SMP PTI
CPU: 7 PID: 8447 Comm: test Kdump: loaded Not tainted 4.19.24-8.al7.x86_64 #1
Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS
rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org
Hi,
i try to get hdmi running on bananapi-r2 with 5.1 but also without CK Hu's
frambuffer-Patch i get no x-server working
my codebase: https://github.com/frank-w/BPI-R2-4.14/commits/5.1-hdmi
reused some Patches working on 5.0 (here X-server is working, but not fbcon)
WARNING: CPU: 2 PID: 895
On Tue, Mar 19, 2019 at 6:22 PM Russell King - ARM Linux admin
wrote:
>
> On Mon, Mar 18, 2019 at 10:57:55PM -0400, Bo YU wrote:
> > Calling strncpy with a maximum size argument of 64 bytes on destination
> > array "domain->name" of size 64 bytes might leave the destination string
> >
Hi, guys,
On 3/19/19 1:53 PM, Maxime Ripard wrote:
On Mon, Mar 11, 2019 at 09:36:27PM +0530, Jagan Teki wrote:
On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard wrote:
On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote:
pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical
> We don't know if this is a "category" per-se, or just a single Utgard
> tiling format - as discussed I'm trying to get an answer for that.
FWIW, as I think I mentioned on an message, this format is used on
Midgard as well, and presumably also Bifrost.
On Midgard, when a texture is uploaded
Maxime Ripard writes:
> On Mon, Mar 18, 2019 at 04:23:56PM +, Måns Rullgård wrote:
>> Maxime Ripard writes:
>>
>> > On Thu, Mar 14, 2019 at 04:09:13PM +, Måns Rullgård wrote:
>> >> Maxime Ripard writes:
>> >>
>> >> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
>> >>
Hi Deepak
Am 18.03.19 um 17:59 schrieb Deepak Singh Rawat:
> Hi Thomas,
>
> Thanks for doing this and somehow I missed the last patch, sorry about
> that. Have some questions below otherwise the patch looks good to me.
>
> Reviewed-by: Deepak Rawat
>
> I will include your changes in
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #10 from tempel.jul...@gmail.com ---
Thanks for the information, really a relief to know that this is being worked
on.
Does this aim to achieve as good performance as with "legacy DC" for every
window operation as well?
Would it
Hi, Deepak,
On Mon, 2019-03-18 at 09:59 -0700, Deepak Singh Rawat wrote:
> Hi Thomas,
>
> Thanks for doing this and somehow I missed the last patch, sorry
> about
> that. Have some questions below otherwise the patch looks good to me.
>
> Reviewed-by: Deepak Rawat
>
> I will include your
https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #9 from L.S.S. ---
Just tested... it seems if I connect to the monitor directly the problem
doesn't occur.
Guess the KVM does play a part in this. However, I still need the KVM as I've
four PCs connected to this monitor.
It's not
On Tue, Mar 19, 2019 at 8:29 AM Chen-Yu Tsai wrote:
>
> On Tue, Mar 19, 2019 at 12:58 AM Jagan Teki
> wrote:
> >
> > On Fri, Mar 15, 2019 at 7:04 PM Maxime Ripard
> > wrote:
> > >
> > > On Fri, Mar 15, 2019 at 06:38:23PM +0530, Jagan Teki wrote:
> > > > ICN6211 is MIPI-DSI/RGB converter
The reset driver now supports the ao reset controller, so update the
documentation to match.
Signed-off-by: Peter Griffin
---
Documentation/devicetree/bindings/reset/hisilicon,hi6220-reset.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
Calling strncpy with a maximum size argument of 64 bytes on destination
array "domain->name" of size 64 bytes might leave the destination string
unterminated.
Detected by CoverityScan, CID# 1443992: Memory - illegal accesses
(BUFFER_SIZE_WARNING)
Fixes: 9e2c2e2730126 (drm/etnaviv: add
Maxime Ripard writes:
> On Thu, Mar 14, 2019 at 04:09:13PM +, Måns Rullgård wrote:
>> Maxime Ripard writes:
>>
>> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
>> >> Maxime Ripard writes:
>> >>
>> >> > Hi!
>> >> >
>> >> > On Mon, Mar 11, 2019 at 01:47:13PM +, Mans
This is required to bring Mali450 gpu out of reset.
Signed-off-by: Peter Griffin
---
include/dt-bindings/reset/hisi,hi6220-resets.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/dt-bindings/reset/hisi,hi6220-resets.h
b/include/dt-bindings/reset/hisi,hi6220-resets.h
index
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
This is required to bring Mali450 gpu out of reset.
Signed-off-by: Peter Griffin
---
drivers/reset/hisilicon/hi6220_reset.c | 51 +-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/drivers/reset/hisilicon/hi6220_reset.c
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
Signed-off-by: Souptick Joarder
Reviewed-by: Oleksandr Andrushchenko
---
drivers/gpu/drm/xen/xen_drm_front_gem.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git
Convert to use vm_map_pages() to map range of kernel
memory to user vma.
Tested on Rockchip hardware and display is working,
including talking to Lima via prime.
Signed-off-by: Souptick Joarder
Tested-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 17 ++---
1
hi6220 has a Mali450 MP4 so lets add it into the DT.
Signed-off-by: Peter Griffin
---
arch/arm64/boot/dts/hisilicon/hi6220.dtsi | 38 +++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/boot/dts/hisilicon/hi6220.dtsi
The Hisilicon hi6220 uses a Mali-450MP4 with 4 PPs, so add
a compatible for it.
Signed-off-by: Peter Griffin
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt
On Mon, Mar 18, 2019 at 10:28:10PM +0530, Jagan Teki wrote:
> On Fri, Mar 15, 2019 at 7:04 PM Maxime Ripard
> wrote:
> >
> > On Fri, Mar 15, 2019 at 06:38:23PM +0530, Jagan Teki wrote:
> > > ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > > It has a flexible configuration of MIPI DSI
https://bugs.freedesktop.org/show_bug.cgi?id=110142
--- Comment #7 from Michel Dänzer ---
Please try https://patchwork.freedesktop.org/patch/292720/ , it should fix the
problem.
--
You are receiving this mail because:
You are the assignee for the
Dear Mario,
On 18.03.19 18:19, Mario Kleiner wrote:
In VRR mode, proper vblank/pageflip timestamps can only be computed
after the display scanout position has left front-porch. Therefore
delay calls to drm_crtc_handle_vblank(), and thereby calls to
drm_update_vblank_count() and pageflip event
tree: https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
exynos-drm-fixes
head: 17e6186af38ced4da78f15b935f6a483df627c99
commit: 17e6186af38ced4da78f15b935f6a483df627c99 [1/1] drm/exynos: dsi: Use
drm_bridge_detach
config: arm64-defconfig (attached as .config)
compiler:
https://bugs.freedesktop.org/show_bug.cgi?id=110188
Qiao Xie changed:
What|Removed |Added
OS|All |Linux (All)
--
You are receiving this mail
Previouly drivers have their own way of mapping range of
kernel pages/memory into user vma and this was done by
invoking vm_insert_page() within a loop.
As this pattern is common across different drivers, it can
be generalized by creating new functions and use it across
the drivers.
As now we also need to probe in the reset driver as well.
Signed-off-by: Peter Griffin
---
drivers/clk/hisilicon/clk-hi6220.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/hisilicon/clk-hi6220.c
b/drivers/clk/hisilicon/clk-hi6220.c
index a87809d..952ffe2
I just put a Radeon 9600XT into an Athlon XP machine. I do not know if the card
is good or not, but 2D dumb framebufer works fine with radeon module. However,
init of the acceleration engine fails. I compiled my own kernel (v5.0 from git)
with UBSAN (no other debug yet) and got a cascade of UBSAN
https://bugs.freedesktop.org/show_bug.cgi?id=110188
Bug ID: 110188
Summary: AMD graphics card driver cannot be installed on Fedora
29
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: All
I am seeing the following warning on at least 2 different servers with onboard
radeon graphics.
It was not there with 5.0.
[4.764838] [drm] radeon kernel modesetting enabled.
[4.765334] radeon :01:01.0: vgaarb: deactivate vga console
[4.767746] Console: switching to colour dummy
https://bugs.freedesktop.org/show_bug.cgi?id=110188
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |DRM/AMDgpu-pro
--
You are receiving
Hi Johan,
Am Mittwoch, 6. März 2019, 23:41:10 CET schrieb Johan Jonker:
> From: Zheng Yang
>
> The RK3066 HDMI TX serves as interface between a LCD Controller and
> a HDMI bus. A HDMI TX consists of one HDMI transmitter controller and
> one HDMI transmitter PHY. The interface has three (3)
There has unfortunately been a conflict with the following 3 commits:
commit e9961ab95af81b8d29054361cd5f0c575102cf87
Author: Ayan Kumar Halder
Date: Fri Nov 9 17:21:12 2018 +
drm: Added a new format DRM_FORMAT_XVYU2101010
commit 7ba0fee247ee7a36b3bfbed68f6988d980aa3aa3
Author: Brian
On 15/03/2019 12:09, Chunming Zhou wrote:
From: Christian König
Lockless container implementation similar to a dma_fence_array, but with
only two elements per node and automatic garbage collection.
v2: properly document dma_fence_chain_for_each, add dma_fence_chain_find_seqno,
drop prev
On Tue, Mar 19, 2019 at 01:17:02PM +0100, Maarten Lankhorst wrote:
> There has unfortunately been a conflict with the following 3 commits:
>
> commit e9961ab95af81b8d29054361cd5f0c575102cf87
> Author: Ayan Kumar Halder
> Date: Fri Nov 9 17:21:12 2018 +
> drm: Added a new format
On 3/18/19 1:19 PM, Mario Kleiner wrote:
> In VRR mode, proper vblank/pageflip timestamps can only be computed
> after the display scanout position has left front-porch. Therefore
> delay calls to drm_crtc_handle_vblank(), and thereby calls to
> drm_update_vblank_count() and pageflip event
On 15/03/2019 12:09, Chunming Zhou wrote:
v2: individually allocate chain array, since chain node is free independently.
v3: all existing points must be already signaled before cpu perform signal
operation,
so add check condition for that.
Signed-off-by: Chunming Zhou
---
Hi Brian,
> Since your first patch set, I did raise this internally. The request
> has been making it's way through:
>
> - GPU engineering, to determine what exactly this format is, and
>what other variants there might be which are supported on different
>GPU generations, so that we can
[ +Sudeep - just FYI ]
Hi Liviu,
On 27/02/2019 09:40, Liviu Dudau wrote:
Hi Robin,
Sorry for the delay in reviewing this patch, I am drowning a bit this
week in meetings :)
On Mon, Feb 25, 2019 at 02:39:13PM +, Robin Murphy wrote:
When __drm_atomic_helper_disable_all() tries to commit
https://bugs.freedesktop.org/show_bug.cgi?id=108323
--- Comment #5 from jpalacios...@gmail.com ---
(In reply to bmilreu from comment #3)
> Yes, seems like the same issue. It would be useful to know if someone with a
> non-Sapphire RX580 has the same problem.
MSI RX 480 Gaming X is also affected.
Hi John,
On Tue, Mar 05, 2019 at 12:54:29PM -0800, John Stultz wrote:
> From: "Andrew F. Davis"
[snip]
> +
> +#define NUM_HEAP_MINORS 128
> +static DEFINE_IDR(dma_heap_idr);
> +static DEFINE_MUTEX(minor_lock); /* Protect idr accesses */
I saw that Matthew Wilcox is trying to nuke idr:
On Tue, Mar 19, 2019 at 08:05:32PM +0800, Qiang Yu wrote:
> Hi Brian,
>
> > Since your first patch set, I did raise this internally. The request
> > has been making it's way through:
> >
> > - GPU engineering, to determine what exactly this format is, and
> >what other variants there might
Am 19.03.19 um 13:27 schrieb Lionel Landwerlin:
On 15/03/2019 12:09, Chunming Zhou wrote:
[SNIP]
+/**
+ * struct dma_fence_chain - fence to represent an node of a fence chain
+ * @base: fence base class
+ * @lock: spinlock for fence handling
+ * @prev: previous fence of the chain
+ *
On Mon, Mar 18, 2019 at 04:23:56PM +, Måns Rullgård wrote:
> Maxime Ripard writes:
>
> > On Thu, Mar 14, 2019 at 04:09:13PM +, Måns Rullgård wrote:
> >> Maxime Ripard writes:
> >>
> >> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
> >> >> Maxime Ripard writes:
> >> >>
MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4
to update internal state (shadow registers).
Apparently the driver implements it incorrectly. The rule should be
as follows:
- do not request updating registers until previous request was finished,
ie.
On 3/18/19 1:19 PM, Mario Kleiner wrote:
> We want vblank counts and timestamps of flip completion as sent
> in pageflip completion events to be consistent with the vblank
> count and timestamp of the vblank of flip completion, like in non
> VRR mode.
>
> In VRR mode, drm_update_vblank_count() -
ACLK400_DISP1 bus feeds some internal buses of the display subsystem, some
of which are also related to TV/Mixer hardware modules. When that bus
is set to 120MHz, Exynos Mixer is not able to properly handle two XRGB
display planes at FullHD-60MHz. DMA underrun happens, which in turn might
result
On Mon, Mar 11, 2019 at 08:07:29PM +0530, Jagan Teki wrote:
> On Mon, Mar 11, 2019 at 7:42 PM Maxime Ripard
> wrote:
> >
> > On Thu, Mar 07, 2019 at 11:24:01PM +0530, Jagan Teki wrote:
> > > Hi Maxime,
> > >
> > > On Fri, Feb 8, 2019 at 3:23 PM Maxime Ripard
> > > wrote:
> > > >
> > > > The
On Mon, Mar 11, 2019 at 08:28:22PM +0530, Jagan Teki wrote:
> On Mon, Mar 11, 2019 at 7:39 PM Maxime Ripard
> wrote:
> >
> > On Thu, Mar 07, 2019 at 09:24:02PM +0530, Jagan Teki wrote:
> > > On Thu, Mar 7, 2019 at 9:09 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Thu, Mar 07, 2019 at
1 - 100 of 151 matches
Mail list logo
