On Fri, 30 Nov 2018 12:30:52 -0800
Eric Anholt wrote:
> Paul Kocialkowski writes:
>
> > In order to test whether the load tracker is working as expected, we
> > need the ability to compare the commit result with the underrun
> > indication. With the load tracker always enabled, commits that are
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #31 from alex...@tut.by ---
Comment on attachment 142687
--> https://bugs.freedesktop.org/attachment.cgi?id=142687
Patch to workaround FATAL issue on VCE2.0 ringtest initialization .
Note: Its just workaround .
I see 2 problems :
https://bugs.freedesktop.org/show_bug.cgi?id=108781
--- Comment #30 from alex...@tut.by ---
Created attachment 142687
--> https://bugs.freedesktop.org/attachment.cgi?id=142687&action=edit
Patch to workaround FATAL issue on VCE2.0 ringtest initialization .
--
You are receiving this mail because
Hi Yangtao,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc4 next-20181130]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/
Hi Yangtao,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.20-rc4 next-20181130]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/
On 2018-11-18 22:25, Jayant Shekhar wrote:
In case of msm drm bind failure, pm runtime put sync
is called from dsi driver which issues an asynchronous
put on mdss device. Subsequently when dpu_mdss_destroy
is triggered the change will make sure to put the mdss
device in suspend and clearing pendi
https://bugs.freedesktop.org/show_bug.cgi?id=108917
Bug ID: 108917
Summary: gamma adjustments cause stuttering with amdgpu.dc=1,
especially problematic with RedShift etc.
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD6
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #1 from tempel.jul...@gmail.com ---
Created attachment 142686
--> https://bugs.freedesktop.org/attachment.cgi?id=142686&action=edit
dmesg log
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108854
--- Comment #1 from Tom Seewald ---
I can confirm this is still happening on 4.20-rc4 as well as with more up to
date userspace software.
libdrm: 3.27.0
Mesa: 18.2.4
The hangs can be reliably reproduced at least as far back as kernel 4.15 so I
https://bugs.freedesktop.org/show_bug.cgi?id=108704
--- Comment #10 from Laurent Pointecouteau ---
(In reply to Alex Deucher from comment #9)
> Please try the patch in comment 1.
I've applied the patch and there are no more amdgpu related errors showing up
in dmesg after booting. However, this h
This solves a problem we see with drm/msm, caused by getting
iommu_dma_ops while we attach our own domain and manage it directly at
the iommu API level:
[0038] user address but active_mm is swapper
Internal error: Oops: 9605 [#1] PREEMPT SMP
Modules linked in:
CPU: 7 PID: 7
On Fri, Nov 30, 2018 at 9:05 PM Tomasz Figa wrote:
>
> On Thu, Nov 29, 2018 at 4:23 PM Tomasz Figa wrote:
> >
> > On Thu, Nov 29, 2018 at 12:03 PM Robin Murphy wrote:
> > >
> > > On 29/11/2018 19:57, Tomasz Figa wrote:
> > > > On Thu, Nov 29, 2018 at 11:40 AM Jordan Crouse
> > > > wrote:
> > >
On devices with a burst_mode_ratio which is not 100 (1:1), the pclk
will have a different value then drm_display_mode.clock .
On a Prowise PT301 tablet where vbt.lfp_lvds_vbt_mode.clock is 66100 and
burst_mode_ratio is 130 this leads to the following errors:
[drm:pipe_config_err [i915]] *ERROR* m
If we exit vlv_dsi_init() because we failed to find a fixed_mode, then
we've already called drm_connector_init() and we should call
drm_connector_cleanup() to unregister the connector object.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/vlv_dsi.c | 4 +++-
1 file changed, 3 insertions(+
The display engine has 2 dithering enable bits which both need to be set
for dithering to happen, 1 in the PIPECONF register which is taken care of
by i9xx_set_pipeconf() and a second bit at the encoder level.
The dsi code was not setting the encoder level dithering enable bit causing
dithering to
There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc
pixel-formats which this commit addresses:
1) It assumes that the pipe_bpp is the same as the bpp going over the dsi
lanes. This assumption is not valid for MIPI_DSI_FMT_RGB666, where pipe_bpp
should be 18 so that we do proper di
The GOP sometimes initializes the pclk at a (slightly) different frequency
then the pclk which we've calculated.
This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.
This fixes the first modeset being
The next patch in this series uses intel_fuzzy_clock_check from the
vlv_dsi.c code.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_d
This is a preparation patch for moving the calling of *_dphy_param_init()
out of intel_dsi_vbt_init.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/intel_dsi_vbt.c | 77 +++-
1 file changed, 42 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel
The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.
Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.
This also removes the single "if (IS_ICELAKE(dev_priv
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #18 from Sergio Marcelo ---
Video of problem happening:
https://www.youtube.com/watch?v=E4oy8tqaYs0
My set up: Ubuntu 18.10, AMD Ryzen 2700X, RX Vega 56
This is the workaround that worked for me:
* Beyond adding "R600_DEBUG=nir" t
Hi Boris,
Le vendredi 30 novembre 2018 à 19:57 +0100, Boris Brezillon a écrit :
> On Fri, 30 Nov 2018 17:11:04 +0100
> Paul Kocialkowski wrote:
>
> > In order to test whether the load tracker is working as expected, we
> > need the ability to compare the commit result with the underrun
> > indic
Hi Eric,
Le vendredi 30 novembre 2018 à 12:30 -0800, Eric Anholt a écrit :
> Paul Kocialkowski writes:
>
> > In order to test whether the load tracker is working as expected, we
> > need the ability to compare the commit result with the underrun
> > indication. With the load tracker always enabl
https://bugs.freedesktop.org/show_bug.cgi?id=108916
Bug ID: 108916
Summary: polaris11 d3d9 rendering issue
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Hi Jon,
On Fri, Nov 30, 2018 at 11:15 PM Jonathan Corbet wrote:
> On Fri, 30 Nov 2018 14:12:19 -0800
> Jarkko Sakkinen wrote:
>
> > As a maintainer myself (and based on somewhat disturbed feedback from
> > other maintainers) I can only make the conclusion that nobody knows what
> > the responsib
25 matches
Mail list logo