Hi John,
On Tue, 22 Oct 2019 at 00:33, John Stultz wrote:
>
> Lucky number 13! :)
>
> Last week in v12 I had re-added some symbol exports to support
> later patches I have pending to enable loading heaps from
> modules. He reminded me that back around v3 (its been awhile!) I
> had removed those
The CMDQ (Command Queue) in MT8183 is used to help
update all relevant display controller registers
with critical time limation.
This patch add cmdq interface in ddp_comp interface,
let all ddp_comp interface can support cpu/cmdq function
at the same time.
This patch depends on ptach:
add drm
In order to commit state asynchronously, we change
.atomic_commit to drm_atomic_helper_commit().
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 11
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 86 ++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7
Support to async updates of cursors by using the new atomic
interface for that.
Signed-off-by: Bibby Hsieh
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 32 +
drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 ++
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 44
On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
> 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
On Thu, Oct 24, 2019 at 02:32:14PM +0200, Daniel Vetter wrote:
> On Thu, Oct 24, 2019 at 11:02:40AM +0200, Gerd Hoffmann wrote:
> > On Wed, Oct 23, 2019 at 05:22:26PM -0500, Rob Herring wrote:
> > > Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
> > > introduced a GEM object
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #162 from Shmerl ---
I suppose it's a problem with radeonsi specifically. Hopefully AMD developers
can clarify this.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #161 from b...@thschuetz.de ---
> Regarding this issue, is this issue mostly caused by the amdgpu driver
> itself, or caused by mesa?
I tried to avoid freezes and uninstalled amdgpu, just using the modesetting
driver for X11 - and
On 2019/10/25 上午4:44, Alex Williamson wrote:
On Thu, 24 Oct 2019 11:51:35 +0800
Jason Wang wrote:
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
On 2019/10/25 上午3:54, Alex Williamson wrote:
On Thu, 24 Oct 2019 11:31:04 +0800
Jason Wang wrote:
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
On 2019/10/25 上午4:13, Alex Williamson wrote:
On Thu, 24 Oct 2019 13:46:36 -0600
Alex Williamson wrote:
On Thu, 24 Oct 2019 11:27:36 +0800
Jason Wang wrote:
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
https://bugs.freedesktop.org/show_bug.cgi?id=112124
Bug ID: 112124
Summary: Kingdom Come: Deliverance (DXVK) - kernel performance
regression [Navi] [RADV/ACO]
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #160 from L.S.S. ---
I'll try AMD_DEBUG="nodma,nongg" when I get back.
Regarding this issue, is this issue mostly caused by the amdgpu driver itself,
or caused by mesa? It seems more related to the driver as I have this same
system
Hi Mark,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc4 next-20191024]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify
Hi Dan,
On Thu, 24 Oct 2019 23:53:06 +0300 Dan Carpenter
wrote:
>
> Originally this error path used to leak "bin" but then we accidentally
> applied two separate commits to fix it and ended up with a double free.
>
> Signed-off-by: Dan Carpenter
> ---
> Hi Stephen,
>
> I think this one is
https://bugs.freedesktop.org/show_bug.cgi?id=107139
ashutosh.di...@intel.com changed:
What|Removed |Added
QA Contact||intel-gfx-bugs@lists.freede
https://bugs.freedesktop.org/show_bug.cgi?id=107139
--- Comment #3 from ashutosh.di...@intel.com ---
Bug assessment: The IGT submits batch buffers both before and after hibernating
the system and ensures they complete successfully. This bug has not been
updated in over a year. The system is a KBL
Originally this error path used to leak "bin" but then we accidentally
applied two separate commits to fix it and ended up with a double free.
Signed-off-by: Dan Carpenter
---
Hi Stephen,
I think this one is actually just a linux-next issue and the Fixes tag
would point to commit f8593384f83f
On Thu, 24 Oct 2019 11:51:35 +0800
Jason Wang wrote:
> 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.
> >>
> >>
On Thu, 24 Oct 2019 13:46:36 -0600
Alex Williamson wrote:
> On Thu, 24 Oct 2019 11:27:36 +0800
> Jason Wang wrote:
>
> > 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
Problem:
When run_job fails and HW fence returned is NULL we still signal
the s_fence to avoid hangs but the user has no way of knowing if
the actual HW job was ran and finished.
Fix:
Allow .run_job implementations to return ERR_PTR in the fence pointer
returned and then set this error for
Use ERR_PTR to return back the error happened during amdgpu_ib_schedule.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index
On Thu, 24 Oct 2019 11:31:04 +0800
Jason Wang wrote:
> 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
> >> ---
>
Hi all,
On Thu, 24 Oct 2019 14:49:36 +0200 Daniel Vetter wrote:
>
> Ok adding Stephen. There's a merge conflict between drm-misc-fixes and
> drm-next (I think) and the merge double-added the kfree(bin). See
> above for the relevant sha1. Dave is already on here as a heads-up,
> but also adding
On Thu, 24 Oct 2019 11:27:36 +0800
Jason Wang wrote:
> 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
https://bugzilla.kernel.org/show_bug.cgi?id=205309
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285639
--> https://bugzilla.kernel.org/attachment.cgi?id=285639=edit
kernel .config (kernel 5.4-rc4)
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=205309
--- Comment #1 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 285637
--> https://bugzilla.kernel.org/attachment.cgi?id=285637=edit
dmesg (kernel 5.4-rc4)
--
You are receiving this mail because:
You are watching the assignee of
Hi Rajat,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc4 next-20191024]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option
https://bugzilla.kernel.org/show_bug.cgi?id=205309
Bug ID: 205309
Summary: kmemleak reports various leaks in amdgpu
Product: Drivers
Version: 2.5
Kernel Version: 5.4-rc4
Hardware: x86-64
OS: Linux
Tree:
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #159 from Michael de Lang ---
Thank you for making me look twice at the contents of the variable. Although
the env variable is incorrect, the quotes don't do anything to the contents of
the variable. Rather the error is in that it
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #158 from Konstantin Pereiaslov ---
Also experiencing this with Radeon RX 5700 XT and amdgpu
19.1.0+git1910111930.b467d2~oibaf~b with kernel version 5.3.7-050307-generic
running KDE Neon User edition with latest updates.
Didn't
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, let's always call mmap() object callback with an offset of 0,
https://bugzilla.kernel.org/show_bug.cgi?id=205277
--- Comment #8 from har...@gmx.de ---
I have to agree, the code in its current state, only allows overvolting for dpm
level 7.
Since the highest performance level is the most interesting one, if it comes to
undervolting, energy saving and
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #157 from Marko Popovic ---
(In reply to Michael de Lang from comment #156)
> Just had a hang using 5.4.0-rc3, mesa 19.3~git1910171930.4b458b~oibaf~d,
> AMD_DEBUG="nodma nongg" while using firefox:
>
> Oct 24 16:31:26
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #156 from Michael de Lang ---
Just had a hang using 5.4.0-rc3, mesa 19.3~git1910171930.4b458b~oibaf~d,
AMD_DEBUG="nodma nongg" while using firefox:
Oct 24 16:31:26 oipo-X570-AORUS-ELITE kernel: [27386.467009] broken atomic
modeset
On Thu, Oct 24, 2019 at 06:26:36PM +0530, Jagan Teki wrote:
> On Thu, Oct 17, 2019 at 3:22 PM Maxime Ripard wrote:
> >
> > On Wed, Oct 16, 2019 at 02:19:44PM +0530, Jagan Teki wrote:
> > > On Wed, Oct 16, 2019 at 1:33 PM Maxime Ripard wrote:
> > > >
> > > > On Mon, Oct 14, 2019 at 05:37:50PM
On Thu, Oct 24, 2019 at 01:28:28PM +0530, Jagan Teki wrote:
> On Thu, Oct 17, 2019 at 3:22 PM Maxime Ripard wrote:
> >
> > On Wed, Oct 16, 2019 at 02:19:44PM +0530, Jagan Teki wrote:
> > > On Wed, Oct 16, 2019 at 1:33 PM Maxime Ripard wrote:
> > > >
> > > > On Mon, Oct 14, 2019 at 05:37:50PM
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #155 from jmsharvey...@gmail.com ---
Some observations from me that may point to this being an OpenGL issue:
* Vulkan applications seem to work (mostly). I've not had a crash with the
Dolphin Emulator with the Vulkan backend and
Hi Rajat,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc4 next-20191024]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option
On Wed, Oct 23, 2019 at 08:40:59AM -0700, Mark Salyzyn wrote:
> On 10/23/19 4:56 AM, Jarkko Sakkinen wrote:
> > 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
On Thu, Oct 24, 2019 at 03:26:28PM +0300, Jani Nikula wrote:
> On Wed, 23 Oct 2019, Mark Salyzyn wrote:
> > I will split this between pure and inert documentation/comments for now,
> > with a followup later for the code portion which understandably is more
> > controversial.
>
> Please split
On Sun, 20 Oct 2019 21:17:17 +0800
Changbin Du wrote:
> The 'functions' directive is not only for functions, but also works for
> structs/unions. So the name is misleading. This patch renames it to
> 'identifiers', which specific the functions/types to be included in
> documentation. We keep the
From: Thierry Reding
The ->load() and ->unload() drivers are midlayers and should be avoided
in modern drivers. Fix this by moving the code into the driver ->probe()
and ->remove() implementations, respectively.
v2: kick out conflicting framebuffers before initializing fbdev
Signed-off-by:
On Wed, Oct 23, 2019 at 08:40:59AM -0700, Mark Salyzyn wrote:
> On 10/23/19 4:56 AM, Jarkko Sakkinen wrote:
> > 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
On Thu, Oct 24, 2019 at 05:20:32PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 24, 2019 at 03:54:41PM +0200, Thierry Reding wrote:
> > On Thu, Oct 24, 2019 at 02:34:00PM +0300, Ville Syrjälä wrote:
> > > On Thu, Oct 24, 2019 at 12:31:06PM +0200, Thierry Reding wrote:
> > > > On Wed, Oct 23, 2019 at
On Thu, Oct 24, 2019 at 07:31:19PM +0300, Dmitry Osipenko wrote:
> 24.10.2019 19:21, Dmitry Osipenko пишет:
> > 24.10.2019 19:09, Dmitry Osipenko пишет:
> >> 24.10.2019 18:57, Dmitry Osipenko пишет:
> >>> 24.10.2019 18:56, Thierry Reding пишет:
> On Thu, Oct 24, 2019 at 06:47:23PM +0300,
On Thu, Oct 24, 2019 at 12:31:06PM +0200, Thierry Reding wrote:
> On Wed, Oct 23, 2019 at 05:00:41PM -0700, Manasi Navare wrote:
> > 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
On Thu, Oct 24, 2019 at 06:07:54PM +0200, Daniel Vetter wrote:
> On Thu, Oct 24, 2019 at 05:10:30PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The ->load() and ->unload() drivers are midlayers and should be avoided
> > in modern drivers. Fix this by moving the code into the
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #154 from L.S.S. ---
I'm not sure about how to locally pipe dmesg log to file so the moment when the
system freezes could be captured.
And interestingly, the GCVM_L2_PROTECTION_FAULT errors that I saw from
journalctl when it froze
From: Thierry Reding
So far the pad clock was only needed on the second SOR instance. The
clock does exist for all SOR instances, though, so make sure it is
always implemented. This prepares for further unification of the code
in subsequent patches.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
Store capabilities in max_* fields and add separate fields for the
currently selected settings.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c| 16 +++-
drivers/gpu/drm/tegra/dp.h| 15 ++-
drivers/gpu/drm/tegra/dpaux.c | 8
From: Thierry Reding
While probing the DisplayPort link, query the fast training capability.
If supported, drivers can use the fast link training sequence instead of
the more involved full link training sequence.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 3 +++
From: Thierry Reding
Parses additional link rates from DPCD if the sink supports eDP 1.4.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 127 +
drivers/gpu/drm/tegra/dp.h | 9 +++
2 files changed, 136 insertions(+)
diff --git
From: Thierry Reding
Make use of the DP link training helpers to implement full and fast link
training. While at it, refactor some of the code and remove various code
sequences that are not necessary.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dpaux.c | 69
From: Thierry Reding
The SOR found on Tegra SoCs does not support all the rates potentially
advertised by eDP 1.4. Make sure that the rates that are not supported
are filtered out.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 26 ++
1 file changed,
From: Thierry Reding
When the SOR is disabled in DP mode as part of an unplug event, do not
attempt to power the DP link down. Powering down the link requires the
DPAUX to transmit AUX messages which only works if there's a connected
sink.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
Add a helper that will perform link training as described in the
DisplayPort specification.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 456 +
drivers/gpu/drm/tegra/dp.h | 68 ++
2 files changed, 524
From: Thierry Reding
If the sink supports eDP, read the eDP revision from it's DPCD.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 18 --
drivers/gpu/drm/tegra/dp.h | 2 ++
2 files changed, 18 insertions(+), 2 deletions(-)
diff --git
From: Thierry Reding
Reuse parameters from earlier generations to support DisplayPort on
Tegra194.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index
From: Thierry Reding
The device tree bindings for the Tegra210 SOR don't require the
controller instance to be defined, since the instance can be derived
from the compatible string. The index is never used on Tegra210, so we
got away with it not getting set. However, subsequent patches will
From: Thierry Reding
The code to enable audio support is split into two parts, one being
generic for the SOR and another part that is specific whether the SOR is
in HDMI mode or in DP mode. Split out the common part in preparation for
reusing the code in DP mode.
Signed-off-by: Thierry Reding
From: Thierry Reding
In order to support different modes (DP in addition to HDMI), split out
the audio setup/teardown into callbacks.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git
From: Thierry Reding
Parse from the sink capabilities whether or not it supports ANSI 8B/10B
channel coding as specified in ANSI X3.230-1994, clause 11.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 3 +++
drivers/gpu/drm/tegra/dp.h | 7 +++
2 files changed, 10
From: Thierry Reding
Use existing parsing helpers to probe a DisplayPort link.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
index
From: Thierry Reding
If the sink is eDP and supports the alternate scrambler reset, enable
it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
index
From: Thierry Reding
Rework eDP code to correspond more closely to what's documented. This
also improves the reliability of modesets.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 138 +---
1 file changed, 49 insertions(+), 89 deletions(-)
From: Thierry Reding
This is necessary for the output abstraction to retrieve a list of valid
modes from the EDID of a connected panel/monitor. This will be useful in
conjunction with DisplayPort support that will be added in a subsequent
patch, so that the driver can read EDID via the AUX
From: Thierry Reding
The SOR0 on Tegra210 does, contrary to what was previously assumed, in
fact support DisplayPort. The difference between SOR0 and SOR1 is that
the latter supports audio and HDCP over DP, whereas the former doesn't.
The code for eDP and DP is now almost identical and the
From: Thierry Reding
Add support for regular DisplayPort on Tegra210 and Tegra186.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 10 +-
drivers/gpu/drm/tegra/sor.c | 343 +++-
drivers/gpu/drm/tegra/sor.h | 1 +
3 files changed, 348
From: Thierry Reding
With the clocks modelled consistently across SoC generations, the clock
setup for eDP, HDMI and DP can now be unified.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 92 -
1 file changed, 81 insertions(+), 11
From: Thierry Reding
The correct I/O pad needs to be powered up before DP can be used. Make
sure the correct default is set for Tegra generations where the I/O pad
cannot be derived from the SOR instance.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 1 +
1 file changed, 1
From: Thierry Reding
It turns out that SOR1 is just another instance of the same block as the
SOR0, so there is no need to distinguish them.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/sor.c | 18 --
1 file changed, 18 deletions(-)
diff --git
From: Thierry Reding
The connector type detection code is duplicated in two places. Keeping
both places in sync is an extra maintenance burden that can be avoided
by comparing the connector type operations that are set upon the first
detection.
Signed-off-by: Thierry Reding
---
From: Thierry Reding
Store the AUX read interval from DPCD, so that it can be used to wait
for the durations given in the specification during link training.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 31 +++
drivers/gpu/drm/tegra/dp.h | 11
From: Thierry Reding
This helper chooses an appropriate configuration, according to the
bitrate requirements of the video mode and the capabilities of the
DisplayPort sink.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 55 ++
From: Thierry Reding
Parse from the sink capabilities whether or not the eDP alternate
scrambler reset value of 0xfffe is supported.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 5 +
drivers/gpu/drm/tegra/dp.h | 7 +++
2 files changed, 12 insertions(+)
diff --git
From: Thierry Reding
Make use of ANSI 8B/10B channel coding if the DisplayPort sink supports
it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
From: Thierry Reding
Rather than storing capabilities as flags in an integer, use a separate
boolean per capability. This simplifies the code that checks for these
capabilities.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 18 +++---
drivers/gpu/drm/tegra/dp.h
From: Thierry Reding
This set of patches build on top of the existing eDP support that exists
for Tegra124 and extends it with full DP support on Tegra210, Tegra186
and Tegra194. After the series, the eDP code is unified with the DP code
and only parameterized where necessary.
Thierry
Thierry
From: Thierry Reding
The TPS3 capability can be exposed by DP 1.2 and later sinks if they
support the alternative training pattern for channel equalization.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 3 +++
drivers/gpu/drm/tegra/dp.h | 7 +++
2 files changed, 10
From: Thierry Reding
The drm_dp_link structure tracks capabilities on the DP link. Add some
kerneldoc to explain what each of its fields means.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dp.h
From: Thierry Reding
Subsequent patches will add non-volatile fields to struct drm_dp_link,
so introduce a function to zero out only the volatile fields.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/dp.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff
https://bugzilla.kernel.org/show_bug.cgi?id=201957
--- Comment #15 from Konstantin Pereiaslov (per...@perk11.info) ---
My kernel version is 5.3.7-050307-generic running KDE Neon User edition with
latest updates.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201957
Konstantin Pereiaslov (per...@perk11.info) changed:
What|Removed |Added
CC|
drm_sched_cleanup_jobs() attempts to free finished jobs, however because
it is called as the condition of wait_event_interruptible() it must not
sleep. Unfortuantly some free callbacks (notibly for Panfrost) do sleep.
Instead let's rename drm_sched_cleanup_jobs() to
drm_sched_get_cleanup_job()
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #153 from Marko Popovic ---
(In reply to L.S.S. from comment #152)
> UPDATE: I just got another freeze on 5.3.6 kernel. The same
> GCVM_L2_PROTECTION_FAULT error followed by a ring sdma0 timeout.
>
> So it seems AMD_DEBUG="nodma
https://bugzilla.kernel.org/show_bug.cgi?id=205277
Pelle van Gils (pe...@vangils.xyz) changed:
What|Removed |Added
Kernel Version|5.4.0-rc3 |5.4.0-rc4
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=205277
--- Comment #7 from Pelle van Gils (pe...@vangils.xyz) ---
(In reply to haro41 from comment #3)
> Did you debug this issue? I think the problem could be outside this code.
>
> I would outcomment the if-statement following for-loop in your
On Thu, Oct 24, 2019 at 05:10:30PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> The ->load() and ->unload() drivers are midlayers and should be avoided
> in modern drivers. Fix this by moving the code into the driver ->probe()
> and ->remove() implementations, respectively.
>
>
https://bugzilla.kernel.org/show_bug.cgi?id=205277
--- Comment #6 from Pelle van Gils (pe...@vangils.xyz) ---
Created attachment 285633
--> https://bugzilla.kernel.org/attachment.cgi?id=285633=edit
proposed patch v2
--
You are receiving this mail because:
You are watching the assignee of the
On Thu, Oct 24, 2019 at 05:17:37PM +0200, Geert Uytterhoeven wrote:
> Fix misspellings of "connector" and "connection"
>
> Signed-off-by: Geert Uytterhoeven
Thanks, applied to drm-misc-next.
-Daniel
> ---
> drivers/gpu/drm/gma500/mdfld_dsi_output.c | 2 +-
> include/uapi/drm/exynos_drm.h
On Thu, Oct 24, 2019 at 06:47:23PM +0300, Dmitry Osipenko wrote:
> 24.10.2019 16:50, Thierry Reding пишет:
> > On Thu, Oct 24, 2019 at 04:28:41PM +0300, Dmitry Osipenko wrote:
> >> 24.10.2019 14:58, Thierry Reding пишет:
> >>> On Sun, Jun 23, 2019 at 08:37:42PM +0300, Dmitry Osipenko wrote:
>
Hi Dave & Daniel,
Here's the pull for last week and this week. As you know we had some trouble
with the OMAP_BO* additions last week, those have since been reverted.
Speaking of UAPI, we have a new DRM_SYNCOBJ_QUERY_FLAGS_LAST_SUBMITTED flag from
AMD to get the last signaled timeline value from
On Thu, Oct 24, 2019 at 09:51:04AM -0500, Rob Herring wrote:
> On Thu, Oct 24, 2019 at 9:22 AM Ayan Halder wrote:
Hi Bob,
Thanks for your quick response.
> >
> >
> > Hi Folks,
> >
> > I have a question regarding "reserved-memory". I am using an Arm Juno
> > platform which has a chunk of ram in
From: Thierry Reding
The ->load() and ->unload() drivers are midlayers and should be avoided
in modern drivers. Fix this by moving the code into the driver ->probe()
and ->remove() implementations, respectively.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 386
On 2019-10-23 8:00 p.m., Manasi Navare wrote:
> 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
On Thu, Oct 24, 2019 at 4:39 PM Rob Herring wrote:
>
> On Thu, Oct 24, 2019 at 7:32 AM Daniel Vetter wrote:
> >
> > On Thu, Oct 24, 2019 at 11:02:40AM +0200, Gerd Hoffmann wrote:
> > > On Wed, Oct 23, 2019 at 05:22:26PM -0500, Rob Herring wrote:
> > > > Commit c40069cb7bd6 ("drm: add mmap() to
https://bugzilla.kernel.org/show_bug.cgi?id=205277
--- Comment #5 from har...@gmx.de ---
In the (now obsolete) proposed code, the variable 'i' will become 8, when the
for-loop is done. The following if-statement will access something outside the
array memory.
Something like this may work
On Thu, Oct 24, 2019 at 9:22 AM Ayan Halder wrote:
>
>
> Hi Folks,
>
> I have a question regarding "reserved-memory". I am using an Arm Juno
> platform which has a chunk of ram in its fpga. I intend to make this
> memory as reserved so that it can be shared between various devices
> for passing
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/udl/udl_drv.c | 3 +
drivers/gpu/drm/udl/udl_drv.h | 4 -
drivers/gpu/drm/udl/udl_fb.c | 263 +-
drivers/gpu/drm/udl/udl_main.c| 2 -
drivers/gpu/drm/udl/udl_modeset.c | 3 +-
5 files
1 - 100 of 185 matches
Mail list logo
