On Tue, Oct 22, 2019 at 10:50:42AM +0200, Daniel Vetter wrote:
> On Tue, Oct 22, 2019 at 10:48 AM Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, Oct 22, 2019 at 10:42:10AM +0200, Daniel Vetter wrote:
> > > On Thu, Oct 17, 2019 at 12:41:37PM +0100, Russell King - ARM Linux admin
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #121 from Mauro Gaspari ---
(In reply to blppt from comment #120)
> I dont have anything to attach here, but same issue here, ubuntu 19.04,
> kernel 5.4-rc3, vega64 W/C, Mesa 19.3.0 -- it only seems to occur with DXVK
> and not D9VK
When deferring the probe because of a missing regulator, we were calling
pm_runtime_disable even if pm_runtime_enable wasn't called.
Move the call to pm_runtime_disable to the right place.
Signed-off-by: Tomeu Vizoso
Reported-by: Chen-Yu Tsai
Cc: Robin Murphy
Fixes: f4a3c6a44b35
On Tue, 22 Oct 2019, Daniel Vetter wrote:
> On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
>> This patch adds a scaling filter mode porperty
>> to allow:
>> - A driver/HW to showcase it's scaling filter capabilities.
>> - A userspace to pick a desired effect while scaling.
>>
On 2019-10-23 4:32 a.m., zhongshiqi wrote:
> dc.c:583:null check is needed after using kzalloc function
>
> Signed-off-by: zhongshiqi
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
Hi Mark,
Thank you for the patch.
On Tue, Oct 22, 2019 at 02:41:45PM -0700, Mark Salyzyn wrote:
> Replace all occurrences of prefered with preferred to make future
> checkpatch.pl's happy. A few places the incorrect spelling is
> matched with the correct spelling to preserve existing user space
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and
On Wed, Oct 23, 2019 at 3:11 PM Krzysztof Kozlowski wrote:
> On Thu, Oct 10, 2019 at 10:28:02PM +0200, Arnd Bergmann wrote:
> > The contents are available for testing in
> >
> > git://kernel.org:/pub/scm/linux/kernel/git/arnd/playground.git
> > s3c-multiplatform
>
> When sending v2, can you Cc:
Hi Daniel, Dave,
Here is this week's drm-misc-fixes PR.
Thanks!
Maxime
drm-misc-fixes-2019-10-23:
Two fixes for komeda, one for typos and one to prevent an hardware issue
when flushing inactive pipes
The following changes since commit 5b3ec8134f5f9fa1ed0a538441a495521078bbee:
drm/panfrost:
On Tue, Oct 22, 2019 at 02:41:45PM -0700, Mark Salyzyn wrote:
> Replace all occurrences of prefered with preferred to make future
> checkpatch.pl's happy. A few places the incorrect spelling is
> matched with the correct spelling to preserve existing user space API.
>
> Signed-off-by: Mark
2019. 10. 23. 9:42 keltezéssel, Pekka Paalanen írta:
On Tue, 22 Oct 2019 17:50:21 +0200
Böszörményi Zoltán wrote:
Hi,
I have the below configuration for an Intel based POS system that,
while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel),
only two are usable. DP1 for the
https://bugs.freedesktop.org/show_bug.cgi?id=111481
Benjamin Neff changed:
What|Removed |Added
CC||mail+freedesktop@benjaminne
On 2019-10-23 1:21 pm, Tomeu Vizoso wrote:
When deferring the probe because of a missing regulator, we were calling
pm_runtime_disable even if pm_runtime_enable wasn't called.
Move the call to pm_runtime_disable to the right place.
Signed-off-by: Tomeu Vizoso
Reported-by: Chen-Yu Tsai
Cc:
Currently, except for the create and remove, the rest of
mdev_parent_ops is designed for vfio-mdev driver only and may not help
for kernel mdev driver. With the help of class id, this patch
introduces device specific callbacks inside mdev_device
structure. This allows different set of callback to
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the
On Wed, Oct 23, 2019 at 3:13 PM Krzysztof Kozlowski wrote:
> On Thu, Oct 10, 2019 at 10:30:12PM +0200, Arnd Bergmann wrote:
> > @@ -321,6 +320,7 @@ static struct s3c2410fb_mach_info jive_lcd_config = {
> >* data. */
> >
> > .gpcup = (0xf << 1) | (0x3f << 10),
> > +
On Wed, Oct 23, 2019 at 10:34:05AM +0300, Pekka Paalanen wrote:
> On Tue, 22 Oct 2019 20:48:02 +0530
> "Sharma, Shashank" wrote:
>
> > Hello Ville,
> >
> > Thanks for the comments, mine inline.
> >
> >
> > On 10/22/2019 5:50 PM, Ville Syrjälä wrote:
> > > On Tue, Oct 22, 2019 at 03:29:44PM
On Wed, 23 Oct 2019 14:12:03 +0200
Böszörményi Zoltán wrote:
> 2019. 10. 23. 9:42 keltezéssel, Pekka Paalanen írta:
> > On Tue, 22 Oct 2019 17:50:21 +0200
> > Böszörményi Zoltán wrote:
> >
> >> Hi,
> >>
> >> I have the below configuration for an Intel based POS system that,
> >> while
Add support to parse mdev class id table.
Reviewed-by: Parav Pandit
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/vfio_mdev.c | 2 ++
scripts/mod/devicetable-offsets.c | 3 +++
scripts/mod/file2alias.c | 10 ++
3 files changed, 15 insertions(+)
diff --git
On Thu, Oct 10, 2019 at 10:28:02PM +0200, Arnd Bergmann wrote:
> I've spent some time looking at the remaining ARMv4/ARMv5 platforms
> that are not part of ARCH_MULTIPLATFORM, and tried to get them closer
> to that. Here is what came out of that for the samsung platforms:
>
> * Exynos and s5pv210
On Tue, 22 Oct 2019, Daniel Vetter wrote:
> On Fri, Oct 18, 2019 at 01:38:32PM +0200, Gerd Hoffmann wrote:
>> Signed-off-by: Gerd Hoffmann
>> ---
>> drivers/gpu/drm/virtio/virtgpu_kms.c | 9 -
>> 1 file changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git
Passing the wrong type feels icky, everywhere else we use the pipe as
the first parameter. Spotted while discussing patches with Thomas
Zimmermann.
v2: Make xen compile correctly
Acked-By: Thomas Zimmermann (v1)
Cc: Thomas Zimmermann
Cc: Noralf Trønnes
Cc: Gerd Hoffmann
Cc: Eric Anholt
Cc:
When deferring the probe because of a missing regulator, we were calling
pm_runtime_disable even if pm_runtime_enable wasn't called.
Move the call to pm_runtime_disable to the right place.
Signed-off-by: Tomeu Vizoso
Fixes: f4a3c6a44b35 ("drm/panfrost: Disable PM on probe failure")
Cc: Robin
Mdev bus only supports vfio driver right now, so it doesn't implement
match method. But in the future, we may add drivers other than vfio,
the first driver could be virtio-mdev. This means we need to add
device class id support in bus match method to pair the mdev device
and mdev driver correctly.
On Wed, Oct 23, 2019 at 2:41 AM Böszörményi Zoltán wrote:
>
> 2019. 10. 22. 22:57 keltezéssel, Ilia Mirkin írta:
> > On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote:
> >> Section "Device"
> >> Identifier "UDL"
> >> Driver "modesetting"
> >>
Remove unnecessary casts to pointer types passed to kfree.
Issue detected by coccinelle:
@@
type t1;
expression *e;
@@
-kfree((t1 *)e);
+kfree(e);
Signed-off-by: Wambui Karuga
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Thu, Oct 10, 2019 at 10:30:12PM +0200, Arnd Bergmann wrote:
> The s3c2410fb driver is too deeply intertwined with the s3c24xx
> platform code. Change it in a way that avoids the use of platform
> header files but having all interface data in a platform_data
> header, and the private register
This patch implements basic support for mdev driver that supports
virtio transport for kernel virtio driver.
Signed-off-by: Jason Wang
---
drivers/vfio/mdev/mdev_core.c| 20
drivers/vfio/mdev/mdev_private.h | 2 +
include/linux/mdev.h | 6 ++
On Wed, Oct 23, 2019 at 3:18 PM Jani Nikula wrote:
>
> On Tue, 22 Oct 2019, Daniel Vetter wrote:
> > On Fri, Oct 18, 2019 at 01:38:32PM +0200, Gerd Hoffmann wrote:
> >> Signed-off-by: Gerd Hoffmann
> >> ---
> >> drivers/gpu/drm/virtio/virtgpu_kms.c | 9 -
> >> 1 file changed, 4
On Wed, Oct 23, 2019 at 12:13 PM Daniel Vetter wrote:
> Passing the wrong type feels icky, everywhere else we use the pipe as
> the first parameter. Spotted while discussing patches with Thomas
> Zimmermann.
>
> v2: Make xen compile correctly
>
> Acked-By: Thomas Zimmermann (v1)
> Cc: Thomas
On Wed, Oct 23, 2019 at 12:37:03PM +0530, Kiran Gunda wrote:
> The auto string detection algorithm checks if the current WLED
> sink configuration is valid. It tries enabling every sink and
> checks if the OVP fault is observed. Based on this information
> it detects and enables the valid sink
This patch series aims at adding support for runtime bus-format
negotiation between all elements of the
'encoder -> bridges -> connector/display' section of the pipeline.
In order to support that, we need drm bridges to fully take part in the
atomic state validation process, which requires adding
One of the last remaining objects to not have its atomic state.
This is being motivated by our attempt to support runtime bus-format
negotiation between elements of the bridge chain.
This patch just paves the road for such a feature by adding a new
drm_bridge_state object inheriting from
We are about to replace the single-linked bridge list by a double-linked
one based on list.h, leading to the suppression of the encoder->bridge
field. But before we can do that we must provide a
drm_bridge_chain_get_first_bridge() bridge helper and patch all drivers
and core helpers to use it
To iterate over all bridges attached to a specific encoder.
Suggested-by: Laurent Pinchart
Signed-off-by: Boris Brezillon
---
Changes in v3:
* None
Changes in v2:
* New patch
---
include/drm/drm_bridge.h | 11 +++
1 file changed, 11 insertions(+)
diff --git a/include/drm/drm_bridge.h
So that each element in the chain can easily access its predecessor.
This will be needed to support bus format negotiation between elements
of the bridge chain.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* None
Changes in v2:
* Adjust things to the "dummy encoder bridge" change (patch 2
bridge->next is only points to the new bridge if drm_bridge_attach()
succeeds. No need to reset it manually here.
Note that this change is part of the attempt to make the bridge chain
a double-linked list. In order to do that we must patch all drivers
manipulating the bridge->next field.
Some LVDS encoder might support several input/output bus formats. Add
a way to describe the one used on a specific design by adding optional
'data-mapping' properties to the input/output ports.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Use bus-width for the rgb24/rgb18 distinction
*
drm_bridge_state is extended to describe the input and output bus
configuration. This bus configuration is exposed through the
drm_bus_cfg struct which contains 2 properties: the bus format and
the bus flags.
Bus format negotiation is automated by the core, drivers just have
to implement the
The current definition does not represent the exact display pipeline we
have on the board: the LVDS panel is actually connected through a
parallel -> LVDS bridge. Let's fix that so the driver can select the
proper bus format on the CRTC end.
Signed-off-by: Boris Brezillon
---
Changes in v3:
*
And use it in drivers accessing the bridge->next field directly.
This is part of our attempt to make the bridge chain a double-linked list
based on the generic list helpers.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Inline drm_bridge_chain_get_next_bridge() (Suggested by Laurent)
The [pre_]enable/[post_]disable hooks are passed the old atomic state.
Update the doc and rename the arguments to make it clear.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* New patch
---
drivers/gpu/drm/drm_bridge.c | 24
include/drm/drm_bridge.h | 16
Add the data-mapping property to describe the output bus format and
the bus-width property to describe the input bus format.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* New patch
---
.../bindings/display/bridge/lvds-transmitter.txt| 13 +
1 file changed, 13 insertions(+)
So that the previous bridge element in the chain knows which input
format the panel bridge expects.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Adjust things to match the new bus-format negotiation approach
* Use drm_atomic_helper_bridge_propagate_bus_fmt
* Don't implement
Add a new entry for the Toshiba LTA089AC29000 panel.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* None
---
drivers/gpu/drm/panel/panel-simple.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
Encoder drivers will progressively transition to the drm_bridge
interface in place of the drm_encoder one.
Converting the Exynos DSI encoder driver to this approach allows us to
use the ->pre_{enable,disable}() hooks and get rid of the hack
resetting encoder->bridge.next (which was needed to
Change the prefix of bridge helpers targeting a bridge chain from
drm_bridge_ to drm_bridge_chain_ to better reflect the fact that
the operation will happen on all elements of chain, starting at the
bridge passed in argument.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* None
Changes in
The LTA089AC29000 and LT089AC29000 are not exactly the same. Let's add
a new compatible for the LTA variant.
Signed-off-by: Boris Brezillon
---
.../bindings/display/panel/toshiba,lt089ac29000.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Will be useful for bridge drivers that want to do bus format
negotiation with their neighbours.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Inline drm_bridge_chain_get_prev_bridge()
* Fix the doc
Changes in v2:
* Fix the kerneldoc
* Drop the !bridge || !bridge->encoder check
---
Now that bridges can expose the bus format/flags they expect, we can
use those instead of the relying on the display_info provided by the
connector (which is only valid if the encoder is directly connected
to bridge element driving the panel/display).
We also explicitly expose the bus formats
Encoder drivers will progressively transition to the drm_bridge
interface in place of the drm_encoder one.
Let's start with the VC4 driver, and use the ->pre_{enable,disable}()
hooks to get rid of the hack resetting encoder->bridge.next (which was
needed to control the encoder/bridge
This way the drm_bridge_funcs interface is consistent with the rest of
the subsystem.
The only driver implementing those hooks (analogix DP) is patched too.
Signed-off-by: Boris Brezillon
---
Changes in v3:
* Old state clarification moved to a separate patch
Changes in v2:
* Pass the old
So that bridge drivers have a way to check/reject an atomic operation.
The drm_atomic_bridge_chain_check() (which is just a wrapper around
the ->atomic_check() hook) is called in place of
drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
the core falls back on
On 23/10/2019 13:21, Tomeu Vizoso wrote:
> When deferring the probe because of a missing regulator, we were calling
> pm_runtime_disable even if pm_runtime_enable wasn't called.
>
> Move the call to pm_runtime_disable to the right place.
>
> Signed-off-by: Tomeu Vizoso
> Reported-by: Chen-Yu
https://bugs.freedesktop.org/show_bug.cgi?id=109887
--- Comment #14 from Stefan Springer ---
*** Bug 110347 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=110113
Stefan Springer changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109887
Stefan Springer changed:
What|Removed |Added
CC||wsla...@gmail.com
--- Comment #13
On 2019-10-19 3:34 a.m., Wambui Karuga wrote:
> Correct the "_LENTH" mispelling in the AMDGPU_MAX_TIMEOUT_PARAM_LENGTH
> constant.
>
> Signed-off-by: Wambui Karuga
This patch would be better sent in a patch set with the "make undeclared
variables static" patch. You can do that by providing a
On 2019-10-19 3:32 a.m., Wambui Karuga wrote:
> Remove unnecessary assignment for return value and have the
> function return the required value directly.
> Issue found by coccinelle:
> @@
> local idexpression ret;
> expression e;
> @@
>
> -ret =
> +return
> e;
> -return ret;
>
>
On 2019-10-19 3:24 a.m., Wambui Karuga wrote:
> Make the `amdgpu_lockup_timeout` and `amdgpu_exp_hw_support` variables
> static to remove the following sparse warnings:
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c:103:19: warning: symbol
> 'amdgpu_lockup_timeout' was not declared. Should it be
> -Original Message-
> From: Jason Wang
> Sent: Wednesday, October 23, 2019 8:08 AM
> To: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> ker...@vger.kernel.org; dri-devel@lists.freedesktop.org; intel-
> g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
>
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #127 from Shmerl ---
powerplay is a different bug from the sdma one, but it was listed as part of
this report before, that's why I mentioned it above.
--
You are receiving this mail because:
You are the assignee for the
On Mon, 2019-10-21 at 15:44 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> [Why]
>
> Some LED panel drivers might not like fractional PWM. In such cases,
> backlight flickering may be observed.
>
> [How]
>
> Add a DC feature mask to disable fractional PWM, and associate it with
> the
Hi Rob,
On Tue, Oct 22, 2019 at 03:02:06PM -0500, Rob Herring wrote:
> On Tue, Oct 22, 2019 at 6:30 AM Laurent Pinchart wrote:
> > On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> >> Add support in CMA helpers to handle callers specifying
> >> DRM_MODE_DUMB_KERNEL_MAP flag. Existing
They're midlayer, broken, and because of the old gunk, we can't fix
them. For examples see the various checks in drm_mode_object.c against
dev->registered, which cannot be enforced if the driver still uses the
load hook.
Unfortunately our biggest driver still uses load/unload, so this would
be
Properties can't be attached after registering, userspace would get
confused (no one bothers to reprobe really).
- Add kerneldoc
- Enforce this with some checks. This needs a somewhat ugly check
since connectors can be added later on, but we still need to attach
all properties before they go
On Wed, Oct 23, 2019 at 11:16 AM Adam Ford wrote:
> What is the plan to address the regression for 5.4? I wasn't sure if
> we're going to apply the i.mx fixes or temporarily revert the
> offending patch, or something else. (or maybe nothing at all)
Yes, I do see the regression on a imx53 board
Hi Rob,
On Tue, Oct 22, 2019 at 07:42:06AM -0500, Rob Herring wrote:
> On Tue, Oct 22, 2019 at 6:14 AM Laurent Pinchart wrote:
> > On Mon, Oct 21, 2019 at 04:45:46PM -0500, Rob Herring wrote:
> > > Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> > > drm_mode_create_dumb. This flag is
https://bugs.freedesktop.org/show_bug.cgi?id=110347
Stefan Springer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Oct 22, 2019 at 11:29:54AM +0200, Bartosz Golaszewski wrote:
> wt., 22 paź 2019 o 10:36 Bartosz Golaszewski napisał(a):
> >
> > From: Bartosz Golaszewski
> >
> > While working on my other series related to gpio-backlight[1] I noticed
> > that we could simplify the driver if we made the
On Fri, Oct 18, 2019 at 4:36 AM Michal Vokáč wrote:
>
> On 17. 10. 19 19:44, Adam Ford wrote:
> > On Thu, Oct 17, 2019 at 12:13 PM Thierry Reding
> > wrote:
> >>
> >> On Thu, Oct 17, 2019 at 12:07:21PM -0500, Adam Ford wrote:
> >>> On Thu, Oct 17, 2019 at 10:14 AM Thierry Reding
> >>> wrote:
>
On Sun, Feb 24, 2019 at 06:34:05PM +0300, Dmitry Osipenko wrote:
> Tiling modifier can't be applied to YV12 video overlay because all tiling
> modifiers are filtered out for multi-plane formats. AFAIK, all modifiers
> should work with all of formats, hence the checking is incorrect and
> simply
https://bugs.freedesktop.org/show_bug.cgi?id=109887
Stefan Springer changed:
What|Removed |Added
Summary|vega56 |[Vega10][powerplay] P7 gets
On Wed, Oct 23, 2019 at 11:23:11AM -0300, Fabio Estevam wrote:
> On Wed, Oct 23, 2019 at 11:16 AM Adam Ford wrote:
>
> > What is the plan to address the regression for 5.4? I wasn't sure if
> > we're going to apply the i.mx fixes or temporarily revert the
> > offending patch, or something else.
On 2019-10-23 10:19 a.m., Lukáš Krejčí wrote:
> On Mon, 2019-10-21 at 15:44 -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> [Why]
>>
>> Some LED panel drivers might not like fractional PWM. In such cases,
>> backlight flickering may be observed.
>>
>> [How]
>>
>> Add a DC feature mask to
https://bugzilla.kernel.org/show_bug.cgi?id=204241
David (dav@gmx.com) changed:
What|Removed |Added
CC||dav@gmx.com
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=204965
David (dav@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
On Wed, Oct 23, 2019 at 11:32:16AM +0200, Christian König wrote:
> Am 23.10.19 um 11:08 schrieb Daniel Vetter:
> > On Tue, Oct 22, 2019 at 03:01:13PM +, Jason Gunthorpe wrote:
> > > On Tue, Oct 22, 2019 at 09:57:35AM +0200, Daniel Vetter wrote:
> > >
> > > > > The unusual bit in all of this
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #132 from Jaap Buurman ---
Many people are experiencing the hangs with OpenGL: Quake with the OpenGL
renderer, Chrome/Chromium, Firefox, etc.
I am beginning to suspect that RadeonSI might be to blame instead of the AMDGPU
kernel
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #133 from Shmerl ---
(In reply to Jaap Buurman from comment #132)
>
> I am beginning to suspect that RadeonSI might be to blame instead of the
> AMDGPU kernel driver. Does anyone agree with that notion?
That's my suspicion as well,
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #136 from Jaap Buurman ---
Has anyone tried AMD's closed source OpenGL driver to see if that one is
stable?
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #137 from Alexandr Kára ---
It hangs reproducibly with RADV (Vulkan) as well. As an example, many people
report crashes with Return of the Tomb Raider.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #128 from yam...@yamagi.org ---
(In reply to yamagi from comment #124)
> Interestingly I've got the problem the other way round. My 5700XT was
> running fine since I got it about two weeks ago. This is Arch Linux, I've
> run Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #129 from yam...@yamagi.org ---
Created attachment 145799
--> https://bugs.freedesktop.org/attachment.cgi?id=145799=edit
sdma0 after apitrace crash
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #130 from yam...@yamagi.org ---
Created attachment 145800
--> https://bugs.freedesktop.org/attachment.cgi?id=145800=edit
sdma0 after q2 crash
--
You are receiving this mail because:
You are the assignee for the
On Tue, Oct 22, 2019 at 12:07 PM Matthias Brugger
wrote:
>
> Hi Rob,
>
> On 21/10/2019 23:45, Rob Herring wrote:
> > The only reason the Mediatek driver doesn't use the CMA helpers is it
> > sets DMA_ATTR_NO_KERNEL_MAPPING and does a vmap() on demand. Using
> > vmap() is not even guaranteed to
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #135 from Shmerl ---
(In reply to Benjamin Neff from comment #134)
>
> I don't know if OpenGL is involved in all of my freezes, I had freezes while
> watching a video on youtube in chromium, also while just browsing the web in
>
On Wed, Oct 23, 2019 at 10:49 AM Steven Price wrote:
>
> On 23/10/2019 13:21, Tomeu Vizoso wrote:
> > When deferring the probe because of a missing regulator, we were calling
> > pm_runtime_disable even if pm_runtime_enable wasn't called.
> >
> > Move the call to pm_runtime_disable to the right
Place the declaration of struct nouveau_conn_atom above that of
struct nouveau_connector. This commit makes no changes to the moved
block what so ever, it just moves it up a bit.
This is a preparation patch to fix some issues with connector handling
on pre nv50 displays (which do not use atomic
We do not support atomic modesetting on pre-nv50 hardware, but until now
our connector code was setting drm_connector->state on pre-nv50 hardware.
This causes the core to enter atomic modesetting paths in at least:
1. drm_connector_get_encoder(), returning connector->state->best_encoder
which is
The DSI PHY regulator supports two regulator modes: LDO and DCDC.
This mode can be selected using the "qcom,dsi-phy-regulator-ldo-mode"
device tree property.
However, at the moment only the 20nm PHY driver actually implements
that option. Add a check in the 28nm PHY driver to program the
On Wed, Oct 23, 2019 at 9:28 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> On Tue, Oct 22, 2019 at 07:42:06AM -0500, Rob Herring wrote:
> > On Tue, Oct 22, 2019 at 6:14 AM Laurent Pinchart wrote:
> > > On Mon, Oct 21, 2019 at 04:45:46PM -0500, Rob Herring wrote:
> > > > Introduce a new flag,
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #131 from Shmerl ---
Does it also hang with Mesa master?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #134 from Benjamin Neff ---
I had the freeze with different versions of mesa-git, but I didn't update that
since two days, I can try with the current master and see if it still freezes.
I don't have a way to reproduce it, it is
On Wed, Oct 23, 2019 at 11:16:01AM +0200, Daniel Vetter wrote:
> On Tue, Oct 22, 2019 at 10:53:57PM -0500, Navid Emamdoost wrote:
> > On Tue, Oct 22, 2019 at 4:36 AM Daniel Vetter wrote:
> > >
> > > On Mon, Oct 21, 2019 at 01:52:49PM -0500, Navid Emamdoost wrote:
> > > > In the impelementation of
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #146 from Shmerl ---
You can also use Your $HOME/.profile for setting session wide variables.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Hi, Rob:
On Wed, 2019-10-23 at 12:42 -0500, Rob Herring wrote:
> On Tue, Oct 22, 2019 at 12:07 PM Matthias Brugger
> wrote:
> >
> > Hi Rob,
> >
> > On 21/10/2019 23:45, Rob Herring wrote:
> > > The only reason the Mediatek driver doesn't use the CMA helpers is it
> > > sets
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #148 from Shmerl ---
(In reply to Daniel Suarez from comment #147)
>
> You shouldn't be using a 5700 XT in a system that demands 100% uptime, I
> have had mine randomly hang in the night without Firefox even being open,
> only
From: Sean Paul
These formats are handled in the rdma code, but for some reason they're
not published as supported formats for the planes. So add them to the
list.
Cc: Nicolas Boichat
Cc: Daniele Castagna
Cc: Miguel Casas
Tested-by: Miguel Casas
Signed-off-by: Sean Paul
---
1 - 100 of 182 matches
Mail list logo
