On Thu, Oct 04, 2018 at 10:24:44PM +0200, Daniel Vetter wrote:
> Didn't get updated in a rework of the original patch.
Oops. Thanks for fixing,
> /**
> * drm_driver_legacy_fb_format - compute drm fourcc code from legacy
> description
> + * @dev: DRM device
> * @bpp: bits per pixels
> *
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #15 from Dieter Nützel (die...@nuetzel-hh.de) ---
(In reply to Dieter Nützel from comment #14)
> Diff !!!
>
> BAD
> Host Data Path Light Sleep: Off
card0/device> cat pp_dpm_mclk
0: 300Mhz
1: 1000Mhz
2: 2000Mhz *
card0/device>
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #14 from Dieter Nützel (die...@nuetzel-hh.de) ---
Diff !!!
BAD
Host Data Path Light Sleep: Off
GOOD
Host Data Path Light Sleep: On
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #13 from Dieter Nützel (die...@nuetzel-hh.de) ---
amd-staging-drm-next (with broken SDDM and then 'init 3')
Why is 'GPU Load:' so hight?
=> take it with a drain of salt.
Clock Gating Flags Mask: 0x3fbcf
Graphics Medium
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #12 from Dieter Nützel (die...@nuetzel-hh.de) ---
openSUSE Tumbleweed Kernel:stable 4.18.12-2.ga880bd8-default
After the patch.
(For 'before' I have to reboot to broken 'amd-staging-drm-next')
This reverts commit 0586feba322e1de05075700eb4b835c8b683e62b
This patch makes it to need get_vblank_counter callback in crtc
to get frame counter from decon driver.
However, drm_dev->max_vblank_count is a member unique to
vendor's DRM driver but in case of ARM DRM, some CRTC devices
don't
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) ---
Can you attach the output of `cat /sys/kernel/debug/dri/0/amdgpu_pm_info`
before and after the patch?
--
You are receiving this mail because:
You are watching the assignee of the
https://bugs.freedesktop.org/show_bug.cgi?id=106671
--- Comment #24 from Alan W. Irwin ---
Created attachment 141904
--> https://bugs.freedesktop.org/attachment.cgi?id=141904=edit
X log file showing segfault
Just now the direct X server failed with a segfault (see the attached log file
for
On Fri, Oct 05, 2018 at 08:50:19AM +1000, Dave Airlie wrote:
> Hey Greg,
>
> I was meant to take today off so sent the pull yesterday, but some
> more stuff came in and I'd rather not sit on it,
>
> Two fixes for amdgpu:
> one corrects a use of process->mm
> one fix for display code race
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try
Next version of https://patchwork.freedesktop.org/series/49878/ . No
changes, except that these patches are against master so hopefully
intel's CI doesn't get confused this time.
Lyude Paul (5):
drm/atomic_helper: Disallow new modesets on unregistered connectors
drm/nouveau: Fix
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup
With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #2 from Shmerl ---
Still broken with 4.19.0-rc6-amd64.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Currently, i915 appears to rely on blocking modesets on
no-longer-present MSTB ports by simply returning NULL for
->best_encoder(), which in turn causes any new atomic commits that don't
disable the CRTC to fail. This is wrong however, since we still want to
allow userspace to disable CRTCs on
Since we need to be able to allow DPMS on->off prop changes after an MST
port has disappeared from the system, we need to be able to make sure we
can compute a config for the resulting atomic commit. Currently this is
impossible when the port has disappeared, since the VCPI slot searching
we try
Currently we set intel_connector->mst_port to NULL to signify that the
MST port has been removed from the system so that we can prevent further
action on the port such as connector probes, mode probing, etc.
However, we're going to need access to intel_connector->mst_port in
order to fixup
With the exception of modesets which would switch the DPMS state of a
connector from on to off, we want to make sure that we disallow all
modesets which would result in enabling a new monitor or a new mode
configuration on a monitor if the connector for the display in question
is no longer
Next version of https://patchwork.freedesktop.org/series/49877/
This fixes some rather silly bugs regarding DPMS On->Off changes failing
for connectors which were just recently destroyed.
Lyude Paul (5):
drm/atomic_helper: Disallow new modesets on unregistered connectors
drm/nouveau: Fix
As mentioned in the previous commit, we currently prevent new modesets
on recently-removed MST connectors by returning no encoder from our
->best_encoder() callback once the MST port has disappeared. This is
wrong however, because it prevents legacy modesetting users from being
able to disable
https://bugs.freedesktop.org/show_bug.cgi?id=105911
--- Comment #13 from tnmailingli...@gmail.com ---
I now booted with amdgpu.dc_log=1 and found the following in my log when DC is
on (I'm currently on 4.15.0.36):
[1.479998] [drm] DC: create_links: connectors_num: physical:4, virtual:0
[
Hey Greg,
I was meant to take today off so sent the pull yesterday, but some
more stuff came in and I'd rather not sit on it,
Two fixes for amdgpu:
one corrects a use of process->mm
one fix for display code race condition that can result in a crash
Two core fixes:
One for a use-after-free in
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #10 from Dieter Nützel (die...@nuetzel-hh.de) ---
(In reply to Alex Deucher from comment #9)
> I don't think this is a bug. The problem is, prior to that patch, the
> display component was requesting minimum clocks that were 10x too
Hi!
I've sent out patches that replace 05/21 and 07/21. Since I'm on travel,
I'm not sure I'll be able to incorporate them in a pull before the merge
window though.
/Thomas
On 10/04/2018 10:24 PM, Daniel Vetter wrote:
...
___
dri-devel mailing list
Make the connector is_implicit property immutable.
As far as we know, no user-space application is writing to it.
Also move the verification that all implicit display units scan out
from the same framebuffer to atomic_check().
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
This fixes a layout update race condition. We make sure
the crtc mutex is locked before we dereference crtc->state. Otherwise the
state might change under us.
Since now we're already holding the crtc mutexes when reading the gui
coordinates, protect them with the crtc mutexes rather than with the
https://bugs.freedesktop.org/show_bug.cgi?id=108014
--- Comment #6 from Jerry Zuo ---
(In reply to Lyude Paul from comment #3)
> Just a note: I definitely don't have the time to take a closer look at this.
> If someone from AMD could take a look that would be /REALLY/ appreciated.
We are
Hi Daniel.
On Thu, Oct 04, 2018 at 10:24:43PM +0200, Daniel Vetter wrote:
> Well except the destroy helper, which isn't really a primary helper
> but generally useful, if mislabelled.
>
> Reviewed-by: Ville Syrjälä
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_plane_helper.c | 85
https://bugs.freedesktop.org/show_bug.cgi?id=108014
--- Comment #5 from Jerry Zuo ---
.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=108014
--- Comment #4 from Jerry Zuo ---
Created attachment 141903
--> https://bugs.freedesktop.org/attachment.cgi?id=141903=edit
MST patch
--
You are receiving this mail because:
You are the assignee for the
Hi Daniel.
> Aside: I think a lot more drivers should be using the device-level
> drm_atomic_helper_shutdown/suspend/resume helpers and related
> functions. In almost all the cases they get things exactly right.
One more point to todo.rst then?
Sam
On Thu, Oct 04, 2018 at 10:24:42PM +0200, Daniel Vetter wrote:
> It's for legacy drivers only (atomic ones should use
> drm_atomic_helper_check_plane_state() instead), and there's no users
> left except the one in the primary plane helpers.
>
> Signed-off-by: Daniel Vetter
> ---
>
On Thu, Oct 04, 2018 at 10:24:45PM +0200, Daniel Vetter wrote:
> Motivated by review comments from Ville
>
> Cc: Ville Syrjälä
> Cc: Sean Paul
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville Syrjälä
> ---
> Documentation/gpu/todo.rst | 10 ++
> 1 file changed, 10 insertions(+)
>
On Wed, Oct 03, 2018 at 11:18:26AM +0200, Daniel Vetter wrote:
> It's for legacy drivers only (atomic ones should use
> drm_atomic_helper_check_plane_state() instead), and there's no users
> left except the one in the primary plane helpers.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Ville
Shuts up warning noise.
Signed-off-by: Daniel Vetter
---
include/drm/drm_mode_config.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 928e4172a0bb..d643d268693e 100644
--- a/include/drm/drm_mode_config.h
+++
From: Thomas Hellstrom
Use the correct helper and also return early on helper
success rather than on helper failure.
Also explicitly return 0 in the case of no fb.
v2: Check for !fb after updating state->visible (Ville).
Reviewed-by: Ville Syrjälä
Signed-off-by: Thomas Hellstrom (v1)
It's for legacy drivers only (atomic ones should use
drm_atomic_helper_check_plane_state() instead), and there's no users
left except the one in the primary plane helpers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 49 +++---
Motivated by review comments from Ville
Cc: Ville Syrjälä
Cc: Sean Paul
Signed-off-by: Daniel Vetter
---
Documentation/gpu/todo.rst | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 77c2b3c25565..5c9d86c962af 100644
Well except the destroy helper, which isn't really a primary helper
but generally useful, if mislabelled.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_plane_helper.c | 85 --
include/drm/drm_plane_helper.h | 10
2 files
Didn't get updated in a rework of the original patch.
Fixes: 059b5eb5d955 ("drm: move native byte order quirk to new
drm_driver_legacy_fb_format function")
Cc: Gerd Hoffmann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fourcc.c | 6 +++---
1 file changed, 3 insertions(+), 3
With armada the last bigger driver that realistically needed these to
convert from legacy kms to atomic is converted. These helpers have
been broken more often than not the past 2 years, and as this little
patch series shows, tricked a bunch of people into using the wrong
helpers for their
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
v2: Rebase.
Reviewed-by: Ville Syrjälä
Acked-by: Eric
drm_plane_helper_disable is a non-atomic drivers only function, and
will blow up (since no one passes the locking context it needs).
Atomic drivers which want to quiescent their hw on unload should
use drm_atomic_helper_shutdown() instead.
The sti cleanup code seems supremely confused:
- In the
These do absolutely nothing for atomic drivers.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_crtc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index
That's purely for the uapi layer to implement the ALLOW_MODESET flag.
Drivers should instead look at the state, e.g. through
drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also remove
the confusing comment, since checking allow_modeset is at best a micro
optimization.
Signed-off-by:
Hi all,
Resend mostly unchanged, except a few patches tacked on a the end. Main
goal here is to get intel-gfx-ci to approve this, since last time around
patchwork didn't parse what I've done :-)
Still a bunch of unreviewed stuff, so feedback highly welcome.
Cheers, Daniel
Daniel Vetter (20):
Motivated by vmwgfx digging around in core uapi bits it shouldn't dig
around in.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/drm/drm_atomic.h
We already have a separate overview doc for this, makes sense to
untangle it from the overall atomic helpers.
v2: Rebase
v3: Rebase more.
Acked-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
Documentation/gpu/drm-kms-helpers.rst | 19 +-
drivers/gpu/drm/Makefile |
It's the default. The exported version was kinda a transition state,
before we made this the default.
To stop new atomic drivers from using it (instead of just relying on
the default) let's unexport it.
v2: rename the default implementation to a more fitting name and add a
comment (Laurent)
These do absolutely nothing for atomic drivers.
Reviewed-by: Ville Syrjälä
Signed-off-by: Daniel Vetter
Cc: Boris Brezillon
Cc: Nicolas Ferre
Cc: Alexandre Belloni
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 --
1 file changed, 2
The idea behind allowing drivers to override legacy ioctls (instead of
using the generic implementations unconditionally) is to handle bugs
in old driver-specific userspace. Like e.g. vmw_kms_set_config does,
to work around some vmwgfx userspace not clearing its ioctl structs
properly.
But you
The core _does_ the call to drm_atomic_commit for you. That's pretty
much the entire point of having the fancy new atomic_set/get_prop
callbacks.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Sinclair Yeh
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 --
1 file
For atomic driver this is the default, no need to reimplement it. We
still need to keep the copypasta for not-atomic drivers though, since
no one polished the legacy crtc helpers as much as the atomic ones.
v2: amdgpu uses ->best_encoder internally, give it a local copy. It
might be a good idea
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
I don't think this is a bug. The problem is, prior to that patch, the display
component was requesting minimum clocks that were 10x too low. This saved
power, but led to display
Good catch.
Reviewed-by: Sinclair Yeh
On Thu, Oct 04, 2018 at 06:49:53PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The return statement is redundant as there is a return statement
> immediately before it so we have dead code that can be removed.
> Also remove the unused declaration
On Tue, Oct 02, 2018 at 04:36:31PM +, Thomas Hellstrom wrote:
> On 10/02/2018 05:15 PM, Ville Syrjälä wrote:
> > On Tue, Oct 02, 2018 at 03:35:12PM +0200, Daniel Vetter wrote:
> >> The core _does_ the call to drm_atomic_commit for you. That's pretty
> >> much the entire point of having the
On Wed, Oct 03, 2018 at 04:24:58PM +0200, Giulio Benetti wrote:
> If using tcon with VGA,
We don't have support for VGA at the moment. Or are you talking about
using a VGA bridge?
> tcon->panel will be null(0), this will cause segmentation fault when
> trying to dereference
Hi,
On Wed, Oct 03, 2018 at 04:24:57PM +0200, Giulio Benetti wrote:
> At the moment, the check of tcon->panel to be valid is wrong. IS_ERR()
> has been used, but that macro doesn't check if tcon->panel pointer is
> null or not, but check if tcon->panel is between -1 and -4095(MAX_ERRNO).
>
>
Hi Rob
Thanks for the review. Will copy the DT list in the next patchset.
Some comments inline.
Thanks
Abhinav
On 2018-10-04 12:01, Rob Herring wrote:
If you want DT bindings reviewed, you have to cc the DT list. (Or wait
for Sean Paul to ping me on IRC)
On Fri, Sep 28, 2018 at 7:39 PM
On Thu, Oct 04, 2018 at 05:04:21PM +0200, Arnd Bergmann wrote:
> On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes wrote:
> > Den 04.10.2018 09.48, skrev Daniel Vetter:
> > > On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
> > >> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
> > >>> On
On Thu, Oct 04, 2018 at 02:33:24PM -0400, Sean Paul wrote:
> On Tue, Oct 02, 2018 at 03:35:10PM +0200, Daniel Vetter wrote:
> > It's the default. The exported version was kinda a transition state,
> > before we made this the default.
> >
> > To stop new atomic drivers from using it (instead of
If you want DT bindings reviewed, you have to cc the DT list. (Or wait
for Sean Paul to ping me on IRC)
On Fri, Sep 28, 2018 at 7:39 PM Abhinav Kumar wrote:
>
> Add the device tree bindings for Truly NT35597 panel driver. This panel
> driver supports both single DSI and dual DSI.
By driver, you
On Tue, Oct 02, 2018 at 03:35:10PM +0200, Daniel Vetter wrote:
> It's the default. The exported version was kinda a transition state,
> before we made this the default.
>
> To stop new atomic drivers from using it (instead of just relying on
> the default) let's unexport it.
>
> Signed-off-by:
On Thu, Oct 4, 2018 at 5:05 PM Neil Armstrong wrote:
>
> On 04/10/2018 12:09, Daniel Vetter wrote:
> > On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
> >> The mode_config max_width/max_height determines the maximum framebuffer
> >> size the pixel reader can handle. But the values
https://bugzilla.kernel.org/show_bug.cgi?id=201275
quirin.blae...@freenet.de changed:
What|Removed |Added
Summary|Power consumption RX460 |Power consumption RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201275
--- Comment #8 from quirin.blae...@freenet.de ---
4.18.12
Bug still present, removing 93b100ddda3be284be160e9ccba28c7f8f21ab73 solves
this problem for now.
--
You are receiving this mail because:
You are watching the assignee of the bug.
From: Colin Ian King
The return statement is redundant as there is a return statement
immediately before it so we have dead code that can be removed.
Also remove the unused declaration of ret.
Detected by CoverityScan, CID#1473793 ("Structurally dead code")
Signed-off-by: Colin Ian King
---
https://bugs.freedesktop.org/show_bug.cgi?id=106374
--- Comment #4 from Hugo Sánchez ---
I am having the same issue. That is a big problem cause GPU cannot reach its
max power. A RX Vega 64 for example can consume around 300w with OC and the
220w is causing frame drops in the case of games.
--
Am 04.10.2018 um 18:32 schrieb Nayan Deshmukh:
Hi Christian,
On Thu, Sep 27, 2018 at 12:55 AM Nayan Deshmukh
wrote:
Hi Christian,
On Wed, Sep 26, 2018, 10:13 AM Christian König
wrote:
Am 26.09.2018 um 09:39 schrieb Lucas Stach:
Hi Nayan,
Am Mittwoch, den 26.09.2018, 02:09 +0900 schrieb
On Wed, Oct 03, 2018 at 06:12:42PM +0200, Daniel Vetter wrote:
> On Wed, Oct 03, 2018 at 05:50:17PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When we decide that a plane is attached to the wrong pipe we try
> > to turn off said plane. However we are passing around the crtc we
>
Hi Daniel,
On Wednesday, 3 October 2018 12:08:38 EEST Daniel Vetter wrote:
> On Tue, Oct 02, 2018 at 04:53:12PM +0300, Laurent Pinchart wrote:
> > On Tuesday, 2 October 2018 16:35:10 EEST Daniel Vetter wrote:
> > > It's the default. The exported version was kinda a transition state,
> > > before
On Thu, Oct 04, 2018 at 02:55:42PM +1000, Dave Airlie wrote:
> Hi Greg,
>
> Nothing too much happening at this point,
>
> 3 i915 fixes:
> compressed error handling zlib fix
> compiler warning cleanup
> and a minor code cleanup
>
> 2 tda9950:
> Two fixes for the HDMI CEC
>
> 1 exynos:
> A fix
Hi, Emil,
On 10/04/2018 04:12 PM, Emil Velikov wrote:
> On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom wrote:
>> Hi, Emil,
>>
>> On 09/05/2018 03:53 PM, Emil Velikov wrote:
>>> On 5 September 2018 at 14:20, Thomas Hellstrom
>>> wrote:
>>>
> In that case, please give me 24h to do a libdrm
https://bugs.freedesktop.org/show_bug.cgi?id=103791
Michel Dänzer changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |xorg-driver-...@lists.x.org
https://bugs.freedesktop.org/show_bug.cgi?id=105744
Michel Dänzer changed:
What|Removed |Added
Product|xorg|DRI
Component|Driver/AMDgpu
https://bugs.freedesktop.org/show_bug.cgi?id=104531
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
Hi Christian,
On Thu, Sep 27, 2018 at 12:55 AM Nayan Deshmukh
wrote:
>
> Hi Christian,
>
>
> On Wed, Sep 26, 2018, 10:13 AM Christian König
> wrote:
>>
>> Am 26.09.2018 um 09:39 schrieb Lucas Stach:
>> > Hi Nayan,
>> >
>> > Am Mittwoch, den 26.09.2018, 02:09 +0900 schrieb Nayan Deshmukh:
>> >>
https://bugs.freedesktop.org/show_bug.cgi?id=91831
Michel Dänzer changed:
What|Removed |Added
QA Contact|xorg-t...@lists.x.org |
https://bugs.freedesktop.org/show_bug.cgi?id=97810
Michel Dänzer changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
Hi Dave,
Just two small fixes for 4.19:
- Fix an ordering issue in DC with respect to atomic flips that could result
in a crash
- Fix incorrect use of process->mm in KFD
The following changes since commit d8938c981f58ee344687b7910a611ac345960045:
Merge branch 'drm-tda9950-fixes' of
This release adds a fallback for realpath() which was blocked by the
web-browser sand-boxing. While the browsers are fixed-up they seem to have
little incentive to roll bugfix releases :-\
-Emil
Ayan Kumar Halder (1):
libdrm: headers: Sync with drm-next
Christian König (4):
On 04/10/2018 12:09, Daniel Vetter wrote:
> On Thu, Oct 04, 2018 at 10:42:43AM +0200, Neil Armstrong wrote:
>> The mode_config max_width/max_height determines the maximum framebuffer
>> size the pixel reader can handle. But the values were set thinking they
>> were determining the maximum screen
On Thu, Oct 4, 2018 at 4:43 PM Noralf Trønnes wrote:
> Den 04.10.2018 09.48, skrev Daniel Vetter:
> > On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
> >> On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
> >>> On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
>
>
Hi,
On Thu, Oct 04, 2018 at 03:43:11PM +0200, Lucas Stach wrote:
> Am Donnerstag, den 04.10.2018, 14:20 +0100 schrieb Emil Velikov:
> > [adding etnaviv@ for bigger exposure]
> >
> > Hi Guido,
> >
> > > On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote:
> > >
> > > This makes it simple to test
On Thu, Oct 04, 2018 at 03:11:43PM +0530, Sharat Masetty wrote:
> Implement routines to estimate GPU busy time and fetching the
> current frequency for the polling interval. This is required by
> the devfreq framework which recommends a frequency change if needed.
> The driver code then tries to
Den 04.10.2018 09.48, skrev Daniel Vetter:
On Wed, Oct 3, 2018 at 9:51 PM Arnd Bergmann wrote:
On Wed, Oct 3, 2018 at 6:13 PM Daniel Vetter wrote:
On Wed, Oct 03, 2018 at 05:49:32PM +0200, Noralf Trønnes wrote:
Den 02.10.2018 22.58, skrev Arnd Bergmann:
The variable is now referenced
On Sun, 30 Sep 2018 at 18:31, Thomas Hellstrom wrote:
>
> Hi, Emil,
>
> On 09/05/2018 03:53 PM, Emil Velikov wrote:
> > On 5 September 2018 at 14:20, Thomas Hellstrom
> > wrote:
> >
> >>> In that case, please give me 24h to do a libdrm release before pushing.
> >>> I had to push some
On Mon, 1 Oct 2018 at 16:09, Ayan Kumar Halder wrote:
>
> Generated using make headers_install from the drm-next
> tree - git://anongit.freedesktop.org/drm/drm
> branch - drm-next
> commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f
>
> The changes were as follows :-
>
> core: (drm.h,
On Sat, 22 Sep 2018 at 14:28, Ezequiel Garcia wrote:
>
> This is the DRM driver for all Allwinner (sunxi) platforms.
>
> Signed-off-by: Ezequiel Garcia
Reviewed-by: Emil Velikov
Will push this in a moment.
Thanks
Emil
___
dri-devel mailing list
On Thu, 20 Sep 2018 at 13:25, Eric Engestrom wrote:
>
> On Wednesday, 2018-09-19 23:05:48 -0700, Lucas De Marchi wrote:
> > Signed-off-by: Lucas De Marchi
>
> Reviewed-by: Eric Engestrom
>
> But it'd be good to have a confirmation from Rob that it actually works:
> Cc: Rob Herring
>
Yes it
The GPU hardware fences and the job out-fences are on different timelines
so it's wrong to compare them. Fix this by only looking at the out-fence.
Fixes: 2c83a726d6fb (drm/etnaviv: bring back progress check in job
timeout handler)
Signed-off-by: Lucas Stach
---
Am Donnerstag, den 04.10.2018, 14:20 +0100 schrieb Emil Velikov:
> [adding etnaviv@ for bigger exposure]
>
> Hi Guido,
>
> > On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote:
> >
> > This makes it simple to test if all cache types are mappable.
> >
> > > > Signed-off-by: Guido Günther
> >
Hi Dave,
Here comes -fixes for drm-next.
One compiler warning fix and adding back a removed max stride
check, nothing end user visible.
Regards, Joonas
PS. Travelling next week, so I'll skip PR unless there's
something big.
---
drm-intel-next-fixes-2018-10-04:
Compiler warning fix and
On Wed, 5 Sep 2018 at 19:01, Stefan Agner wrote:
>
> Use libutil to lookup connector type names and state. This also
> makes sure that the latest connector type addition "DPI" gets
> printed correctly.
>
> Signed-off-by: Stefan Agner
For the series:
Reviewed-by: Emil Velikov
Will do some
[adding etnaviv@ for bigger exposure]
Hi Guido,
On Fri, 14 Sep 2018 at 13:06, Guido Günther wrote:
>
> This makes it simple to test if all cache types are mappable.
>
> Signed-off-by: Guido Günther
> ---
> Prompted by
>
>
1 - 100 of 145 matches
Mail list logo
