Makes it easier to extract the fences in a dma_fence_array.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-array.c | 42 +++
include/linux/dma-fence-array.h | 24 ++
2 files changed, 66 insertions(+)
diff --git a/drivers/dma-buf/dma-fe
Add a new dma_resv_prune_fences() function to improve memory management.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 37 ++
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 3 +-
drivers/gpu/drm/i915/i915_gem_batch_pool.c | 2 +-
drivers/gpu/
Replace the old shared fences with the new readers container
and change all callers accordingly.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 99 +---
drivers/dma-buf/dma-resv.c| 524 +++---
.../gpu/drm/amd/amdgpu/amdgpu_amdk
First step towards new shared fence container implementation.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 16 +---
drivers/gpu/drm/msm/msm_gem.c | 14 ++
drivers/gpu/drm/nouveau/nouveau_fence.c | 2 +-
3 files changed, 8 inserti
Additional to readers and writers add another class of operations
which never participate in implicit synchronization.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-resv.c | 27 ---
include/linux/dma-resv.h | 2 ++
2 files changed, 26 insertions(+), 3 deletion
https://bugs.freedesktop.org/show_bug.cgi?id=111455
Bug ID: 111455
Summary: DMAR: [INTR-REMAP] Blocked an interrupt request due to
source-id verification failure
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=111456
Bug ID: 111456
Summary: amdgpu numerous failures on resume from suspend
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Wed, Aug 21, 2019 at 2:12 AM Neil Armstrong wrote:
>
> Hi Rob,
>
> On 20/08/2019 21:59, Rob Herring wrote:
> > Convert the Arm Midgard GPU binding to DT schema format.
> >
> > Signed-off-by: Rob Herring
> > ---
> > .../bindings/gpu/arm,mali-midgard.txt | 119 -
> > .../bin
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #35 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Do you mind posting your compositor settings in plasma? That would certainly
influence flip timing and submission and I haven't been able to reproduce the
issue with the se
Bring dmabuf sharing through implementing prime_import_sg_table callback.
This will help to validate userspace conformance in prime configurations
without using any actual hardware (e.g. in the cloud).
This enables kms_prime on vkms.
V2:
- Rodrigo: styleguide + return code check
Cc: Rodrigo Siq
Hi Daniel,
On Wed, Aug 21, 2019 at 10:21:07AM +0200, Daniel Vetter wrote:
> On Tue, Aug 20, 2019 at 10:05:05PM +0300, Laurent Pinchart wrote:
> > On Thu, Aug 08, 2019 at 05:11:33PM +0200, Boris Brezillon wrote:
> > > The VC4 and Exynos DSI encoder drivers need a custom enable/disable
> > > sequenc
Hi Boris,
On Thu, Aug 08, 2019 at 05:11:36PM +0200, Boris Brezillon wrote:
> bridge->next is only points to the new bridge if drm_bridge_attach()
> succeeds. No need to reset it manually here.
>
> Note that this change is part of the attempt to make the bridge chain
> a double-linked list. In ord
On Wed, Jul 31, 2019 at 11:40:18AM +0300, Peter Ujfalusi wrote:
> The default-on property - or the def_value via legacy pdata) should be
> handled as:
> if it is 1, the backlight must be enabled (kept enabled)
> if it is 0, the backlight must be disabled (kept disabled)
>
> This only works for the
On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
wrote:
> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> > On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >> With nouveau fixed all ttm-using drives have the correct nesting of
> >> mmap_sem vs dma_resv, and we can just lock the buffer.
On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware)
wrote:
>
> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> > With nouveau fixed all ttm-using drives have the correct nesting of
> > mmap_sem vs dma_resv, and we can just lock the buffer.
> >
> > Assuming I didn't screw up anything with my audit
This patch adds a line with the port name to connectors in
debugfs/i916_display_info. A hint is printed if the port is type-C.
Signed-off-by: Simon Ser
Cc: Imre Deak
---
drivers/gpu/drm/i915/i915_debugfs.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_de
On Tue, Aug 20, 2019 at 04:49:21PM +0200, Daniel Vetter wrote:
> On Mon, Aug 19, 2019 at 11:50 AM Daniel Thompson
> wrote:
> > On Mon, Aug 19, 2019 at 07:46:28AM +0200, Uwe Kleine-König wrote:
> > > And the big upside is that in the end (i.e. when all kernel drivers and
> > > userspace application
Hi
I'm wondering, whether this happens to everybody using xorg-server 1.20
(1.20.3 in my case).
When using X11 forwarding via ssh
ssh -X
(DISPLAY=localhost:10.0)
the list of available extensions when running xdpyinfo is limited to
[...]
number of extensions:2
BIG-REQUESTS
XC-MI
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #36 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Nicholas Kazlauskas from comment #35)
> Do you mind posting your compositor settings in plasma? That would certainly
> influence flip timing and submission and I haven't
On Wed, Aug 21, 2019 at 4:30 PM Thomas Hellström (VMware)
wrote:
>
> On 8/21/19 4:10 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware)
> > wrote:
> >> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >>> With nouveau fixed all ttm-using drives have the correct nesti
Hi Boris,
Thank you for the patch.
On Thu, Aug 08, 2019 at 05:11:37PM +0200, Boris Brezillon wrote:
> DRM bridges should not be operated independently. Let's rename the
> drm_bridge_xxx() helpers that take the first bridge of the chain and
> iterate over the whole chain into drm_bridge_chain_xx()
On Mon, Aug 19, 2019 at 07:19:39PM +0200, Sam Ravnborg wrote:
> On Thu, Aug 08, 2019 at 05:11:38PM +0200, Boris Brezillon wrote:
> > This is part of our attempt to make the bridge chain a double-linked
> > list based on the generic list helpers. In order to do that, we must
> > patch all drivers ma
On Wed, Aug 21, 2019 at 05:15:54PM +0300, Simon Ser wrote:
> This patch adds a line with the port name to connectors in
> debugfs/i916_display_info. A hint is printed if the port is type-C.
>
> Signed-off-by: Simon Ser
> Cc: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 9 +
>
On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
wrote:
> On 8/21/19 4:09 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> > wrote:
> >> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> >>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> With
Quoting Christian König (2019-08-21 13:31:42)
> Add a new dma_resv_prune_fences() function to improve memory management.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 37 ++
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 3 +-
> driv
Quoting Chris Wilson (2019-08-21 15:55:08)
> Quoting Christian König (2019-08-21 13:31:42)
> > Add a new dma_resv_prune_fences() function to improve memory management.
> >
> > Signed-off-by: Christian König
> > ---
> > drivers/dma-buf/dma-resv.c | 37 ++
> > d
On 8/21/19 1:49 AM, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20190820:
>
on x86_64:
../drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘ggtt_restore_mappings’:
../drivers/gpu/drm/i915/i915_gem_gtt.c::3: error: implicit declaration of
function ‘wbinvd_on_all_cpus’; did you mean
Am 21.08.19 um 16:47 schrieb Daniel Vetter:
> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> wrote:
>> On 8/21/19 4:09 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
>>> wrote:
On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> On
On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
wrote:
> On 8/21/19 4:47 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> > wrote:
> >> On 8/21/19 4:09 PM, Daniel Vetter wrote:
> >>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> >>>
On Wed, Aug 21, 2019 at 5:19 PM Thomas Hellström (VMware)
wrote:
> On 8/21/19 5:14 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
> > wrote:
> >> On 8/21/19 4:47 PM, Daniel Vetter wrote:
> >>> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> >>>
Quoting Christian König (2019-08-21 13:31:45)
> @@ -117,17 +120,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void *data,
>
> busy_check_writer(rcu_dereference(obj->base.resv->fence_excl));
>
> /* Translate shared fences to READ set of engines */
> - list = rcu_
https://bugzilla.kernel.org/show_bug.cgi?id=204181
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
On Tue, 20 Aug 2019 22:05:05 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thu, Aug 08, 2019 at 05:11:33PM +0200, Boris Brezillon wrote:
> > The VC4 and Exynos DSI encoder drivers need a custom enable/disable
> > sequence and manually set encoder->bridge to NULL
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up anything with my audit of course.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_inte
On 2019-08-20 8:36 a.m., Jason Gunthorpe wrote:
> On Tue, Aug 20, 2019 at 11:45:54AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> On Mon, 19 Aug 2019 18:34:41 -0700 Randy Dunlap
>> wrote:
>>> On 8/19/19 2:18 AM, Stephen Rothwell wrote:
Hi all,
Changes since 20190816:
>
On Wed, 21 Aug 2019 10:21:07 +0200
Daniel Vetter wrote:
> On Tue, Aug 20, 2019 at 10:05:05PM +0300, Laurent Pinchart wrote:
> > Hi Boris,
> >
> > Thank you for the patch.
> >
> > On Thu, Aug 08, 2019 at 05:11:33PM +0200, Boris Brezillon wrote:
> > > The VC4 and Exynos DSI encoder drivers need
On Tue, Aug 20, 2019 at 05:18:10PM +0200, Daniel Vetter wrote:
> On Tue, Aug 20, 2019 at 10:34:18AM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 20, 2019 at 10:19:02AM +0200, Daniel Vetter wrote:
> > > We need to make sure implementations don't cheat and don't have a
> > > possible schedule/blocki
On Tue, 20 Aug 2019 21:53:15 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thu, Aug 08, 2019 at 05:11:32PM +0200, Boris Brezillon wrote:
> > We are about to add a drm_bridge_state that inherits from
> > drm_private_state which is defined in drm_atomic.h. Problem
On Tue, Aug 20, 2019 at 02:56:36PM +, Koenig, Christian wrote:
> Am 20.08.19 um 16:53 schrieb Daniel Vetter:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >reall
On Wed, Aug 21, 2019 at 12:43:12PM +0300, Jani Nikula wrote:
> The module is drm_kms_helper, not drm_kms_firmware.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204549
> Reported-by: Göran Uddeborg
> Fixes: ac6c35a4d8c7 ("drm: add backwards compatibility support for
> drm_kms_helper.
On Wed, 21 Aug 2019 17:45:04 +0300
Laurent Pinchart wrote:
> Hi Boris,
>
> Thank you for the patch.
>
> On Thu, Aug 08, 2019 at 05:11:37PM +0200, Boris Brezillon wrote:
> > DRM bridges should not be operated independently. Let's rename the
> > drm_bridge_xxx() helpers that take the first bridge
On Wed, Aug 21, 2019 at 3:23 AM Daniel Vetter wrote:
>
> On Tue, Aug 20, 2019 at 07:35:47AM -0500, Rob Herring wrote:
> > On Tue, Aug 20, 2019 at 4:05 AM Daniel Vetter wrote:
> > >
> > > On Mon, Aug 19, 2019 at 11:12:02AM -0500, Rob Herring wrote:
> > > > Lockdep reports a circular locking depend
On Wed, Aug 21, 2019 at 02:31:44PM +0200, Christian König wrote:
> Add a new container for fences which internally uses
> dma_fence_array's to store the fences.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-resv.c | 221 +
> include/linux/dma-
On Wed, Aug 21, 2019 at 02:31:37PM +0200, Christian König wrote:
> Hi everyone,
>
> In previous discussion it surfaced that different drivers use the shared
> and explicit fences in the dma_resv object with different meanings.
>
> This is problematic when we share buffers between those drivers an
Quoting Christian König (2019-08-21 13:31:45)
> @@ -528,20 +352,9 @@ void dma_resv_prune_fences(struct dma_resv *obj)
> dma_fence_put(fence);
> }
>
> - list = dma_resv_get_list(obj);
> - if (!list)
> - return;
> -
> - for (i = 0; i < list->s
Quoting Christian König (2019-08-21 13:31:40)
> Try to recycle an dma_fence_array object by dropping the last
> reference to it without freeing it.
>
> Signed-off-by: Christian König
> ---
> drivers/dma-buf/dma-fence-array.c | 27 +++
> include/linux/dma-fence-array.h |
On Tue, Aug 20, 2019 at 04:12:28PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Previously, dpu_crtc_frame_event_work() would try to aquire all the
> modeset locks in order to check whether it can release bandwidth. (If
> we only have cmd-mode display, bandwidth can be released at frame-done
>
On Wed, Aug 21, 2019 at 05:15:54PM +0300, Simon Ser wrote:
> This patch adds a line with the port name to connectors in
> debugfs/i916_display_info. A hint is printed if the port is type-C.
Typo here, should be i915_display_info
Manasi
>
> Signed-off-by: Simon Ser
> Cc: Imre Deak
> ---
> dri
On Wed, Aug 21, 2019 at 11:03:55AM -0500, Rob Herring wrote:
> On Wed, Aug 21, 2019 at 3:23 AM Daniel Vetter wrote:
> >
> > On Tue, Aug 20, 2019 at 07:35:47AM -0500, Rob Herring wrote:
> > > On Tue, Aug 20, 2019 at 4:05 AM Daniel Vetter wrote:
> > > >
> > > > On Mon, Aug 19, 2019 at 11:12:02AM -0
On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >
On 2019-08-20 7:57 p.m., Nathan Chancellor wrote:
> When building arm32 allyesconfig:
>
> ld.lld: error: undefined symbol: __aeabi_uldivmod
referenced by dc_link.c
gpu/drm/amd/display/dc/core/dc_link.o:(wait_for_alt_mode) in archive
drivers/built-in.a
referenced by dc_link.c
>
Hi Laurent,
Thank you for getting back to me.
> From: Laurent Pinchart
> Sent: 20 August 2019 17:04
> Subject: Re: [PATCH v2 7/9] drm: rcar-du: lvds: Add dual-LVDS panels support
>
> Hi Fabrizio,
>
> On Thu, Aug 15, 2019 at 03:36:53PM +, Fabrizio Castro wrote:
> > On 15 August 2019 14:09 L
Am Dienstag, 20. August 2019, 21:59:56 CEST schrieb Rob Herring:
> This series converts the various Arm Mali GPU bindings to use the DT
> schema format.
>
> The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
> because there's all different ordering. The Utgard binding generate
Quoting Chris Wilson (2019-08-21 16:24:22)
> Quoting Christian König (2019-08-21 13:31:45)
> > @@ -117,17 +120,10 @@ i915_gem_busy_ioctl(struct drm_device *dev, void
> > *data,
> >
> > busy_check_writer(rcu_dereference(obj->base.resv->fence_excl));
> >
> > /* Translate s
On Mon, Aug 19, 2019 at 3:27 PM John Stultz wrote:
> On Thu, Jun 27, 2019 at 8:18 AM Matt Redfearn
> wrote:
> >
> > In contrast to all of the DSI panel drivers in drivers/gpu/drm/panel
> > which attach to the DSI host via mipi_dsi_attach() at probe time, the
> > ADV7533 bridge device does not. I
Hi,
On Tue, Aug 13, 2019 at 01:07:52PM +0200, Arnd Bergmann wrote:
> On Tue, Aug 13, 2019 at 12:10 PM Guido Günther wrote:
> > On Tue, Aug 13, 2019 at 10:08:44AM +0200, Arnd Bergmann wrote:
> > > On Fri, Aug 9, 2019 at 6:24 PM Guido Günther wrote:
> > > >
> > > > This adds all the gpr registers a
On Wed, Aug 21, 2019 at 12:24 PM Heiko Stuebner wrote:
>
> Am Dienstag, 20. August 2019, 21:59:56 CEST schrieb Rob Herring:
> > This series converts the various Arm Mali GPU bindings to use the DT
> > schema format.
> >
> > The Midgard and Bifrost bindings generate warnings on 'interrupt-names'
>
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #30 from Nicholas Kazlauskas ---
(In reply to tempel.julian from comment #29)
> The patches by Nicholas are now merged in drm-next-5.4 branch (tested with
> recent commit that bases the branch on 5.3-rc3), but the mouse input issue
>
Hi John.
On Tue, Aug 20, 2019 at 11:06:01PM +, John Stultz wrote:
> Sending this out again (apologies!), to address a few issues Sam
> found.
>
> This patchset contains one fix (in the front, so its easier to
> eventually backport), and a series of changes from YiPing to
> refactor the kirin
On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
wrote:
>
> On 8/21/19 6:34 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> >> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >>> Full audit of everyone:
> >>>
> >>> - i915, radeon, amdgp
On 8/20/19 3:12 PM, David Francis wrote:
> The first step in MST DSC is checking MST endpoints
> to see how DSC can be enabled
>
> Case 1: DP-to-DP peer device
> if the branch immediately upstream has
> - PDT = DP_PEER_DEVICE_DP_MST_BRANCHING (2)
> - DPCD rev. >= DP 1.4
> - Exactly one input
Hi Guido,
Thank you for the patch.
On Fri, Aug 09, 2019 at 06:24:22PM +0200, Guido Günther wrote:
> The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
>
> Signed-off-by: Guido Günther
> ---
> .../bindings/display/bridge/nwl-dsi.yaml | 155 ++
> 1 file ch
On Tue, 20 Aug 2019 10:40:58 +0200
Neil Armstrong wrote:
> This patchset is based on Boris's "drm: Add support for bus-format
> negotiation" RFC at [1]
Small clarification. Neil's work in based on a slightly different
version of my RFC [4] (I plan to post a v2 very soon).
> patchset to impleme
Am 21.08.2019 20:28 schrieb "Thomas Hellström (VMware)"
:
On 8/21/19 8:11 PM, Daniel Vetter wrote:
> On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> wrote:
>> On 8/21/19 6:34 PM, Daniel Vetter wrote:
>>> On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
On Wed, 14 Aug 2019 09:51:07 +0200
Neil Armstrong wrote:
> On 08/08/2019 17:11, Boris Brezillon wrote:
> > This takes the form of various helpers, plus the addition of 2 new
> > structs:
> > * drm_bus_caps: describe the bus capabilities of a bridge/encoder. For
> > bridges we have one for the i
When refactoring port lookup for DSS outputs, commit d17eb4537a7e
("drm/omap: Factor out common init/cleanup code for output devices")
incorrectly hardcoded usage of DT port 0. This breaks operation for SDI
(which uses the DT port 1) and DPI outputs other than DPI0 (which are
not used in mainline D
On Tue, 20 Aug 2019 10:41:00 +0200
Neil Armstrong wrote:
> Before switching to bridge funcs, make sure drm_display_mode is passed
> as const to the venc functions.
>
> Signed-off-by: Neil Armstrong
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/meson/meson_venc.c | 2 +-
> drivers/gpu
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #38 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Alex Deucher from comment #37)
> (In reply to Sergey Kondakov from comment #34)
> > By the way, is there any disadvantage in forcing TearFree to be always on
> > when it
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #31 from tempel.jul...@gmail.com ---
Created attachment 145117
--> https://bugs.freedesktop.org/attachment.cgi?id=145117&action=edit
new dmesg log with staging-drm-next kernel default parameters
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #32 from tempel.jul...@gmail.com ---
Created attachment 145118
--> https://bugs.freedesktop.org/attachment.cgi?id=145118&action=edit
issue demonstrated with D9VK frametime graph in game Oblivion
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #33 from Nicholas Kazlauskas ---
I haven't seen anything like the video in my testing. It also doesn't seem to
happen every time so I'm wondering if something else is going on in the
background that's issuing atomic commits.
Do you
Hello,
This small patch series attemps at decoupling EDID retrieval from
drm_connector, following a discussion with Daniel Vetter [1]. While
working on this I noticed a few issues with EDID retrieval, which I have
attempted to fix in patches 1/5 to 4/5. Patch 5/5 then tries to decouple
the EDID re
This change started as an attempt to remove the forward declaration of
validate_displayid(), and ended up reorganising the DisplayID parsing
code to fix serial intertwined issues.
The drm_parse_display_id() function, which parses a DisplayID block, is
made aware of whether the DisplayID comes from
This patch is a proof of concept showing how EDID retrieval could be
decoupled from drm_connector, in order to avoid passing the connector
pointer to the drm_bridge .get_edid() operation. The user of such
bridges (in most case the future drm_bridge_connector helper, see
"[PATCH v2 00/50] drm/omap:
The static function that populates the drm_connector tile-related fields
from EDID displayid will be used outside of drm_edid.c. As it logically
belongs to connector code, move it to drm_connector.c and rename it from
drm_get_displayid() to drm_connector_set_displayid().
While at it, fix a few che
The drm_get_edid() function skips EDID read when the connector is
disabled through connector->force. drm_do_get_edid(), which is supposed
to be used instead of drm_get_edid() for drivers that need to provide a
custom DDC read method, is missing the connector force checks. This
breaks the connector
Move the EDID retrieval functions to the end of the file to avoid
forward declarations. While at it fix a typo in a comment
(s/firmare/firmware/). No functional change is included.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_edid.c | 637 ++---
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #34 from tempel.jul...@gmail.com ---
Thank you for being still with me on this.
I've downgraded to stock packages provided by Arch stable repository, which is:
xorg-server 1.20.5
xf86-video-amdgpu 19.0.1
mesa 19.1.4
stock (read: no)
On Wed, 2019-08-21 at 12:27 +, Kazlauskas, Nicholas wrote:
> On 8/20/19 4:43 PM, Lyude Paul wrote:
> > Some nitpicks below
> >
> > On Tue, 2019-08-20 at 15:11 -0400, David Francis wrote:
> > > We were using drm helpers to convert a timing into its
> > > bandwidth, its bandwidth into pbn, and i
On Fri, Aug 9, 2019 at 8:43 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> The Vulkan timeline semaphores allow signaling to happen on the point
> of the timeline without all of the its dependencies to be created.
>
> The current 2 implementations (AMD/Intel) of the Vulkan spec on
On Wed, Aug 21, 2019 at 11:04 AM Sam Ravnborg wrote:
>
> Hi John.
>
> On Tue, Aug 20, 2019 at 11:06:01PM +, John Stultz wrote:
> > Sending this out again (apologies!), to address a few issues Sam
> > found.
> >
> > This patchset contains one fix (in the front, so its easier to
> > eventually b
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #35 from tempel.jul...@gmail.com ---
Created attachment 145119
--> https://bugs.freedesktop.org/attachment.cgi?id=145119&action=edit
debug dmesg.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=111459
Bug ID: 111459
Summary: AMDg black screen
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: not set
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #36 from tempel.jul...@gmail.com ---
The log now starts at [ 2788.164016], I hope nothing important is cut out. Else
I'd have to recheck my log size limits.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=111459
--- Comment #1 from peter m ---
Created attachment 145120
--> https://bugs.freedesktop.org/attachment.cgi?id=145120&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug.___
On Mon, Aug 05, 2019 at 08:22:24PM -0400, Brian Masney wrote:
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #39 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Sergey Kondakov from comment #38)
>
> Thanks ! It's a shame, I've already begun believing in "The Silver Bullet of
> VSync". And it's completely "software" GPU-agnostic fu
On Wed, Aug 21, 2019 at 02:26:02PM -0500, Rob Herring wrote:
> On Mon, Aug 05, 2019 at 08:22:24PM -0400, Brian Masney wrote:
> > Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> > must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> > optional ocmem prop
On Wed, Aug 21, 2019 at 08:27:59PM +0200, Thomas Hellström (VMware) wrote:
> On 8/21/19 8:11 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
> > wrote:
> > > On 8/21/19 6:34 PM, Daniel Vetter wrote:
> > > > On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hel
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #37 from Nicholas Kazlauskas ---
Are you running a color management tool in the background?
The difference between my setup and yours is that there isn't anything locking
the connectors hundreds of times per second and performing fu
https://bugs.freedesktop.org/show_bug.cgi?id=111332
--- Comment #2 from Todd ---
I can't comment on where the fix should be, but
1. This does not happen on a radeon based system
2. With the patch applied to the amdgpu code the application has been running
for over 7 days now with no issues.
--
Liu, Wenjing would like to recall the message, "[PATCH v2 11/14]
drm/amd/display: Validate DSC caps on MST endpoints".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
This reverts commit 55ad81f3510ec1a1c19e6a4d8a6319812d07d256.
optc dsc config was causing warnings due to missing register
definitions. With the registers restored, the function can
be re-enabled
The reverted commit also disabled sanity checks and dsc
power gating. The sanity check warnings are n
In create_stream_for_sink, check for SST DP connectors
Parse DSC caps to DC format, then, if DSC is supported,
compute the config
DSC hardware will be programmed by dc_commit_state
Tested-by: Mikita Lipski
Signed-off-by: David Francis
Reviewed-by: Nicholas Kazlauskas
---
.../gpu/drm/amd/disp
This reverts commit 5f2fd347eeff7d4ce271920efd47baaa18fe968c.
Re-enable enc2_dp_set_dsc_config. This function caused warnings
due to missing register definitions. With the registers added,
this now works
Signed-off-by: David Francis
Reviewed-by: Roman Li
Reviewed-by: Harry Wentland
Reviewed-by
This reverts commit 55a6f5bbcf00a49565946c0a9b8c716313dc6c05.
This commit was accidentally promoted twice
Signed-off-by: David Francis
Reviewed-by: Roman Li
Reviewed-by: Harry Wentland
Reviewed-by: Nicholas Kazlauskas
---
.../drm/amd/display/dc/dcn20/dcn20_hwseq.c| 4 --
.../gpu/drm/amd
This patchset enables Display Stream Compression (DSC) on DP
connectors on Navi ASICs, both SST and DSC.
8k60 and 4k144 support requires ODM combine, an AMD internal
feature that may be a bit buggy right now.
Patches 1 through 5 enable DSC for SST. Most of the work was
already done in the Navi pr
With DSC, bpp can be a multiple of 1/16, so
drm_dp_calc_pbn_mode is insufficient.
Add drm_dp_calc_pbn_mode_dsc, a function which is
the same as drm_dp_calc_pbn_mode, but the bpp is
in units of 1/16.
Cc: Lyude Paul
Cc: Nicholas Kazlauskas
Signed-off-by: David Francis
---
drivers/gpu/drm/drm_dp
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Signed-off-by: David Francis
Reviewed-by: Nicholas Kazlauskas
---
This reverts commit 80e80ec817f161560b4159608fb41bd289abede3.
This commit fixed an issue with underscan commits not updating all
needed timing values, but through various refactors it is no longer
necessary. It causes corruption on odm combine by
overwriting the halved h_active in the stream timin
1 - 100 of 210 matches
Mail list logo
