On Wed, May 30, 2018 at 12:30:51PM +0200, Daniel Vetter wrote:
> On Tue, May 29, 2018 at 03:59:18PM +0200, Gerd Hoffmann wrote:
> > So drivers don't need dummy functions just returning NULL.
> >
> > Cc: Daniel Vetter
> > Signed-off-by: Gerd Hoffmann
>
> Reviewed-by: Daniel Vetter
>
> Please p
From: Christoffer Dall
User space Android code identifies pixclock == 0 as a sign for emulation
and will set the frame rate to 60 fps when reading this value, which is
the desired outcome.
Change-Id: I759bf518bf6683446bc786bf1be3cafa02dd8d42
Signed-off-by: Christoffer Dall
Signed-off-by: Peter
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: Ben Skeggs
Cc: David Airlie
Cc: dri-devel@lists.freedesktop.org
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Yisheng Xie
---
v2:
- handle err case before normal case - p
match_string() returns the index of an array for a matching string,
which can be used instead of open coded variant.
Cc: David Airlie
Cc: Yisheng Xie
Cc: Daniel Vetter
Cc: Arvind Yadav
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Yisheng Xie
---
v2:
- handle err case before normal case
Dne četrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
> On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > >> > > + if (tcon->quirks->needs_tcon_top) {
> > >> > > + struct device_node *np;
> > >> > > +
> > >> > > + np = of_parse_phandle(dev->of_node,
This patch add checks for NULL drm_connector_helper_funcs
pointers before derefrencing the variable to avoid NULL pointer
dereference and make the helper function optional in the following
cases:
1) when using drm_helper_probe_single_connector_modes for fill_modes
callback in the drm_connector_fun
On Tue, May 22, 2018 at 11:43 PM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref->
On 05/31/2018 01:51 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>
>>
>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>
>>>
>>> Oleksandr Andrushchenko (8):
>>> xen/grant-table: Make set/clear page private code shared
>>> xen/balloon: Move co
On 05/31/2018 10:41 AM, Oleksandr Andrushchenko wrote:
> On 05/31/2018 08:51 AM, Oleksandr Andrushchenko wrote:
>> On 05/31/2018 04:46 AM, Boris Ostrovsky wrote:
>>>
>>>
>>> On 05/25/2018 11:33 AM, Oleksandr Andrushchenko wrote:
>>>
Oleksandr Andrushchenko (8):
xen/grant-table: Ma
From: Roman Kiryanov
Address issues pointed by checkpatch.pl
Signed-off-by: Roman Kiryanov
---
drivers/video/fbdev/goldfishfb.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/goldfishfb.c b/drivers/video/fbdev/goldfishfb.c
index 3b70044773b6..de29c4f
Hi Lucas,
I think I found an issue in etnaviv kernel driver regarding
VIV_FE_DRAW_2D_HEADER_DATA_COUNT
In your old test
https://github.com/etnaviv/etna_viv/blob/master/attic/test2d/bitblt2d_from_stream.c
you append streamed data at the end of draw command buffer, but driver
gives an error :
etnav
From: Yu Ning
Follow the same way in which ACPI was enabled for goldfish battery. See
commit d3be10e for details.
Note that this patch also depends on commit af33cac.
Signed-off-by: Yu Ning
Signed-off-by: Roman Kiryanov
---
drivers/video/fbdev/goldfishfb.c | 8
1 file changed, 8 ins
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.19-wip
head: d9d75cfdd854593351f7537b2c0f5739304e
commit: 2b6199a1d1b70fccd62aed961ba4c2b979ae499c [10/60] drm/amd/display:
replace msleep with udelay in fbc path
smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce11
Hi All,
The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
through it's Embedded Controller, to enable the Linux CEC Core to communicate
with it and get the CEC Physical Address from the correct HDMI Connector, the
following must be added/changed:
- Add the CEC sub-device reg
In non device-tree world, we can need to get the notifier by the driver
name directly and eventually defer probe if not yet created.
This patch adds a variant of the get function by using the device name
instead and will not create a notifier if not yet created.
But the i915 driver exposes at lea
The EC can expose a CEC bus, this patch adds the CEC related definitions
needed by the cros-ec-cec driver.
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
Reviewed-by: Hans Verkuil
---
include/linux/mfd/cros_ec_commands.h | 81
1 file change
Having a 16 byte mkbp event size makes it possible to send CEC
messages from the EC to the AP directly inside the mkbp event
instead of first doing a notification and then a read.
Signed-off-by: Stefan Adolfsson
Signed-off-by: Neil Armstrong
Tested-by: Enric Balletbo i Serra
---
drivers/platfo
This patchs adds the cec_notifier feature to the intel_hdmi part
of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate
between each HDMI ports.
The changes will allow the i915 HDMI code to notify EDID and HPD changes
to an eventual CEC adapter.
Signed-off-by: Neil Armstrong
The ChromeOS Embedded Controller can expose a CEC bus, this patch add the
driver for such feature of the Embedded Controller.
This driver is part of the cros-ec MFD and will be add as a sub-device when
the feature bit is exposed by the EC.
The controller will only handle a single logical address
The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device
when the CEC feature bit is present.
Signed-off-by: Neil Armstrong
Reviewed-by: Enric Balletbo i Serra
Acked-by: Hans Verkuil
---
drivers/mfd/cros_ec_dev.c | 16
1 file changed, 16 insertions(+)
diff --git a
On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> Having a 16 byte mkbp event size makes it possible to send CEC
> messages from the EC to the AP directly inside the mkbp event
> instead of first doing a notification and then a read.
>
> Signed-off-by: Stefan Adolfsson
> Signed-off-by: Neil Armstro
On Thu, May 31, 2018 at 03:51:37PM +0100, Emil Velikov wrote:
> Hi Lowry,
>
> Small drive-by suggestion. Haven't checked if others have pointed it
> out previously :-\
>
> On 30 May 2018 at 12:23, Lowry Li wrote:
>
> > +/**
> > + * drm_plane_create_blend_mode_property - create a new blend mode
://github.com/0day-ci/linux/commits/Lowry-Li/drm-blend-Add-per-plane-pixel-blend-mode-property/20180601-180033
base: git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm64-allmodconfig (attached as .config)
compiler: aarch64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget
https
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use these instead of open-coding.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/grant-table.c | 54 +--
include/xen/grant_table
From: Oleksandr Andrushchenko
Memory {increase|decrease}_reservation and VA mappings update/reset
code used in balloon driver can be made common, so other drivers can
also re-use the same functionality without open-coding.
Create a dedicated file for the shared code and export corresponding
symbo
From: Oleksandr Andrushchenko
Only gnttab_{alloc|free}_pages are exported as EXPORT_SYMBOL
while all the rest are exported as EXPORT_SYMBOL_GPL, thus
effectively making it not possible for non-GPL driver modules
to use grant table module. Export gnttab_{alloc|free}_pages as
EXPORT_SYMBOL_GPL so a
From: Oleksandr Andrushchenko
This work is in response to my previous attempt to introduce Xen/DRM
zero-copy driver [1] to enable Linux dma-buf API [2] for Xen based
frontends/backends. There is also an existing hyper_dmabuf approach
available [3] which, if reworked to utilize the proposed soluti
From: Oleksandr Andrushchenko
Allow mappings for DMA backed buffers if grant table module
supports such: this extends grant device to not only map buffers
made of balloon pages, but also from buffers allocated with
dma_alloc_xxx.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev.c
From: Oleksandr Andrushchenko
Extend grant table module API to allow allocating buffers that can
be used for DMA operations and mapping foreign grant references
on top of those.
The resulting buffer is similar to the one allocated by the balloon
driver in terms that proper memory reservation is m
From: Oleksandr Andrushchenko
Add UAPI and IOCTLs for dma-buf grant device driver extension:
the extension allows userspace processes and kernel modules to
use Xen backed dma-buf implementation. With this extension grant
references to the pages of an imported dma-buf can be exported
for other dom
From: Oleksandr Andrushchenko
1. Import a dma-buf with the file descriptor provided and export
granted references to the pages of that dma-buf into the array
of grant references.
2. Add API to close all references to an imported buffer, so it can be
released by the owner. This is only v
From: Oleksandr Andrushchenko
1. Create a dma-buf from grant references provided by the foreign
domain. By default dma-buf is backed by system memory pages, but
by providing GNTDEV_DMA_FLAG_XXX flags it can also be created
as a DMA write-combine/coherent buffer, e.g. allocated with
co
From: Oleksandr Andrushchenko
Allow creating grant device context for use by kernel modules which
require functionality, provided by gntdev. Export symbols for dma-buf
API provided by the module.
Signed-off-by: Oleksandr Andrushchenko
---
drivers/xen/gntdev-dmabuf.c | 6 +++
drivers/xen/gntde
Boris, I dropped your r-b for this patch as I changed
EXPORT_SYMBOL to EXPORT_SYMBOL_GPL as Juergen requested
On 06/01/2018 02:41 PM, Oleksandr Andrushchenko wrote:
From: Oleksandr Andrushchenko
Make set/clear page private code shared and accessible to
other kernel modules which can re-use th
Am 31.05.2018 um 07:07 schrieb Souptick Joarder:
On Thu, May 24, 2018 at 12:25 AM, Souptick Joarder wrote:
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fa
On Wed, May 30, 2018 at 02:27:55PM +0100, Brian Starkey wrote:
> Hi Lowry,
>
> On Wed, May 30, 2018 at 07:23:53PM +0800, Lowry Li wrote:
> >Pixel blend modes represent the alpha blending equation
> >selection, describing how the pixels from the current
> >plane are composited with the background.
The device parameter is completely unused because it is available in the
attachment structure as well.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 3 +--
drivers/gpu/drm/drm_prime.c
Neither used nor correctly implemented anywhere. Just completely remove
the interface.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 44 --
drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 2 -
drivers/gpu/drm/armada/armada_gem.c
First step towards unpinned DMA buf operation.
I've checked the DRM drivers to potential locking of the reservation
object, but essentially we need to audit all implementations of the
dma_buf _ops for this to work.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 4
include/l
Add function variants which can be called with the reservation lock
already held.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 60 ++-
include/linux/dma-buf.h | 5
2 files changed, 59 insertions(+), 6 deletions(-)
diff --git
The caching of SGT's done by the DRM code is actually quite harmful and
should probably removed altogether in the long term.
Start by providing a separate DMA-buf export implementation in amdgpu. This is
also a prerequisite of unpinned DMA-buf handling.
v2: fix unintended recursion, remove debugg
Sorry, accidentally send this series without a cover letter.
This is a cleanup to the DMA-buf interface, which is also a prerequisite
to unpinned DMA-buf operation.
Patch #1 and #2 just remove unused functionality and clean up callback
parameters.
Patch #3 and #4 introduce taking the reserv
Hi,
This serie aims at adding the support for pixel blend modes represent the
alpha blending equation selection in the driver. It also introduces to use
it in the malidp driver.
Let me know what you think,
Lowry
Changes for v3:
- Refines the comments of drm_plane_create_blend_mode_property:
1. Check the pixel blending mode and plane alpha value when
do the plane_check. Mali DP supports blending the current plane
with the background either based on the pixel alpha blending
mode or by using the layer's alpha value, but not both at the
same time. If both case, plane_check will return fai
Pixel blend modes represent the alpha blending equation
selection, describing how the pixels from the current
plane are composited with the background.
Add a pixel_blend_mode to drm_plane_state and a
blend_mode_property to drm_plane, and related support
functions.
Defines three blend modes in drm
On Thu, May 31, 2018 at 12:17 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
Series is:
Reviewed-by: Alex Deucher
> ---
> Documentation/gpu/amdgpu.rst | 14 +++
> drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c | 119 ++
> 2 files
On 2018-06-01 02:58 PM, Alex Deucher wrote:
> On Thu, May 31, 2018 at 12:17 PM, Michel Dänzer wrote:
>> From: Michel Dänzer
>>
>> Signed-off-by: Michel Dänzer
>
> Series is:
> Reviewed-by: Alex Deucher
Thanks. Is it okay to merge all of these via the amdgpu tree, or should
I wait for an ack f
On Fri, Jun 1, 2018 at 9:40 AM, Michel Dänzer wrote:
> On 2018-06-01 02:58 PM, Alex Deucher wrote:
>> On Thu, May 31, 2018 at 12:17 PM, Michel Dänzer wrote:
>>> From: Michel Dänzer
>>>
>>> Signed-off-by: Michel Dänzer
>>
>> Series is:
>> Reviewed-by: Alex Deucher
>
> Thanks. Is it okay to merg
On 2018-06-01 03:44 PM, Alex Deucher wrote:
> On Fri, Jun 1, 2018 at 9:40 AM, Michel Dänzer wrote:
>> On 2018-06-01 02:58 PM, Alex Deucher wrote:
>>> On Thu, May 31, 2018 at 12:17 PM, Michel Dänzer wrote:
From: Michel Dänzer
Signed-off-by: Michel Dänzer
>>>
>>> Series is:
>>> Rev
On 2018-06-01 02:11 PM, Christian König wrote:
> Sorry, accidentally send this series without a cover letter.
>
> This is a cleanup to the DMA-buf interface, which is also a prerequisite
> to unpinned DMA-buf operation.
>
> Patch #1 and #2 just remove unused functionality and clean up callback
>
https://bugs.freedesktop.org/show_bug.cgi?id=106544
Leonid Maksymchuk changed:
What|Removed |Added
CC||leonm...@gmail.com
--- Comment #2 f
On Fri, 1 Jun 2018 15:40:44 +0200
Michel Dänzer wrote:
> Thanks. Is it okay to merge all of these via the amdgpu tree, or should
> I wait for an ack from Jon and/or core DRM maintainers for that?
I've been assuming they would go through a DRM tree, no need to wait for
me.
Thanks,
jon
_
On Fri, Jun 1, 2018 at 9:56 AM, Michel Dänzer wrote:
> On 2018-06-01 03:44 PM, Alex Deucher wrote:
>> On Fri, Jun 1, 2018 at 9:40 AM, Michel Dänzer wrote:
>>> On 2018-06-01 02:58 PM, Alex Deucher wrote:
On Thu, May 31, 2018 at 12:17 PM, Michel Dänzer wrote:
> From: Michel Dänzer
>
On Thu, May 31, 2018 at 8:04 AM, Andy Shevchenko
wrote:
> On Thu, May 31, 2018 at 12:49 AM, Arnd Bergmann wrote:
>
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c: In function 'hdmi_probe_of':
>> drivers/video/fbdev/omap2/omapfb/dss/hdmi5.c:584:2: error: implicit
>> declaration of function 'of_n
Am 01.06.2018 um 16:02 schrieb Michel Dänzer:
On 2018-06-01 02:11 PM, Christian König wrote:
Sorry, accidentally send this series without a cover letter.
This is a cleanup to the DMA-buf interface, which is also a prerequisite
to unpinned DMA-buf operation.
Patch #1 and #2 just remove unused f
On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej Škrabec wrote:
> Dne četrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
> > > >> > > + if (tcon->quirks->needs_tcon_top) {
> > > >> > > + struct device_node *n
On 2018-06-01 05:17 PM, Christian König wrote:
> Am 01.06.2018 um 16:02 schrieb Michel Dänzer:
>> On 2018-06-01 02:11 PM, Christian König wrote:
>>> Sorry, accidentally send this series without a cover letter.
>>>
>>> This is a cleanup to the DMA-buf interface, which is also a prerequisite
>>> to u
https://bugs.freedesktop.org/show_bug.cgi?id=106544
--- Comment #3 from Leonid Maksymchuk ---
Tested same kernel on Radeon RX 570 - no errors in dmesg, seems to affect R9
Fury video cards only.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106544
--- Comment #4 from Leonid Maksymchuk ---
With my Radeon R9 Fury, I tested kernels down to 4.16.3 (latest version that
does not crash) and found this commit to be a reason for errors:
https://patchwork.kernel.org/patch/10354647/
I built kernel
On Fri, Jun 1, 2018 at 8:29 AM, Maxime Ripard wrote:
> On Thu, May 31, 2018 at 07:54:08PM +0200, Jernej Škrabec wrote:
>> Dne četrtek, 31. maj 2018 ob 11:21:33 CEST je Maxime Ripard napisal(a):
>> > On Thu, May 24, 2018 at 03:01:09PM -0700, Chen-Yu Tsai wrote:
>> > > >> > > + if (tcon->quirks->nee
On Fri, May 25, 2018 at 02:26:06PM -0700, Jeykumar Sankaran wrote:
> Switch DPU from dsi-staging to upstream dsi driver. To make
> the switch atomic, this change includes:
> - remove dpu connector layers
> - clean up dpu connector dependencies in encoder/crtc
> - compile out writeback and display p
https://bugs.freedesktop.org/show_bug.cgi?id=106544
Michel Dänzer changed:
What|Removed |Added
CC||charlene@amd.com,
https://bugs.freedesktop.org/show_bug.cgi?id=106544
--- Comment #6 from Leonid Maksymchuk ---
Forgot to mention that I too use HDMI cable to connect my display.
And after reverting this commit display outs from sleep (DPMS) normally w/o
blanking.
--
You are receiving this mail because:
You are
With this we can now terminate jobs enqueue into SW queue the moment
the task is being killed instead of waiting for last user of
drm file to release it.
Also stop checking for kref_read(&ctx->refcount) == 1 when
calling drm_sched_entity_do_release since other task
might still hold a reference to
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
happens when HW ring is already hangged whem a new en
Am 01.06.2018 um 19:11 schrieb Andrey Grodzovsky:
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handle entity->last_scheduled == NULL use case which
ha
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #6 from d...@volny.cz ---
It seems I'm now affected by this bug too...
Hardware:
GPU: RX Vega 64 Liquid
CPU: Ryzen R7 1800X
Software:
OS: OpenSUSE Tumbleweed
Kernel: 4.17rc5 (from OpenSUSE Factory repos)
Mesa: 18.1.0 (from OpenSUSE
On 2018-06-01 09:21, Sean Paul wrote:
On Fri, May 25, 2018 at 02:26:06PM -0700, Jeykumar Sankaran wrote:
Switch DPU from dsi-staging to upstream dsi driver. To make
the switch atomic, this change includes:
- remove dpu connector layers
- clean up dpu connector dependencies in encoder/crtc
- comp
SDM845 DPU driver was talking to dsi-staging driver for its dsi
operations through the customized dpu_connector layer. The following
series of patches removes DPU dependency from various dpu
connector API's before purging the dpu_connector altogether. It
also completes the switch to upstream DSI
Switch DPU from dsi-staging to upstream dsi driver. To make
the switch atomic, this change includes:
- remove dpu connector layers
- clean up dpu connector dependencies in encoder/crtc
- compile out writeback and display port drivers
- compile out dsi-staging driver (separate patch submitted to
r
Remove autorefresh support for smart panels in SDM845 for now.
It needs more discussion to figure out the user space
communication to set preference for the feature.
changes in v2:
- none
changes in v3:
- none
changes in v4:
- none
Reviewed-by: Sean Paul
Signed-off-by: Je
Remove custom ioctl support in SDM845 which allows
user space to register/unregister for hw events.
changes in v2:
- none
changes in v3:
- none
changes in v4:
- none
Reviewed-by: Sean Paul
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Sean Paul
Signed-off-by: Rajesh Y
ping pong split topology was meant for low end soc's which
doesn't have enough layer mixers to support split panels.
Considering how uncommon the topology is for current chipset's and
also to simply the driver programming, striping off the support
for SDM845.
changes in v2:
- none
changes
Upstream DSI driver doesn't support DSC panels yet. Remove
the support for compression from DPU for now.
changes in v2:
- indents and unrelated change clean up (Sean Paul)
- fix compilation dependency in dsi-staging
changes in v3:
-none
changes in v4:
-none
Signed-
Hi Maruthi,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: f7ceee8ca796986a75d579130ab9be5ffe67cf2c
commit: 2a6630b1095609b26a205b7c537594f3cde99c0a [114/556] ASoC: AMD: enable
ACP3x drivers build
config: sh-allmodconfig (
https://bugs.freedesktop.org/show_bug.cgi?id=106317
--- Comment #6 from Kertesz Laszlo ---
I did some additional testing and it seems that if i disable the monitor
connected through DVI (xrandr --output DVI-D-0 --off), the HDMI monitor has no
issues with dpms.
--
You are receiving this mail bec
https://bugs.freedesktop.org/show_bug.cgi?id=106317
--- Comment #7 from Kertesz Laszlo ---
Tested with the DVI monitor only (disabled the HDMI) too and seems to work fine
aswell.
I also tested with both and even now with kernel 4.17.0-rc7+ it locks up.
--
You are receiving this mail because:
Y
On Wed, May 30, 2018 at 07:12:52PM -0700, Abhinav Kumar wrote:
> Higher values of pclk can exceed 32 bits when multiplied
> by a factor.
>
> Make the pclk_rate u64 to accommodate higher pixel clock
> rates.
>
> Signed-off-by: Abhinav Kumar
Can you please rebase this on "drm/msm/dsi: adjust dsi
On 06/01/2018 01:22 PM, Christian König wrote:
Am 01.06.2018 um 19:11 schrieb Andrey Grodzovsky:
Dying process might be blocked from receiving any more signals
so avoid using it.
Also retire enity->fini_status and just check the SW queue,
if it's not empty do the fallback cleanup.
Also handl
"qxl_bo_unref" may sleep, but calling "qxl_release_map" causes
"preempt_disable()" to be called and "preempt_enable()" isn't called
until "qxl_release_unmap" is used. Move the call to "qxl_bo_unref" out
from in between the two to avoid sleeping from an atomic context.
This issue can be demonstrate
https://bugs.freedesktop.org/show_bug.cgi?id=106773
Bug ID: 106773
Summary: Raven ridge, *ERROR* ring vcn_dec timeout
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=106773
--- Comment #1 from ojab ---
Created attachment 139955
--> https://bugs.freedesktop.org/attachment.cgi?id=139955&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106775
Bug ID: 106775
Summary: continuous error "write-fence failed" for etnaviv
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: nor
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #203 from iburnth3playb00k ---
(In reply to chris from comment #188)
> I suffered pretty much all of the issue listed in this thread for many weeks
> since upgrading to 3 1440p monitors.
>
> I have an Club 3D R9 390 Royal Queen.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Jan Vesely changed:
What|Removed |Added
Depends on||61417
Referenced Bugs:
https://bugs.freed
Make the pclk_rate u64 to accommodate higher pixel clock
rates.
Changes in v3:
- Rebased on top of https://patchwork.kernel.org/patch/10348865/
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drive
https://bugs.freedesktop.org/show_bug.cgi?id=106287
--- Comment #4 from stu...@gmail.com ---
Well, I finally got back to the game. I'm on mesa 18.1 and I see the problem
again. Maybe it was never fully fixed.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #5 from udo ---
Also happens on 4.17-rc7.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #6 from udo ---
These issues happen multiple times per day.
Not when I am away, but when I am using the PC.
Thus making the system unusable due to unreliability.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #8 from udo ---
video as in youtube, vlc, xine, etc.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
ht
https://bugs.freedesktop.org/show_bug.cgi?id=10
--- Comment #7 from udo ---
Also when no video activity is going on, thus bug can happen.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel
91 matches
Mail list logo
