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
On 2019/10/24 上午5:57, Alex Williamson wrote:
On Wed, 23 Oct 2019 21:07:50 +0800
Jason Wang wrote:
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
On Wed, Oct 23, 2019 at 8:22 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
>
On 2019/10/24 上午5:42, Alex Williamson wrote:
On Wed, 23 Oct 2019 21:07:48 +0800
Jason Wang wrote:
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 +++
On 2019/10/24 上午5:42, Alex Williamson wrote:
On Wed, 23 Oct 2019 21:07:47 +0800
Jason Wang wrote:
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
Hi Dave, Daniel,
Fixes for 5.4 for amdgpu.
The following changes since commit 5c1e34b5159ec65bf33e2c1a62fa7158132c10cf:
Merge tag 'drm-misc-fixes-2019-10-17' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes (2019-10-18 06:40:28
+1000)
are available in the Git repository at:
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #120 from bl...@yahoo.com ---
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 for some reason.
Example: GW2 (DX9 game)
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #149 from Seba Pe ---
(In reply to Jaap Buurman from comment #136)
> Has anyone tried AMD's closed source OpenGL driver to see if that one is
> stable?
I've been running AMDGPU-PRO without issues while waiting for a fix for this
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stripped out of amdgpu's function
On Wed, Oct 23, 2019 at 4:06 PM CK Hu wrote:
>
> 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
Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
introduced a GEM object mmap() hook which is expected to subtract the
fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
a fake offset. To fix this, we need to add the fake offset just like the
On Wed, 23 Oct 2019 21:07:50 +0800
Jason Wang wrote:
> 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 +
>
On Wed, 23 Oct 2019 21:07:48 +0800
Jason Wang wrote:
> 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
On Wed, 23 Oct 2019 21:07:47 +0800
Jason Wang wrote:
> 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #147 from Daniel Suarez ---
(In reply to Jaap Buurman from comment #144)
> I need as close as 100% uptime on this machine as possible, so I don't
> really have the time to add applications over time until the problem is
> fixed. I
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
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #145 from Shmerl ---
According to
man environment
The /etc/environment file specifies the environment variables to be set. The
file must consist of simple NAME=VALUE pairs on separate lines.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #144 from Jaap Buurman ---
I need as close as 100% uptime on this machine as possible, so I don't really
have the time to add applications over time until the problem is fixed. I need
stability now. So a systemwide setting is fine
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #143 from Shmerl ---
(In reply to Jaap Buurman from comment #142)
> How can I set both AMD_DEBUG=nongg and AMD_DEBUG=nodma in the
> /etc/environment file? Do they need to be on two separate lines, or will the
> second line simply
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #142 from Jaap Buurman ---
How can I set both AMD_DEBUG=nongg and AMD_DEBUG=nodma in the /etc/environment
file? Do they need to be on two separate lines, or will the second line simply
overwrite the first one by setting the same
On Mon, Oct 21, 2019 at 07:06:00PM +, Jason Gunthorpe wrote:
> On Mon, Oct 21, 2019 at 02:40:41PM -0400, Jerome Glisse wrote:
> > On Tue, Oct 15, 2019 at 03:12:27PM -0300, Jason Gunthorpe wrote:
> > > From: Jason Gunthorpe
> > >
> > > 8 of the mmu_notifier using drivers (i915_gem, radeon_mn,
On Tue, Jul 30, 2019 at 9:22 AM Chunming Zhou wrote:
>
>
> 在 2019/7/30 21:17, Koenig, Christian 写道:
> > Am 30.07.19 um 15:02 schrieb Chunming Zhou:
> >> user space needs a flexiable query ability.
> >> So that umd can get last signaled or submitted point.
> >> v2:
> >> add sanitizer checking.
>
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #141 from Pierre-Eric Pelloux-Prayer
---
Thanks for the quake 2 trace, I could reproduce the same hang here.
If anyone has a reliable way to trigger the issue, the most helpful thing to do
for now is an apitrace capture.
The umr
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #140 from Shmerl ---
For individual games, I recommend opening separate bugs for each title.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #139 from Daniel Suarez ---
I get instant hangs when playing Space Engineers, the moment I load into a
world it completely hands my system, cannot even enter TTY.
Tested with Manjaro and Mesa-git along with all the other packages
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
---
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #138 from Shmerl ---
(In reply to Alexandr Kára from comment #137)
> It hangs reproducibly with RADV (Vulkan) as well. As an example, many people
> report crashes with Return of the Tomb Raider.
It could be a bug in radv as well
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
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 #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.___
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
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
>
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
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 #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 #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
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
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 #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
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
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,
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 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://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
> -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;
>
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 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
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
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
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.
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
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)
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
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
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(+)
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
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
*
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
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
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
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
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.
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
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 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
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: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 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.
https://bugs.freedesktop.org/show_bug.cgi?id=109887
Stefan Springer changed:
What|Removed |Added
Summary|vega56 |[Vega10][powerplay] P7 gets
https://bugs.freedesktop.org/show_bug.cgi?id=110347
Stefan Springer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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=109887
Stefan Springer changed:
What|Removed |Added
CC||wsla...@gmail.com
--- Comment #13
https://bugs.freedesktop.org/show_bug.cgi?id=110113
Stefan Springer changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
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
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
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
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
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=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 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:
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
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 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
1 - 100 of 182 matches
Mail list logo
