On Tue, Dec 18, 2018 at 8:15 AM Andrzej Hajda wrote:
>
> On 17.12.2018 15:46, Daniel Vetter wrote:
> > On Mon, Dec 17, 2018 at 10:54:48AM +0100, Andrzej Hajda wrote:
> >> Hi Daniel,
> >>
> >> Thanks for reviewing other two patches.
> >>
> >>
> >> On 14.12.2018 17:29, Daniel Vetter wrote:
> >>> On
Hi Kieran,
On Monday, 13 November 2017 15:48:19 EET Kieran Bingham wrote:
> On 13/11/17 10:32, Laurent Pinchart wrote:
> > Hello everybody,
> >
> > This patch series fixes two issues related to dma-buf import for the
> > Renesas R-Car DU when the imported buffer is either not physically
> > conti
Check first two header bytes before trying to read the edid blob,
to avoid the log being spammed in case qemu has no edid support (old
qemu or edid turned off).
Fixes: 01f23459cf drm/bochs: add edid support.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/bochs/bochs_hw.c | 4
1 file chang
On 17.12.2018 15:46, Daniel Vetter wrote:
> On Mon, Dec 17, 2018 at 10:54:48AM +0100, Andrzej Hajda wrote:
>> Hi Daniel,
>>
>> Thanks for reviewing other two patches.
>>
>>
>> On 14.12.2018 17:29, Daniel Vetter wrote:
>>> On Fri, Dec 14, 2018 at 02:38:52PM +0100, Andrzej Hajda wrote:
rr_cache_
Hi Morimoto-san,
Thank you for the patch.
On Tuesday, 18 December 2018 08:00:24 EET Kuninori Morimoto wrote:
> From: Kuninori Morimoto
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
> Signed-off-by: Kuninori Morimoto
Reviewed-by: Laurent Pi
On 18 December 2018 5:03:22 am AEDT, Emil Velikov
wrote:
>Hi Christopher,
>
>On Tue, 20 Nov 2018 at 04:30, Christopher James Halse Rogers
> wrote:
>>
>> I have wanted this code in Mir, so it's plausibly useful elsewhere,
>> particularly if the DRM device major number is going to become
>> dynamic
Signed-off-by: Tapani Pälli
---
(Driver was removed from Mesa long time ago.)
libkms/Android.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libkms/Android.mk b/libkms/Android.mk
index 0be72054..bf4781a3 100644
--- a/libkms/Android.mk
+++ b/libkms/Android.mk
@@ -1,6 +1,6
On 18 December 2018 4:35:37 am AEDT, Emil Velikov
wrote:
>Hi Christopher,
>
>On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers
> wrote:
>>
>> We can't use drmSetMaster to query whether or not a drm fd is master
>> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>>
>
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #64 from CheatCodesOfLife ---
It'll be a different bug, this only affects Vega10 cards. Polaris is fine with
Cemu and the other guy's Vega test app.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #34 from Shmerl ---
I tested the patch. I don't see the error message now, but the startup monitor
sleep regression is still present. Is it a separate issue? I can open another
bug if needed.
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=109022
--- Comment #3 from e88z4 ---
I did a little more troubleshooting on my API trace.
Call #36840880 is the culprit of the VMC Page Fault error. The GPU didn't crash
right away but continuing 100-200 calls after 36840880 might randomly trigger
th
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #63 from e88z4 ---
Hi
I came across this bug report that might be related to my bug report #109022
https://bugs.freedesktop.org/show_bug.cgi?id=109022
I got the VMC Page Fault error as well while playing Yuzu with RX580. The bug
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #33 from Sibren Vasse ---
Just tried the patch, so far no reg_wait warnings. Looking good!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing l
On Thu, 2018-12-13 at 15:09 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-12-13 at 07:18 +0200, Ville Syrjälä wrote:
> > On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan
> > wrote:
> > > On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
>
Hi,
On Sun, Dec 16, 2018 at 11:06 PM Viresh Kumar wrote:
>
> +Rob +Stephen,
>
> On 14-12-18, 09:04, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar
> > wrote:
> > >
> > > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > > + gpu_opp_table: opp-
On Mon, Dec 17, 2018 at 8:48 PM Daniel Vetter wrote:
>
> On Thu, Dec 13, 2018 at 07:09:15PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Dec 13, 2018 at 5:25 PM Daniel Vetter
> > wrote:
> > >
> > > On Thu, Dec 13, 2018 at 5:18 PM Rafael J. Wysocki
> > > wrote:
> > > >
> > > > On Thu, Dec 13, 20
On Mon, Dec 17, 2018 at 05:43:59PM +, Emil Velikov wrote:
> On Fri, 19 Oct 2018 at 18:20, Lucas De Marchi
> wrote:
> >
>
> > /_build*
> > /build*
> >
> These two sound perfectly reasonable IMHO. They will catch vast
> majority of use-cases.
>
> With that the series is:
> Acked-by: Emil Veli
Correct definition of both formats by swapping red
and blue channels
v3: update commit message
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
b/driver
https://bugs.freedesktop.org/show_bug.cgi?id=109073
tiredandn...@gmail.com changed:
What|Removed |Added
Summary|AMDGPU Radeon RX540 system |AMDGPU Radeon RX540 system
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #72 from dwagner ---
Just for the record, since another month has passed: I can still reproduce the
crash with today's git head of amd-staging-drm-next within minutes. (Also using
the very latest firmware files from
https://people.fr
https://bugs.freedesktop.org/show_bug.cgi?id=109073
tiredandn...@gmail.com changed:
What|Removed |Added
Priority|medium |high
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #4 from tiredandn...@gmail.com ---
Created attachment 142843
--> https://bugs.freedesktop.org/attachment.cgi?id=142843&action=edit
dmesg with 4.20.0-042000rc7-generic without ac adapter
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #3 from tiredandn...@gmail.com ---
Created attachment 142842
--> https://bugs.freedesktop.org/attachment.cgi?id=142842&action=edit
Kern.log of failed boot (black screen) with 4.20.0-042000rc7-generic
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #2 from tiredandn...@gmail.com ---
With 4.20.0-042000rc7-generic it is actually worse. The system hangs with a
black screen while booting with power adapter connected. Without power adapter
it does boot.
--
You are receiving this ma
Some hardware may place additional restrictions on the gamma/degamma
curves described by our LUT properties. E.g., that a gamma curve never
decreases or that the red/green/blue channels of a LUT's entries must be
equal. Let's add a helper function that drivers can use to test that a
userspace-pro
We currently program userspace-provided gamma and degamma LUT's into our
hardware without really checking to see whether they satisfy our
hardware's rules. We should try to catch tables that are invalid for
our hardware early and reject the atomic transaction.
All of our platforms that accept a d
Fix intf_type description in msm_disp_info to show that
it represents drm encoder mode of the display.
changes in v3:
- introduced in the series
changes in v4:
- none
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 del
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the SDM845 Display port
driver changes[1].
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jordan Crouse)
Bail out KMS hw init on display initialization failures with
proper error logging.
changes in v3:
- introduced in the series
changes in v4:
- avoid duplicate return on errors (Sean Paul)
- avoid spamming errors on failures (Jordon Crouse)
Signed-off-by: Jeykumar Sankaran
---
drivers
On Thu, 22 Nov 2018 14:36:53 +0530, Sravanthi Kollukuduru wrote:
> Add interconnect properties such as interconnect provider specifier
> , the edge source and destination ports which are required by the
> interconnect API to configure interconnect path for MDSS.
>
> Changes in v2:
> - none
>
On Mon, Dec 17, 2018 at 03:20:10PM -0600, Rob Herring wrote:
> On Wed, Dec 12, 2018 at 02:18:47PM -0700, Jordan Crouse wrote:
> > Update the GPU bindings and document the new bindings for the GMU
> > device found with Adreno a6xx targets.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> > .../devi
Hi Yue,
Thank you for the patch.
On Monday, 17 December 2018 11:18:30 EET YueHaibing wrote:
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
> Fixes: 8f1597c8f1a5 ("d
On Tue, 11 Dec 2018 21:13:57 +0530, Jagan Teki wrote:
> Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel
> with inbuilt ST7701 chip.
>
> The default regulator names in ST7701 chip is renamed in Techstar TS8550B
> so, add specific binding names for them.
>
> Signed-off-by: Jag
On Wed, Dec 12, 2018 at 02:18:47PM -0700, Jordan Crouse wrote:
> Update the GPU bindings and document the new bindings for the GMU
> device found with Adreno a6xx targets.
>
> Signed-off-by: Jordan Crouse
> ---
> .../devicetree/bindings/display/msm/gmu.txt | 56 +++
> .../devic
https://bugs.freedesktop.org/show_bug.cgi?id=109080
Bug ID: 109080
Summary: Broken video playback colors on AMD Ryzen 5 (PRO)
Mobile 2500U in 18.1 and 18.2
Product: Mesa
Version: 18.2
Hardware: Other
OS: All
On 2018-12-14 07:22, Sean Paul wrote:
On Thu, Dec 13, 2018 at 10:51:03AM -0800, Jeykumar Sankaran wrote:
Bail out KMS hw init on display initialization failures with
proper error logging.
changes in v3:
- introduced in the series
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/m
On 2018-12-14 3:47 a.m., Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote:
>> There should be no functional changes here
>
> Would be good to explain what you did refactor here, instead of me trying
> to reconstruct it from the patch. Especially pre-coffee that hel
Hi Maxime,
On Mon, Dec 17, 2018 at 04:49:21PM +0100, Maxime Ripard wrote:
> Hi Sakari,
>
> Thanks for your feedback.
>
> On Thu, Dec 13, 2018 at 10:49:28PM +0200, sakari.ai...@iki.fi wrote:
> > > + /**
> > > + * @lanes:
> > > + *
> > > + * Number of active data lanes used for the transmission
On 2018-12-14 3:42 a.m., Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:30PM -0500, Lyude Paul wrote:
>> There's no reason we need this, it's just confusing looking.
>>
>> Signed-off-by: Lyude Paul
>> Cc: Juston Li
>> ---
>> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
>> 1 file chang
Emil Velikov writes:
> Hi Christopher,
>
> On Tue, 20 Nov 2018 at 04:30, Christopher James Halse Rogers
> wrote:
>>
>> I have wanted this code in Mir, so it's plausibly useful elsewhere,
>> particularly if the DRM device major number is going to become
>> dynamic.
>>
> Can you elaborate/link to
Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit finis
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complete before rerunning the jobs.
v2: Fix resubmission
Sergey Suloev writes:
> Eric, thanks for answer,
>
> I am in doubt the type of my panel. It is Himax HX8379A-based panel.
> Is there a deterministic way to find out which type of panel I have,
> video or command ?
You have to find your panel's documentation, existing drivers, etc.
signature
On Thu, Dec 13, 2018 at 07:09:15PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 13, 2018 at 5:25 PM Daniel Vetter wrote:
> >
> > On Thu, Dec 13, 2018 at 5:18 PM Rafael J. Wysocki wrote:
> > >
> > > On Thu, Dec 13, 2018 at 1:36 PM Daniel Vetter
> > > wrote:
>
> [cut]
>
> > > > I can do the ol
It's a legacy kms only thing, good to hide it better now that all
those old drivers use the legacy crtc helpers directly.
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 1
The correct way for legacy drivers to update properties that need to
do a full modeset, is to do a full modeset.
Note that we don't need to call the drm_mode_config_internal helper
because we're not changing any of the refcounted paramters.
v2: Fixup error handling (Ville). Since the old code did
It's not a core function, and the matching atomic functions are also
not in the core. Plus the suspend/resume helper is also already there.
Needs a tiny bit of open-coding, but less midlayer beats that I think.
v2: Rebase onto ast (which gained a new user).
Cc: Sam Bobroff
Reviewed-by: Alex Deu
Doesn't do anything for atomic drivers.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index a7c39f39793f..f8a1d70a31c7 100644
--- a/dri
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_sim.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 68629e614990..6530d88f7293 100644
--- a/drivers/gpu/d
The correct way for legacy drivers to update properties that need to
do a full modeset, is to do a full modeset.
Note that we don't need to call the drm_mode_config_internal helper
because we're not changing any of the refcounted paramters.
v2: Fixup error handling (Ville). Since the old code did
On 2018-12-14 07:22, Sean Paul wrote:
On Thu, Dec 13, 2018 at 10:51:03AM -0800, Jeykumar Sankaran wrote:
Bail out KMS hw init on display initialization failures with
proper error logging.
changes in v3:
- introduced in the series
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/m
On 2018-12-14 11:46, Tanmay Shah wrote:
Red and Blue colors will be interchanged on display with
current format maps for RGB565 and BGR565.
Change both format maps to display correct colors.
You can drop "DPU PATCH" prefix in the patches.
Can you also provide history on what has changed since
On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote:
> Hi All,
>
> As discussed a while ago, I would like to see us enable fastboot by
> default, starting with Skylake / GEN9 and newer hardware, so that we can
> avoid an unnecessary modeset at boot and move to a truely flickerfree boot.
On Wed, 12 Dec 2018 at 19:49, François Tigeot wrote:
>
> It is a cleaner and less fragile way to get PCI IDs than the one
> currently used by local DPorts patches.
>
Thanks for these François. Props to Ilia for pushing these.
JFYI, once DragonFly gets PCI dynamic power management, the team may
wa
Am 17.12.18 um 17:57 schrieb Grodzovsky, Andrey:
>
> On 12/17/2018 10:27 AM, Christian König wrote:
>> Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
>>> Decauple sched threads stop and start and ring mirror
>>> list handling from the policy of what to do about the
>>> guilty jobs.
>>> When stoppp
On Tue, 11 Dec 2018 at 22:15, François Tigeot wrote:
>
> * There is no way to check if a device name is really a drm device
> by looking it up in a virtual filesystem like on Linux
>
> * The major device number is also dynamically allocated from a pool,
> comparing it to a constant makes no se
Sergey Suloev writes:
> Eric, Noralf,
>
> could either of you answer a question about Vc4 DRM, please ?
>
> I am trying to connect MIPI DSI display to VC4 but it isn't showing
> anything. I have noticed
> that the DSI host transfer() method vc4_dsi_host_transfer gets called
> for the commands
Hi Christopher,
On Tue, 20 Nov 2018 at 04:30, Christopher James Halse Rogers
wrote:
>
> I have wanted this code in Mir, so it's plausibly useful elsewhere,
> particularly if the DRM device major number is going to become
> dynamic.
>
Can you elaborate/link to the code that uses the major/minor?
F
Op 17-12-2018 om 15:19 schreef Hans de Goede:
> When the pipe_config's update_pipe flag is set we may need to update the
> panel fitting settings. On GEN9+ this means we need to update the crtc's
> scaler settings.
>
> This fixes the following WARN_ON, during i915 loading on an Asrock
> B150M Pro4S
On Wed, 7 Nov 2018 at 14:44, Eric Engestrom wrote:
>
> Reported-by: Jan Vesely
> Signed-off-by: Eric Engestrom
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/
On Wed, 7 Nov 2018 at 18:02, Eric Engestrom wrote:
>
> Also, move the sentence about "who would use libdrm" into its own paragraph,
> as it is something people discovering libdrm will want to know.
>
> Signed-off-by: Eric Engestrom
Reviewed-by: Emil Velikov
-Emil
__
On Mon, Dec 17, 2018 at 6:38 PM Emil Velikov wrote:
>
> Hi Christopher,
>
> On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers
> wrote:
> >
> > We can't use drmSetMaster to query whether or not a drm fd is master
> > because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>
On Wed, 7 Nov 2018 at 18:01, Eric Engestrom wrote:
>
> Thanks to the #error just above, any file including this header can only
> see one state for this macro: defined, with the value `1`.
> Let's just #undef it once we're done using it in here so that other
> files don't misconstrue any meaning t
Hi Chunming Zhou,
On Fri, 2 Nov 2018 at 08:27, Chunming Zhou wrote:
>
> Signed-off-by: Chunming Zhou
> ---
> include/drm/drm.h | 38 ++
Please read through include/drm/README about how include/drm/ should be updated.
Thanks
Emil
_
On Wed, 24 Oct 2018 at 17:59, Eric Engestrom wrote:
>
> On Wednesday, 2018-10-24 17:53:51 +0100, Eric Engestrom wrote:
> > Fixes the tests on ARM, but more importantly this makes it much easier
> > to maintain.
>
> BTW I have a wip to replace all of those with a python script that will
> be more t
On Fri, 19 Oct 2018 at 18:20, Lucas De Marchi wrote:
>
> /_build*
> /build*
>
These two sound perfectly reasonable IMHO. They will catch vast
majority of use-cases.
With that the series is:
Acked-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-
https://bugs.freedesktop.org/show_bug.cgi?id=108272
--- Comment #12 from Jan Vesely ---
Hi,
sorry for the delay. somehow I missed the notifications.
(In reply to jamespharvey20 from comment #11)
> When I originally filed this, I assumed it was 1 bug since I tried 2 things
> with OpenCL, and both
https://bugs.freedesktop.org/show_bug.cgi?id=109068
--- Comment #3 from Samantha McVey ---
Created attachment 142838
--> https://bugs.freedesktop.org/attachment.cgi?id=142838&action=edit
4.20-rc5 dmesg
In addition, this is what happens to the levels of "brightness" and
"actual_brightness" befo
Hi Christopher,
On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers
wrote:
>
> We can't use drmSetMaster to query whether or not a drm fd is master
> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>
Can you please mention the exact use case here? You mentioned it ove
https://bugs.freedesktop.org/show_bug.cgi?id=109068
--- Comment #2 from Samantha McVey ---
Created attachment 142837
--> https://bugs.freedesktop.org/attachment.cgi?id=142837&action=edit
amd-staging-drm-next dmesg
--
You are receiving this mail because:
You are the assignee for the bug.__
On 12/17/2018 10:27 AM, Christian König wrote:
> Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>> from
https://bugs.freedesktop.org/show_bug.cgi?id=103949
--- Comment #4 from Patrik Jakobsson ---
Hi, I'm getting the same error on upstream 4.18, 4.19 and drm-fixes-4.20
whenever I hotplug a DP monitor. Can you point me to the patch that is supposed
to fix this? I took a quick look at the mailing lis
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Alex Deucher changed:
What|Removed |Added
Attachment #142834|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Alex Deucher changed:
What|Removed |Added
Attachment #142835|0 |1
is patch|
On Mon, Dec 17, 2018 at 04:37:21PM +0100, Lucas Stach wrote:
> Hi Christian,
>
> Am Montag, den 17.12.2018, 11:09 +0100 schrieb Christian Gmeiner:
> > Am Fr., 14. Dez. 2018 um 11:44 Uhr schrieb Lucas Stach > tronix.de>:
> > >
> > > Hi Dave,
> > >
> > > nothing major this time, mostly some clean
https://bugs.freedesktop.org/show_bug.cgi?id=109066
--- Comment #2 from Benjamin Hodgetts ---
Created attachment 142836
--> https://bugs.freedesktop.org/attachment.cgi?id=142836&action=edit
Pulseaudio HDMI Sink Errors
I'll try amd-staging-drm-next but I've been getting almost non-stop errors o
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #32 from Jerry Zuo ---
Created attachment 142835
--> https://bugs.freedesktop.org/attachment.cgi?id=142835&action=edit
Patch for dp_blank timeout
--
You are receiving this mail because:
You are the assignee for the bug.__
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> It only written and we don't infer any useful information from
> it anymore. Remove it.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 2 --
> drivers/gpu/drm/etnaviv/
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> The etnaviv_gpu header only needs to know about the pointer types, so
> replace by a forward declaration and only include the headers where needed.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> The only event function that is called from IRQ context is event_free,
> which is already using atomic bitmap operations, so we can avoid taking
> the event spinlock in this function completely. As other the other
> functions still using
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #31 from Alex Deucher ---
(In reply to Jerry Zuo from comment #30)
> Please try the patch, and see if you can see reg_wait timeout
> dce110_stream_encoder_dp_blank()
Can you attach a non-zipped version?
--
You are receiving this m
Hi Sakari,
Thanks for your feedback.
On Thu, Dec 13, 2018 at 10:49:28PM +0200, sakari.ai...@iki.fi wrote:
> > + /**
> > +* @lanes:
> > +*
> > +* Number of active data lanes used for the transmissions.
>
> Could you add that these are the first "lanes" number of lanes from what
> ar
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #30 from Jerry Zuo ---
Please try the patch, and see if you can see reg_wait timeout
dce110_stream_encoder_dp_blank()
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #29 from Jerry Zuo ---
Created attachment 142834
--> https://bugs.freedesktop.org/attachment.cgi?id=142834&action=edit
parch for reg_wait timeout for dce
--
You are receiving this mail because:
You are the assignee for the bug.__
Hi Christian,
Am Montag, den 17.12.2018, 11:09 +0100 schrieb Christian Gmeiner:
> Am Fr., 14. Dez. 2018 um 11:44 Uhr schrieb Lucas Stach tronix.de>:
> >
> > Hi Dave,
> >
> > nothing major this time, mostly some cleanups that were found on
> > the
> > way of reworking the code in preparation for
It only written and we don't infer any useful information from
it anymore. Remove it.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 2 --
drivers/gpu/drm/etnaviv/etnaviv_drv.c| 8 +---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 2 --
drivers/gpu/drm/etnaviv/et
The etnaviv_gpu header only needs to know about the pointer types, so
replace by a forward declaration and only include the headers where needed.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 5 ++---
2 files changed, 4 inser
The only event function that is called from IRQ context is event_free,
which is already using atomic bitmap operations, so we can avoid taking
the event spinlock in this function completely. As other the other
functions still using the event spinlock are all called from normal
process context, we c
Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complet
https://bugs.freedesktop.org/show_bug.cgi?id=109049
Chris Wilson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
Hello, Juergen, Boris!
As this DRM part of the series is the only one which needs ack/nack
(and it might take quite some time to complete) could we please
merge the patches 1 and 3 now that already
Hi,
On 17-12-18 15:38, Ville Syrjälä wrote:
On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote:
Hi All,
As discussed a while ago, I would like to see us enable fastboot by
default, starting with Skylake / GEN9 and newer hardware, so that we can
avoid an unnecessary modeset at boot a
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #25 from quirin.blae...@freenet.de ---
Bug is still alive. amd-staging-drm-next
75061f375e7f627acbc3aa5466bc1ee552f3f22c
plymouth low res -> clear -> crash
(4da295299bda146326b44f22d8eeaa797d6acb38 too)
--
You are receiving this mail
On Mon, Dec 17, 2018 at 10:54:48AM +0100, Andrzej Hajda wrote:
> Hi Daniel,
>
> Thanks for reviewing other two patches.
>
>
> On 14.12.2018 17:29, Daniel Vetter wrote:
> > On Fri, Dec 14, 2018 at 02:38:52PM +0100, Andrzej Hajda wrote:
> >> rr_cache_dir function cannot assume REPO/.git is a direc
https://bugs.freedesktop.org/show_bug.cgi?id=109066
--- Comment #1 from Nicholas Kazlauskas ---
Do you see this occur on the amd-staging-drm-next branch from:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next ?
If yes, then it would also help to know more about your userspac
On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote:
> Hi All,
>
> As discussed a while ago, I would like to see us enable fastboot by
> default, starting with Skylake / GEN9 and newer hardware, so that we can
> avoid an unnecessary modeset at boot and move to a truely flickerfree boot.
Hi,
On 17-12-18 15:29, Daniel Vetter wrote:
On Mon, Dec 17, 2018 at 3:23 PM Hans de Goede wrote:
From: Maarten Lankhorst
We may not be perfect at reading out the initial mode, but when the mode
is sanitized by our first modeset we know for sure the state is compatible,
so we can compare wit
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #6 from Nicholas Kazlauskas ---
I suspect that Alex is right about this being similar to the cursor update
issue - a large volume of color management changes through the full atomic
commit codepath would likely be quite slow. The dc=
On Mon, Dec 17, 2018 at 3:23 PM Hans de Goede wrote:
>
> From: Maarten Lankhorst
>
> We may not be perfect at reading out the initial mode, but when the mode
> is sanitized by our first modeset we know for sure the state is compatible,
> so we can compare with intel_pipe_config_compare.
>
> Chang
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Rather then enabling it everywhere, lets start with enabling it on
Skylake and newer.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/i915_params.c | 6 --
drivers/gpu/drm/i915/i915_params.h
1 - 100 of 149 matches
Mail list logo
