Hi Linus,
Not much happening in fixes land this week only one PR for two amdgpu
powergating fixes was waiting for me, maybe something will show up
over the weekend, maybe not.
Dave.
drm-fixes-2021-06-18:
drm fixes for 5.13-rc7
amdgpu:
- GFX9 and 10 powergating fixes
The following changes since
Hello Bjorn,
On Thu, Jun 17, 2021 at 01:06:51PM -0500, Bjorn Andersson wrote:
> On Thu 17 Jun 11:54 CDT 2021, Uwe Kleine-K?nig wrote:
> > On Thu, Jun 17, 2021 at 11:38:26AM -0500, Bjorn Andersson wrote:
> > > On Thu 17 Jun 01:24 CDT 2021, Uwe Kleine-K?nig wrote:
> > > > On Wed, Jun 16, 2021 at 10:
We have assumed that if the current placement was not the requested
placement, but instead one of the busy placements, a TTM move would have
been triggered. That is not the case.
So when we initially place LMEM objects in "Limbo", (that is system
placement without any pages allocated), to be able
There is a reversed if statement in amdgpu_preempt_mgr_new() so it
always returns -ENOMEM.
Fixes: 09b020bb05a5 ("Merge tag 'drm-misc-next-2021-06-09' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/amd/amdgpu/amdgpu_preempt_mgr.c |
Am 18.06.21 um 10:37 schrieb Dan Carpenter:
There is a reversed if statement in amdgpu_preempt_mgr_new() so it
always returns -ENOMEM.
Fixes: 09b020bb05a5 ("Merge tag 'drm-misc-next-2021-06-09' of
git://anongit.freedesktop.org/drm/drm-misc into drm-next")
Signed-off-by: Dan Carpenter
Most be
On Thu, 17 Jun 2021 16:37:14 +0300
Laurent Pinchart wrote:
> Hi Pekka,
>
> On Thu, Jun 17, 2021 at 02:33:11PM +0300, Pekka Paalanen wrote:
> > On Thu, 17 Jun 2021 13:29:48 +0300 Laurent Pinchart wrote:
> > > On Thu, Jun 17, 2021 at 10:27:01AM +0300, Pekka Paalanen wrote:
> > > > On Thu, 17 J
Hi Dave and Daniel,
here's the extra PR for drm-misc-next-fixes for this week. In addition
to the previous fixes, it only contains the dp_mst build fix.
Best regards
Thomas
drm-misc-next-fixes-2021-06-18:
Short summary of fixes pull:
* hyperv: advertise the correct formatmodifiers for its prim
On Fri, Jun 18, 2021 at 4:31 AM Dave Airlie wrote:
>
> On Fri, 18 Jun 2021 at 12:26, Dave Airlie wrote:
> >
> > when I pulled this in drm-next I got these.
> >
> > were the mst fixes meant for next or fixes btw? I'm not really sure,
> > but either way I don't think this is a local reason it doesn
The practical upside here is that this only needs a single API call to
program the hardware which (depending on the underlaying hardware) can
be more effective and prevents glitches.
Up to now the return value of the pwm functions was ignored. Fix this
and propagate the error to the caller.
Signe
Implementation of https://lkml.org/lkml/2021/5/12/764 now feature complete
albeit not fully tested.
I have not yet corrected the DSC behavior and double checked the dithering
behavior. I release the feature complete patch series now anyways so that
work on the userspace implementation can start.
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports d
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to
an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11
missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git a/dri
This commit implements the "active bpc" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 19 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 22 insertions(+), 1 deletion(-)
diff -
Add a new general drm property "active bpc" which can be used by graphic
drivers to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to
check which one actually got used. While in theory the driver chooses the
best/hi
This commit implements the "active bpc" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 17 +
drivers/gpu/drm/i915/display/intel_dp.c | 7 +--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
This commit implements the "active color format" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 31 insertions(+), 2 deletions(-
This commit implements the "active color range" drm property for the AMD
GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 33 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 37 insertions(+)
diff --git a/d
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monito
This commit implements the "active color range" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 6 ++
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/g
Add a new general drm property "active color range" which can be used by
graphic drivers to report the used color range back to userspace.
There was no way to check which color range got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of
the monitor a
This commit implements the "active color format" drm property for the Intel
GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c |
Add a new general drm property "preferred color format" which can be used
by userspace to tell the graphic drivers to which color format to use.
Possible options are:
- auto (default/current behaviour)
- rgb
- ycbcr444
- ycbcr422 (not supported by both amdgpu and i915)
- ycbcr4
Add "Broadcast RGB" to general drm context so that more drivers besides
i915 and gma500 can implement it without duplicating code.
Userspace can use this property to tell the graphic driver to use full or
limited color range for a given connector, overwriting the default
behaviour/automatic detect
This commit implements the "preferred color format" drm property for the
AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 30 +++
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4 +++
2 files changed, 28 insertions(+), 6 deletion
This commit implements the "preferred color format" drm property for the
Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_dp.c | 7 ++-
drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++
3 f
This commit implements the "Broadcast RGB" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 22 ++-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 4
2 files changed, 21 insertions(+), 5 deletions(-)
di
Change from the i915 specific "Broadcast RGB" drm property implementation
to the general one.
This commit delete all traces of the former "Broadcast RGB" implementation
and add a new one using the new driver agnoistic functions an variables.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i91
On Fri, Jun 18, 2021 at 5:05 AM Desmond Cheong Zhi Xi
wrote:
> On 18/6/21 1:12 am, Daniel Vetter wrote:
> > On Tue, Jun 15, 2021 at 10:36:45AM +0800, Desmond Cheong Zhi Xi wrote:
> >> This patch ensures that the device's master mutex is acquired before
> >> accessing pointers to struct drm_master
Am 17.06.21 um 21:58 schrieb Daniel Vetter:
On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
[SNIP]
But, to the broader point, maybe? I'm a little fuzzy on exactly where
i915 inserts and/or depends on fences.
When you combine that with complex drivers which use TTM and buffer
Hi Pekka,
On Fri, Jun 18, 2021 at 11:55:38AM +0300, Pekka Paalanen wrote:
> On Thu, 17 Jun 2021 16:37:14 +0300 Laurent Pinchart wrote:
> > On Thu, Jun 17, 2021 at 02:33:11PM +0300, Pekka Paalanen wrote:
> > > On Thu, 17 Jun 2021 13:29:48 +0300 Laurent Pinchart wrote:
> > > > On Thu, Jun 17, 2021
Hi,
Static analysis with Coverity has found a rather old issue in
drivers/gpu/drm/gma500/oaktrail_crtc.c with the following commit:
commit 9bd81acdb648509dbbc32d4da0477c9fae0d6a73
Author: Patrik Jakobsson
Date: Mon Dec 19 21:41:33 2011 +
gma500: Convert Oaktrail to work with new outpu
On Fri, Jun 18, 2021 at 10:58:44AM +0200, Uwe Kleine-König wrote:
> The practical upside here is that this only needs a single API call to
> program the hardware which (depending on the underlaying hardware) can
> be more effective and prevents glitches.
>
> Up to now the return value of the pwm f
On 17-06-2021 20:37, Jonathan Marek wrote:
On 6/16/21 1:50 AM, rajee...@codeaurora.org wrote:
On 03-06-2021 01:32, rajee...@codeaurora.org wrote:
On 02-06-2021 02:28, Rob Herring wrote:
On Mon, May 31, 2021 at 07:03:53PM +0530, Rajeev Nandan wrote:
+
+properties:
+ compatible:
+ oneOf
On Fri, 18 Jun 2021 at 09:31, Thomas Hellström
wrote:
>
> We have assumed that if the current placement was not the requested
> placement, but instead one of the busy placements, a TTM move would have
> been triggered. That is not the case.
>
> So when we initially place LMEM objects in "Limbo", (
On Fri, Jun 18, 2021 at 12:26 PM Colin Ian King
wrote:
>
> Hi,
Hi Colin
>
> Static analysis with Coverity has found a rather old issue in
> drivers/gpu/drm/gma500/oaktrail_crtc.c with the following commit:
Relevant code is in drivers/gpu/drm/gma500/oaktrail_lvds.c
>
> commit 9bd81acdb648509dbb
On Fri, 18 Jun 2021 12:58:49 +0300
Laurent Pinchart wrote:
> Hi Pekka,
>
> On Fri, Jun 18, 2021 at 11:55:38AM +0300, Pekka Paalanen wrote:
> > On Thu, 17 Jun 2021 16:37:14 +0300 Laurent Pinchart wrote:
> > > On Thu, Jun 17, 2021 at 02:33:11PM +0300, Pekka Paalanen wrote:
> > > > On Thu, 17 J
This is the first step to bring GPU support to the NXP LS1028A SoC. It
features a Mali DP500, a Vivante GC7000 and has one DisplayPort output
which is driven by a Cadence MHDP controller and PHY.
This was briefly tested with glmark2, a patched mesa kmsro driver [1]
to support the mali DP500/GC7000
The GPU is found on the NXP LS1028A SoC. The feature bits are taken from
the NXP downstream kernel driver 6.4.3.p1.
Signed-off-by: Michael Walle
---
changes since RFC:
- none
drivers/gpu/drm/etnaviv/etnaviv_hwdb.c | 31 ++
1 file changed, 31 insertions(+)
diff --git a/
The LS1028A SoC errata sheet mentions A-050121 "GPU hangs if clock
gating for Rasterizer, Setup Engine and Texture Engine are enabled".
The workaround is to disable the corresponding clock gatings.
Signed-off-by: Michael Walle
---
changes since RFC:
- corrected the wording of the comment
drive
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
head: 13c2ceb6addb6b14468e09b75832c98909eed8e7
commit: 88be9a0a06b73ecd85a688a7c174c941e9692e92 [2/8] drm/i915/ttm: add
ttm_buddy_man
config: x86_64-randconfig-a012-20210618 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22
Hi Pekka,
On Fri, Jun 18, 2021 at 02:32:00PM +0300, Pekka Paalanen wrote:
> On Fri, 18 Jun 2021 12:58:49 +0300 Laurent Pinchart wrote:
> > On Fri, Jun 18, 2021 at 11:55:38AM +0300, Pekka Paalanen wrote:
> > > On Thu, 17 Jun 2021 16:37:14 +0300 Laurent Pinchart wrote:
> > > > On Thu, Jun 17, 2021
Fixed checkpatch --strict issue and pushed to drm-misc-next.
https://cgit.freedesktop.org/drm/drm-misc/commit/?id=f03ab6629c7b410d874151cf1d8570899a65fdda
User process might want to share the device memory with another
driver/device, and to allow it to access it over PCIe (P2P).
To enable this, we utilize the dma-buf mechanism and add a dma-buf
exporter support, so the other driver can import the device memory and
access it.
The device memory is al
From: Tomer Tayar
Implement the calls to the dma-buf kernel api to create a dma-buf
object backed by FD.
We block the option to mmap the DMA-BUF object because we don't support
DIRECT_IO and implicit P2P. We only implement support for explicit P2P
through importing the FD of the DMA-BUF.
In the
On 6/18/21 12:53 PM, Matthew Auld wrote:
On Fri, 18 Jun 2021 at 09:31, Thomas Hellström
wrote:
We have assumed that if the current placement was not the requested
placement, but instead one of the busy placements, a TTM move would have
been triggered. That is not the case.
So when we initial
On 17/06/2021 07:20, ChunyouTang wrote:
> From: ChunyouTang
>
> of the low 8 bits.
Please don't split the subject like this. The first line of the commit
should be a (very short) summary of the patch. Then a blank line and
then a longer description of what the purpose of the patch is and why
it'
On 17/06/2021 09:04, ChunyouTang wrote:
> From: ChunyouTang
>
> The 'break' can cause 'Memory manager not clean during takedown'
>
> It cannot use break to finish the circulation,it should use
>
> continue to traverse the circulation.it should put every mapping
>
> which is not NULL.
You don'
Hi Jagan,
On Wed, 3 Feb 2021 at 09:13, Jagan Teki wrote:
> @@ -1167,6 +1151,20 @@ __dw_mipi_dsi_probe(struct platform_device *pdev,
> dw_mipi_dsi_debugfs_init(dsi);
> pm_runtime_enable(dev);
>
> + ret = drm_of_find_panel_or_bridge(dev->of_node, 1, 0,
> +
When we resurrected the selftest we forgot to add back the selftest()
hook, meaning the test is not currently run.
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
drivers/gpu/drm/i915/selftests/i915_mock_selftests.h | 1 +
1 file changed, 1 insertion(+)
dif
Looks like it got lost along the way, so add it back. This is needed for
the region query uAPI where we need to report an accurate available size
for lmem.
This time around let's push it directly into the allocator, which
simplifies things, like not having to care about internal fragmentation,
or
Hi.
On 6/18/21 3:31 PM, Matthew Auld wrote:
When we resurrected the selftest we forgot to add back the selftest()
hook, meaning the test is not currently run.
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Do we need a Fixes: tag?
Reviewed-by: Thomas Hells
On 18/06/2021 14:36, Thomas Hellström wrote:
Hi.
On 6/18/21 3:31 PM, Matthew Auld wrote:
When we resurrected the selftest we forgot to add back the selftest()
hook, meaning the test is not currently run.
Reported-by: kernel test robot
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Do we
On 6/18/21 3:31 PM, Matthew Auld wrote:
Looks like it got lost along the way, so add it back. This is needed for
the region query uAPI where we need to report an accurate available size
for lmem.
Hmm. How is this uAPI intended to work in a multi-client environment
where the returned value ca
On 2021-06-17 9:23 p.m., Shaokun Zhang wrote:
> Function 'dpp1_full_bypass' is declared twice, so remove the repeated
> declaration and unnessary blank line.
>
> Cc: Harry Wentland
> Cc: Leo Li
> Cc: Alex Deucher
> Signed-off-by: Shaokun Zhang
Reviewed-by: Harry Wentland
Harry
> ---
>
On Fri, Jun 18, 2021 at 4:15 AM Christian König
wrote:
>
> Am 17.06.21 um 21:58 schrieb Daniel Vetter:
> > On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
> >> [SNIP]
> >>> But, to the broader point, maybe? I'm a little fuzzy on exactly where
> >>> i915 inserts and/or depends on
On 2021-06-16 10:40 a.m., Wan Jiabing wrote:
> Fix coccicheck warning:
>
> ./drivers/gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c:
> 55:12-42: duplicated argument to && or ||
>
> Signed-off-by: Wan Jiabing
Reviewed-by: Harry Wentland
Harry
> ---
> .../gpu/drm/amd/display/dc/dml
On 18/06/2021 14:44, Thomas Hellström wrote:
On 6/18/21 3:31 PM, Matthew Auld wrote:
Looks like it got lost along the way, so add it back. This is needed for
the region query uAPI where we need to report an accurate available size
for lmem.
Hmm. How is this uAPI intended to work in a multi-cl
On 6/18/21 1:25 AM, Claire Chang wrote:
> On Fri, Jun 18, 2021 at 7:30 AM Stefano Stabellini
> wrote:
>>
>> On Thu, 17 Jun 2021, Claire Chang wrote:
>>> Add a new function, swiotlb_init_io_tlb_mem, for the io_tlb_mem struct
>>> initialization to make the code reusable.
>>>
>>> Signed-off-by: Clair
On Fri, Jun 18, 2021 at 11:15 AM Christian König
wrote:
>
> Am 17.06.21 um 21:58 schrieb Daniel Vetter:
> > On Thu, Jun 17, 2021 at 09:37:36AM +0200, Christian König wrote:
> >> [SNIP]
> >>> But, to the broader point, maybe? I'm a little fuzzy on exactly where
> >>> i915 inserts and/or depends on
From: Tvrtko Ursulin
A little bit of documentation covering the topics of engine discovery,
context engine maps and virtual engines. It is not very detailed but
supposed to be a starting point of giving a brief high level overview of
general principles and intended use cases.
v3:
* Move text to
Am 18.06.21 um 16:31 schrieb Daniel Vetter:
[SNIP]
And that drivers choose to ignore the exclusive fence is an absolutely
no-go from a memory management and security point of view. Exclusive
access means exclusive access. Ignoring that won't work.
Yeah, this is why I've been going all over the
From: Tvrtko Ursulin
A little bit of documentation covering the topics of engine discovery,
context engine maps and virtual engines. It is not very detailed but
supposed to be a starting point of giving a brief high level overview of
general principles and intended use cases.
v2:
* Have the tex
On Fri, Jun 18, 2021 at 4:42 PM Christian König
wrote:
>
> Am 18.06.21 um 16:31 schrieb Daniel Vetter:
> > [SNIP]
> >> And that drivers choose to ignore the exclusive fence is an absolutely
> >> no-go from a memory management and security point of view. Exclusive
> >> access means exclusive access
Am 2021-06-18 um 4:39 a.m. schrieb Christian König:
> Am 18.06.21 um 10:37 schrieb Dan Carpenter:
>> There is a reversed if statement in amdgpu_preempt_mgr_new() so it
>> always returns -ENOMEM.
>>
>> Fixes: 09b020bb05a5 ("Merge tag 'drm-misc-next-2021-06-09' of
>> git://anongit.freedesktop.org/drm
On Thu, 17 Jun 2021 at 18:27, Daniel Vetter wrote:
>
> On Mon, Jun 14, 2021 at 09:45:37PM +0900, Sergey Senozhatsky wrote:
> > Hi,
> >
> > We are observing some user-space crashes (sigabort, segfaults etc.)
> > under moderate memory pressure (pretty far from severe pressure) which
> > have one thi
It's no problem! We all make mistakes sometimes :), I should have been more
diligent on compile-checking this myself as well
On Thu, 2021-06-17 at 08:20 +, Lin, Wayne wrote:
> [Public]
>
> Really sorry for the mistake that I made and any inconvenience it brought.
> Thanks José and Lyude.
>
>
Am 18.06.21 um 17:17 schrieb Daniel Vetter:
[SNIP]
Ignoring _all_ fences is officially ok for pinned dma-buf. This is
what v4l does. Aside from it's definitely not just i915 that does this
even on the drm side, we have a few more drivers nowadays.
No it seriously isn't. If drivers are doing thi
On 18/6/21 5:12 pm, Daniel Vetter wrote:
On Fri, Jun 18, 2021 at 5:05 AM Desmond Cheong Zhi Xi
wrote:
On 18/6/21 1:12 am, Daniel Vetter wrote:
On Tue, Jun 15, 2021 at 10:36:45AM +0800, Desmond Cheong Zhi Xi wrote:
This patch ensures that the device's master mutex is acquired before
accessing
On Fri, Jun 18, 2021 at 6:43 PM Christian König
wrote:
>
> Am 18.06.21 um 17:17 schrieb Daniel Vetter:
> > [SNIP]
> > Ignoring _all_ fences is officially ok for pinned dma-buf. This is
> > what v4l does. Aside from it's definitely not just i915 that does this
> > even on the drm side, we have a fe
Acked-by: Tony Ye
Regards,
Tony
On 6/11/2021 4:40 PM, Matthew Brost wrote:
> Add entry for i915 new parallel submission uAPI plan.
>
> v2:
> (Daniel Vetter):
>- Expand logical order explaination
>- Add dummy header
>- Only allow N BBs in execbuf IOCTL
>- Configure parallel sub
Am 18.06.21 um 19:20 schrieb Daniel Vetter:
On Fri, Jun 18, 2021 at 6:43 PM Christian König
wrote:
Am 18.06.21 um 17:17 schrieb Daniel Vetter:
[SNIP]
Ignoring _all_ fences is officially ok for pinned dma-buf. This is
what v4l does. Aside from it's definitely not just i915 that does this
even o
Sorry for the mobile reply, but V4L2 is absolutely not write-only; there has
never been an intersection of V4L2 supporting dmabuf and not supporting reads.
I see your point about the heritage of dma_resv but it’s a red herring. It
doesn’t matter who’s right, or who was first, or where the code w
https://bugzilla.kernel.org/show_bug.cgi?id=209457
--- Comment #28 from Leandro Jacques (ls...@yahoo.com) ---
Created attachment 297465
--> https://bugzilla.kernel.org/attachment.cgi?id=297465&action=edit
amdgpu crash log for kernel 5.4.126
Another problem appeared in kernel 5.4.126 as the atta
On 18/06/2021 12:19, Patrik Jakobsson wrote:
> On Fri, Jun 18, 2021 at 12:26 PM Colin Ian King
> wrote:
>>
>> Hi,
>
> Hi Colin
>
>>
>> Static analysis with Coverity has found a rather old issue in
>> drivers/gpu/drm/gma500/oaktrail_crtc.c with the following commit:
>
> Relevant code is in drive
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #18 from Leandro Jacques (ls...@yahoo.com) ---
Created attachment 297467
--> https://bugzilla.kernel.org/attachment.cgi?id=297467&action=edit
amdgpu crash log for kernel 5.4.126
Before 5.4.126 I had no issues at all, downgrading to
From: Colin Ian King
Currently a loop scans through the connector list checking
for connectors that do not match a specific criteria. The
use of the continue statement is a little unintuitive and
can confuse static analysis checking. Invert the criteria
matching logic and use a break to terminat
Hi Daniel,
thanks for jumping in here.
And yes, you are absolutely right we need to get this fixed and not yell
at each other that we have a different understanding of things.
Your proposal sounds sane to me, but I wouldn't call it slots. Rather
something like "use cases" since we can have m
On Fri, Jun 18, 2021 at 8:02 PM Christian König
wrote:
>
> Am 18.06.21 um 19:20 schrieb Daniel Vetter:
> > On Fri, Jun 18, 2021 at 6:43 PM Christian König
> > wrote:
> >> Am 18.06.21 um 17:17 schrieb Daniel Vetter:
> >>> [SNIP]
> >>> Ignoring _all_ fences is officially ok for pinned dma-buf. This
On Thu, 17 Jun 2021 10:43:33 -0400, Jonathan Marek wrote:
> These got lost when going from .txt to .yaml bindings, add them back.
>
> Signed-off-by: Jonathan Marek
> ---
> .../bindings/display/msm/dsi-phy-7nm.yaml | 66 +++
> 1 file changed, 66 insertions(+)
> create mode 10
On Fri, Jun 18, 2021 at 8:35 PM Colin King wrote:
>
> From: Colin Ian King
>
> Currently a loop scans through the connector list checking
> for connectors that do not match a specific criteria. The
> use of the continue statement is a little unintuitive and
> can confuse static analysis checking.
The pull request you sent on Fri, 18 Jun 2021 17:14:45 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-06-18
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c3bf96eaa4c4e701fee04665bea70867cf5e8388
Thank you!
--
Deet-doot-dot, I am a bot.
https://k
On Mon, 14 Jun 2021 at 19:37, Joonas Lahtinen
wrote:
>
> Quoting Joonas Lahtinen (2021-06-11 14:13:02)
> > Quoting Joonas Lahtinen (2021-06-11 13:40:56)
> > > Quoting Maarten Lankhorst (2021-06-11 12:27:15)
> > > > Pull request for drm-misc-next and drm-intel-gt-next.
> > > >
> > > > topic/i915-tt
https://bugzilla.kernel.org/show_bug.cgi?id=213391
--- Comment #19 from dimit...@gmail.com ---
I've also just replaced /lib/firmware/amdgpu with the `20210315` version, I'll
see how this goes. Currently running Fedora kernel 5.12.11-200.fc33.x86_64 on
a T495.
Question, don't I also need to updat
Applied. Thanks!
Alex
On Thu, Jun 17, 2021 at 2:43 PM Harry Wentland wrote:
>
> On 2021-06-16 10:31 p.m., Pu Lehui wrote:
> > GCC reports the following warning with W=1:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:3635:17:
> > warning:
> > variable ‘status’ set but not u
Applied. Thanks!
On Thu, Jun 17, 2021 at 3:04 PM Harry Wentland wrote:
>
>
>
> On 2021-06-16 9:16 p.m., Pu Lehui wrote:
> > GCC reports the following warning with W=1:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_psr.c:70:13:
> > warning:
> > variable ‘dc’ set but not used
Applied. Thanks!
Alex
On Thu, Jun 17, 2021 at 3:20 PM Harry Wentland wrote:
>
>
>
> On 2021-06-16 4:52 p.m., Gustavo A. R. Silva wrote:
> > In preparation to enable -Wimplicit-fallthrough for Clang, fix
> > the following warning by replacing a /* fall through */ comment
> > with the new pseudo-
Applied. Thanks!
On Fri, Jun 18, 2021 at 9:48 AM Harry Wentland wrote:
>
>
>
> On 2021-06-17 9:23 p.m., Shaokun Zhang wrote:
> > Function 'dpp1_full_bypass' is declared twice, so remove the repeated
> > declaration and unnessary blank line.
> >
> > Cc: Harry Wentland
> > Cc: Leo Li
> > Cc: Ale
Applied. Thanks!
On Fri, Jun 18, 2021 at 9:56 AM Harry Wentland wrote:
>
> On 2021-06-16 10:40 a.m., Wan Jiabing wrote:
> > Fix coccicheck warning:
> >
> > ./drivers/gpu/drm/amd/display/dc/dml/dcn31/display_rq_dlg_calc_31.c:
> > 55:12-42: duplicated argument to && or ||
> >
> > Signed-off-by: Wa
On Fri, Jun 18, 2021 at 5:00 PM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> A little bit of documentation covering the topics of engine discovery,
> context engine maps and virtual engines. It is not very detailed but
> supposed to be a starting point of giving a brief high level overview
Quoting Dmitry Baryshkov (2021-06-09 09:03:14)
> On 09/06/2021 01:11, Stephen Boyd wrote:
> > Quoting Dmitry Baryshkov (2021-06-08 14:41:21)
> >> Hi Stephen,
> >>
> >> On 08/06/2021 22:55, Stephen Boyd wrote:
> >>> A problem was reported on CoachZ devices where the display wouldn't come
> >>> up, o
On Wed, 09 Jun 2021 14:10:47 +0200, Oleksij Rempel wrote:
> Add Logictechno and Multi-Inno panels:
> - Logic Technologies LTTD800x480 L2RT 7" 800x480 TFT Resistive Touch Module
> - Logic Technologies LTTD800480070-L6WH-RT 7” 800x480 TFT Resistive Touch
> Module
> - Multi-Inno Technology Co.,Ltd MI
On Wed, 09 Jun 2021 14:10:48 +0200, Oleksij Rempel wrote:
> Add "skov" entry for the SKOV A/S: https://www.skov.com/en/
>
> Signed-off-by: Oleksij Rempel
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
Acked-by: Rob Herring
On Wed, 09 Jun 2021 14:10:49 +0200, Oleksij Rempel wrote:
> Add SKOV imx6q/dl LT2, LT6 and mi1010ait-1cp1 boards.
>
> Signed-off-by: Oleksij Rempel
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 5 +
> 1 file changed, 5 insertions(+)
>
Acked-by: Rob Herring
On Fri, Jun 18, 2021 at 11:31:09AM +0100, Daniel Thompson wrote:
> On Fri, Jun 18, 2021 at 10:58:44AM +0200, Uwe Kleine-König wrote:
> > The practical upside here is that this only needs a single API call to
> > program the hardware which (depending on the underlaying hardware) can
> > be more effe
On Fri, Jun 18, 2021 at 11:40 AM Felix Kuehling wrote:
>
> Am 2021-06-18 um 4:39 a.m. schrieb Christian König:
> > Am 18.06.21 um 10:37 schrieb Dan Carpenter:
> >> There is a reversed if statement in amdgpu_preempt_mgr_new() so it
> >> always returns -ENOMEM.
> >>
> >> Fixes: 09b020bb05a5 ("Merge
In
commit ebc0808fa2da0548a78e715858024cb81cd732bc
Author: Chris Wilson
Date: Tue Oct 18 13:02:51 2016 +0100
drm/i915: Restrict pagefault disabling to just around copy_from_user()
we entirely missed that there's a slow path call to eb_relocate_entry
(or i915_gem_execbuffer_relocate_entry
Am 2021-05-01 um 1:03 p.m. schrieb Adrian Reber:
>
> It would also be good to have your patchset submitted as a PR on github
> to have our normal CI test coverage of the changes.
Hi Adrian,
We moved our work to a new github repository that is a fork of
checkpoint-restore/criu so that we could sen
On Fri, Jun 18, 2021 at 6:54 PM Desmond Cheong Zhi Xi
wrote:
>
> On 18/6/21 5:12 pm, Daniel Vetter wrote:
> > On Fri, Jun 18, 2021 at 5:05 AM Desmond Cheong Zhi Xi
> > wrote:
> >> On 18/6/21 1:12 am, Daniel Vetter wrote:
> >>> On Tue, Jun 15, 2021 at 10:36:45AM +0800, Desmond Cheong Zhi Xi wrote:
Hi Steve,
1,
from
https://lore.kernel.org/lkml/31644881-134a-2d6e-dddf-e658a3a81...@arm.com/
I can see what your sent,I used a wrong email address,Now it correct.
2,
> >Unless I'm mistaken the situation where some mappings may be NULL is
> >caused by the loop in panfrost_lookup_bos(
Hi Steve,
1,Now I know how to write the subject
2,the low 8 bits is the exception type in spec.
and you can see prnfrost_exception_name()
switch (exception_code) {
/* Non-Fault Status code */
case 0x00: return "NOT_STARTED/IDLE/OK";
case 0x01: return "DONE";
case 0
1 - 100 of 119 matches
Mail list logo
