On Fri, Oct 04, 2019 at 02:34:42PM +, Mihail Atanassov wrote:
> To support transmitters other than the tda998x, we need to allow
> non-component framework bridges to be attached to a dummy drm_encoder in
> our driver.
>
> For the existing supported encoder (tda998x), keep the behaviour as-is,
On Tue, Oct 08, 2019 at 05:00:46PM +0200, Daniel Vetter wrote:
> On Mon, May 20, 2019 at 5:33 AM Lowry Li (Arm Technology China)
> wrote:
> >
> > - Creates the zpos property.
> > - Implement komeda_crtc_normalize_zpos to replace
> > drm_atomic_normalize_zpos, reasons as the following:
> >
> > 1.
https://bugs.freedesktop.org/show_bug.cgi?id=111922
--- Comment #2 from Pierre Ossman ---
Not easily unfortunately as I've only been using Fedora kernels, so I don't
have a build environment set up.
--
You are receiving this mail because:
You are the assignee for the
Quoting Brian Masney (2019-10-06 18:45:09)
> diff --git a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> b/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> index b607c9ff9e12..380a805cd1f0 100644
> --- a/arch/arm/boot/dts/qcom-msm8974-lge-nexus5-hammerhead.dts
> +++
Quoting Brian Masney (2019-10-06 18:45:08)
> diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
> b/arch/arm/boot/dts/qcom-msm8974.dtsi
> index 7fc23e422cc5..af02eace14e2 100644
> --- a/arch/arm/boot/dts/qcom-msm8974.dtsi
> +++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
> @@ -1335,6 +1342,77 @@
>
On Fri, Sep 27, 2019 at 12:42:13PM +, Liviu Dudau wrote:
> On Fri, Sep 27, 2019 at 02:02:59AM +, james qian wang (Arm Technology
> China) wrote:
> > On Thu, Sep 26, 2019 at 11:51:21AM +, Liviu Dudau wrote:
> > > On Thu, Sep 26, 2019 at 10:00:22AM +, Lowry Li (Arm Technology China)
I didn't have the guts to do this, and I am glad you did it :)
Yuyang
On Fri, 20 Sep 2019 at 00:10, Qian Cai wrote:
>
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_module.c:25:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_priv.h:40:10: fatal error: drm/drmP.h:
No such file or directory
40 |
https://bugs.freedesktop.org/show_bug.cgi?id=111913
--- Comment #9 from Andrew Sheldon ---
(In reply to Stefan Rehm from comment #8)
> In my case the resolution of both monitors is 2560x1440
You could try overclocking (or underclocking) one or both monitors to see if
the bug still exists,
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_gem_gtt.c
between commit:
1e0a96e50882 ("drm/i915: export color_differs")
from the drm tree and commit:
71724f708997 ("drm/mm: Use helpers for drm_mm_node booleans")
from the drm-misc
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_vma.c
between commits:
1e0a96e50882 ("drm/i915: export color_differs")
33dd88992313 ("drm/i915: cleanup cache-coloring")
b290a78b5c3d ("drm/i915: Use helpers for drm_mm_node booleans")
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_gem.c
between commits:
b290a78b5c3d ("drm/i915: Use helpers for drm_mm_node booleans")
2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
from the drm tree and commit:
On Wed, 2 Oct 2019, Krzysztof Kozlowski wrote:
> Convert generic PWM bindings to DT schema format using json-schema. The
> consumer bindings are split to separate file.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
[ ... ]
> diff --git
Neil Armstrong writes:
> Seeing the description, it seems to be a libdrm with steroids,
> why libdrm doesn't handle all this already ?
That'd be a lot of steroids; we're talking about creating helper
functions all the way up to rendering images into scanout buffers
(presumably using Vulkan?)
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.c
between commit:
2d6f6f359fd8 ("drm/i915: add i915_driver_modeset_remove()")
from the drm tree and commit:
f2521f7731ed ("drm/i915: switch to
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
between commit:
8a9a982767b7 ("drm/i915: use a separate context for gpu relocs")
from the drm tree and commit:
4ee92c7149da ("drm/mm: Convert drm_mm_node booleans to
Hi Rob,
On Tue, Oct 8, 2019 at 8:08 PM Rob Clark wrote:
> afaict this should be at least in v5.4-rc2.. am I missing something?
You are right, it is in 5.4-rc indeed, sorry.
It is 5.3.x stable that has this commit missing, but I guess it will
be backported at some point.
Thanks!
On Tue, Oct 8, 2019 at 9:11 AM Fabio Estevam wrote:
>
> Hi Rob,
>
> On Wed, Sep 4, 2019 at 2:19 PM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > Looks like the dma_sync calls don't do what we want on armv7 either.
> > Fixes:
> >
> > Unable to handle kernel paging request at virtual address
On Tue, Oct 8, 2019 at 2:46 PM Rob Herring wrote:
>
> On Tue, Oct 8, 2019 at 10:13 AM Robin Murphy wrote:
> >
> > As brought up on IRC, logging a vague and unattributed message for a
> > normal and expected operation looks a bit spammy. Use a dev_* variant
> > to clarify it as a driver message,
Hi! a couple people poked me to take a look at this, hopefully I can provide
some helpful insight here.
So: I've tried a _lot_ of various redesigns with MST and some portions of the
DP helpers. I actually was going to try to write up some common helpers for
handling link training across drivers,
Add an optional CRTC gamma LUT support, and enable it on RK3288.
This is currently enabled via a separate address resource,
which needs to be specified in the devicetree.
The address resource is required because on some SoCs, such as
RK3288, the LUT address is after the MMU address, and the
Following Sean's comments, here's a new version.
On this new iteration, we modify the GAMMA LUT
on .atomic_enable and .atomic_begin.
With this change, the GAMMA settings are effectively
re-applied after resuming the machine, so the previous
patch "RFC: drm/atomic-helper: Reapply color
RK3288 SoC VOPs have optional support Gamma LUT setting,
which requires specifying the Gamma LUT address in the devicetree.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
---
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, as suggested by Doug.
Add the register specifier description for an
optional gamma LUT address.
Signed-off-by: Ezequiel Garcia
Reviewed-by: Douglas Anderson
Reviewed-by: Rob Herring
---
Changes from v3:
* None.
Changes from v2:
* None.
Changes from v1:
* Drop reg-names, suggested by Doug.
---
On Tue, 2019-10-08 at 16:03 -0400, Sean Paul wrote:
> On Tue, Oct 08, 2019 at 04:33:35PM -0300, Ezequiel Garcia wrote:
> > On Tue, 2019-10-08 at 16:23 -0300, Ezequiel Garcia wrote:
> > > Hello Sean,
> > >
> > > On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> > > > On Mon, Sep 30, 2019 at
On Tue, Oct 8, 2019 at 10:13 AM Robin Murphy wrote:
>
> As brought up on IRC, logging a vague and unattributed message for a
> normal and expected operation looks a bit spammy. Use a dev_* variant
> to clarify it as a driver message, and downgrade the level to debug to
> avoid cluttering up end
On 08.10.2019 12:24, Lyude Paul wrote:
> ...
> yikes
> I need to apologize because I was going through my email and I realized you
> _did_ respond to me earlier regarding some of these questions, it just appears
> the reply fell through the cracks and somehow I didn't notice it until just
> now.
https://bugs.freedesktop.org/show_bug.cgi?id=111933
Bug ID: 111933
Summary: driconf-0.9.1-r2 - assert iter or allowNone
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: not set
Move from the deprecated i2c_new_dummy() to devm_i2c_new_dummy_device().
We now get an ERRPTR which we use in error handling and we can skip
removal of the created devices.
Signed-off-by: Wolfram Sang
---
Rebased to v5.4-rc2 since last time. One of the last two users of the
old API, so please
https://bugs.freedesktop.org/show_bug.cgi?id=111932
Bug ID: 111932
Summary: driconf: TypeError: cannot concatenate 'str' and 'int'
objects
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Move from the deprecated i2c_new_dummy() to i2c_new_dummy_device(). We
now get an ERRPTR which we use in error handling.
Signed-off-by: Wolfram Sang
---
Rebased to v5.4-rc2 since last time. One of the last two users of the
old API, so please apply soon, so I can remove the old interface. Only
Hi All:
drivers/video/fbdev/pm3fb.c:
Inside function pm3fb_write_mode(), variable "m" "n" "p" could leave
uninitialized after pm3fb_calculate_clock(), however, they are used
later in PM3_WRITE_DAC_REG, which is potentially unsafe.
--
Kind Regards,
Yizhuo Zhai
Computer Science, Graduate
https://bugzilla.kernel.org/show_bug.cgi?id=205089
--- Comment #5 from Alex Deucher (alexdeuc...@gmail.com) ---
If you could come up with a reproducible test case, that would help for
tracking down why it's hanging in the first place.
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=205089
--- Comment #4 from Bruno Jacquet (maxi...@free.fr) ---
Okay, I got this, but should I investigate the initial GPU reset cause?
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Tue, Oct 08, 2019 at 04:33:35PM -0300, Ezequiel Garcia wrote:
> On Tue, 2019-10-08 at 16:23 -0300, Ezequiel Garcia wrote:
> > Hello Sean,
> >
> > On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> > > On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> > > > Add an optional
On Tue, Oct 8, 2019 at 12:17 PM Jacek Anaszewski
wrote:
>
> On 10/8/19 5:00 PM, Rob Herring wrote:
> > On Tue, Oct 8, 2019 at 8:30 AM Jean-Jacques Hiblot wrote:
> >>
> >> Rob,
> >>
> >> On 08/10/2019 14:51, Jean-Jacques Hiblot wrote:
> >>> Hi Rob,
> >>>
> >>> On 07/10/2019 18:15, Rob Herring
On Thu 2019-10-03 12:40:28, Lee Jones wrote:
> On Thu, 03 Oct 2019, Jean-Jacques Hiblot wrote:
>
> > This series aims to add a led-backlight driver, similar to pwm-backlight,
> > but using a LED class device underneath.
> >
> > A few years ago (2015), Tomi Valkeinen posted a series implementing
On Tue, 2019-10-08 at 16:23 -0300, Ezequiel Garcia wrote:
> Hello Sean,
>
> On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> > On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> > > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > > This is currently
Hello Sean,
On Mon, 2019-10-07 at 14:54 -0400, Sean Paul wrote:
> On Mon, Sep 30, 2019 at 07:28:00PM -0300, Ezequiel Garcia wrote:
> > Add an optional CRTC gamma LUT support, and enable it on RK3288.
> > This is currently enabled via a separate address resource,
> > which needs to be specified in
On Tue, Oct 08, 2019 at 06:33:51PM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> > Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> > in __lock_release"), @nested is no longer used in lock_release(), so
> > remove it from all
On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> The number of logical gpu (lgpu) is defined to be the number of compute
> unit (CU) for a device. The lgpu allocation limit only applies to
> compute workload for the moment (enforced via kfd queue creation.) Any
> cu_mask update is validated against
https://bugs.freedesktop.org/show_bug.cgi?id=111922
--- Comment #1 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On 2019-08-29 2:05 a.m., Kenny Ho wrote:
> drm.lgpu
> A read-write nested-keyed file which exists on all cgroups.
> Each entry is keyed by the DRM device's major:minor.
>
> lgpu stands for logical GPU, it is an abstraction used to
> subdivide a physical DRM
https://bugzilla.kernel.org/show_bug.cgi?id=205089
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Bruno Jacquet from comment #2)
> If I understand you right this means there is still another issue that
> caused the GPU reset. And this issue in particular is just a
On Tue, Oct 8, 2019 at 1:47 PM Sean Paul wrote:
>
> On Mon, Sep 23, 2019 at 01:59:25AM +, Lowry Li (Arm Technology China)
> wrote:
> > From: "Lowry Li (Arm Technology China)"
> >
> > Adds system power management support in KMS kernel driver.
> >
> > Depends on:
> >
https://bugzilla.kernel.org/show_bug.cgi?id=205089
--- Comment #2 from Bruno Jacquet (maxi...@free.fr) ---
If I understand you right this means there is still another issue that caused
the GPU reset. And this issue in particular is just a consequence of the reset
not being properly handled?
--
On Mon, Sep 23, 2019 at 01:59:25AM +, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Adds system power management support in KMS kernel driver.
>
> Depends on:
> https://patchwork.freedesktop.org/series/62377/
>
> Changes since v1:
> Since we have
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #81 from Shmerl ---
Also opened Firefox specific bug here in case it's radeonsi issue:
https://gitlab.freedesktop.org/mesa/mesa/issues/1910
--
You are receiving this mail because:
You are the assignee for the
On 10/8/19 5:00 PM, Rob Herring wrote:
> On Tue, Oct 8, 2019 at 8:30 AM Jean-Jacques Hiblot wrote:
>>
>> Rob,
>>
>> On 08/10/2019 14:51, Jean-Jacques Hiblot wrote:
>>> Hi Rob,
>>>
>>> On 07/10/2019 18:15, Rob Herring wrote:
Please send DT bindings to DT list or it's never in my queue. IOW,
On 10/8/19 5:00 PM, Rob Herring wrote:
> On Tue, Oct 8, 2019 at 8:30 AM Jean-Jacques Hiblot wrote:
>>
>> Rob,
>>
>> On 08/10/2019 14:51, Jean-Jacques Hiblot wrote:
>>> Hi Rob,
>>>
>>> On 07/10/2019 18:15, Rob Herring wrote:
Please send DT bindings to DT list or it's never in my queue. IOW,
On Fri, 04 Oct 2019, Koenig, Christian wrote:
Am 04.10.19 um 08:57 schrieb Christian König:
Am 03.10.19 um 22:18 schrieb Davidlohr Bueso:
The generic tree tree really wants [a, b) intervals, not fully closed.
As such convert it to use the new interval_tree_gen.h. Most of the
conversions are
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #80 from Shmerl ---
Looks like there are a bunch of fixes related to powerplay here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next
So if anyone has time to test, may be some of them fix that concurrent sensor
access bug
On Mon, Oct 07, 2019 at 07:12:22PM +0200, Sam Ravnborg wrote:
> One user of drmP.h sneaked in after the merge window.
> Drop the use of drmP.h and delete the header file for good.
>
> Small band-aid on top of not going to xdc :-)
>
> Build tested with various architectures and configs.
Applied
From: Ville Syrjälä
Add a function to fill the AVI infoframe bar information from
the standard tv margin properties.
Cc: Eric Anholt
Cc: Boris Brezillon
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 17 +
include/drm/drm_edid.h | 4
2 files changed,
From: Ville Syrjälä
Use the new drm_hdmi_avi_infoframe_bars() helper instead
of hand rolling it.
Cc: Eric Anholt
Cc: Boris Brezillon
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=111921
--- Comment #4 from Andrey Grodzovsky ---
What happens if you disable GPU reset by loading the kernel with
amdgpu.gpu_recovery=0 ?
--
You are receiving this mail because:
You are the assignee for the
On Mon, Sep 30, 2019 at 08:57:32AM +, Koenig, Christian wrote:
> Am 30.09.19 um 09:22 schrieb Daniel Vetter:
> > On Sun, Sep 22, 2019 at 2:08 PM Qiang Yu wrote:
> >> This causes kernel crash when testing lima driver.
> >>
> >> Cc: Christian König
> >> Fixes: b8c036dfc66f ("dma-buf: simplify
On Tue, 2019-10-08 at 12:24 -0400, Lyude Paul wrote:
> ...
> yikes
> I need to apologize because I was going through my email and I realized you
> _did_ respond to me earlier regarding some of these questions, it just
> appears
> the reply fell through the cracks and somehow I didn't notice it
On Mon, Sep 23, 2019 at 09:03:01AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.09.19 um 21:35 schrieb Sean Paul:
> > From: Sean Paul
> >
> > Fixes
> > include/drm/drm_gem_ttm_helper.h:1: warning: no structured comments found
>
> That missing documentation looks like an oversight to me.
>
>
On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all lock_release() calls and friends.
>
> Signed-off-by: Qian Cai
Ack on
On Thu, Sep 26, 2019 at 10:47:35AM +0200, Rohan Garg wrote:
> On viernes, 20 de septiembre de 2019 17:25:10 (CEST) Thierry Reding wrote:
> > On Thu, Sep 19, 2019 at 02:53:21PM +0200, Rohan Garg wrote:
> > > DRM_IOCTL_BO_SET_LABEL lets you label GEM objects, making it
> > > easier to debug issues
...
yikes
I need to apologize because I was going through my email and I realized you
_did_ respond to me earlier regarding some of these questions, it just appears
the reply fell through the cracks and somehow I didn't notice it until just
now. Sorry about that!
I'm still not sure I understand
Hi Rob,
On Wed, Sep 4, 2019 at 2:19 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Looks like the dma_sync calls don't do what we want on armv7 either.
> Fixes:
>
> Unable to handle kernel paging request at virtual address 50001000
> pgd = (ptrval)
> [50001000] *pgd=
> Internal
On 07/10/2019 14:16, Tomi Valkeinen wrote:
On 07/10/2019 14:25, Jean-Jacques Hiblot wrote:
A first version of this work had been sent by Tomi Valkeinen in may 2017
(https://www.spinics.net/lists/dri-devel/msg140663.html).
This series adds a few new OMAP_BO flags to help the userspace manage
On 07/10/2019 13:25, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
On SoCs with DMM/TILER, we have two ways to allocate buffers: normal
dma_alloc or via DMM (which basically functions as an IOMMU). DMM can
map 128MB at a time, and we only map the DMM buffers when they are used
(i.e. not at
On 07/10/2019 13:25, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
Add a helper function omap_gem_validate_flags() which validates the
omap_bo flags passed from the userspace.
Also drop the dev_err() message, as the userspace can cause that at
will.
Signed-off-by: Tomi Valkeinen
---
On 07/10/2019 13:25, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
omap_gem_new() has a comment about OMAP_BO_SCANOUT which does not make
sense. Also, for the TILER case, we drop OMAP_BO_SCANOUT flag for some
reason.
It's not clear what the original purpose of OMAP_BO_SCANOUT is, but
On 07/10/2019 13:25, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
OMAP_BO_TILED does not make sense, as OMAP_BO_TILED_* values are not
bitmasks but normal values. As we already have OMAP_BO_TILED_MASK for
the mask, we can remove OMAP_BO_TILED and use OMAP_BO_TILED_MASK
instead.
On 07/10/2019 13:25, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
Reorder OMAP_BO flags and improve the comments.
Signed-off-by: Tomi Valkeinen
---
include/uapi/drm/omap_drm.h | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git
On 07/10/2019 13:25, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
Allow NULL to be passed in 'dma_addr' for omap_gem_pin(), in case the
caller does not need the dma_addr.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 6 --
1 file changed, 4 insertions(+),
On 07/10/2019 13:25, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
Add omap_gem_unpin_locked() which is a version of omap_gem_unpin() that
expects the caller to hold the omap_obj lock.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem.c | 24 +---
1
https://bugs.freedesktop.org/show_bug.cgi?id=111921
--- Comment #3 from Rémi Verschelde ---
I don't reset the GPU manually, no. I'm not sure why this happens, but I've had
such output in dmesg as far as I can remember (since I got this laptop in
March).
For the reference, I've been using kernel
https://bugs.freedesktop.org/show_bug.cgi?id=111913
--- Comment #8 from Stefan Rehm ---
In my case the resolution of both monitors is 2560x1440
--
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=111921
--- Comment #2 from Andrey Grodzovsky ---
Hey, I noticed a lot of 'amdgpu :01:00.0: GPU pci config reset' there.
Since I see no command submissions timeout errors it looks like you manually
tried to reset the GPU multiple times - on one of
On Tuesday, October 8, 2019 6:16 PM, Daniel Vetter wrote:
> On Tue, Oct 8, 2019 at 5:11 PM Simon Ser cont...@emersion.fr wrote:
>
> > On Tuesday, October 8, 2019 6:03 PM, Daniel Vetter dan...@ffwll.ch wrote:
> >
> > > > > > > In any case, this doesn't change the patch itself. Probably
> > > > >
https://bugs.freedesktop.org/show_bug.cgi?id=111922
Bug ID: 111922
Summary: amdgpu fails to resume on 5.2 kernel [regression]
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity:
On Wed, Sep 18, 2019 at 07:55:23PM +0200, Christian König wrote:
> The ww_mutex framework allows for detecting deadlocks when multiple
> threads try to acquire the same set of locks in different order.
>
> The problem is that handling those deadlocks was the burden of the user of
> the ww_mutex
On Tue, Oct 8, 2019 at 5:11 PM Simon Ser wrote:
>
> On Tuesday, October 8, 2019 6:03 PM, Daniel Vetter wrote:
>
> > > > > > In any case, this doesn't change the patch itself. Probably
> > > > > > something worth
> > > > > > mentionning in the commit message.
> > > > >
> > > > > Yes, recording
As brought up on IRC, logging a vague and unattributed message for a
normal and expected operation looks a bit spammy. Use a dev_* variant
to clarify it as a driver message, and downgrade the level to debug to
avoid cluttering up end users' logs.
Signed-off-by: Robin Murphy
---
On Tuesday, October 8, 2019 6:03 PM, Daniel Vetter wrote:
> > > > > In any case, this doesn't change the patch itself. Probably something
> > > > > worth
> > > > > mentionning in the commit message.
> > > >
> > > > Yes, recording these use cases would be very nice.
> > >
> > > There's a lot
On Tue, Oct 08, 2019 at 05:04:56PM +0200, Krzysztof Kozlowski wrote:
> On Tue, Oct 08, 2019 at 09:38:15AM -0500, Rob Herring wrote:
> > Are you running using DT_SCHEMA_FILES? If so, you won't get the core schema.
>
> Ah, yes, now I see proper errors. Thanks for pointing this.
>
> I'll send next
On Tue, Oct 08, 2019 at 09:38:15AM -0500, Rob Herring wrote:
> Are you running using DT_SCHEMA_FILES? If so, you won't get the core schema.
Ah, yes, now I see proper errors. Thanks for pointing this.
I'll send next version of this patch only (if others are ok).
Best regards,
Krzysztof
On Tue, Oct 08, 2019 at 07:49:39PM +0900, Tomasz Figa wrote:
> On Tue, Oct 8, 2019 at 7:03 PM Daniel Vetter wrote:
> >
> > On Sat, Oct 05, 2019 at 02:41:54PM +0900, Tomasz Figa wrote:
> > > Hi Daniel, Gerd,
> > >
> > > On Tue, Sep 17, 2019 at 10:23 PM Daniel Vetter wrote:
> > > >
> > > > On Thu,
On Tue, Oct 8, 2019 at 1:39 PM Pekka Paalanen wrote:
>
> On Tue, 8 Oct 2019 11:59:04 +0200
> Daniel Vetter wrote:
>
> > On Mon, Sep 30, 2019 at 10:07:07AM +0300, Pekka Paalanen wrote:
> > > On Sun, 29 Sep 2019 20:30:44 +
> > > Simon Ser wrote:
> > >
> > > > Hi,
> > > >
> > > > > On Mon, Sep
/snip
> > > > > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > > > > index d16158deacdc..f3587a54b8ac 100644
> > > > > --- a/include/drm/drm_panel.h
> > > > > +++ b/include/drm/drm_panel.h
> > > > > @@ -141,6 +141,56 @@ struct drm_panel {
> > > > >*/
> > > > >
On Mon, May 20, 2019 at 5:33 AM Lowry Li (Arm Technology China)
wrote:
>
> - Creates the zpos property.
> - Implement komeda_crtc_normalize_zpos to replace
> drm_atomic_normalize_zpos, reasons as the following:
>
> 1. The drm_atomic_normalize_zpos allows to configure same zpos for
> different
On Tue, Oct 8, 2019 at 8:30 AM Jean-Jacques Hiblot wrote:
>
> Rob,
>
> On 08/10/2019 14:51, Jean-Jacques Hiblot wrote:
> > Hi Rob,
> >
> > On 07/10/2019 18:15, Rob Herring wrote:
> >> Please send DT bindings to DT list or it's never in my queue. IOW,
> >> send patches to the lists that
On Mon, Oct 07, 2019 at 03:12:00PM -0700, dbasehore . wrote:
> On Mon, Oct 7, 2019 at 9:38 AM Sean Paul wrote:
> >
> > On Wed, Sep 25, 2019 at 03:58:30PM -0700, Derek Basehore wrote:
> > > This adds a helper function for reading the rotation (panel
> > > orientation) from the device tree.
> > >
>
On Tue, Oct 8, 2019 at 7:51 AM Jean-Jacques Hiblot wrote:
>
> Hi Rob,
>
> On 07/10/2019 18:15, Rob Herring wrote:
> > Please send DT bindings to DT list or it's never in my queue. IOW,
> > send patches to the lists that get_maintainers.pl tells you to.
> >
> > On Mon, Oct 7, 2019 at 7:45 AM
On Tue, Oct 8, 2019 at 4:36 PM Alex Deucher wrote:
>
> On Tue, Oct 8, 2019 at 5:32 AM Daniel Stone wrote:
> >
> > Hi,
> >
> > On Mon, 7 Oct 2019 at 19:16, Keith Packard wrote:
> > > Daniel Stone writes:
> > > > I think there would be a load of value in starting with simple helpers
> > > >
On Tue, Oct 8, 2019 at 9:29 AM Krzysztof Kozlowski wrote:
>
> On Tue, Oct 08, 2019 at 09:17:16AM -0500, Rob Herring wrote:
> > On Tue, Oct 8, 2019 at 9:05 AM Rob Herring wrote:
> > >
> > > On Tue, Oct 8, 2019 at 7:50 AM Krzysztof Kozlowski
> > > wrote:
> > > >
> > > > On Tue, Oct 08, 2019 at
On Tue, Oct 8, 2019 at 5:32 AM Daniel Stone wrote:
>
> Hi,
>
> On Mon, 7 Oct 2019 at 19:16, Keith Packard wrote:
> > Daniel Stone writes:
> > > I think there would be a load of value in starting with simple helpers
> > > which can be used independently of any larger scheme, tackling that
> > >
On Tue, Oct 08, 2019 at 09:17:16AM -0500, Rob Herring wrote:
> On Tue, Oct 8, 2019 at 9:05 AM Rob Herring wrote:
> >
> > On Tue, Oct 8, 2019 at 7:50 AM Krzysztof Kozlowski wrote:
> > >
> > > On Tue, Oct 08, 2019 at 07:38:14AM -0500, Rob Herring wrote:
> > > > On Fri, Oct 4, 2019 at 10:14 AM
On 2019-10-08 10:00 a.m., Joe Perches wrote:
> On Tue, 2019-10-08 at 13:56 +, Harry Wentland wrote:
> []
>>> diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
>>> b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
>> []
>>> @@ -2745,7 +2745,7 @@ static enum bp_result
On Tue, Oct 8, 2019 at 9:05 AM Rob Herring wrote:
>
> On Tue, Oct 8, 2019 at 7:50 AM Krzysztof Kozlowski wrote:
> >
> > On Tue, Oct 08, 2019 at 07:38:14AM -0500, Rob Herring wrote:
> > > On Fri, Oct 4, 2019 at 10:14 AM Krzysztof Kozlowski
> > > wrote:
> > > >
> > > > The clkoutN names of
On 08/10/2019 17:13, Tony Lindgren wrote:
* Tomi Valkeinen [190930 10:38]:
If use_mclk is false, mclk_mode is written to a register without
initialization. This doesn't cause any ill effects as the written value
is not used when use_mclk is false.
To fix this, write use_mclk only when
On Tue, Oct 8, 2019 at 7:50 AM Krzysztof Kozlowski wrote:
>
> On Tue, Oct 08, 2019 at 07:38:14AM -0500, Rob Herring wrote:
> > On Fri, Oct 4, 2019 at 10:14 AM Krzysztof Kozlowski wrote:
> > >
> > > The clkoutN names of clocks must be unique because they represent
> > > unique inputs of clock
On Tue, Oct 08, 2019 at 11:50:33AM +0200, Daniel Vetter wrote:
> On Thu, Sep 19, 2019 at 11:04:01AM -0400, Sean Paul wrote:
> > On Thu, Sep 05, 2019 at 12:41:27PM +0200, Daniel Vetter wrote:
> > > On Wed, Sep 4, 2019 at 10:29 PM Sean Paul wrote:
> > > >
> > > > From: Sean Paul
> > > >
> > > >
On Tue, 2019-10-08 at 13:56 +, Harry Wentland wrote:
[]
> > diff --git a/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> > b/drivers/gpu/drm/amd/display/dc/bios/bios_parser.c
> []
> > @@ -2745,7 +2745,7 @@ static enum bp_result bios_get_board_layout_info(
> > struct bios_parser *bp;
>
https://bugs.freedesktop.org/show_bug.cgi?id=111913
--- Comment #7 from Timur Kristóf ---
(In reply to Andrew Sheldon from comment #5)
> Are both monitors 60hz? I've seen this occur with 2x60hz setups, but not
> with other combinations of refresh rates. It seems to be similar to issues
> with
1 - 100 of 186 matches
Mail list logo
