Build a6xx_gpu_state.c only if either of CONFIG_DEBUG_FS, CONFIG_DEV_COREDUMP
is defined.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/Makefile | 5 -
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git
This patch simply fixes a typo for the name of an indexed register.
CP_MEMPOOOL -> CP_MEMPOOL.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #28 from Duncan Roe ---
Created attachment 142384
--> https://bugs.freedesktop.org/attachment.cgi?id=142384=edit
Log of applying FBC patchset
--
You are receiving this mail because:
You are the assignee for the
Add a new function which, in addition to ascii85 encoding to buffer
also returns the length of the encoded string. The length return enables
iteration over the output buffer space. This helps with efficient encoding
of larger buffers, since we avoid an additional memcpy/scnprintf.
Signed-off-by:
The ringbuffer data to capture at crashtime can end up being large
sometimes, and the size can vary from being less than a page to the
full size of 32KB. So use the kvmalloc variant that perfectly fits the bill.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 4 ++--
When the userspace tries to read the crashstate dump, the read side
implementation in the driver currently ascii85 encodes all the binary
buffers and it does this each time the read system call is called.
A userspace tool like cat typically does a page by page read and the
number of read calls
https://bugs.freedesktop.org/show_bug.cgi?id=108671
--- Comment #3 from coolo...@gmail.com ---
It seems to have been fixed in the latest amd drm staging next. Not sure if
this means it has already been addressed and can be closed.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=108671
--- Comment #2 from Alex Deucher ---
Please attach your dmesg output and xorg log. Is this a regression? If so,
can you bisect?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108671
--- Comment #1 from coolo...@gmail.com ---
Created attachment 142383
--> https://bugs.freedesktop.org/attachment.cgi?id=142383=edit
photo of artifact
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=108671
Bug ID: 108671
Summary: Massive Screen Artifacting on linux 4.19+
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #27 from Duncan Roe ---
(In reply to Alex Deucher from comment #24)
> Does just removing this line from the code:
> value |= 0x84;
> also fix the issue?
No, I get the black screen again. To be clear, I applied the patch in
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #26 from Duncan Roe ---
Created attachment 142382
--> https://bugs.freedesktop.org/attachment.cgi?id=142382=edit
One-line patch as Alex requested
--
You are receiving this mail because:
You are the assignee for the
Allows drivers to pass a larger modifier array, thereby avoiding
declarations of static modifier arrays that are only slight different
for each plane.
Cc: dri-devel@lists.freedesktop.org
Cc: Ville Syrjälä
Suggested-by: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
---
Reviewed-by: Chunming Zhou
> -Original Message-
> From: Eric Anholt
> Sent: Tuesday, November 06, 2018 7:01 AM
> To: dri-devel@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org; Eric Anholt ; Zhou,
> David(ChunMing) ; Koenig, Christian
>
> Subject: [PATCH] drm/syncobj: Fix oops
Hi Philipp,
I love your patch! Perhaps something to improve:
[auto build test WARNING on sof-driver-fuweitax/master]
[also build test WARNING on v4.20-rc1 next-20181105]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https
>-Original Message-
>From: Navare, Manasi D
>Sent: Friday, November 2, 2018 2:31 PM
>To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Cc: Navare, Manasi D ; Jani Nikula
>; Ville Syrjala ;
>Srivatsa, Anusha ; Harry Wentland
>
>Subject: [PATCH v8 04/19] drm/dsc: Add
Hi Philipp,
I love your patch! Yet something to improve:
[auto build test ERROR on sof-driver-fuweitax/master]
[also build test ERROR on v4.20-rc1 next-20181105]
[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
https://bugs.freedesktop.org/show_bug.cgi?id=108350
--- Comment #3 from Alessandro ---
Created attachment 142378
--> https://bugs.freedesktop.org/attachment.cgi?id=142378=edit
Debug files
I was not able to bisect but here are some additional debug logs
--
You are receiving this mail
On Mon, Nov 05, 2018 at 03:31:48PM -0800, Anusha Srivatsa wrote:
> If the panel supports FEC, the driver has to
> set the FEC_READY bit in the dpcd register:
> FEC_CONFIGURATION.
>
> This has to happen before link training.
>
> v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
>-
On Mon, Nov 05, 2018 at 03:31:47PM -0800, Anusha Srivatsa wrote:
> For DP 1.4 and above, Display Stream compression can be
> enabled only if Forward Error Correctin can be performed.
>
> Add a crtc state for FEC. Currently, the state
> is determined by platform, DP and DSC being
> enabled. Moving
Hi all,
Today's linux-next merge of the drm-msm tree got a conflict in:
drivers/gpu/drm/msm/hdmi/hdmi.c
between commit:
f384d7d514d1 ("drm: Convert to using %pOFn instead of device_node.name")
from the drm-misc tree and commit:
bdc309778907 ("drm: msm: Use DRM_DEV_* instead of dev_*")
If FEC is supported, the corresponding
DP_TP_CTL register bits have to be configured.
The driver has to program the FEC_ENABLE in DP_TP_CTL[30] register
and wait till FEC_STATUS in DP_TP_CTL[28] is 1.
Also add the warn message to make sure that the control
register is already active while
If the panel supports FEC, the driver has to
set the FEC_READY bit in the dpcd register:
FEC_CONFIGURATION.
This has to happen before link training.
v2: s/intel_dp_set_fec_ready/intel_dp_sink_set_fec_ready
- change commit message. (Gaurav)
v3: rebased. (r-b Manasi)
v4: Use fec crtc state,
Set the suitable bits in DP_TP_CTL to stop
bit correction when DSC is disabled.
v2:
- rebased.
- Add additional check for compression state. (Gaurav)
v3: rebased.
v4:
- Move the code to the proper spot according to spec (Ville)
- Use proper checks (manasi)
v5: Remove unnecessary checks (Ville)
For DP 1.4 and above, Display Stream compression can be
enabled only if Forward Error Correctin can be performed.
Add a crtc state for FEC. Currently, the state
is determined by platform, DP and DSC being
enabled. Moving forward we can use the state
to have error correction on other scenarios too
https://bugs.freedesktop.org/show_bug.cgi?id=108608
abortretryf...@gmail.com changed:
What|Removed |Added
Attachment #142294|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=108608
--- Comment #5 from abortretryf...@gmail.com ---
It works! Mostly.
Everything seems to run fine until after a suspend/resume, after which i get
scrambled gibberish on one monitor (DisplayPort-0) and nothing on the other two
(DVI-D-0,1).
Do some cleanup in the static inline functions defined in
dpu_media_info.h by cleaning up gotos and unneeded local
variables.
Signed-off-by: Jordan Crouse
---
.../gpu/drm/msm/disp/dpu1/msm_media_info.h| 164 ++
1 file changed, 57 insertions(+), 107 deletions(-)
diff --git
Do some debugfs cleanups from across the DPU driver. The DRM
destroy functions will do a recursive delete on the entire
debugfs node so there is no need to store dentry pointers for
the debugfs files that are persistent for the life of the
driver. This also means that the destroy functions can go
The functions in dpu_dbg.c aren't used. The two main dump functions
fail after a lookup from dpu_dbg_base.reg_base_list which turns out
to never be populated and once those are removed the rest of the
file doesn't make any sense.
v2: Moved some unrelated changes to another patch
Signed-off-by:
dpu_irq.c does some unneeded checks and passes control
to dpu_core_irq.c The simple functions can be defined
in the same file where we use them and the files and
their associated hangers on can be deleted.
Additionally the postinstall hook isn't used even
in dpu_core_irq.c so zap that entire
Remove some unused container_of() helper functions.
v2: Retained still used helper functions in the name of readability
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 10 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 10 --
Remove more static inline functions that are lightly used and/or
very simple and easy to build into the calling functions.
v2: Removed another unused function from dpu_hw_lm.c and add back
dpu_crtc_get_client_type() since there was a question regarding
its usefulness.
Signed-off-by: Jordan
Allow the KMS operation 'irq_postinstall' to be optional
so that the target display drivers don't need to define
a dummy function if they don't need one.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
The static inline function dpu_crtc_enabled() is only called once
and the function that calls it in turn is only called once and
the return value can be easily checked in the calling functions
so collapse everything down.
Signed-off-by: Jordan Crouse
---
Outside of superfluous parameter checks the dpu_hw_blk_init()
doesn't have any failure paths. Switch it over to be a void
function and we can remove error handling paths in all the functions
that call it. While we're in those functions remove unneeded
initialization for a static variable.
v2:
I've been working on various methods to automate code cleanup strategies
and I'm using dpu as my guinea pig. I started out by trying to identify
unused or lightly static inline functions and then that morphed to
very small functions in general and that then identified a few general
areas of
Use the standard DEFINE_SHOW_ATTRIBUTE macro for seq_file based
debugfs files instead of custom macros and hand-coded functions.
v2: Added a cleanup for dpu_encoder.c too
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 14 +---
dpu_crtc_get_mixer_height() is only used once and the value it
returns can be easily derived from the calling function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 13 -
2 files changed, 1
This broke rendering on V3D, where we almost always have a 0
in-syncobj.
Signed-off-by: Eric Anholt
Fixes: 48197bc564c7 ("drm: add syncobj timeline support v9")
Cc: Chunming Zhou
Cc: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
This is rather confusing to look at as-is:
dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler()
handles disabling the actual HPD IRQ, while
intel_hpd_irq_storm_disable() handles moving the HPD pin state over from
MARK_DISABLED to DISABLED along with enabling polling for it.
This series contains a fix for a problem which is very difficult to
reproduce under normal circumstances without specialized testing
hardware, along with a fix that seems to be required for some especially
rebellious GM45 laptops.
Lyude Paul (5):
drm/i915: Fix possible race in
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having
Currently in intel_hpd_irq_storm_detect() when we detect that the last
recorded hotplug wasn't within the period defined by
HPD_STORM_DETECT_DELAY, we make the mistake of resetting the HPD count
to 0 without incrementing it. This results in us only enabling storm
detection when we go +2 above the
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750]
On Thu, Nov 01, 2018 at 09:00:42PM +0100, Paul Kocialkowski wrote:
> This adds the device-tree bindings for the LeMaker BL035-RGB-002 3.5"
> QVGA TFT LCD panel, compatible with simple-panel.
>
> Signed-off-by: Paul Kocialkowski
> ---
> .../bindings/display/panel/lemaker,bl035-rgb-002.txt
On Thu, Nov 01, 2018 at 09:00:41PM +0100, Paul Kocialkowski wrote:
> This introduces a new device-tree binding vendor prefix for Shenzhen
> LeMaker Technology Co., Ltd.
Would be nice to say this is already in use, but wasn't documented.
>
> Signed-off-by: Paul Kocialkowski
> ---
>
On Thu, Nov 01, 2018 at 04:34:42PM +0200, Stefan Mavrodiev wrote:
> On 7/16/18 6:08 PM, Rob Herring wrote:
> > On Thu, Jul 12, 2018 at 11:21:53AM +0300, Stefan Mavrodiev wrote:
> > > This patch adds Olimex Ltd. LCD-OLinuXino bridge panel driver. The
> > > panel is used with different LCDs
Hi Tony,
On Monday, 5 November 2018 22:14:46 EET Tony Lindgren wrote:
> * Laurent Pinchart [181105 19:23]:
> > This patch applies on top of the "[PATCH v2 0/4] omapdrm: Fix runtime PM
> > issues at module load and unload time" series. It demonstrates what I
> > think is the proper long term fix
Hi Tony,
On Monday, 5 November 2018 22:02:47 EET Tony Lindgren wrote:
> * Laurent Pinchart [181105 15:10]:
> > The bind function performs hardware access (in hdmi4_cec_init()) and
> > thus requires the device to be active. Ensure this by surrounding the
> > bind function by hdmi_runtime_get()
On 2018-11-05 09:24, Sean Paul wrote:
On Fri, Nov 02, 2018 at 04:38:48PM -0700, Jeykumar Sankaran wrote:
On 2018-11-01 12:18, Sean Paul wrote:
> On Wed, Oct 31, 2018 at 05:19:05PM -0700, Jeykumar Sankaran wrote:
> > msm maintains a separate structure to define vblank
> > work definitions and a
Hi Fabrizio,
Thanks for working on that. I think your solution fixes the issue we had
on atmel boards [1] in a clean way (still have to find some time to
test it).
On Mon, 5 Nov 2018 13:56:48 +
Fabrizio Castro wrote:
> @@ -441,6 +558,9 @@ static int sii902x_remove(struct i2c_client
https://bugs.freedesktop.org/show_bug.cgi?id=108577
Roman Li changed:
What|Removed |Added
CC||roman...@amd.com
--- Comment #25 from Roman
https://bugs.freedesktop.org/show_bug.cgi?id=108668
--- Comment #1 from Samantha McVey ---
In addition, even though there is a write error, when you read back the
brightness value, it shows that the backlight is at level 0, while its
brightness has actually been unchanged from before:
echo 0 >
On Fri, Nov 02, 2018 at 08:19:07PM -0400, Lyude Paul wrote:
> This is rather confusing to look at as-is:
> dev_priv->display.hpd_irq_setup(dev_priv); in intel_hpd_irq_handler()
> handles disabling the actual HPD IRQ, while
> intel_hpd_irq_storm_disable() handles moving the HPD pin state over from
https://bugs.freedesktop.org/show_bug.cgi?id=108668
Bug ID: 108668
Summary: drm/amd/display: set backlight level limit to 1:
breaks userspace programs assuming 0 is the minimum
brightness
Product: DRI
Version:
https://bugs.freedesktop.org/show_bug.cgi?id=107928
--- Comment #14 from Matthew Miller ---
Same thing on Fedora 29. 4.18.16-300.fc29.x86_64; also RX Vega 64. One monitor,
connected either via DP or MDP.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105982
--- Comment #1 from Matthew Miller ---
Is this the same as #107261?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #10 from quirin.blae...@freenet.de ---
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Am 05.11.18 um 16:39 schrieb bugzilla-dae...@bugzilla.kernel.org:
> https://bugzilla.kernel.org/show_bug.cgi?id=201273
>
> --- Comment #9 from
Hi,
On Fri, Nov 2, 2018 at 5:49 AM Jayant Shekhar wrote:
>
> In case of msm drm bind failure, dpu_mdss_destroy is triggered.
> In this function, resources are freed and pm runtime disable is
> called, which triggers dpu_mdss_disable. Now in dpu_mdss_disable,
> driver tries to access a memory
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #24 from Alex Deucher ---
Does just removing this line from the code:
value |= 0x84;
also fix the issue?
--
You are receiving this mail because:
You are the assignee for the bug.___
The internal encoders (DSI, HDMI4, HDMI5 and VENC) runtime PM handlers
attempt to manage the runtime PM state of the connected DISPC, based on
the rationale that the DISPC providing data to the encoders requires
ensuring that the display is active whenever the encoders are active.
While the DISPC
https://bugs.freedesktop.org/show_bug.cgi?id=108139
--- Comment #5 from Alex Deucher ---
(In reply to Nicholas Kazlauskas from comment #2)
> Do you mind posting a full dmesg log for your 4.18 kernel? It would probably
> help to have drm.debug=4 in your boot parameters as well for this.
Is deep
On Sun, Sep 16, 2018 at 01:45:24PM +0530, Uma Shankar wrote:
> Existing LUT precision structure is having only 16 bit
> precision. This is not enough for upcoming enhanced hardwares
> and advance usecases like HDR processing. Hence added a new
> structure with 32 bit precision values. Also added
Heya,
On 2018-11-05 18:25, Emil Velikov wrote:
On Mon, 5 Nov 2018 at 11:42, Robert Foss wrote:
When the execbuf call receives an in-fence it will get the dma_fence
related to that fence fd and wait on it before submitting the draw call.
On the out-fence side we get fence returned by the
https://bugs.freedesktop.org/show_bug.cgi?id=108260
--- Comment #8 from Daniel Exner ---
Can confirm: Message is gone on 4.20-rc1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Fri, Nov 02, 2018 at 02:45:33PM -0700, Matthias Kaehlcke wrote:
> Allow the 10nm PHY driver to get the ref clock from the DT.
>
Might be nice to state that there are no current users of the 10nm phy in your
commit message.
Sean
> Signed-off-by: Matthias Kaehlcke
> ---
>
On Fri, Nov 02, 2018 at 02:45:34PM -0700, Matthias Kaehlcke wrote:
> Get the PHY ref clock from the device tree instead of hardcoding
> its name and rate.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/gpu/drm/msm/dsi/pll/dsi_pll_10nm.c | 11 ++-
> 1 file changed, 10
On Mon, 5 Nov 2018 at 11:42, Robert Foss wrote:
>
> When the execbuf call receives an in-fence it will get the dma_fence
> related to that fence fd and wait on it before submitting the draw call.
>
> On the out-fence side we get fence returned by the submitted draw call
> and attach it to a
https://bugs.freedesktop.org/show_bug.cgi?id=108644
--- Comment #3 from Dan Horák ---
OK, will try both.
It crashed twice since last Thursday when I updated the firmware, so it might
take me some time to get a better info. There isn't a clear reproducer.
--
You are receiving this mail
On Fri, Nov 02, 2018 at 04:38:48PM -0700, Jeykumar Sankaran wrote:
> On 2018-11-01 12:18, Sean Paul wrote:
> > On Wed, Oct 31, 2018 at 05:19:05PM -0700, Jeykumar Sankaran wrote:
> > > msm maintains a separate structure to define vblank
> > > work definitions and a list to track events submitted
>
This is the only place in the driver that should have to deal with
the raw hardware fences. To avoid any further confusion, consolidate
the fence handling in this file and remove any traces of this from
the header files.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.h | 11
There is no need to track the currently active fence. The GPU scheduler
keeps track of all the in-flight jobs.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 7 ++-
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 1 -
2 files changed, 2 insertions(+), 6 deletions(-)
diff
While 144MHz is listed in the datasheet as the typical pixel clock
this leads to a vrefresh rate of 64Fps, which is not what most people
expect. Change this to 135MHz to provide a more common 60Fps refresh
rate.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/panel/panel-simple.c | 2 +-
1 file
https://bugs.freedesktop.org/show_bug.cgi?id=108644
--- Comment #2 from Alex Deucher ---
Does this patch help?
https://patchwork.freedesktop.org/patch/259364/
Can you bisect which firmware commit
(https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git)
caused the regression
On Mon, Nov 05, 2018 at 07:54:52AM +0100, Andrzej Hajda wrote:
> On 02.11.2018 19:25, Jordan Crouse wrote:
> > Devices that are bound as components should not use devm since
> > device managed memory is not freed when the component is
> > unbound.
> >
> > In particular this is an issue if the
https://bugs.freedesktop.org/show_bug.cgi?id=108644
--- Comment #1 from Dan Horák ---
for the record - this is with Radeon Pro WX 4100
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
Does this patch help?
https://patchwork.freedesktop.org/patch/259364/
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108652
--- Comment #1 from Alex Deucher ---
Has the performance changed in any specific applications?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Mon, 5 Nov 2018 at 15:30, Chris Wilson wrote:
>
> Quoting kbuild test robot (2018-10-26 16:55:25)
> > Hi Emil,
> >
> > Thank you for the patch! Yet something to improve:
> >
> > [auto build test ERROR on sof-driver-fuweitax/master]
> > [also build test ERROR on v4.19 next-20181019]
> > [if
Allow to compile-test imx-drm on other platforms.
Signed-off-by: Philipp Zabel
---
drivers/gpu/drm/imx/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/Kconfig b/drivers/gpu/drm/imx/Kconfig
index c9e439c82241..3f20b7fe82b9 100644
---
This patch fixes backtraces like the following when sending SIGKILL to a
process with a currently pending plane update:
[drm:ipu_plane_atomic_check] CRTC should be enabled
[drm:drm_framebuffer_remove] *ERROR* failed to commit
[ cut here ]
WARNING: CPU: 3
https://bugs.freedesktop.org/show_bug.cgi?id=108625
--- Comment #12 from Alex Deucher ---
(In reply to Carsten Haitzler from comment #10)
> so wouldn't that make it a necessity then if its even glamor needing it? i
> guess i can turn off glamor accel but realistically gl is a necessity so the
>
Quoting kbuild test robot (2018-10-26 16:55:25)
> Hi Emil,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on sof-driver-fuweitax/master]
> [also build test ERROR on v4.19 next-20181019]
> [if your patch is applied to the wrong git tree, please drop us a note to
On 2018-11-01 9:51 p.m., Lyude Paul wrote:
> [why]
> Removing connector reusage from DM to match the rest of the tree ended
> up revealing an issue that was surprisingly subtle. The original amdgpu
> code for DC that was submitted appears to have left a chunk in
> dm_dp_create_fake_mst_encoder()
On Mon, 5 Nov 2018 at 14:54, Imre Deak wrote:
>
> Fix typo in struct field initializer.
>
> Fixes: 3a6eb795641c ("drm/vgem: create a render node for vgem")
> Cc: Emil Velikov
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Imre Deak
Reviewed-by:
https://bugs.freedesktop.org/show_bug.cgi?id=108625
--- Comment #11 from Alex Deucher ---
Does this patch help?
https://patchwork.freedesktop.org/patch/259364/
Does ARM support write combining? The driver uses it pretty extensively. You
might try disabling GTT_USWC (uncached write combined)
Hi Tony,
On Thursday, 1 November 2018 18:17:43 EET Laurent Pinchart wrote:
> On Thursday, 1 November 2018 17:58:56 EET Tony Lindgren wrote:
> > * Laurent Pinchart [181101 12:13]:
> >> On Thursday, 1 November 2018 13:47:40 EET Tomi Valkeinen wrote:
> >>> We do dispc_runtime_get/put in the HDMI
The bind function performs hardware access (in hdmi4_cec_init()) and
thus requires the device to be active. Ensure this by surrounding the
bind function by hdmi_runtime_get() and hdmi_runtime_put() calls.
Fixes: 27d624527d99 ("drm/omap: dss: Acquire next dssdev at probe time")
Signed-off-by:
The DSS DT node contains children that describe the DSS components
(DISPC and internal encoders). Each of those components is handled by a
platform driver, and thus needs to be backed by a platform device.
The corresponding platform devices are created in mach-omap2 code by a
call to
The runtime suspend and resume callbacks for the DSI, HDMI4, HDMI5 and
VENC try to manage the runtime PM state of the DISPC, which can be
unavailable at probe time (due to the DSS probe being deferred for
instance) and remove time (due to the DISPC being removed already). The
proper fix is to move
The probe function performs hardware access to read the number of
supported data lanes from a configuration register and thus requires the
device to be active. Ensure this by surrounding the access with
dsi_runtime_get() and dsi_runtime_put() calls.
Fixes: edb715dffdee ("drm/omap: dss: dsi: Move
Hello,
This series fixes crashes in the omapdss driver at both load and unload
time, due to runtime PM problems related to probe deferral. The bugs got
introduced in v4.20-rc, this should thus be considered as v4.20 fixes.
At the core of the problem comes commit 27d624527d99 ("drm/omap: dss:
Fix typo in struct field initializer.
Fixes: 3a6eb795641c ("drm/vgem: create a render node for vgem")
Cc: Emil Velikov
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Imre Deak
---
drivers/gpu/drm/vgem/vgem_drv.c | 2 +-
1 file changed, 1 insertion(+), 1
+amdgfx, amdgpu specific patches should go here
On 2018-11-05 05:33 AM, Shaokun Zhang wrote:
> RETIMER_REDRIVER_INFO shows the buffer as a decimal value with a '0x'
> prefix, which is somewhat misleading.
>
> Fix it to print hexadecimal, as was intended.
>
> Fixes: 2f14bc89("drm/amd/display:
On Mon, Nov 05, 2018 at 02:30:50PM +, Wentland, Harry wrote:
>
>
> On 2018-11-05 9:04 a.m., Ville Syrjälä wrote:
> > On Mon, Nov 05, 2018 at 10:26:01AM +0100, Daniel Vetter wrote:
> >> On Thu, Nov 01, 2018 at 08:46:44PM +0200, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
> >>>
> >>>
On Mon, Nov 05, 2018 at 10:33:47AM +0100, Daniel Vetter wrote:
> On Thu, Nov 01, 2018 at 08:46:46PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Convert drm_atomic_plane_check() over to using explicit old vs. new
> > plane states. Avoids the confusion of "what does plane->state
On 2018-11-05 9:04 a.m., Ville Syrjälä wrote:
> On Mon, Nov 05, 2018 at 10:26:01AM +0100, Daniel Vetter wrote:
>> On Thu, Nov 01, 2018 at 08:46:44PM +0200, Ville Syrjala wrote:
>>> From: Ville Syrjälä
>>>
>>> Replace 'crtc->state' with the explicit old crtc state.
>>>
>>> Actually it shouldn't
On Mon, Nov 05, 2018 at 10:26:01AM +0100, Daniel Vetter wrote:
> On Thu, Nov 01, 2018 at 08:46:44PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Replace 'crtc->state' with the explicit old crtc state.
> >
> > Actually it shouldn't matter whether we use the old or the new
> > crtc
1 - 100 of 155 matches
Mail list logo
