On Thu, 14 Jan 2021, Steven Rostedt wrote:
> [ Forgot to add those on the commit itself ]
>
> -- Steve
>
>
> On Thu, 14 Jan 2021 16:32:06 -0500
> Steven Rostedt wrote:
>
>> On reboot, one of my test boxes now triggers the following warning:
>>
>> [ cut here ]
>> RPM
Am 14.01.21 um 22:13 schrieb Felix Kuehling:
Am 2021-01-14 um 11:51 a.m. schrieb Jerome Glisse:
On Thu, Jan 14, 2021 at 02:37:36PM +0100, Christian König wrote:
Am 14.01.21 um 12:52 schrieb Daniel Vetter:
[SNIP]
I had a new idea, i wanted to think more about it but have not yet,
anyway here
On Fri, 15 Jan 2021 at 07:22, Alex Deucher wrote:
>
> Hi Dave, Daniel,
>
> More new stuff for 5.12.
>
> The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075:
>
> drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug
> 210921) (2021-01-08 15:18:57 -0500)
>
On 1/14/2021 1:24 AM, Grodzovsky, Andrey wrote:
>
>
> On 1/14/21 12:11 AM, Chen, Xiaogang wrote:
>> On 1/12/2021 10:54 PM, Grodzovsky, Andrey wrote:
>>>
>>> On 1/4/21 1:01 AM, Xiaogang.Chen wrote:
From: Xiaogang Chen
amdgpu DM handles INTERRUPT_LOW_IRQ_CONTEXT interrupt(hpd,
Hi Linus,
As mentioned in the previous pull, Ben has requested if we can include
Ampere modesetting support under fixes, it's for new GPUs and
shouldn't affect existing hardware. It's a bit bigger than just adding
a PCI ID, and I'm fine if you think we should hold it off until later.
Dave.
On Thu, Jan 14, 2021 at 2:01 PM Steven Rostedt wrote:
>
> Thanks, I take it, it will be going into mainline soon.
Just got merged - it might be a good idea to verify that your problem is solved.
Linus
___
dri-devel mailing list
The pull request you sent on Fri, 15 Jan 2021 14:01:12 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-01-15
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5ee88057889bbca5f5bb96031b62b3756b33e164
Thank you!
--
Deet-doot-dot, I am a bot.
Hey Linus,
Back to mostly regular scheduling for me. Big thanks to Daniel for
stepping into my duties for the last few turns.
Regular fixes for rc4, a bunch of fixes across i915, amdgpu and
nouveau here, along with a couple of TTM fixes, and dma-buf and one
core pageflip/modifier interaction
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) produced this warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c: In function
'amdgpu_display_user_framebuffer_create':
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c:929:24: warning: unused variable
'adev'
If the HPD signal never asserts in panel_simple_prepare() and we
return an error, we should unset the enable GPIO and disable the
regulator to make it consistent for the caller.
At the moment I have some hardware where HPD sometimes doesn't assert.
Obviously that needs to be debugged, but this
Hey Dave,
This series of patches to add modesetting support for Ampere has been
pulled out of a larger, more invasive series. As there's currently no
firmware available for us to use, the rest of it isn't important right
now, and it'd be nice to have something non-invasive to provide what
Hey Dave,
As requested, here's a tree with the non-Ampere-specific fixes split
out, as most of them are potentially relevant to already-supported
GPUs.
I'll send another pull request with bare-bones GA102/GA104 support shortly.
Ben.
The following changes since commit
Hi, Yongqiang:
Chun-Kuang Hu 於 2021年1月7日 週四 下午6:05寫道：
>
> Hi, Yongqiang:
>
> Yongqiang Niu 於 2021年1月7日 週四 上午11:12寫道：
> >
> > Get the fifo size from device tree
> > because each rdma in the same SoC may have different fifo size
>
> Reviewed-by: Chun-Kuang Hu
Applied to mediatek-drm-next [1],
Hi, Yongqiang:
Yongqiang Niu 於 2021年1月11日 週一 下午3:48寫道：
>
> the orginal setting is not correct, fix it follow hardware data sheet.
> if keep this error setting, mt8173/mt8183 display ok
> but mt8192 display abnormal.
>
Applied to mediatek-drm-next [1], thanks.
[1]
On Thu, 14 Jan 2021 at 18:56, Christian König wrote:
> Unfortunately not of hand.
>
> I also don't see any bug reports from other people and can't reproduce
> the last backtrace you send out TTM here.
Because only the most desperate will install kernels with enabled
debug flags and then load the
Rob Herring 於 2021年1月15日 週五 上午3:11寫道：
>
> On Mon, 11 Jan 2021 15:43:37 +0800, Yongqiang Niu wrote:
> > add description for postmask
> > postmask is used control round corner for display frame
> >
> > Signed-off-by: Yongqiang Niu
> > ---
> >
On Wed, Jan 13, 2021 at 07:33:39PM +0100, AngeloGioacchino Del Regno wrote:
> From: Konrad Dybcio
>
> Port over the command from downstream to prevent undefined
> behaviour.
Reviewed-by: Jordan Crouse
> Signed-off-by: Konrad Dybcio
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
>
On Wed, Jan 13, 2021 at 07:33:38PM +0100, AngeloGioacchino Del Regno wrote:
> From: Konrad Dybcio
>
> Port over the command from downstream to prevent undefined
> behaviour.
Reviewed-by: Jordan Crouse
> Signed-off-by: Konrad Dybcio
> Signed-off-by: AngeloGioacchino Del Regno
>
> ---
>
On Wed, Jan 13, 2021 at 07:33:37PM +0100, AngeloGioacchino Del Regno wrote:
> From: Konrad Dybcio
>
> The upstream API for some reason uses logbase2 instead of
> just passing the argument as-is, whereas downstream CAF
> kernel does the latter.
>
> Hence, a mistake has been made when porting:
>
This reverts commit 0883ce8146ed6074c76399f4e70dbed788582e12. Originally
these quirks were added because of the issues with using the eDP
backlight interfaces on certain laptop panels, which made it impossible
to properly probe for DPCD backlight support without having a whitelist
for panels that
Since we now support controlling panel backlights through DPCD using
both the standard VESA interface, and Intel's proprietary HDR backlight
interface, we should allow the user to be able to explicitly choose
between one or the other in the event that we're wrong about panels
reliably reporting
So-recently a bunch of laptops on the market have started using DPCD
backlight controls instead of the traditional DDI backlight controls.
Originally we thought we had this handled by adding VESA backlight
control support to i915, but the story ended up being a lot more
complicated then that.
Currently, every different type of backlight hook that i915 supports is
pretty straight forward - you have a backlight, probably through PWM
(but maybe DPCD), with a single set of platform-specific hooks that are
used for controlling it.
HDR backlights, in particular VESA and Intel's HDR
In the next commit where we split PWM related backlight functions from
higher-level backlight functions, we'll want to be able to retrieve the
backlight level for the current display panel from the
intel_panel_bl_funcs->setup() function using pwm_funcs->get(). Since
intel_panel_bl_funcs->setup()
A while ago we ran into issues while trying to enable the eDP backlight
control interface as defined by VESA, in order to make the DPCD
backlight controls on newer laptop panels work. The issue ended up being
much more complicated however, as we also apparently needed to add
support for an
On Thu, 14 Jan 2021 21:35:53 +
Chris Wilson wrote:
> Quoting Steven Rostedt (2021-01-14 21:32:06)
> > On reboot, one of my test boxes now triggers the following warning:
>
> 057fe3535eb3 ("drm/i915: Disable RPM wakeref assertions during driver
> shutdown")
> is included with the
Quoting Steven Rostedt (2021-01-14 21:32:06)
> On reboot, one of my test boxes now triggers the following warning:
057fe3535eb3 ("drm/i915: Disable RPM wakeref assertions during driver shutdown")
is included with the drm-intel-fixes PR.
-Chris
___
[ Forgot to add those on the commit itself ]
-- Steve
On Thu, 14 Jan 2021 16:32:06 -0500
Steven Rostedt wrote:
> On reboot, one of my test boxes now triggers the following warning:
>
> [ cut here ]
> RPM raw-wakeref not held
> WARNING: CPU: 4 PID: 1 at
On reboot, one of my test boxes now triggers the following warning:
[ cut here ]
RPM raw-wakeref not held
WARNING: CPU: 4 PID: 1 at drivers/gpu/drm/i915/intel_runtime_pm.h:106
gen6_write32+0x1bc/0x2a0 [i915]
Modules linked in: ebtable_filter ebtables bridge stp llc
Hi Dave, Daniel,
More new stuff for 5.12.
The following changes since commit 044a48f420b9d3c19a135b821c34de5b2bee4075:
drm/amdgpu: fix DRM_INFO flood if display core is not supported (bug 210921)
(2021-01-08 15:18:57 -0500)
are available in the Git repository at:
Implement the new provider method for registering dma-buf based memory
regions.
Signed-off-by: Jianxin Xiong
---
providers/mlx5/mlx5.c | 2 ++
providers/mlx5/mlx5.h | 3 +++
providers/mlx5/verbs.c | 22 ++
3 files changed, 27 insertions(+)
diff --git
This is the fifth version of the patch series. Change log:
v5:
* Use a different mr_type for dmabuf so that ibv_dofork_range() is not
called inside ibv_dereg_mr() for dmabuf based mr
v4: https://www.spinics.net/lists/linux-rdma/msg98135.html
* Rework the cmake funciton rdma_cython_module to
The filter definition is wrong and causes get_access_flags() always
returning empty list. As the result the MR tests using this function
are effectively skipped (but report success).
Signed-off-by: Jianxin Xiong
---
tests/utils.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Define a new sub-class of 'MR' that uses dma-buf object for the memory
region. Define a new class 'DmaBuf' as a wrapper for dma-buf allocation
mechanism implemented in C.
Update the cmake function for cython modules to allow building modules
with mixed cython and c source files.
Signed-off-by:
Add new API function and new provider method for registering dma-buf
based memory region. Update the man page and bump the API version.
Signed-off-by: Jianxin Xiong
---
debian/libibverbs1.symbols | 2 ++
libibverbs/CMakeLists.txt| 2 +-
libibverbs/cmd_mr.c | 38
Define a set of unit tests similar to regular MR tests and a set of
tests for send/recv and rdma traffic using dma-buf MRs. Add a utility
function to generate access flags for dma-buf based MRs because the
set of supported flags is smaller.
Signed-off-by: Jianxin Xiong
---
tests/args_parser.py
To commit 2eef437c4669 ("RDMA/uverbs: Add uverbs command for dma-buf based
MR registration").
Signed-off-by: Jianxin Xiong
---
kernel-headers/rdma/ib_user_ioctl_cmds.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/kernel-headers/rdma/ib_user_ioctl_cmds.h
Am 2021-01-14 um 11:51 a.m. schrieb Jerome Glisse:
> On Thu, Jan 14, 2021 at 02:37:36PM +0100, Christian König wrote:
>> Am 14.01.21 um 12:52 schrieb Daniel Vetter:
>>> [SNIP]
> I had a new idea, i wanted to think more about it but have not yet,
> anyway here it is. Adding a new callback
On Tue, Jan 12, 2021 at 02:49:32PM +0800, Nick Fan wrote:
> Add devicetree schema for Arm Mali Valhall GPU
>
> Define a compatible string for the Mali Valhall GPU
> for Mediatek's SoC platform.
>
> Signed-off-by: Nick Fan
> ---
> .../bindings/gpu/arm,mali-valhall.yaml| 252
Hi Dave, Daniel,
Fixes for 5.11.
The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:
Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-5.11-2021-01-14
for you to
On Thu, Jan 14, 2021 at 08:08:06PM +0100, Christian König wrote:
> Am 14.01.21 um 17:36 schrieb Daniel Vetter:
> > On Thu, Jan 14, 2021 at 5:01 PM Christian König
> > wrote:
> > > Am 14.01.21 um 16:40 schrieb Daniel Vetter:
> > > > [SNIP]
> > > > > So I think we have to somehow solve this in the
https://bugzilla.kernel.org/show_bug.cgi?id=211189
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
[cc'd efifb and vgaarb maintainers on bugzilla, but not sure whether
people pay attention to that]
On Thu, Jan 14, 2021 at 10:42:53AM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=211189
>
> Bug ID: 211189
>Summary:
https://bugzilla.kernel.org/show_bug.cgi?id=211189
Bjorn Helgaas (bj...@helgaas.com) changed:
What|Removed |Added
CC||airl...@linux.ie,
On Mon, 11 Jan 2021 15:43:37 +0800, Yongqiang Niu wrote:
> add description for postmask
> postmask is used control round corner for display frame
>
> Signed-off-by: Yongqiang Niu
> ---
> Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 1 +
> 1 file changed, 1 insertion(+)
Am 14.01.21 um 17:36 schrieb Daniel Vetter:
On Thu, Jan 14, 2021 at 5:01 PM Christian König
wrote:
Am 14.01.21 um 16:40 schrieb Daniel Vetter:
[SNIP]
So I think we have to somehow solve this in the kernel or we will go in
circles all the time.
So from that pov I think the kernel should at
On Thu, 2021-01-14 at 09:12 +0200, Jani Nikula wrote:
> On Wed, 13 Jan 2021, Lyude Paul wrote:
> > Currently, every different type of backlight hook that i915 supports is
> > pretty straight forward - you have a backlight, probably through PWM
> > (but maybe DPCD), with a single set of
On Wed, Jan 13, 2021 at 8:51 AM Yang Li wrote:
>
> Fix the following coccicheck warning:
> ./drivers/gpu/drm/amd/display/dc/dml/dcn20/display_mode_vba_20.c:3141:30-39:
> WARNING: Comparison to bool
>
> Reported-by: Abaci Robot
> Signed-off-by: Yang Li
Applied all 4 patches. Thanks!
Alex
>
On Thu, Jan 14, 2021 at 4:29 AM ZhiJie.Zhang wrote:
>
> Signed-off-by: ZhiJie.Zhang
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c
>
On Thu, Jan 14, 2021 at 2:53 AM Mauro Carvalho Chehab
wrote:
>
> There's a missing colon, causing the markup to be ignored,
> solving those warnings:
>
> ../drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:340: warning:
> Incorrect use of kernel-doc format: *
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:214: warning:
> Function parameter or member 'link' not described in 'dc_link_detect_sink'
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1710: warning:
> Function parameter or member 'old_stream' not described in
> 'dc_is_stream_unchanged'
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:287: warning: Cannot
> understand
> *
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> It looks like it could be used inside the DC_TRACE_LEVEL_MESSAGE() macro.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function
> ‘dpcd_set_source_specific_data’:
>
On Thu, Jan 14, 2021 at 02:26:41PM +0100, Thomas Zimmermann wrote:
> From d0583fe22cd0cd29749ff679e46e13b58de325cb Mon Sep 17 00:00:00 2001
> From: Thomas Zimmermann
> Date: Thu, 14 Jan 2021 14:21:51 +0100
> Subject: [PATCH] drm/cma: Set vma ops in mmap function
>
> Signed-off-by: Thomas
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
> ‘dc_link_construct’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:1588:1: warning: the
> frame size of
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:1115:23:
> warning: no previous prototype for ‘dce60_create_resource_pool’
> [-Wmissing-prototypes]
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:1126:23:
> warning: no previous prototype for ‘dce80_create_resource_pool’
> [-Wmissing-prototypes]
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce80/dce80_resource.c:29:
>
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_8_0_sh_mask.h:9546:58:
> warning:
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce60/dce60_resource.c:28:
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_6_0_d.h:568:43:
> warning: initialized
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:54:
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:537:3:
> note: in
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> In file included from
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce100/dce100_resource.c:54:
>
> drivers/gpu/drm/amd/amdgpu/../include/asic_reg/dce/dce_10_0_sh_mask.h:5084:45:
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:806:6: warning: no
> previous prototype for ‘apply_ctx_interdependent_lock’ [-Wmissing-prototypes]
>
> Cc: Harry Wentland
> Cc: Leo Li
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dce112/dce112_resource.c:883:6:
> warning: no previous prototype for ‘dce112_validate_bandwidth’
> [-Wmissing-prototypes]
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:3710:19: warning:
> no previous prototype for ‘linkRateInKHzToLinkRateMultiplier’
> [-Wmissing-prototypes]
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c: In function
> ‘query_hdcp_capability’:
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link.c:599:28: warning:
> variable
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:1120:5: warning:
> no previous prototype for ‘shift_border_left_to_dst’ [-Wmissing-prototypes]
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/modules/info_packet/info_packet.c:412:
> warning: Cannot understand
> *
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/modules/power/power_helpers.c:281:6:
> warning: no previous prototype for ‘fill_iram_v_2’ [-Wmissing-prototypes]
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dmub/src/dmub_dcn30.c:83:6: warning:
> no previous prototype for ‘dmub_dcn30_backdoor_load’ [-Wmissing-prototypes]
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../include/renoir_ip_offset.h:226:29: warning:
> ‘UVD0_BASE’ defined but not used [-Wunused-const-variable=]
>
On Wed, Jan 13, 2021 at 3:08 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:299:10: warning: no
> previous prototype for ‘generic_reg_get’ [-Wmissing-prototypes]
>
On Mon, Jan 11, 2021 at 2:20 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:2753: warning:
> Function parameter or member 'vbios' not described in
> 'is_display_configuration_supported'
>
On Thu, Jan 14, 2021 at 02:37:36PM +0100, Christian König wrote:
> Am 14.01.21 um 12:52 schrieb Daniel Vetter:
> > [SNIP]
> > > > I had a new idea, i wanted to think more about it but have not yet,
> > > > anyway here it is. Adding a new callback to dma fence which ask the
> > > > question can it
Applied. Thanks!
Alex
On Fri, Jan 8, 2021 at 3:15 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c: In function
> ‘calculate_bandwidth’:
>
On Thu, Jan 14, 2021 at 5:01 PM Christian König
wrote:
>
> Am 14.01.21 um 16:40 schrieb Daniel Vetter:
> > [SNIP]
> >> So I think we have to somehow solve this in the kernel or we will go in
> >> circles all the time.
> >>
> >>> So from that pov I think the kernel should at most deal with an
>
Hi Thomas,
On 14/01/2021 15:15, Thomas Zimmermann wrote:
On 23/11/2020 11:56, Thomas Zimmermann wrote:
> The new GEM object function drm_gem_cma_mmap() sets the VMA flags
> and offset as in the old implementation and immediately maps in the
> buffer's memory pages.
>
>
The CRTC mode setting and routing configuration are performed at the
earliest of atomic enable and atomic begin, to ensure that a valid
configuration is applied to the hardware before the CRTC gets enabled
and before planes are setup (the latter being required in particular by
the VSP). This
Create a new private state object for the DU groups, and move the
initialisation of a group object to a new function rcar_du_group_init().
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Rebase to v5.11
- Fix pointer passing for
From: Laurent Pinchart
The vsp1_du_atomic_flush() function calls vsp1_du_pipeline_configure()
to configure the hardware pipeline. The function is currently guaranteed
to be called with the pipeline enabled, but this will change by future
rework of the DU driver. Guard the hardware configuration
From: Laurent Pinchart
Routing configuration for the DU is complex. Depending on the SoC
generation various routing options are available:
- The VSP to DU routing is not available on Gen1, is configurable on
Gen2 and is fixed on Gen3. When configurable, the routing affects both
CRTC groups
Create rcar_du_group_atomic_check() and rcar_du_group_atomic_setup()
functions to track and apply group state through the DRM atomic state.
The use_count field is moved from the rcar_du_group structure to an
enabled field in the rcar_du_group_state structure.
This allows separating group setup
Refactoring of the group control code will soon require more iteration
over the available groups. Simplify this process by introducing a group
iteration helper.
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v2:
- Don't assign __group
Manage the power state, and initial configuration of the CRTC from the
commit tail handler. CRTCs which need to be activated are taken out of
standby, and any deactivated CRTCs are put into standby.
This aims at removing CRTC state tracking from the rcar_du_crtc
structure. The initial
The vsp1_du_setup_lif() function is deprecated, and the users have been
removed. Remove the implementation and the associated configuration
structure.
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 46
The configuration API between the VSP and the DU has been updated to
provide finer grain control over modesetting, and enablement.
Split rcar_du_vsp_enable() into rcar_du_vsp_modeset() and
rcar_du_vsp_enable() accordingly, and update each function to use the
new VSP API.
There are no further
This patch series refactors atomic commit tail handling in the R-Car DU
driver to simplify the code flow, and open the door to further
optimisations. It rebases the series posted by Laurent "[PATCH v3 00/10]
drm: rcar-du: Rework CRTC and groups for atomic commits", which was
itself based upon work
Break vsp1_du_setup_lif() into components more suited to the DRM Atomic
API. The existing vsp1_du_setup_lif() API call is maintained as it is
still used from the DU.
Reviewed-by: Ulrich Hecht
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
Changes since v3:
- Minor formatting
On Thu, Jan 14, 2021 at 4:56 PM Geert Uytterhoeven wrote:
>
> Hi Daniel,
>
> CC linux-fbdev
>
> On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter wrote:
> > On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> > wrote:
> > > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi wrote:
> > > > > Could we pause
Am 14.01.21 um 16:40 schrieb Daniel Vetter:
[SNIP]
So I think we have to somehow solve this in the kernel or we will go in
circles all the time.
So from that pov I think the kernel should at most deal with an
hmm_fence for cross-process communication and maybe some standard wait
primitives
Hi Daniel,
CC linux-fbdev
On Tue, Jan 12, 2021 at 5:00 PM Daniel Vetter wrote:
> On Sat, Jan 9, 2021 at 12:11 AM Linus Torvalds
> wrote:
> > On Fri, Jan 8, 2021 at 11:13 AM Phillip Susi wrote:
> > > > Could we pause this madness? Scrollback is still useful. I needed it
> > > > today... it was
Hi,
looking at it, seems alright. Not sure why the lock was supposedly
needed, maybe it was at some point (it seems like all usage of this lock
was introduced way back in 2015, commit 153b3d5b037ee).
For the series: Reviewed-by: Roland Scheidegger
Roland
Am 12.01.21 um 09:49 schrieb Daniel
On Thu, Jan 14, 2021 at 4:08 PM Christian König
wrote:
> Am 14.01.21 um 15:23 schrieb Daniel Vetter:
> > On Thu, Jan 14, 2021 at 3:13 PM Christian König
> > wrote:
> >> Am 14.01.21 um 14:57 schrieb Daniel Vetter:
> >>> On Thu, Jan 14, 2021 at 2:37 PM Christian König
> >>> wrote:
> Am
Looks good. Thanks!
Reviewed-by: Zack Rusin
> On Jan 12, 2021, at 03:49, Daniel Vetter wrote:
>
> Hi Roland,
>
> Hopefully you had a nice start into the new year! Ping for some
> review/testing on this series.
>
> Thanks, Daniel
>
> On Fri, Dec 11, 2020 at 5:29 PM Daniel Vetter wrote:
>>
Hi Dave & Daniel,
Here is the first PR for v5.12. There are quite a few patches
accumulated after the holidays as usual:
Most importantly there are fixes to the clear residual security
mitigations to avoid GPU hangs caused by them. Further there is
option to allow the user to decide to disable
Hi
Am 14.01.21 um 15:34 schrieb Kieran Bingham:
Hi Thomas,
On 14/01/2021 13:26, Thomas Zimmermann wrote:
Hi Kieran
Am 14.01.21 um 13:51 schrieb Kieran Bingham:
Hi Thomas,
On 23/11/2020 11:56, Thomas Zimmermann wrote:
The new GEM object function drm_gem_cma_mmap() sets the VMA flags
and
On 13/01/2021 06:07, Nicolas Boichat wrote:
Add support for MT8183's G72 Bifrost.
Signed-off-by: Nicolas Boichat
Reviewed-by: Tomeu Vizoso
LGTM
Reviewed-by: Steven Price
---
(no changes since v7)
Changes in v7:
- Fix GPU ID in commit message
Changes in v6:
- Context conflicts,
On 13/01/2021 06:07, Nicolas Boichat wrote:
GPUs with more than a single regulator (e.g. G72 on MT8183) will
require platform-specific handling for devfreq, for 2 reasons:
1. The opp core (drivers/opp/core.c:_generic_set_opp_regulator)
does not support multiple regulators, so we'll need
Am 14.01.21 um 15:23 schrieb Daniel Vetter:
On Thu, Jan 14, 2021 at 3:13 PM Christian König
wrote:
Am 14.01.21 um 14:57 schrieb Daniel Vetter:
On Thu, Jan 14, 2021 at 2:37 PM Christian König
wrote:
Am 14.01.21 um 12:52 schrieb Daniel Vetter:
[SNIP]
I had a new idea, i wanted to think more
On Thu, Jan 14, 2021 at 07:52:45PM +0530, Sumera Priyadarsini wrote:
> Fix typo in intro chapter in drm_vblank.c.
> Change 'sacn' to 'scan'.
>
> Signed-off-by: Sumera Priyadarsini
Nice catch, applied.
-Daniel
> ---
> drivers/gpu/drm/drm_vblank.c | 2 +-
> 1 file changed, 1 insertion(+), 1
1 - 100 of 199 matches
Mail list logo
