On Wed, Mar 21, 2018 at 04:45:53PM +0100, Greg Kroah-Hartman wrote:
> The memmap options sent to the udl framebuffer driver were not being
> checked for all sets of possible crazy values. Fix this up by properly
> bounding the allowed values.
>
> Reported-by: Eyal Itkin
> Cc: stable
> Signed-of
On Wed, Mar 21, 2018 at 10:34:05AM +0100, Christian König wrote:
> Am 21.03.2018 um 09:18 schrieb Daniel Vetter:
> > [SNIP]
> > They're both in i915_gem_userptr.c, somewhat interleaved. Would be
> > interesting if you could show what you think is going wrong in there
> > compared to amdgpu_mn.c.
>
On Wed, Mar 21, 2018 at 12:54:20PM +0100, Christian König wrote:
> Am 21.03.2018 um 09:28 schrieb Daniel Vetter:
> > On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote:
> > > Am 20.03.2018 um 15:08 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > For the in-driver reservation path (CS) ha
On 03/21/2018 10:12 PM, Ville Syrjala wrote:
From: Ville Syrjälä
Apparently xf86-video-vmware leaves the mode->type uninitialized
when feeding the mode to the kernel. Thus we have no choice but
to accept the garbage in. We'll just ignore any of the bits we
don't want. The mode type is just a hi
It published the gem object to userspace, by that point other threads
can guess the id and start using it. And gem IDs are _very_ easy to
guess (it's just an idr).
Since gem objects is the only thing we allow drivers to create
themselves (all the kms/prime/syncobj stuff is handled by the core) no
On Thu, Mar 22, 2018 at 07:59:59AM +0100, Daniel Vetter wrote:
> Does anyone working on overflow-proof integers? That would make a lot of
> this code so much simpler if we could just ask the compiler to carry the
> oferflow bit around for a given expression and then check that and bail
> with -EINV
Hi,
On Wed, 2018-03-21 at 16:47 +, Daniel Stone wrote:
> Hi Paul,
>
> On 21 March 2018 at 15:29, Paul Kocialkowski
> wrote:
> > +/*
> > + * Allwinner "MB32" tiled format
> > + *
> > + * This is the primary layout coming out of the VPU, where pixels
> > are tiled
> > + * 32x32.
> > + */
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=105684
Bug ID: 105684
Summary: Loading amdgpu hits general protection fault:
[#1] SMP NOPTI
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #1 from jian-h...@endlessm.com ---
Created attachment 138270
--> https://bugs.freedesktop.org/attachment.cgi?id=138270&action=edit
general protection fault: [#1] SMP NOPTI
--
You are receiving this mail because:
You are the a
Hi Chen-Yu,
On Thu, 2018-03-22 at 14:47 +0800, Chen-Yu Tsai wrote:
> On Wed, Mar 21, 2018 at 11:28 PM, Paul Kocialkowski
> wrote:
> > It turns out that the frontend is not capable of preserving the
> > alpha
> > component (that is always set to 0xff), so only support XRGB
> > instead.
> >
>
> > +int dma_configure(struct device *dev)
> > +{
> > + if (dev->bus->dma_configure)
> > + return dev->bus->dma_configure(dev);
>
> What if dma_common_configure() is called in case "bus->dma_configure" is not
> defined?
Then we'd still have a dependency of common code on OF and ACPI.
> +static int amba_dma_configure(struct device *dev)
> +{
> + return dma_common_configure(dev);
> +}
So it turns out we only end with two callers of dma_common_configure
after this series. Based ont hat I'm tempted with the suggestion
from Robin to just have amba call platform_dma_configure,
From: Ville Syrjälä
Use drm_mode_equal_no_clocks_no_stereo() in
drm_match_hdmi_mode_clock_tolerance() for consistency as we
also use it in drm_match_hdmi_mode() and the cea mode matching
functions.
This doesn't actually change anything since the input mode
comes from detailed timings and we matc
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, then getblob called
with the blob id of a user-mode, should clear the aspect-ratio
information in the blob data.
Currently for a given blob id, there is no way to determine if the
blob stores user-mode or not. This can only be
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.
This patch add
From: Ville Syrjälä
If the user mode would specify an aspect ratio other than 4:3 or 16:9
we now silently ignore it. Maybe a better apporoach is to return an
error? Let's try that.
Also we must be careful that we don't try to send illegal picture
aspect in the infoframe as it's only capable of s
From: Ville Syrjälä
commit 6dffd431e229 ("drm: Add aspect ratio parsing in DRM layer")
cause us to not send out any VICs in the AVI infoframes. That commit
was since reverted, but if and when we add aspect ratio handing back
we need to be more careful.
Let's handle this by considering the aspect
From: Ankit Nautiyal
This patch series is a re-attempt to enable aspect ratio support in
DRM layer. Currently the aspect ratio information gets lost in translation
during a user->kernel mode or vice versa.
The old patch series (https://pw-emeril.freedesktop.org/series/10850/) had
4 patches, out
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and requests for a
modeset with mode having aspect ratio bits set, then the given
user-mode must be rejected. Secondly, while preparing a user-mode from
kernel mode, the aspect-ratio info must not be given, if aspect-ratio
is n
From: Ville Syrjälä
Make mode matching less confusing by allowing the caller to specify
which parts of the modes should match via some flags.
Signed-off-by: Ville Syrjälä
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/drm_modes.c | 134 ++--
include/d
From: Ankit Nautiyal
To enable aspect-ratio support in DRM, blindly exposing the aspect
ratio information along with mode, can break things in existing
user-spaces which have no intention or support to use this aspect
ratio information.
To avoid this, a new drm client cap is required to enable a
From: Ankit Nautiyal
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regadless of
whether user space requested this information or not.
This patch prunes the modes with aspect-ratio information, from a
connector's modeli
From: Ville Syrjälä
AVI infoframe can only carry none, 4:3, or 16:9 picture aspect
ratios. Return an error if the user asked for something different.
Cc: Shashank Sharma
Cc: "Lin, Jia"
Cc: Akashdeep Sharma
Cc: Jim Bride
Cc: Jose Abreu
Cc: Daniel Vetter
Cc: Emil Velikov
Cc: Thierry Reding
From: "Sharma, Shashank"
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch:
- Adds new DRM flags for to represent these new aspect ratios.
- Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.
This patch was once
> --- a/drivers/dma/qcom/hidma_mgmt.c
> +++ b/drivers/dma/qcom/hidma_mgmt.c
> @@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct
> device_node *np)
> }
> of_node_get(child);
> new_pdev->dev.of_node = child;
> - of_dma_
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #2 from jian-h...@endlessm.com ---
Sorry for the messages before, the editing error.
I have an AMD Ryzen 5 2400G with Radeon Vega Graphics computer. When I loading
amdgpu module manually, it will hit the panic.
<6>[ 128.532951] [d
On Thu, Mar 22, 2018 at 4:23 PM, Paul Kocialkowski
wrote:
> Hi Chen-Yu,
>
> On Thu, 2018-03-22 at 14:47 +0800, Chen-Yu Tsai wrote:
>> On Wed, Mar 21, 2018 at 11:28 PM, Paul Kocialkowski
>> wrote:
>> > It turns out that the frontend is not capable of preserving the
>> > alpha
>> > component (that
Hi,
On Thu, 2018-03-22 at 16:37 +0800, Chen-Yu Tsai wrote:
> On Thu, Mar 22, 2018 at 4:23 PM, Paul Kocialkowski
> wrote:
> > Hi Chen-Yu,
> >
> > On Thu, 2018-03-22 at 14:47 +0800, Chen-Yu Tsai wrote:
> > > On Wed, Mar 21, 2018 at 11:28 PM, Paul Kocialkowski
> > > wrote:
> > > > It turns out tha
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #3 from jian-h...@endlessm.com ---
The kernel version I tested is 4.16-rc6.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@li
Hi Alex,
On Tue, Feb 20, 2018 at 10:18 PM, Alex Deucher wrote:
>> It seems that we are not alone seeing amdgpu-induced stability
>> problems on multiple Raven Ridge platforms.
>> https://www.phoronix.com/scan.php?page=news_item&px=AMD-Raven-Ridge-Mobo-Linux
>>
>> AMD, what can we do to help?
>
>
From: Ville Syrjälä
Document the fact that the use of a framebuffer with alpha implies
pre-multipled alpha blending, and that the crtc background color
is assumed to be black.
Not sure drm_fourcc.h is the best place for the uapi docs, but
couldn't think of anything better really.
Cc: Mario Klei
Hi Dave,
please consider merging these fixes for an array underflow error in ipu-
prg and an issue where the vblank completion event would be signalled to
userspace too early due to a race condition.
regards
Philipp
The following changes since commit 0c8efd610b58cb23cefdfa12015799079aef94ae:
https://bugs.freedesktop.org/show_bug.cgi?id=105663
Marta Löfstedt changed:
What|Removed |Added
Component|IGT |DRM/Intel
QA Contact|
On 03/22/2018 03:14 AM, Boris Ostrovsky wrote:
On 03/21/2018 10:58 AM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Add support for Xen para-virtualized frontend display driver.
Accompanying backend [1] is implemented as a user-space application
and its helper library [2], ca
Am 22.03.2018 um 08:14 schrieb Daniel Vetter:
On Wed, Mar 21, 2018 at 10:34:05AM +0100, Christian König wrote:
Am 21.03.2018 um 09:18 schrieb Daniel Vetter:
[SNIP]
For correct operation you always need to implement invalidate_range_end as
well and add some lock/completion work Otherwise get_us
On Thu, Mar 22, 2018 at 11:14:17AM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Document the fact that the use of a framebuffer with alpha implies
> pre-multipled alpha blending, and that the crtc background color
> is assumed to be black.
>
> Not sure drm_fourcc.h is the best place for
On Thu, Mar 22, 2018 at 9:03 AM, Greg Kroah-Hartman
wrote:
> On Thu, Mar 22, 2018 at 07:59:59AM +0100, Daniel Vetter wrote:
>> Does anyone working on overflow-proof integers? That would make a lot of
>> this code so much simpler if we could just ask the compiler to carry the
>> oferflow bit around
Am 22.03.2018 um 08:18 schrieb Daniel Vetter:
On Wed, Mar 21, 2018 at 12:54:20PM +0100, Christian König wrote:
Am 21.03.2018 um 09:28 schrieb Daniel Vetter:
On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote:
Am 20.03.2018 um 15:08 schrieb Daniel Vetter:
[SNIP]
For the in-driver
The utility uses kmap_atomic() instead of vmapping the whole buffer
object. As a result there will be more book-keeping but on some
architectures this will help avoid exhausting vmalloc space and also
avoid expensive TLB flushes.
The blit utility also adds a provision to compute a bounding box of
fbdev framebuffers were previously pinned to be able to keep them mapped
across updates.
This commit introduces a mechanism that instead revalidates the map on
each update, keeping the map cached across updates. The cached map is torn
down if the underlying pages change. Typically on buffer object
The start / stop and preempt commands don't honor the context argument
but rather acts on all available contexts.
Also add detection for context 1 availability.
Note that currently there's no driver interface for submitting buffers
using the high-priority command queue (context 1).
Testing done:
We were relying on the pinned screen object backup buffer to be destroyed
when not used. But if we hold a copy of the atomic state, like when
hibernating, the backup buffer might not be destroyed since it's
refcounted by the atomic state. This causes us to hibernate with a
buffer pinned in VRAM.
F
It was used to early block fbdev dirty processing. Replace it with an
unprotected check of the par->dirty.active field. While this might
race with the vmw_fb_off() function, we do a protected check later so
the race will at worst lead to grabbing and releasing a couple of locks.
Signed-off-by: Tho
This blit was previously performed using two large vmaps, one of which
was teared down and remapped on each blit. Use the more resource-
conserving TTM cpu blit instead.
The blit is used in boundary-box computing mode which makes it possible
to minimize the bounding box used in host operations.
S
Make it possible to hibernate also with masters that don't switch VT at
hibernation time. We save and restore modesetting state unless fbdev is
active and enabled at hibernation time.
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 75
From: Himanshu Jha
Use kasprintf instead of combination of kmalloc and sprintf. Also,
remove the local variables used for storing the string length as they
are not required now.
Signed-off-by: Himanshu Jha
Reviewed-by: Sinclair Yeh
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/v
/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -43,10 +43,10 @@
#include
#define VMWGFX_DRIVER_NAME "vmwgfx"
-#define VMWGFX_DRIVER_DATE "20170612"
+#define VMWGFX_DRIVER_DATE "20180322"
#define VMWGFX_DRIVER_MAJOR 2
#define VMWGFX_DRIVER_MINOR 14
-#def
For legacy surfaces, they were previously registered as device resources
when the driver resources were created. Since they are evictable we instead
register them as device resources once they are created on the device,
just like for guest-backed surfaces. This has implications during
hibernation w
From: Arnd Bergmann
DRM_VMW_EVENT_FENCE_SIGNALED (struct drm_vmw_event_fence) and
DRM_EVENT_VBLANK (struct drm_event_vblank) pass timestamps in 32-bit
seconds/microseconds format.
As of commit c61eef726a78 ("drm: add support for monotonic vblank
timestamps"), other DRM drivers use monotonic time
Hi Dave,
again a bit late, as my hope was to see some more patches landing, but
that didn't work out. All the stuff in this pull request has been in
linux-next for at least 2 weeks. Diff is a bit bigger than usual, but
it's mostly our HW headers gaining some weight.
Changes this time mostly come
From: Russell King
The old way did clamp the jiffy conversion and thus caused the timeouts
to become negative after some time. Also it didn't work with userspace
which actually fills the upper 32bits of the 64bit timestamp value.
clock_gettime() is 32-bit on 32-bit architectures. Using 64-bit ti
All the DRM GEM dma-buf import/export operations are done through the
virtual DRM master device. As this isn't instanciated from DT anymore
we need to make sure the DMA ops are set up correctly.
Signed-off-by: Lucas Stach
---
v2: Create device with correct DMA mask/ops, instead of fixing up in
pr
This was useful on MMUv1 GPUs, which don't generate proper faults,
when the GPU write caches weren't fully understood and not properly
handled by the kernel driver. As this has been fixed for quite some
time, the cycling though the MMU address space needlessly spreads
out the MMU mappings.
Signed-
Hi all,
Random drive-by crusade against dev->struct_mutex usage. The only two
leftover drivers still relying on gem_free_object and the magic lifetime
rule that hodling dev->struct_mutex will prevent gem object destruction
are msm and gma500. Both actually need this, and don't look like they can
b
tinydrm doesn't use dev->struct_mutex and therefore has no need to use
gem_free_object.
Signed-off-by: Daniel Vetter
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 2 +-
include/drm/tinydrm/tinydrm.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
https://bugzilla.kernel.org/show_bug.cgi?id=198907
--- Comment #4 from Andrew (aun.soko...@gmail.com) ---
(In reply to Jani Nikula from comment #2)
> Please attach dmesg with drm.debug=14 added.
done
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=198907
--- Comment #3 from Andrew (aun.soko...@gmail.com) ---
Created attachment 274865
--> https://bugzilla.kernel.org/attachment.cgi?id=274865&action=edit
dmesg with drm.debug=14 added
--
You are receiving this mail because:
You are watching the as
The utility uses kmap_atomic() instead of vmapping the whole buffer
object. As a result there will be more book-keeping but on some
architectures this will help avoid exhausting vmalloc space and also
avoid expensive TLB flushes.
The blit utility also adds a provision to compute a bounding box of
Hi, Dave,
Two vmwgfx fixes for 4.16. Both cc'd stable.
The following changes since commit 93dfdf9fde9f20f1c46738bf184adeebc7d7d66e:
Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux
into drm-fixes (2018-03-01 14:03:14 +1000)
are available in the Git repository at:
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #44 from taij...@posteo.de ---
Created attachment 138278
--> https://bugs.freedesktop.org/attachment.cgi?id=138278&action=edit
dmesg with 4.17-wip-b6356df3eb9a with aptx.patch
OK, the patch works, dmesg reports that ATPX is force-a
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #45 from taij...@posteo.de ---
Created attachment 138279
--> https://bugs.freedesktop.org/attachment.cgi?id=138279&action=edit
dmesg with 4.17-wip-b6356df3eb9a with aptx.patch and backlight.patch
Here is the dmesg output with both
Hi, Dave.
A relative large set of various improvements for vmwgfx. Some of them
have been around for a while, some are relatively new, but functionality
should have been tested in our standalone repo.
There was a kbuild test robot compilation failure on Debian for
"drm/vmwgfx: Add a cpu blit util
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #72 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
With iommu=off I can still see the error after around 3 attempts
With iommu=off amdgpu.cg_mask=0 amdgpu.pg_mask=0 I could not see the stall
after 30 boots
With amdgpu.cg_mask=0
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #73 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Created attachment 274867
--> https://bugzilla.kernel.org/attachment.cgi?id=274867&action=edit
Exclude HIQ patch
So if IOMMU disabling does makes a difference can you please
On Wed, 21 Mar 2018 15:09:32 -0700
Joe Perches wrote:
> diff --git a/kernel/trace/trace_printk.c b/kernel/trace/trace_printk.c
> index ad1d6164e946..50f44b7b2b32 100644
> --- a/kernel/trace/trace_printk.c
> +++ b/kernel/trace/trace_printk.c
> @@ -196,7 +196,7 @@ struct notifier_block module_trace
Hi,
Changes since v1:
- rebased on drm-next
- comments for the v1 (https://patchwork.kernel.org/patch/8358741/) addressed
- u32 -> dma_addr_t when applicable
- additional wmb()/rmb() added to make sure we have correct behavior
Errata i878 says that MPU should not be used to access RAM and DMM a
From: Tomi Valkeinen
Define unique compatible string for the DMM in DRA7xx family.
The new compatible can be used to apply DRA7xx specific workarounds for
ERRATAs, like i878 (MPU Lockup with concurrent DMM and EMIF accesses)
Signed-off-by: Tomi Valkeinen
---
Documentation/devicetree/bindings/
From: Tomi Valkeinen
Errata i878 says that MPU should not be used to access RAM and DMM at
the same time. As it's not possible to prevent MPU accessing RAM, we
need to access DMM via a proxy.
This patch changes DMM driver to access DMM registers via sDMA. Instead
of doing a normal readl/writel c
Den 22.03.2018 11.51, skrev Daniel Vetter:
tinydrm doesn't use dev->struct_mutex and therefore has no need to use
gem_free_object.
Signed-off-by: Daniel Vetter
Cc: "Noralf Trønnes"
---
Acked-by: Noralf Trønnes
drivers/gpu/drm/tinydrm/core/tinydrm-core.c | 2 +-
include/drm/tinydrm/tin
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #74 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Hi Andrey
They patch did not do the trick :(.
Shall I try also with the patch and amdgpu.cg_mask=0 amdgpu.pg_mask=0
--
You are receiving this mail because:
You are watching t
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #75 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to Ricardo Ribalda from comment #74)
> Hi Andrey
>
> They patch did not do the trick :(.
>
> Shall I try also with the patch and amdgpu.cg_mask=0 amdgpu.pg_mask=0
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #22 from Jakob Sinclair ---
I have the exact same issue with this game.
Distribution: Solus 3.999
Kernel driver: amdgpu
glxinfo | grep OpenGL
OpenGL vendor string: X.Org
OpenGL renderer string: AMD Radeon HD 7900 Series (TAHI
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #4 from Harry Wentland ---
Can you attach your complete dmesg log?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.free
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #76 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
I was testing with GALLIUM_DDEBUG=flush
When I removed it:
amdgpu.cg_mask=0 amdgpu.pg_mask=0 : Stalls
iommu=off amdgpu.cg_mask=0 amdgpu.pg_mask=0 : Also stalls
:(
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #46 from Harry Wentland ---
The backlight patch has been stuck in our submission queue for a while but it's
in our internal repo. It should be part of the next set of DC patches, although
I don't think it'll make the 4.17 kernel, unl
On Tue, Mar 20, 2018 at 09:37:49AM -0400, Haneen Mohammed wrote:
> This patch remove the compatibility aliases
> drm_property_{reference/unreference}_blob of
> drm_property_blob_{get/put} since all callers have been converted to the
> prefered _{get/put}.
>
> Remove the helpers from the semantic p
https://bugs.freedesktop.org/show_bug.cgi?id=105651
--- Comment #1 from Harry Wentland ---
amdgpu doesn't currently have support for tiled displays. It's expected with
tiled displays that you see them as you describe.
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Frank,
On Fri, Mar 16, 2018 at 2:39 AM, wrote:
> On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann [mailto:a...@arndb.de]
> wrote:
>>
>> The *.dtb and *.dtb.S files get removed by 'make' during the build
>> process,
>> and later seem to be missed during the 'modpost' stage:
>>
>> rm driver
On Tue, Mar 20, 2018 at 10:11:44AM +0100, Marcel Ziswiler wrote:
> From: Stefan Agner
>
> Use tegra124_(primary|overlay)_formats for Tegra124.
>
> Fixes: 511c7023cf23 ("drm/tegra: dc: Support more formats")
>
> Signed-off-by: Stefan Agner
> Acked-by: Marcel Ziswiler
>
> ---
>
> Changes in v
Hi Dave,
One GVT regression fix and a fix for race condition declaring GPU wedged,
found in CI. The rest are smaller fixes.
Expect next week's pull bit earlier in prep for Easter holidays.
Regards, Joonas
The following changes since commit 963976cfe9c54d4d9e725e61c90c47a4af6b5ea2:
Merge tag
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #77 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to Ricardo Ribalda from comment #76)
> I was testing with GALLIUM_DDEBUG=flush
>
> When I removed it:
>
>
> amdgpu.cg_mask=0 amdgpu.pg_mask=0 : Stalls
>
> iommu=o
Hi Geert,
On Thursday, 22 March 2018 16:26:22 EET Geert Uytterhoeven wrote:
> On Fri, Mar 16, 2018 at 2:39 AM, wrote:
> > On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann wrote:
> >> The *.dtb and *.dtb.S files get removed by 'make' during the build
> >> process, and later seem to be missed du
Thanks. Will apply the patch to drm-next.
Best Regards
Rex
From: Joe Perches
Sent: Thursday, March 22, 2018 3:02 AM
To: Colin King; Koenig, Christian; Zhou, David(ChunMing); David Airlie; Zhu,
Rex; amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.or
https://bugzilla.kernel.org/show_bug.cgi?id=199157
Harry Wentland (harry.wentl...@amd.com) changed:
What|Removed |Added
CC||harry.wentl...@a
Hi Laurent,
CC Yamada-san
On Thu, Mar 22, 2018 at 3:50 PM, Laurent Pinchart
wrote:
> On Thursday, 22 March 2018 16:26:22 EET Geert Uytterhoeven wrote:
>> On Fri, Mar 16, 2018 at 2:39 AM, wrote:
>> > On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann wrote:
>> >> The *.dtb and *.dtb.S files get
From: Ville Syrjälä
drm_atomic_helper_shutdown() needs to release the reference held by
plane->fb, so we want to use drm_atomic_clean_old_fb() in
drm_atomic_helper_disable_all(). However during suspend/resume, gpu
reset and load detection we should probably leave that stuff alone,
as otherwise we
From: Ville Syrjälä
Keep the primary->crtc in sync with the state->crtc (also with
primary->fb and state->fb) when disabling the crtc (and thus also
the primary) via setcrtc().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
di
From: Ville Syrjälä
I really just wanted to fix i915 to re-enable its planes afer load
detection (a two line patch). This is what I actually ended up with
after I ran into a framebuffer refcount leak with said two line patch.
I've tested this on a few i915 boxes and so far it's looking
good. Eve
From: Ville Syrjälä
Make the code a bit more readable by storing the plane pointer in a
local variable rather than having to do crtc->{primary,cursor} all the
time.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 32 +++-
drivers/gpu/drm/drm_plane.c |
From: Ville Syrjälä
drm_atomic_helper_commit_duplicated_state() should only be called
resume/reset/load_detect paths where plane->old_fb should always be
NULL and plane->fb should be equal to the new_plane_state->fb.
Assert that is indeed the case.
Cc: martin.pe...@free.fr
Cc: ch...@chris-wilson
From: Ville Syrjälä
Add a bit of whitespace here and there to make the code look a bit
more structured.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 4 +++-
drivers/gpu/drm/drm_plane.c | 6 +-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
From: Ville Syrjälä
Instead of assigning the plane->fb pointer and clearing the fb pointer
to hand over the reference, let's just do it by grabbing another
referece for plane->fb and let fb keep its original one.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_plane.c | 3 +--
1 file chan
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i
From: Ville Syrjälä
Stop looking at plane->fb on atomic drivers. Use plane->state->fb
instead.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_crtc.c | 11 +--
drivers/gpu/drm/drm_plane.c | 19 ++-
3 fil
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Cc: Benjamin Gaignard
Cc: Vincent Abriou
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/sti/sti_plane.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/st
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Cc: Rob Clark
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 d
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Cc: Boris Brezillon
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/atme
From: Ville Syrjälä
We want to get rid of plane->fb on atomic drivers. Stop looking at it.
Cc: Shawn Guo
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/zte/zx_vou.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.
From: Ville Syrjälä
Stop playing around with plane->crtc/fb/old_fb with atomic
drivers. Make life a lot simpler when we don't have to do the
magic old_fb vs. fb dance around plane updates. That way we
can't risk plane->fb getting out of sync with plane->state->fb
and we're less likely to leak any
From: Ville Syrjälä
We want to get rid of plane->fb/crtc on atomic drivers. Stop setting
them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/
1 - 100 of 231 matches
Mail list logo
