https://bugzilla.kernel.org/show_bug.cgi?id=203781
sehell...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=111819
--- Comment #10 from Dennis Schridde ---
Created attachment 145562
--> https://bugs.freedesktop.org/attachment.cgi?id=145562=edit
dmesg, with backtraces in DCN
`flatpak run --nodevice=all com.valvesoftware.Steam` also makes Steam start.
https://bugs.freedesktop.org/show_bug.cgi?id=111819
Dennis Schridde changed:
What|Removed |Added
Summary|When starting Atom, Signal |Running apps via Flatpak
https://bugs.freedesktop.org/show_bug.cgi?id=111750
--- Comment #2 from Michael Parker ---
While I can now boot and sign in I am still seeing these types of errors.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=111750
--- Comment #1 from Michael Parker ---
I was seeing this issue. After connecting via ssh I was able to get the error
code and found this post.
In the latest update for Fedora 31 Beta (Sept 27, '19) I had a Mesa update show
up and it is now
The mode_config max width/height values determine the maximum
resolution the pixel reader can handle. But the same values are
used to restrict the size of the framebuffer creation. Hardware's
with scaling blocks can operate on framebuffers larger/smaller than
that of the pixel reader resolutions
Below two discussion threads will provide the context behind this patch.
https://www.spinics.net/lists/dri-devel/msg229070.html
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/
Seperating out the core framework patch from vendor implementation.
Jeykumar
Below two discussion threads will provide the context behind this patch.
https://www.spinics.net/lists/dri-devel/msg229070.html
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/
Seperating out the core framework patch from vendor implementation.
Jeykumar
The mode_config max width/height values determine the maximum
resolution the pixel reader can handle. But the same values are
used to restrict the size of the framebuffer creation. Hardware's
with scaling blocks can operate on framebuffers larger/smaller than
that of the pixel reader resolutions
Below two discussion threads will provide the context behind this patch.
https://www.spinics.net/lists/dri-devel/msg229070.html
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/
Seperating out the core framework patch from vendor implementation.
Jeykumar
Below two discussion threads will provide the context behind this patch.
https://www.spinics.net/lists/dri-devel/msg229070.html
https://lore.kernel.org/linux-arm-msm/db26145b-3f64-a334-f698-76f972332...@baylibre.com/T/
Seperating out the core framework patch from vendor implementation.
Jeykumar
https://bugs.freedesktop.org/show_bug.cgi?id=111847
Bug ID: 111847
Summary: Radeon 7, no audio over hdmi 2.0 4k and accelerated
audio over displayport in fullhd display
Product: DRI
Version: XOrg git
Hardware: Other
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #57 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
Sergey, instead of throwing tantrums why can't you just do what you are asked ?
You present an extremely convoluted set of driver config params and demand from
us resolving
Hi Laurent,
Thanks for the patch.
On Wed, 2019-09-25 at 16:55:42 -0700, Laurent Pinchart wrote:
> From: Hyun Kwon
>
> The Xilinx ZynqMP SoC has a hardened display pipeline named DisplayPort
> Subsystem. It includes a buffer manager, a video pipeline renderer
> (blender), an audio mixer and a
https://bugs.freedesktop.org/show_bug.cgi?id=111846
Bug ID: 111846
Summary: Suspend to RAM cause screen to glitch on navi10
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=111846
Yuxuan Shui changed:
What|Removed |Added
Version|XOrg git|unspecified
--
You are receiving this
On Fri, Sep 27, 2019 at 12:07:37PM +0200, Paul Kocialkowski wrote:
> The Xylon LogiCVC is a display controller implemented as programmable
> logic in Xilinx FPGAs.
>
> Signed-off-by: Paul Kocialkowski
> ---
> .../display/xylon,logicvc-display.yaml| 313 ++
> 1 file
On Fri, Sep 27, 2019 at 11:42 PM Bjorn Helgaas wrote:
>
> [+cc Rafael, Mika, linux-pm]
>
> On Fri, Sep 27, 2019 at 04:44:21PM +0200, Karol Herbst wrote:
> > Fixes runpm breakage mainly on Nvidia GPUs as they are not able to resume.
>
> I don't know what runpm is. Some userspace utility? Module
[+cc Rafael, Mika, linux-pm]
On Fri, Sep 27, 2019 at 04:44:21PM +0200, Karol Herbst wrote:
> Fixes runpm breakage mainly on Nvidia GPUs as they are not able to resume.
I don't know what runpm is. Some userspace utility? Module
parameter?
> Works perfectly with this workaround applied.
>
>
On Wed, Sep 25, 2019 at 04:55:02PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We depend on a specific relationship between the VIC number and the
> index in the CEA mode arrays. Assert that the arrays have the excpected
On Wed, Sep 25, 2019 at 04:55:00PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a second table to the cea modes with VIC >= 193.
>
> Cc: Hans Verkuil
> Cc: Shashank Sharma
> Signed-off-by: Ville Syrjälä
I havent verified the actual timings from the CTA spec, but the logic
to
Can you please use addr2line or gdb to pinpoint where in
drm_sched_increase_karma you hit the NULL ptr ? It looks like the guilty
job, but to be sure.
Andrey
On 9/27/19 4:12 AM, Neil Armstrong wrote:
> Hi Christian,
>
> In v5.3, running dEQP triggers the following kernel crash :
>
> [
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #56 from Sergey Kondakov (virtuous...@gmail.com) ---
(In reply to Alex Deucher from comment #54)
> (In reply to Sergey Kondakov from comment #53)
> > Or any of these ?
> > options amdgpu cik_support=1 si_support=1 msi=1
Hi Dave and Daniel,
This should've gone out yesterday, but apparently I had some issue with my mutt
here.
Anyway, nothing that couldn't wait for rc2
Here goes drm-intel-next-fixes-2019-09-26:
- Fix concurrence on cases where requests where getting retired at same time as
resubmitted to HW
-
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #11 from Michael Haworth ---
Issue is not present in Ubuntu 19.10 beta
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Fri, Sep 27, 2019 at 1:51 PM Rob Herring wrote:
>
> On Wed, Sep 25, 2019 at 01:42:37PM -0500, Adam Ford wrote:
> > This patch adds documentation of device tree bindings for the WVGA panel
> > Logic PD Type 28 display.
> >
> > Signed-off-by: Adam Ford
> > ---
> > V3: Correct build errors from
On Wed, Sep 25, 2019 at 01:42:37PM -0500, Adam Ford wrote:
> This patch adds documentation of device tree bindings for the WVGA panel
> Logic PD Type 28 display.
>
> Signed-off-by: Adam Ford
> ---
> V3: Correct build errors from 'make dt_binding_check'
> V2: Use YAML instead of TXT for binding
The pull request you sent on Fri, 27 Sep 2019 15:18:57 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-09-27
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/289991ce1cac18e7cd489902986ef986baa49568
Thank you!
--
Deet-doot-dot, I am a bot.
On Fri, Sep 27, 2019 at 12:07:36PM +0200, Paul Kocialkowski wrote:
> This series introduces support for the LogiCVC display controller.
> The controller is a bit unusual since it is usually loaded as
> programmable logic on Xilinx FPGAs or Zynq-7000 SoCs.
> More details are presented on the main
On Fri, Sep 27, 2019 at 1:56 PM Harry Wentland wrote:
>
> On 2019-09-26 6:51 p.m., Lyude Paul wrote:
> > We are supposed to be atomic after all. We'll need this in a moment for
> > the next commit.
> >
> > Signed-off-by: Lyude Paul
>
> Reviewed-by: Harry Wentland
>
Applied. Thanks!
Alex
>
On Fri, Sep 27, 2019 at 1:48 PM Harry Wentland wrote:
>
> On 2019-09-26 6:51 p.m., Lyude Paul wrote:
> > Signed-off-by: Lyude Paul
>
> Reviewed-by: Harry Wentland
>
Applied. Thanks!
Alex
> Harry
>
> > ---
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
> > 1 file
Am 27.09.2019 20:07 schrieb Ilia Mirkin :
On Thu, Sep 26, 2019 at 5:44 PM Ben Skeggs wrote:
>
> On Tue, 24 Sep 2019 at 22:19, Christian König
> wrote:
> >
> > Hi guys,
> >
> > while working through more old TTM functionality I stumbled over the
> > io_reserve_lru.
> >
> > Basic idea is that
On Thu, Sep 26, 2019 at 5:44 PM Ben Skeggs wrote:
>
> On Tue, 24 Sep 2019 at 22:19, Christian König
> wrote:
> >
> > Hi guys,
> >
> > while working through more old TTM functionality I stumbled over the
> > io_reserve_lru.
> >
> > Basic idea is that when this flag is set the
On 2019-09-26 6:51 p.m., Lyude Paul wrote:
> We are supposed to be atomic after all. We'll need this in a moment for
> the next commit.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Harry
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 10 +-
> 1 file
On 2019-09-26 6:51 p.m., Lyude Paul wrote:
> Signed-off-by: Lyude Paul
Reviewed-by: Harry Wentland
Harry
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git
Commit 554b3529fe01 ("thermal/drivers/core: Remove the module Kconfig's
option") changed the type of THERMAL from tristate to bool, so
THERMAL || !THERMAL is now always y. Remove the redundant dependency.
Discovered through Kconfiglib detecting a dependency loop. The C tools
simplify the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #22 from mikhail.v.gavri...@gmail.com ---
Created attachment 145557
--> https://bugs.freedesktop.org/attachment.cgi?id=145557=edit
./umr -O many,bits -r *.*.mmCP_ME_HEADER_DUMP
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #21 from mikhail.v.gavri...@gmail.com ---
Created attachment 145556
--> https://bugs.freedesktop.org/attachment.cgi?id=145556=edit
./umr -O many,bits -r *.*.mmCP_PFP_HEADER_DUMP
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #19 from mikhail.v.gavri...@gmail.com ---
Created attachment 145554
--> https://bugs.freedesktop.org/attachment.cgi?id=145554=edit
./umr -O many,bits -r *.*.mmGRBM_STATUS*
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #18 from mikhail.v.gavri...@gmail.com ---
Created attachment 145553
--> https://bugs.freedesktop.org/attachment.cgi?id=145553=edit
./umr -R gfx[.]
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #17 from mikhail.v.gavri...@gmail.com ---
Created attachment 145552
--> https://bugs.freedesktop.org/attachment.cgi?id=145552=edit
./umr -O halt_waves -wa
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #20 from mikhail.v.gavri...@gmail.com ---
Created attachment 14
--> https://bugs.freedesktop.org/attachment.cgi?id=14=edit
./umr -O many,bits -r *.*.mmCP_EOP_*
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #16 from mikhail.v.gavri...@gmail.com ---
Created attachment 145551
--> https://bugs.freedesktop.org/attachment.cgi?id=145551=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111803
--- Comment #15 from mikhail.v.gavri...@gmail.com ---
Created attachment 145550
--> https://bugs.freedesktop.org/attachment.cgi?id=145550=edit
trace-cmd start -e dma_fence -e gpu_scheduler -e amdgpu -v -e
"amdgpu:amdgpu_mm_rreg" -e
On Fri, Sep 27, 2019 at 5:17 AM Kirill A. Shutemov wrote:
>
> > Call it "walk_page_mapping()". And talk extensively about how the
> > locking differs a lot from the usual "walk_page_vma()" things.
>
> Walking mappings of a page is what rmap does. This code thas to be
> integrated there.
Well,
>
> The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
> used in a driver.
>
As far as I can see by your second patch QXL is just using exported
(that is not internal) functions.
Not that the idea of making them internal is bad but this comment is
a wrong statement.
>
On 27/09/2019 18:37, Tero Kristo wrote:
If you can provide details about what clock framework / driver does
wrong (sample clk_set_xyz call sequence, expected results via
clk_get_xyz, and what fails), I can take a look at it. Just reporting
arbitrary display driver issues I won't be able to
On 27/09/2019 16:47, Tomi Valkeinen wrote:
On 27/09/2019 15:33, Adam Ford wrote:
It looks like a bug in omap clock handling.
DSS uses dss1_alwon_fck_3430es2 as fclk. dss1_alwon_fck_3430es2 comes
from dpll4_ck, and there's a divider after the PLL, dpll4_m4_ck.
When the DSS driver sets
On Thu, Sep 26, 2019 at 06:51:07PM -0400, Lyude Paul wrote:
> This commit is seperate from the previous one to make it easier to
> revert in the future. Basically, there's multiple userspace applications
> that interpret possible_crtcs very wrong:
>
>
On 27/09/2019 17:00, Steven Price wrote:
> On 27/09/2019 12:48, Neil Armstrong wrote:
>> Hi,
>>
>> On 27/09/2019 13:27, Neil Armstrong wrote:
>>> Hi Steven,
>>>
>>> Thanks for your prompt reaction !
>>>
>>> On 27/09/2019 12:48, Steven Price wrote:
On 27/09/2019 10:55, Steven Price wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=110674
Anthony Rabbito changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #147 from ReddestDream ---
> Already merged to 5.4. I'll take a look at older kernels as well.
@Alex Deucher Thanks so much for all your help! :)
--
You are receiving this mail because:
You are the assignee for the
On Fri, 27 Sep 2019 at 16:33, Marek Szyprowski wrote:
>
> From: Maciej Falkowski
>
> Convert Samsung 2D Graphics Accelerator to newer dt-schema format
>
> Signed-off-by: Maciej Falkowski
> ---
> v3:
> - Merged two if-statements with single if-else statement
> - Added 'additionalProperties:
On 27/09/2019 12:48, Neil Armstrong wrote:
> Hi,
>
> On 27/09/2019 13:27, Neil Armstrong wrote:
>> Hi Steven,
>>
>> Thanks for your prompt reaction !
>>
>> On 27/09/2019 12:48, Steven Price wrote:
>>> On 27/09/2019 10:55, Steven Price wrote:
>>> [...]
One obvious issue with the DRM scheduler
On Fri, 27 Sep 2019 at 16:33, Marek Szyprowski wrote:
>
> From: Maciej Falkowski
>
> Convert Samsung Image Scaler to newer dt-schema format.
>
> Signed-off-by: Maciej Falkowski
> Signed-off-by: Marek Szyprowski
> ---
> v3:
> - Fixed description of 'clocks' property:
> rather than 'mscl clock',
On Tue, Sep 03, 2019 at 04:46:05PM -0400, Lyude Paul wrote:
> For very subtle mistakes with topology refs, it can be rather difficult
> to trace them down with the debugging info that we already have. I had
> one such issue recently while trying to implement suspend/resume
> reprobing for MST, and
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #146 from Alex Deucher ---
(In reply to tom91136 from comment #145)
> @Alex any plans for the patches to be merged for 5.4 or even backported to
> 5.3 at some point?
Already merged to 5.4. I'll take a look at older kernels as
Fixes runpm breakage mainly on Nvidia GPUs as they are not able to resume.
Works perfectly with this workaround applied.
RFC comment:
We are quite sure that there is a higher amount of bridges affected by this,
but I was only testing it on my own machine for now.
I've stresstested runpm by
From: Maciej Falkowski
Convert Samsung Image Scaler to newer dt-schema format.
Signed-off-by: Maciej Falkowski
Signed-off-by: Marek Szyprowski
---
v3:
- Fixed description of 'clocks' property:
rather than 'mscl clock', 'pclk clock'
- Added empty line within if-else statement
- Added
From: Maciej Falkowski
Convert Samsung 2D Graphics Accelerator to newer dt-schema format
Signed-off-by: Maciej Falkowski
---
v3:
- Merged two if-statements with single if-else statement
- Added 'additionalProperties: false'
- Listed all missing 'properties' in properties scope
Best regards,
On 27/09/2019 15:44, Daniel Stone wrote:
Hi Linus,
On Fri, 27 Sep 2019 at 13:37, Linus Walleij wrote:
Also the ILI9322 can actually set up gamma correction which is
very nice for professional applications. I haven't seen any way for
DRM to do gamma correction properly or any framework for it
On Tue, Sep 03, 2019 at 04:46:04PM -0400, Lyude Paul wrote:
> Currently we only print mstb/port pointer addresses in our malloc and
> topology refcount functions using the hashed-by-default %p, but
> unfortunately if you're trying to debug a use-after-free error caused by
> a refcounting error
On Thu, Sep 26, 2019 at 6:52 PM Lyude Paul wrote:
>
> We are supposed to be atomic after all. We'll need this in a moment for
> the next commit.
>
> Signed-off-by: Lyude Paul
Acked-by: Alex Deucher
> ---
> .../drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 10 +-
> 1 file
On Thu, Sep 26, 2019 at 6:52 PM Lyude Paul wrote:
>
> kfree() checks this automatically.
>
> Signed-off-by: Lyude Paul
Reviewed-by: Alex Deucher
And applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 6 ++
> 1 file changed, 2 insertions(+), 4
On 27/09/2019 14:46, Qiang Yu wrote:
> v2:
> use drm_gem_objects_lookup_user instead of
> drm_gem_objects_lookup.
>
> Cc: Eric Anholt
> Signed-off-by: Qiang Yu
Looks familiar :)
Nit: please write a commit message. But otherwise:
Reviewed-by: Steven Price
> ---
>
On 27/09/2019 14:46, Qiang Yu wrote:
> drm_gem_objects_lookup does not use user space bo handles
> directly and left the user to kernel copy work to a new
> interface drm_gem_objects_lookup_user.
>
> This is for driver like lima which does not pass gem bo
> handles continously in an array in
On Tue, Sep 03, 2019 at 04:46:03PM -0400, Lyude Paul wrote:
> Finally! For a very long time, our MST helpers have had one very
> annoying issue: They don't know how to reprobe the topology state when
> coming out of suspend. This means that if a user has a machine connected
> to an MST topology
On Fri, Sep 13, 2019 at 4:45 PM Alex Deucher wrote:
>
> On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul wrote:
> >
> > Currently, every single piece of code in amdgpu that loops through
> > connectors does it incorrectly and doesn't use the proper list iteration
> > helpers,
This prevent CMA printing dumy "PFNs busy" info which is
caused by alloc fail re-try case.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_device.c | 2 +-
drivers/gpu/drm/lima/lima_vm.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git
On 27/09/2019 15:33, Adam Ford wrote:
It looks like a bug in omap clock handling.
DSS uses dss1_alwon_fck_3430es2 as fclk. dss1_alwon_fck_3430es2 comes
from dpll4_ck, and there's a divider after the PLL, dpll4_m4_ck.
When the DSS driver sets dss1_alwon_fck_3430es2 rate to 2700 or
Do not need to maintain our own shmem memory management
code as drm_gem_shmem_helpers provides it. And we can
also benifit from the work of others with shared code.
This is also a preparation for implementing buffer madv.
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/Kconfig | 1
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_gem.c | 64 -
1 file changed, 6 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
index eb70e4429588..3cc1870862c3 100644
---
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/lima/lima_drv.c | 5 ++-
drivers/gpu/drm/lima/lima_gem.c | 73 +++--
2 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/lima/lima_drv.c b/drivers/gpu/drm/lima/lima_drv.c
index
By using shared drm helpers:
1. drm_gem_objects_lookup
2. drm_gem_(un)lock_reservations
3. drm_gem_shmem_helpers
we can simplify lima driver a lot and benifit from updates to
these functions.
drm_gem_objects_lookup need a refine in order to be used by lima.
Note:
1. changes to panfrost and v3d
drm_gem_objects_lookup does not use user space bo handles
directly and left the user to kernel copy work to a new
interface drm_gem_objects_lookup_user.
This is for driver like lima which does not pass gem bo
handles continously in an array in ioctl argument.
v2:
1. add
v2:
use drm_gem_objects_lookup_user instead of
drm_gem_objects_lookup.
Cc: Eric Anholt
Signed-off-by: Qiang Yu
---
drivers/gpu/drm/v3d/v3d_gem.c | 49 +++
1 file changed, 3 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c
On 27/09/2019 15:13, Adam Ford wrote:
On Fri, Sep 27, 2019 at 1:22 AM Tomi Valkeinen wrote:
On 26/09/2019 17:12, Adam Ford wrote:
And what is the hdmi5_configure there? I don't see anything in the
driver that would print hdmi5_configure. And, of course, there's no
hdmi5 on that platform.
On Wed, Sep 25, 2019 at 04:08:22PM -0400, Lyude Paul wrote:
> On Wed, 2019-09-25 at 14:16 -0400, Sean Paul wrote:
> > On Tue, Sep 03, 2019 at 04:45:41PM -0400, Lyude Paul wrote:
> > > When reprobing an MST topology during resume, we have to account for the
> > > fact that while we were suspended
On Wed, Sep 25, 2019 at 05:00:00PM -0400, Lyude Paul wrote:
> On Wed, 2019-09-25 at 15:27 -0400, Sean Paul wrote:
> > On Tue, Sep 03, 2019 at 04:45:54PM -0400, Lyude Paul wrote:
> > > Since we're going to be implementing suspend/resume reprobing very soon,
> > > we need to make sure we are extra
On Wed, Sep 25, 2019 at 5:53 PM Lyude Paul wrote:
>
> Since we're going to be reprobing the entire topology state on resume
> now using sideband transactions, we need to ensure that we actually have
> short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
> So, do that.
>
>
The ttm_mem_io_* functions are actually internal to TTM and shouldn't be
used in a driver.
Instead call the qxl_ttm_io_mem_reserve() function directly.
Signed-off-by: Christian König
---
drivers/gpu/drm/qxl/qxl_drv.h| 2 ++
drivers/gpu/drm/qxl/qxl_object.c | 11 +--
Those are not supposed to be used by drivers.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 086ba2c2f60b..2eca752c39e9 100644
---
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #55 from Tom Seewald (tseew...@gmail.com) ---
(In reply to Sergey Kondakov from comment #53)
> Created attachment 285209 [details]
> dmesg_2019-09-26-amdgpu-old_dereference_on_patched_5.3.1
>
> After about a day of uptime my patched
https://bugzilla.kernel.org/show_bug.cgi?id=204181
--- Comment #54 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Sergey Kondakov from comment #53)
> Or any of these ?
> options amdgpu cik_support=1 si_support=1 msi=1 disp_priority=2 dpm=1
> runpm=1 sched_policy=1 compute_multipipe=1
Hi Linus,
On Fri, 27 Sep 2019 at 13:37, Linus Walleij wrote:
> Also the ILI9322 can actually set up gamma correction which is
> very nice for professional applications. I haven't seen any way for
> DRM to do gamma correction properly or any framework for it
> to adjust and propagate gamma
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)
> > wrote:
> > > Hi Lowry,
> > > On Wed, Sep 25, 2019 at 10:24:58AM
Just a drive-by comment:
On Sat, Aug 24, 2019 at 11:54 AM Sam Ravnborg wrote:
> We will also start to see new drivers where there will be support
> for more than one type of connector interface.
>
> Like for example ili9322:
> - 8-bit serial RGB interface
> - 24-bit parallel RGB interface
>
That is needed by at least a cleanup in radeon.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 3 ++-
include/drm/ttm/ttm_bo_api.h| 2 ++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
Finally clean up the VMA setup for radeon now that TTM exports the
necessary functions.
Not functional change, but only compile tested.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_ttm.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
On Fri, Sep 20, 2019 at 03:11:34PM +, Mihail Atanassov wrote:
> Fix both the string and the struct member being printed.
>
> Fixes: 264b9436d23b ("drm/komeda: Enable writeback split support")
> Signed-off-by: Mihail Atanassov
> ---
>
On Fri, Sep 27, 2019 at 2:55 AM Tomi Valkeinen wrote:
>
> (dropping folks who're probably not interested...)
>
> On 26/09/2019 17:12, Adam Ford wrote:
> > On Thu, Sep 26, 2019 at 1:55 AM Tomi Valkeinen
> > wrote:
> >>
> >> On 25/09/2019 23:51, Adam Ford wrote:
> >>
> Has anyone debugged
On Thu, Sep 26, 2019 at 03:20:42PM -0700, Linus Torvalds wrote:
> On Thu, Sep 26, 2019 at 1:55 PM Thomas Hellström (VMware)
> wrote:
> >
> > Well, we're working on supporting huge puds and pmds in the graphics
> > VMAs, although in the write-notify cases we're looking at here, we would
> >
Am 26.09.19 um 23:44 schrieb Ben Skeggs:
> On Tue, 24 Sep 2019 at 22:19, Christian König
> wrote:
>> Hi guys,
>>
>> while working through more old TTM functionality I stumbled over the
>> io_reserve_lru.
>>
>> Basic idea is that when this flag is set the driver->io_mem_reserve()
>> callback can
On Thu, Sep 26, 2019 at 01:16:55PM -0700, Linus Torvalds wrote:
> On Thu, Sep 26, 2019 at 1:09 PM Thomas Hellström (VMware)
> wrote:
> >
> > That said, if people are OK with me modifying the assert in
> > pud_trans_huge_lock() and make __walk_page_range non-static, it should
> > probably be
On Fri, Sep 27, 2019 at 1:22 AM Tomi Valkeinen wrote:
>
> On 26/09/2019 17:12, Adam Ford wrote:
>
> >> And what is the hdmi5_configure there? I don't see anything in the
> >> driver that would print hdmi5_configure. And, of course, there's no
> >> hdmi5 on that platform. Hmm, ok... it's from
Hi,
On 27/09/2019 13:27, Neil Armstrong wrote:
> Hi Steven,
>
> Thanks for your prompt reaction !
>
> On 27/09/2019 12:48, Steven Price wrote:
>> On 27/09/2019 10:55, Steven Price wrote:
>> [...]
>>> One obvious issue with the DRM scheduler is that there is a call to
>>> cancel_delayed_work()
https://bugs.freedesktop.org/show_bug.cgi?id=111747
--- Comment #9 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- TGL: igt@* -incomplete - Abort requested by .* terminating children -}
{+ TGL: igt@* -incomplete - Abort requested by .* terminating children +}
Hi Steven,
Thanks for your prompt reaction !
On 27/09/2019 12:48, Steven Price wrote:
> On 27/09/2019 10:55, Steven Price wrote:
> [...]
>> One obvious issue with the DRM scheduler is that there is a call to
>> cancel_delayed_work() in drm_sched_stop() which to me looks like it
>> should be
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #19 from Leon ---
By the way, since I have a x470 mb, it cannot be related to PCI express 4.0.
It's also not related to dual displays, since I'm running just one.
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=111482
--- Comment #18 from Leon ---
I have the same problem. Sapphire 5700 XT Nitro, x470 motherboard (asrock
taichi), running arch with kernel 5.3.1. My resolution is 2560x1440 144Hz, with
30Watts idle and 70 Celsius at the memory :( ... Unlike you
1 - 100 of 146 matches
Mail list logo
