+ David, Christian
On Thu, May 13, 2021 at 12:41 PM Tvrtko Ursulin
wrote:
>
>
> Hi,
>
> On 13/05/2021 16:48, Alex Deucher wrote:
> > On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Resurrect of the previosuly merged per client engine busyness
Hi Linus,
Just realised I got the tag header wrong, these are the rc2 fixes. Not
much here, mostly amdgpu fixes, with a couple of radeon, and a
cosmetic vc4. Two MAINTAINER file updates also.
Dave.
drm-fixes-2021-05-14:
drm fixes for 5.13-rc1
two MAINTAINERS updates.
amdgpu:
- Fixes for
Hi all,
On Fri, 30 Apr 2021 08:23:21 +1000 Stephen Rothwell
wrote:
>
> On Thu, 18 Mar 2021 12:52:41 +1100 Stephen Rothwell
> wrote:
> >
> > On Wed, 17 Mar 2021 14:08:24 +1100 Stephen Rothwell
> > wrote:
> > >
> > > Today's linux-next merge of the drm-intel tree got a conflict in:
> > >
From: Chenyang Li
This patch adds an initial DRM driver for the Loongson LS7A1000
bridge chip(LS7A). The LS7A bridge chip contains two display
controllers, support dual display output. The maximum support for
each channel display is to 1920x1080@60Hz.
At present, DC device detection and DRM
Implement use GPIO and I2C driver to detect connector
and fetch EDID via DDC.
Signed-off-by: lichenyang
---
drivers/gpu/drm/loongson/Makefile | 3 +-
drivers/gpu/drm/loongson/loongson_connector.c | 70 -
drivers/gpu/drm/loongson/loongson_drv.c | 16 +-
https://bugzilla.kernel.org/show_bug.cgi?id=213053
Bug ID: 213053
Summary: WARNING on dcn30_hwseq.c dcn30_set_hubp_blank, AMD
Radeon 6700XT
Product: Drivers
Version: 2.5
Kernel Version: 5.12.3
Hardware: All
Hi, Wang:
Chun-Kuang Hu 於 2021年4月12日 週一 下午11:32寫道：
>
> Hi, Wang:
>
> Wang Li 於 2021年4月10日 週六 上午11:31寫道：
> >
> > pm_runtime_get_sync will increment pm usage counter even it failed.
> > Forgetting to putting operation will result in reference leak here.
> > Fix it by replacing it with
On Thu, May 6, 2021 at 8:37 AM Ville Syrjälä
wrote:
>
> On Sat, Mar 20, 2021 at 04:09:47AM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 19, 2021 at 10:45:10PM +0100, Mario Kleiner wrote:
> > > On Fri, Mar 19, 2021 at 10:16 PM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Fri, Mar 19, 2021 at
Add a660 hwcg table, ported over from downstream.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 53 ++
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/adreno/adreno_gpu.h| 2 +-
3 files changed, 55 insertions(+), 1
Accept all SQE firmware versions for A660.
Re-organize the function a bit and print an error message for unexpected
GPU IDs instead of failing silently.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 36 +--
1 file changed, 17 insertions(+),
Add adreno_is_{a660,a650_family} helpers and convert update existing
adreno_is_a650 usage based on downstream driver's logic (changing into
adreno_is_a650_family or adding adreno_is_a660).
And add the remaining changes required for A660, again based on
the downstream driver: missing GMU
If a6xx_hw_init() fails before creating the shadow_bo, the a6xx_pm_suspend
code referencing it will crash. Change the condition to one that avoids
this problem (note: creation of shadow_bo is behind this same condition)
Fixes: e8b0b994c3a5 ("drm/msm/a6xx: Clear shadow on suspend")
Signed-off-by:
Update CP_PROTECT register programming based on downstream.
A6XX_PROTECT_RW is renamed to A6XX_PROTECT_NORDWR to make things aligned
and also be more clear about what it does.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 143 +++---
Value was shifted in the wrong direction, resulting in the field always
being zero, which is incorrect for A650.
Fixes: d0bac4e9cd66 ("drm/msm/a6xx: set ubwc config for A640 and A650")
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1
SM8250 AOP firmware already sets up PDC registers for us, and it only needs
to be enabled. This path will be used for other newer GPUs.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff
These aren't used by anything anymore.
Signed-off-by: Jonathan Marek
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 ---
drivers/gpu/drm/msm/msm_gpu.h | 9 -
2 files changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
Add support for Adreno 660 to the drm/msm driver. Very similar to A650
on the kernel side.
v2:
- added AOP PDC path for a650 and use it for a660 too
- fix UBWC config for a650 (also affects a660)
- add CP_PROTECT update, and corresponding a660 settings in A660 patch
Jonathan Marek (8):
Thanks for the patch.
Reviewed-by: Anitha Chrisanthus
> -Original Message-
> From: Zhen Lei
> Sent: Thursday, May 13, 2021 6:47 AM
> To: Chrisanthus, Anitha ; Dea, Edmund J
> ; David Airlie ; Daniel Vetter
> ; Sam Ravnborg ; dri-devel de...@lists.freedesktop.org>
> Cc: Zhen Lei
>
Hi,
On 13/05/2021 16:48, Alex Deucher wrote:
On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Resurrect of the previosuly merged per client engine busyness patches. In a
nutshell it enables intel_gpu_top to be more top(1) like useful and show not
only physical
Hi Dave, Daniel,
Fixes for 5.13.
The following changes since commit 875d598db60ac81e768fdfd2c589f6209038488b:
MAINTAINERS: Update address for Emma Anholt (2021-05-11 20:38:08 +0200)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
Reviewed-by: Lyude Paul
Will let this sit on the list for a few days to see if anyone's got any
objections and then I'll go ahead and push it
On Wed, 2021-05-12 at 17:00 -0400, Nikola Cornij wrote:
> [why]
> Link rate in kHz is what is eventually required to calculate the link
> bandwidth,
On Thu, May 13, 2021 at 7:00 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Resurrect of the previosuly merged per client engine busyness patches. In a
> nutshell it enables intel_gpu_top to be more top(1) like useful and show not
> only physical GPU engine usage but per process view as
Hi Neil,
On Mon, 26 Apr 2021 at 06:59, Neil Armstrong wrote:
>
> Hi,
>
> On 21/04/2021 07:28, Nicolas Boichat wrote:
> > Hi!
> >
> > This is just a rebase of the v11, untested (but it seems like
> > Neil Armstrong recently tested it), with small changes in
> > binding and dts. v11 cover follows:
On Thu, May 13, 2021 at 10:47 AM Andrey Grodzovsky
wrote:
>
>
>
> On 2021-05-12 4:50 p.m., Alex Deucher wrote:
> > On Wed, May 12, 2021 at 4:30 PM Andrey Grodzovsky
> > wrote:
> >>
> >>
> >>
> >> On 2021-05-12 4:17 p.m., Alex Deucher wrote:
> >>> On Wed, May 12, 2021 at 10:27 AM Andrey
On 2021-05-12 4:50 p.m., Alex Deucher wrote:
On Wed, May 12, 2021 at 4:30 PM Andrey Grodzovsky
wrote:
On 2021-05-12 4:17 p.m., Alex Deucher wrote:
On Wed, May 12, 2021 at 10:27 AM Andrey Grodzovsky
wrote:
This should prevent writing to memory or IO ranges possibly
already allocated
On Thu, May 13, 2021 at 09:53:32PM +0800, Yiyuan GUO wrote:
> In function agp_3_5_enable from drivers/char/agp/isoch.c, the
> variable ndevs may remain zero if all AGP devices have type of
> "Bridge" or "Unclassified device".
Can that actually happen with real hardware? Given the age of AGP
Hi
Am 12.05.21 um 22:30 schrieb Colin King:
From: Colin Ian King
There are two occurrances where objects are being free'd via
a put call and yet they are being referenced after this. Fix these
by adding in the missing continue statement so that the put on the
end of the loop is skipped over.
When call platform_get_irq() to obtain the IRQ of the lcd fails, the
returned error code should be propagated. However, we currently do not
explicitly assign this error code to 'ret'. As a result, 0 was incorrectly
returned.
Fixes: 7f7b96a8a0a1 ("drm/kmb: Add support for KeemBay Display")
On Mon, May 10, 2021 at 06:05:21PM +0200, Daniel Vetter wrote:
> Entirely aside, but an s/master/aggregate/ or similar over the entire
> component.c codebase would help a pile in making it easier to understand
> which part does what. Or at least I'm always terribly confused about which
> bind
Hi Dave, Daniel,
Here's the first round of drm-misc-fixes for 5.13
Maxime
drm-misc-fixes-2021-05-13:
A BO list maintainance fix for TTM, removing an unused function and a
MAINTAINERS update.
The following changes since commit 6efb943b8616ec53a5e444193dccf1af9ad627b5:
Linux 5.13-rc1
Hi
Am 13.05.21 um 10:46 schrieb Zou Wei:
Add the missing unlock before return from function devm_aperture_acquire()
in the error handling case.
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
I added a Fixes tag and queued up the patch for drm-misc-next. Thanks!
Best regards
Thomas
---
Hi
Am 13.05.21 um 01:34 schrieb Randy Dunlap:
struct resource start and end fields are not always long long,
so using %llx to print them can cause build warnings (below).
Fix these by using the special "%pr" for printing struct resource info.
../drivers/gpu/drm/tiny/simpledrm.c: In function
Hi,
Almost two months later,
Le mar., mars 23 2021 at 14:40:08 +, Paul Cercueil
a écrit :
When using a 24-bit panel on a 8-bit serial bus, the pixel clock
requested by the panel has to be multiplied by 3, since the subpixels
are shifted sequentially.
The code (in
From: Chris Wilson
When instantiating a tiled object on an L-shaped memory machine, we mark
the object as unshrinkable to prevent the shrinker from trying to swap
out the pages. We have to do this as we do not know the swizzling on the
individual pages, and so the data will be scrambled across
From: Quanyang Wang
For now, the functions zynqmp_disp_avbuf_enable/disable_audio and
zynqmp_disp_avbuf_enable/disable_video are all programming the register
AV_BUF_OUTPUT_AUDIO_VIDEO_SELECT to select the output for audio or video.
And in the future, many drm properties (like video_tpg,
From: Quanyang Wang
Add a new function is_layer_vid() to simplify the code that
judges if a layer is the video layer.
Signed-off-by: Quanyang Wang
---
drivers/gpu/drm/xlnx/zynqmp_disp.c | 39 +-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git
From: Quanyang Wang
The patch "drm: xlnx: add is_layer_vid() to simplify the code" is to
simplify the code which judge the layer type.
The patch "drm: xlnx: consolidate the functions which programming
AUDIO_VIDEO_SELECT register"
is to consolidate the code that can configure vid/gfx/audio to
From: Tvrtko Ursulin
Expose per-client and per-engine busyness under the previously added sysfs
client root.
The new files are one per-engine instance and located under the 'busy'
directory. Each contains a monotonically increasing nano-second resolution
times each client's jobs were executing
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind
From: Tvrtko Ursulin
Resurrect of the previosuly merged per client engine busyness patches. In a
nutshell it enables intel_gpu_top to be more top(1) like useful and show not
only physical GPU engine usage but per process view as well.
Example screen capture:
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Some clients have the DRM fd passed to them over a socket by the X server.
Grab the real client and pid when they create their first context and
update the exposed data for more useful enumeration.
To enable lockless access to client name and pid data from the following
From: Tvrtko Ursulin
If we make GEM contexts keep a reference to i915_drm_client for the whole
of their lifetime, we can consolidate the current task pid and name usage
by getting it from the client.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish
From: Tvrtko Ursulin
Expose a list of clients with open file handles in sysfs.
This will be a basis for a top-like utility showing per-client and per-
engine GPU load.
Currently we only expose each client's pid and name under opaque numbered
directories in /sys/class/drm/card0/clients/.
For
On 2021-04-08 20:33, Rob Herring wrote:
On Mon, Apr 05, 2021 at 04:36:08PM +0530, Krishna Manikandan wrote:
Add YAML schema for the device tree bindings for DSI
Signed-off-by: Krishna Manikandan
Changes in v1:
- Separate dsi controller bindings to a separate patch (Stephen
Boyd)
-
On Mon, May 10, 2021 at 12:57:16PM +0300, Andy Shevchenko wrote:
> device_for_each_child_node() bumps a reference counting of a returned
> variable.
> We have to balance it whenever we return to the caller.
>
> Fixes: 8fbce8efe15cd ("backlight: lm3630a: Add firmware node support")
> Cc: Brian
Revert the removal of code handling extra VT_RESIZEX ioctl's parameters
beyond those that VT_RESIZE supports, fixing a functional regression
causing `svgatextmode' not to resize the VT anymore. As a consequence
of the reverted change when the video adapter is reprogrammed from the
original
Restore the original intent of the VT_RESIZEX ioctl's `v_clin' parameter
which is the number of pixel rows per character (cell) rather than the
height of the font used.
For framebuffer devices the two values are always the same, because the
former is inferred from the latter one. For VGA used
Fix an issue with VGA console font size changes made after the initial
video text mode has been changed with a user tool like `svgatextmode'
calling the VT_RESIZEX ioctl. As it stands in that case the original
screen geometry continues being used to validate further VT resizing.
Consequently
Hi,
This is a minor update to the previous version of the series, adding a
clarification to 3/3 as to the problem the original fix to which caused
the functional regression the removal of extra VT_RESIZEX parameter
handling caused. No change to actual code.
See individual change
Fix the following make W=1 kernel build warning:
drivers/gpu/drm/radeon/radeon_cs.c:417: warning: expecting prototype for
cs_parser_fini(). Prototype was for radeon_cs_parser_fini() instead
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/radeon/radeon_cs.c | 2 +-
1 file changed, 1
Fix the following make W=1 kernel build warning:
drivers/gpu/drm/drm_context.c:136: warning: expecting prototype for
drm_ctxbitmap_flush(). Prototype was for drm_legacy_ctxbitmap_flush() instead
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/drm_context.c | 2 +-
1 file changed, 1
Fix the following make W=1 kernel build warnings:
drivers/gpu/drm/radeon/radeon_vm.c:61: warning: expecting prototype for
radeon_vm_num_pde(). Prototype was for radeon_vm_num_pdes() instead
drivers/gpu/drm/radeon/radeon_vm.c:642: warning: expecting prototype for
radeon_vm_update_pdes().
Fix the following make W=1 kernel build warning:
drivers/gpu/drm/radeon/cik.c:7450: warning: expecting prototype for
cik_irq_disable(). Prototype was for cik_irq_suspend() instead
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/radeon/cik.c | 2 +-
1 file changed, 1 insertion(+), 1
Yang Yingliang (4):
drm/radeon/cik: correct function name cik_irq_suspend()
drm/radeon: correct function name radeon_cs_parser_fini()
drm/radeon/r100: correct function name r100_cs_packet_parse_vline()
drm/radeon/radeon_vm: correct function names in radeon_vm.c
Fix the following make W=1 kernel build warning:
drivers/gpu/drm/radeon/r100.c:1423: warning: expecting prototype for
r100_cs_packet_next_vline(). Prototype was for r100_cs_packet_parse_vline()
instead
Signed-off-by: Yang Yingliang
---
drivers/gpu/drm/radeon/r100.c | 2 +-
1 file changed,
Add the missing unlock before return from function devm_aperture_acquire()
in the error handling case.
Reported-by: Hulk Robot
Signed-off-by: Zou Wei
---
drivers/gpu/drm/drm_aperture.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_aperture.c
I met below error during boot with i915 builtin if pass
"i915.mitigations=off":
[0.015589] Booting kernel: `off' invalid for parameter `i915.mitigations'
The reason is slab subsystem isn't ready at that time, so kstrdup()
returns NULL. Fix this issue by using stack var instead of kstrdup().
https://bugzilla.kernel.org/show_bug.cgi?id=211277
--- Comment #18 from Jerome C (m...@jeromec.com) ---
(In reply to Alex Deucher from comment #17)
> I don't think we've been able to reproduce it. That said, we did double
> check the programmign sequences and I believe it may be fixed with these
60 matches
Mail list logo
