https://bugs.freedesktop.org/show_bug.cgi?id=106601
--- Comment #14 from Tapani Pälli ---
Is this originally a WebGL test? If so, can you paste the link here please?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
Le 09/10/2018 à 15:51, Christophe Leroy a écrit :
_PAGE_NO_CACHE is a platform specific flag. In addition, this flag
is misleading because one would think it requests a noncached page
whereas a noncached page is _PAGE_NO_CACHE | _PAGE_GUARDED
_PAGE_NO_CACHE alone means write combined noncached
Hi Bjorn,
On Wed, Oct 10, 2018 at 1:02 AM Bjorn Helgaas wrote:
>
> On Mon, Oct 08, 2018 at 05:44:08PM +0800, Bin Meng wrote:
> > On Thu, Oct 4, 2018 at 4:12 AM Bjorn Helgaas wrote:
> > > On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> > > > On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helg
On Wed, Oct 10, 2018 at 11:21 PM Jani Nikula
wrote:
>
> On Wed, 10 Oct 2018, Nick Desaulniers wrote:
> > On Wed, Oct 10, 2018 at 1:30 PM Michal Wajdeczko
> > wrote:
> >>
> >> On Wed, 10 Oct 2018 14:01:40 +0200, Jani Nikula
> >> wrote:
> >>
> >> > On Tue, 09 Oct 2018, Nick Desaulniers wrote:
>
On Wed, 10 Oct 2018 09:35:50 -0400
"Kazlauskas, Nicholas" wrote:
> The patches I've put out target this use case mostly because of the
> benefit for a relatively simple interface. VRR can and has been used in
> more ways that this, however.
>
> An example usecase that differs from this would a
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc pro
On Thu, Oct 11, 2018 at 08:27:43PM -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> This fixes a general protection fault, caused by accessing the contents
> of a flip_done completion object that has already been freed. It occurs
> due to the preemption of a non-blocking commit worker thread W
Pure drive-by while reading code&docs.
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index c09ecaf43825..627210f3ff59 100644
--- a/include/drm/drm_atomic.h
++
Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
> On Wed, 10 Oct 2018 09:35:50 -0400
> "Kazlauskas, Nicholas" wrote:
>
>> The patches I've put out target this use case mostly because of the
>> benefit for a relatively simple interface. VRR can and has been used in
>> more ways that this, however.
>
https://bugs.freedesktop.org/show_bug.cgi?id=108309
Michel Dänzer changed:
What|Removed |Added
Attachment #142001|text/x-log |text/plain
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=108309
Michel Dänzer changed:
What|Removed |Added
Attachment #142000|text/x-log |text/plain
mime type|
Ping! Adding a few people directly and more mailing lists.
Can I get an acked-by/rb for this? It's only a cleanup and not much
functional change.
Regards,
Christian.
Am 04.10.2018 um 15:12 schrieb Christian König:
No need for that any more. Just replace the list when there isn't enough
room
On 2018-10-11 9:44 p.m., Harry Wentland wrote:
> On 2018-10-03 04:25 AM, Mike Lothian wrote:
>>
>> I'm curious to know whether this will/could work over PRIME
>
> I don't see why this shouldn't work over PRIME as long as the
> presenting GPU supports the new variable refresh rate API, but I know
Am 12.10.2018 um 10:26 schrieb Michel Dänzer:
> On 2018-10-11 9:44 p.m., Harry Wentland wrote:
>> On 2018-10-03 04:25 AM, Mike Lothian wrote:
>>> I'm curious to know whether this will/could work over PRIME
>> I don't see why this shouldn't work over PRIME as long as the
>> presenting GPU supports t
Pass the user sent gfp flags to kmalloc() calls. This helps calling the
functions in user desired contexts.
Signed-off-by: Sharat Masetty
---
lib/string_helpers.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/string_helpers.c b/lib/string_helpers.c
index 29c490e..60
The current recovery code gets a pointer to the task struct and does a
few things all within the rcu_read_lock. This puts constraints on the
types of gfp flags that can be used within the rcu lock. This patch
instead gets a reference to the task within the rcu lock and releases
the lock immediately
This patch simply checks first to see if the target can support crash dump
capture before proceeding.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index 19b4af
A few fixes for issues that I have seen in recovery path. The fix in lib/string
is probably not needed anymore with the fixes in drm/msm, but I added it here
nonetheless as it is good to have.
Sharat Masetty (3):
lib/string: Pass the input gfp flags to kmalloc
drm/msm: Check if target supports
On Fri, Oct 12, 2018 at 4:14 PM Jagan Teki wrote:
>
> On Sunday 07 October 2018 03:08 PM, Jernej Skrabec wrote:
> > Video PLL factors can be set in a way that final PLL rate is outside
> > stable range. H6 user manual specifically says that N factor should not
> > be below 12. While it doesn't say
On 8/4/2018 10:47 PM, Rob Clark wrote:
On Thu, Jul 12, 2018 at 3:48 PM Chris Wilson wrote:
Quoting Jordan Crouse (2018-07-12 19:59:25)
Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.
Signed-off-by: Jordan Crouse
---
On Fri, Oct 12, 2018 at 12:25:31AM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The
On Fri, 12 Oct 2018 07:35:57 +
"Koenig, Christian" wrote:
> Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
> > On Wed, 10 Oct 2018 09:35:50 -0400
> > "Kazlauskas, Nicholas" wrote:
> >
> >> The patches I've put out target this use case mostly because of the
> >> benefit for a relatively sim
Wait until the next vblank to be sure that crtc has been disabled.
Signed-off-by: Benjamin Gaignard
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/sti/sti_crtc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_crtc.c b/drivers/gpu/drm/sti/sti_crtc.c
index 5824e6aca
Since drm_atomic_helper_shutdown() rework it is possible to do additional
clean up in sti driver: custom plane destroy functions become useless and
clean up encoder is no more needed.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_cursor.c | 9 +
drivers/gpu/drm/sti/sti_gd
On Mon, Oct 8, 2018 at 5:21 PM Maxime Ripard wrote:
>
> On Fri, Oct 05, 2018 at 11:59:51PM +0200, Giulio Benetti wrote:
> > If tcon->panel pointer is NULL, trying to dereference from it
> > (i.e. tcon->panel->connector) will cause a null pointer dereference.
> >
> > Add tcon->panel null pointer ch
The Acer One 10 uses a clamshell design with a detachable keyboard.
As such in normal operating mode, with the keyboard attach the device
is in landscape mode (and the Acer logo at boot also shows in landscape
mode).
But the device uses a portrait screen rotated 90 degrees (sigh). This
commit adds
On Thursday, 2018-10-11 19:18:10 -0400, mesa-dev-boun...@lists.freedesktop.org
wrote:
> From: Rob Clark
>
> drmMalloc() is already calloc()
Sounds very much like an implementation detail, but everything relies on
it already, so...
Reviewed-by: Eric Engestrom
>
> Signed-off-by: Rob Clark
>
Moving DMA mapping creation to drm_iommu_attach_device allows to avoid
looping through all components and maintaining DMA device flags.
v2: take care of configurations without IOMMU
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/ex
Hi Inki,
Changes:
v2: resend of v1 rebased on next with EXYNOS DRM IOMMU changes posted by Marek.
This patchset refactors IOMMU/DMA code in ExynosDRM driver.
It performs several changes:
- provides simple/clean API for ExynosDRM drivers,
- moves IOMMU related code from drivers to single file,
- m
Exynos DRM drivers should work with and without IOMMU. Providing common
API generic to both scenarios should make code cleaner and allow further
code improvements.
The patch removes including of exynos_drm_iommu.h as the file contains
mostly IOMMU specific stuff, instead it exposes exynos_drm_*_dma
Using C conditionals is preferred solution - it provides better code
coverage, makes code more clear.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 108 --
1 file changed, 36 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/exynos/ex
As DMA code is the only user of IOMMU code both files can be merged.
It allows to remove stub functions, after slight adjustment of
exynos_drm_register_dma. Since IOMMU functions are used locally they
can be marked static.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/Makefile
DRM_EXYNOS_IOMMU symbol is not configurable, it is always equal to
EXYNOS_IOMMU.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/Kconfig| 5 -
drivers/gpu/drm/exynos/Makefile | 2 +-
drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
3 files changed, 2 insertions
Since __exynos_iommu* functions are used only in exynos_drm_iommu.c we can
move them there.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 72 +++
drivers/gpu/drm/exynos/exynos_drm_iommu.h | 72 ---
2 files changed, 72 inserti
On 12.10.2018 12:53, Andrzej Hajda wrote:
> Hi Inki,
>
> Changes:
> v2: resend of v1 rebased on next with EXYNOS DRM IOMMU changes posted by
> Marek.
Ups, I have forgot to add v2 prefix in the subject.
Regards
Andrzej
___
dri-devel mailing list
dri-d
On Fri, Oct 12, 2018 at 03:59:26PM +1000, Dave Airlie wrote:
> Hi Greg,
>
> just a single nouveau fix from last week. Seems to be winding now correctly.
>
> Dave.
>
> drm-fixes-2018-10-12-1:
> single nouveau runtime reference and mst change
> The following changes since commit 0238df646e6224016a
On Fri, 2018-10-12 at 00:25 -0700, Radhakrishna Sripada wrote:
> Use the newly added "max bpc" connector property to limit pipe bpp.
>
> V3: Use drm_connector_state to access the "max bpc" property
> V4: Initialize the drm property, add suuport to DP(Ville)
> V5: Use the property in the connector
Am 12.10.2018 um 11:21 schrieb Pekka Paalanen:
> On Fri, 12 Oct 2018 07:35:57 +
> "Koenig, Christian" wrote:
>
>> Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
>>> On Wed, 10 Oct 2018 09:35:50 -0400
>>> "Kazlauskas, Nicholas" wrote:
>>>
The patches I've put out target this use case m
On Fri, 2018-09-28 at 16:13 -0300, Fabio Estevam wrote:
> Adopt the SPDX license identifier headers to ease license compliance
> management.
>
> Signed-off-by: Fabio Estevam
Thank you, applied to imx-drm/next.
regards
Philipp
___
dri-devel mailing lis
On 10/12/2018 07:20 AM, Koenig, Christian wrote:
Am 12.10.2018 um 11:21 schrieb Pekka Paalanen:
On Fri, 12 Oct 2018 07:35:57 +
"Koenig, Christian" wrote:
Am 12.10.2018 um 09:23 schrieb Pekka Paalanen:
On Wed, 10 Oct 2018 09:35:50 -0400
"Kazlauskas, Nicholas" wrote:
The patches I've
Thanks, I've pushed 2 and 3 to msm-next, since these should probably
go in a -fixes pr for 4.20
This one, you might want to resend w/
--cc-cmd=./scripts/get_maintainer.pl so that it gets seen by someone
who could apply it
fwiw, I use
git config sendemail.cccmd './scripts/get_maintainer.pl -i'
On Fri, 12 Oct 2018 at 00:18, Rob Clark wrote:
>
> From: Rob Clark
>
> drmMalloc() is already calloc()
>
> Signed-off-by: Rob Clark
For the patch
Reviewed-by: Emil Velikov
> ---
> Small micro-optimization that I noticed while doing some perf work..
> I should probably look at promoting amdgpu'
https://bugs.freedesktop.org/show_bug.cgi?id=108340
Bug ID: 108340
Summary: Ambient Occlusion in Two Point Hospital shows black
spot artifacts
Product: Mesa
Version: 18.2
Hardware: x86-64 (AMD64)
OS: Linux (
Hi, Felix,
It looks like there is a locking inversion in ttm_bo_vm_access() where
we take a sleeping bo_reserve() while holding mmap_sem().
Previously we've been assuming the other way around or at least
undefined allowing for drivers to do
bo_reserve()
copy_to_user() / copy_from_user()
bo_
From: Colin Ian King
Trivial fix to spelling mistake in warn message text
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/init.c
b/drivers/gpu/drm/nou
Mali-DP implements a number of tiled yuv formats which are not
currently described in drm_fourcc.h.
This adds those definitions and describes their memory layout by
using the newly added char_per_block, block_w, block_h.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/drm_fourcc.c | 12 ++
In-line member documentation seems to be desired way of documenting
structure members.
This change had been suggested by Daniel Vetter here:
https://lists.freedesktop.org/archives/dri-devel/2018-October/192176.html
Signed-off-by: Alexandru Gheorghe
---
include/drm/drm_fourcc.h | 30
For formats that are supported only with non-linear modifiers it
doesn't make to much sense to define cpp or char_per_block, so that
will be set to 0.
This patch adds a restriction to force having a modifier attached when
cpp/char_per_block is 0, and to bypass checking the pitch restriction.
This
Changes since v3:
- added an utility function that computes the minimum pitch.
- switched drm_format_info to in-line member documentation.
- Cleanup/Improved the kernel doc.
- Added selftests for: drm_format_info* helpers.
There has been some discussion about extending drm core to handle
l
From: Brian Starkey
AFBC is a flexible, proprietary, lossless compression protocol and
format, with a number of defined DRM format modifiers. To facilitate
consistency and compatibility between different AFBC producers and
consumers, document the expectations for usage of the AFBC DRM format
modi
For some pixel formats .cpp structure in drm_format info it's not
enough to describe the peculiarities of the pixel layout, for example
tiled formats or packed formats at bit level.
What's implemented here is to add three new members to drm_format_info
that could describe such formats:
- char_per
Add selftests for the following newly added functions:
- drm_format_info_block_width
- drm_format_info_block_height
- drm_format_info_min_pitch
Signed-off-by: Alexandru Gheorghe
---
.../gpu/drm/selftests/drm_helper_selftests.h | 3 +
drivers/gpu/drm/selftests/test-drm-helper.c | 277 +++
Enable the following formats
- DRM_FORMAT_X0L0: DP650
- DRM_FORMAT_X0L2: DP550, DP650
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/arm/malidp_hw.c | 14 +++---
drivers/gpu/drm/arm/malidp_planes.c | 23 +--
2 files changed, 32 insertions(+), 5 deletions(-)
From: Brian Starkey
As we look to enable AFBC using DRM format modifiers, we run into
problems which we've historically handled via vendor-private details
(i.e. gralloc, on Android).
AFBC (as an encoding) is fully flexible, and for example YUV data can
be encoded into 1, 2 or 3 encoded "planes",
test-drm-helper.ko can't be rmmod-ed because it doesn't have a
module_exit, that could be very inconvenient especially in the
development stage where we usually want to re-run the tests without
any rebooting.
Signed-off-by: Alexandru Gheorghe
---
drivers/gpu/drm/selftests/test-drm-helper.c | 5
These patches are part of a proposed new interface for supporting variable
refresh rate via DRM properties.
=== Changes from v4 ===
amd changes:
* Removed unused FreeSync functions from amdgpu
=== Changes from v3 ===
drm changes:
* Docstring and formatting fixes
amd/display changes:
* Upda
Modern display hardware is capable of supporting variable refresh rates.
This patch introduces the "vrr_capable" property on the connector to
allow userspace to query support for variable refresh rates.
Atomic drivers should attach this property to connectors that are
capable of driving variable r
This patch introduces the 'vrr_enabled' CRTC property to allow
dynamic control over variable refresh rate support for a CRTC.
This property should be treated like a content hint to the driver -
if the hardware or driver is not capable of driving variable refresh
timings then this is not considered
These include the drm_connector 'vrr_capable' and the drm_crtc
'vrr_enabled' properties.
Signed-off-by: Nicholas Kazlauskas
---
Documentation/gpu/drm-kms.rst | 7 +++
drivers/gpu/drm/drm_connector.c | 22 ++
2 files changed, 29 insertions(+)
diff --git a/Documentation
Hi,
I'm looking at the sun4i DRM driver these days (especially for
mainlining the VPU tiled format support through the frontend).
The way things are done currently, all the possibly-supported plane
formats are listed in sun4i_backend_layer_formats and exposed as-is to
userspace for every plane. H
Support for AMDGPU specific FreeSync properties and ioctls are dropped
from amdgpu_dm in favor of supporting drm variable refresh rate
properties.
The notify_freesync and set_freesync_property functions are dropped
from amdgpu_display_funcs.
The drm vrr_capable property is now attached to any DP/
https://bugs.freedesktop.org/show_bug.cgi?id=108347
Bug ID: 108347
Summary: [regression, bisected] Performance drop in various
games
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
This and the r420 patch applied. Thanks!
Alex
On Fri, Oct 12, 2018 at 1:11 PM Gustavo A. R. Silva
wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in this particular case, I replaced "Pass through." with
> "
On 10/10/2018 04:33 PM, John Stultz wrote:
Since 4.12, much later narrowed down to commit 2a55e7b5e544
("staging: android: ion: Call dma_map_sg for syncing and mapping"),
we have seen graphics performance issues on the HiKey960.
This was initially confounded by the fact that the out-of-tree
DRM
Quoting Stephen Boyd (2018-07-26 00:35:14)
> Quoting Sean Wang (2018-07-18 03:06:27)
> > On Wed, 2018-07-18 at 11:05 +0300, Laurent Pinchart wrote:
> > > Hi Sean,
> > >
> > > This looks very strange to me. I'm not familiar with the hardware
> > > architecture, but a clock controller that includes
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against conne
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc pro
(re)assign the hw overlays to planes based on required caps, and to
handle situations where we could not modify an in-use plane.
This means all planes advertise the superset of formats and properties.
Userspace must (as always) use atomic TEST_ONLY step for atomic updates,
as not all planes may be
In order to be able to dynamically assign overlays to planes we need to
be able to asses the overlay capabilities.
Add a helper function to be able to retrieve the supported capabilities
of an overlay.
And export the function to check if a fourcc is supported on a given
overlay.
Signed-off-by: B
We currently assume that an overlay has the same maximum width and
maximum height as the overlay manager. This assumption is incorrect. On
some variants the overlay manager maximum width is twice the maximum
width that the overlay can handle. We need to add the appropriate data
per variant as well
Split out the hardware overlay specifics from omap_plane.
To start, the hw overlays are statically assigned to planes.
The goal is to eventually assign hw overlays dynamically to planes
during plane->atomic_check() based on requested caps (scaling, YUV,
etc). And then perform hw overlay re-assignm
If the drm_plane has a source width that's greater than the max width
supported by a single hw overlay, then we assign a 'r_overlay' to it in
omap_plane_atomic_check().
Both overlays should have the capabilities required to handle the source
framebuffer. The only parameters that vary between the l
In preparation to add omap plane state specific extensions we need to
subclass drm_plane_state and add the relevant helpers.
The addition of specific extension will be done separately.
Signed-off-by: Benoit Parrot
---
drivers/gpu/drm/omapdrm/omap_plane.c | 48 +--
According to the Vulkan spec:
"Vulkan 1.0 initially required all new physical-device-level extension
functionality to be structured within an instance extension. In order
to avoid using an instance extension, which often requires loader
support, physical-device-level extension functionality may
This patch series adds virtual-plane support to omapdrm driver to allow the use
of display wider than 2048 pixels.
In order to do so we introduce the concept of hw_overlay which can then be
dynamically allocated to a plane. When the requested output width exceed what
be supported by one overlay a
Now that we added specific item to our subclassed drm_plane_state
we can add omap_plane_atomic_print_state() helper to dump out our own
driver specific plane state.
Signed-off-by: Benoit Parrot
---
drivers/gpu/drm/omapdrm/omap_plane.c | 18 ++
1 file changed, 18 insertions(+)
di
On 2018-10-12 03:34 AM, Daniel Vetter wrote:
On Thu, Oct 11, 2018 at 08:27:43PM -0400, sunpeng...@amd.com wrote:
From: Leo Li
This fixes a general protection fault, caused by accessing the contents
of a flip_done completion object that has already been freed. It occurs
due to the preemption
On Mon, 8 Oct 2018 18:06:20 +, Leonard Crestez wrote:
> The PCIE and PCIE_PHY blocks are in different power domains on imx6sx
> and this needs to be described using multi-pd bindings.
>
> This was not required until now because the power-domain of the PCIE
> block (DISPLAY) was always on.
>
>
On Wed, Oct 10, 2018 at 02:54:34PM +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:
> -n
On 2018-10-09 23:28, Jeykumar Sankaran wrote:
On 2018-10-09 14:06, Sean Paul wrote:
On Mon, Oct 08, 2018 at 09:27:24PM -0700, Jeykumar Sankaran wrote:
DPU maintained reservation lists to cache assigned
HW blocks for the display and a retrieval mechanism for
the individual DRM components to quer
From: Colin Ian King
Trivial fix to spelling mistake in MODULE_PARM_DESC text
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/via/viafbdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/via/viafbdev.c
b/drivers/video/fbdev/via/viafbdev.c
index
https://bugs.freedesktop.org/show_bug.cgi?id=108309
--- Comment #4 from Samantha McVey ---
This can be closed. I was able to get things working by `idle=nomwait` to my
linux cmdline.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=108322
--- Comment #11 from bmil...@gmail.com ---
Compiled last AMD-drm-next kernel from git and problem's still here, even
worse, it's now flickering everywhere at 75hz.
Discovered from another bug report that forcing clocks to high "fixed" the
flicker
Global shared resources (like hw overlays) for omapdrm are implemented
as a part of atomic state using the drm_private_obj infrastructure
available in the atomic core.
omap_global_state is introduced as a drm atomic private object. The two
funcs omap_get_global_state() and omap_get_existing_global
https://bugs.freedesktop.org/show_bug.cgi?id=108350
Bug ID: 108350
Summary: amd-staging-drm-next-git witcher3 crashes and
graphical oddities
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (
https://bugs.freedesktop.org/show_bug.cgi?id=108350
--- Comment #1 from Alessandro ---
Created attachment 142009
--> https://bugs.freedesktop.org/attachment.cgi?id=142009&action=edit
image of graphical mess
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=108350
Alessandro changed:
What|Removed |Added
Summary|amd-staging-drm-next-git|amd-staging-drm-next-git
88 matches
Mail list logo
