On Fri, 2 Apr 2021 13:22:12 +0200
Simon Ser wrote:
> Force-probing a connector can be slow and cause flickering. As this
> affects the global KMS state, let's make it so only the DRM master
> can force-probe a connector.
>
> Non-master DRM clients won't be able to force-probe a connector
> anym
On Mon, 5 Apr 2021 11:41:50 +0530
Sumera Priyadarsini wrote:
> This patchset adds support for emulating virtual hardware with VKMS.
> The virtual hardware mode can be enabled by using the following command
> while loading the module:
> sudo modprobe vkms enable_virtual_hw=1
Hi,
every ti
On Wednesday, April 7th, 2021 at 9:02 AM, Pekka Paalanen
wrote:
> Btw. can force-probe be triggered via sysfs as well and does it require
> root privs?
sysfs can force-probe like so:
echo detect | sudo tee /sys/class/drm/card0-DP-1/status
But this requires root, yes.
_
On Wed, 7 Apr 2021 at 06:54, Alex Deucher wrote:
>
> On Fri, Apr 2, 2021 at 12:22 PM Christian König
> wrote:
> >
> > Hey Alex,
> >
> > the TTM and scheduler changes should already be in the drm-misc-next
> > branch (not 100% sure about the TTM patch, need to double check next week).
> >
>
> The
On Wed, 07 Apr 2021 07:16:30 +
Simon Ser wrote:
> On Wednesday, April 7th, 2021 at 9:02 AM, Pekka Paalanen
> wrote:
>
> > Btw. can force-probe be triggered via sysfs as well and does it require
> > root privs?
>
> sysfs can force-probe like so:
>
> echo detect | sudo tee /sys/class
On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote:
>
> On Mon, Mar 22, 2021 at 6:34 AM Christian König
> wrote:
> >
> > Hi Daniel,
> >
> > Am 22.03.21 um 10:38 schrieb Daniel Gomez:
> > > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling
> > > wrote:
> > >> This caused a regression in kfdtest in a lar
Hi Robert
Yes, you are right, there are many files reference
gpiod_set_value_cansleep() and
devm_gpiod_get_optional(). How about add config dependencies for all
releated
configs or only add config dependencies for the top level config?
Best regards
Zhang Jianhua
在 2021/4/6 18:21, Robert
> Yes, you are right, there are many files reference
> gpiod_set_value_cansleep() and
>
> devm_gpiod_get_optional(). How about add config dependencies for all
> releated
I think this is the way to go and roughly half of the drm bridge
drivers seem to need this change.
Do you mind submitting a ser
Hi Jon,
As files keep being moved around and DT bindings are
converted and renamed to yaml, their doc references get
outdated, pointing to an invalid places.
This series address those. It is based on the top of docs-next tree,
and most patches here are independent from the other ones.
v2:
-
Changeset bca28426805d ("dt-bindings: iommu: mediatek: Convert IOMMU to DT
schema")
renamed: Documentation/devicetree/bindings/iommu/mediatek,iommu.txt
to: Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml.
Update the cross-references accordingly.
Fixes: bca28426805d ("dt-bindings: iom
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/dp/dp_display.c: In function
‘dp_display_usbpd_attention_cb’:
drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable ‘hpd’ set but not
used [-Wunused-but-set-variable]
Fixes: c58eb1b54fee ("drm/msm/dp: fix connect/disconne
Fix the following gcc warning:
drivers/gpu/drm/nouveau/dispnv50/disp.c:1389:6: warning: variable ‘ret’
set but not used [-Wunused-but-set-variable].
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 6 ++
1 file changed, 2 insertions(+), 4
On Wed, Apr 07, 2021 at 09:27:46AM +0800, songqiang wrote:
Please add the description in the commit message and subject.
Thanks,
Ray
> Signed-off-by: songqiang
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 18 ++
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --g
This is the eighth version of a series to add support to Nouveau for atomic
memory operations on OpenCL shared virtual memory (SVM) regions.
The main change for this version is a simplification of device exclusive
entry handling. Instead of copying entries for copy-on-write mappings
during fork th
Remove multiple similar inline functions for dealing with different
types of special swap entries.
Both migration and device private swap entries use the swap offset to
store a pfn. Instead of multiple inline functions to obtain a struct
page for each swap entry type use a common function
pfn_swap
Both migration and device private pages use special swap entries that
are manipluated by a range of inline functions. The arguments to these
are somewhat inconsitent so rework them to remove flag type arguments
and to make the arguments similar for both read and write entry
creation.
Signed-off-by
The behaviour of try_to_unmap_one() is difficult to follow because it
performs different operations based on a fairly large set of flags used
in different combinations.
TTU_MUNLOCK is one such flag. However it is exclusively used by
try_to_munlock() which specifies no other flags. Therefore rather
Migration is currently implemented as a mode of operation for
try_to_unmap_one() generally specified by passing the TTU_MIGRATION flag
or in the case of splitting a huge anonymous page TTU_SPLIT_FREEZE.
However it does not have much in common with the rest of the unmap
functionality of try_to_unma
Adds some selftests for exclusive device memory.
Signed-off-by: Alistair Popple
Acked-by: Jason Gunthorpe
Tested-by: Ralph Campbell
Reviewed-by: Ralph Campbell
---
lib/test_hmm.c | 124 +++
lib/test_hmm_uapi.h| 2 +
tools/testing/s
Call mmu_interval_notifier_insert() as part of nouveau_range_fault().
This doesn't introduce any functional change but makes it easier for a
subsequent patch to alter the behaviour of nouveau_range_fault() to
support GPU atomic operations.
Signed-off-by: Alistair Popple
---
drivers/gpu/drm/nouve
Some devices require exclusive write access to shared virtual
memory (SVM) ranges to perform atomic operations on that memory. This
requires CPU page tables to be updated to deny access whilst atomic
operations are occurring.
In order to do this introduce a new swap entry
type (SWP_DEVICE_EXCLUSIV
Some NVIDIA GPUs do not support direct atomic access to system memory
via PCIe. Instead this must be emulated by granting the GPU exclusive
access to the memory. This is achieved by replacing CPU page table
entries with special swap entries that fault on userspace access.
The driver then grants th
Hi all,
with display servers proliferating thanks to Wayland, and the Linux
kernel exposing only a very limited set of information based on EDID
(rightfully so!), the need to interpret EDID blobs is spreading even
more. I would like to start the discussion about starting a project to
develop a sha
From: Stefan Riedmueller
This patch adds support for the EDT ETM0350G0DH6 3.5" (320x240) lcd
panel to DRM simple panel driver.
Signed-off-by: Stefan Riedmueller
Signed-off-by: Yunus Bas
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+
From: Stefan Riedmueller
This patch adds support for the EDT ETMV570G2DHU 5.7" (640x480) lcd panel
to DRM simple panel driver.
Signed-off-by: Stefan Riedmueller
Signed-off-by: Yunus Bas
---
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+
[AMD Public Use]
Hi Felix and Christian,
If the regression you are talking about is the NULL pointer problem when
running KFD tests, it should fixed by below patch in this series.
drm/amdgpu: fix NULL pointer dereference
Regards,
Guchun
-Original Message-
From: amd-gfx On Behalf Of C
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c: In function
‘dpu_encoder_phys_cmd_wait_for_commit_done’:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c:688:31: warning: variable
‘cmd_enc’ set but not used [-Wunused-but-set-variable]
Fixe
On Thu, Apr 01, 2021 at 05:52:36PM +0200, Christoph Hellwig wrote:
> Diffstat:
> arch/powerpc/include/asm/fsl_pamu_stash.h | 12
> drivers/gpu/drm/msm/adreno/adreno_gpu.c |5
> drivers/iommu/amd/iommu.c | 23
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 75 -
On 3/30/21 2:25 AM, Tian Tao wrote:
Fix the following coccicheck warning:
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:97:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda_dev.c:88:8-16: WARNING:
use scnprintf or sprintf
drivers/gpu/drm/arm/display/komeda/komeda
On Wed, 7 Apr 2021 at 02:06, Dmitry Baryshkov
wrote:
>
> devm_clk_hw_register_fixed_factor_release(), the release function for
> the devm_clk_hw_register_fixed_factor(), calls
> clk_hw_unregister_fixed_factor(), which will kfree() the clock. However
> after that the devres functions will also kfre
On Wed, 7 Apr 2021 11:44:04 +0300 Pekka Paalanen said:
> Hi all,
>
> with display servers proliferating thanks to Wayland, and the Linux
> kernel exposing only a very limited set of information based on EDID
> (rightfully so!), the need to interpret EDID blobs is spreading even
> more. I would l
Thanks Ray for pointing this out. Looks like the mail ended up in my
spam folder otherwise.
Apart from that this patch is a really really big NAK. I can't count how
often I had to reject stuff like this!
Using the page reference for TTM pages is illegal and can lead to struct
page corruption
Am 07.04.21 um 09:47 schrieb Daniel Gomez:
On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote:
On Mon, Mar 22, 2021 at 6:34 AM Christian König
wrote:
Hi Daniel,
Am 22.03.21 um 10:38 schrieb Daniel Gomez:
On Fri, 19 Mar 2021 at 21:29, Felix Kuehling wrote:
This caused a regression in kfdtest
Hi Pekka,
On 07/04/2021 10:44, Pekka Paalanen wrote:
> Hi all,
>
> with display servers proliferating thanks to Wayland, and the Linux
> kernel exposing only a very limited set of information based on EDID
> (rightfully so!), the need to interpret EDID blobs is spreading even
> more. I would like
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/nouveau/nouveau_display.c: In function
‘nouveau_framebuffer_new’:
drivers/gpu/drm/nouveau/nouveau_display.c:309:15: warning: variable ‘width’ set
but not used [-Wunused-but-set-variable]
Fixes: 4f5746c863db ("drm/nouveau/kms: Check f
Thanks, I will do that.
在 2021/4/7 16:03, Robert Foss 写道:
Yes, you are right, there are many files reference
gpiod_set_value_cansleep() and
devm_gpiod_get_optional(). How about add config dependencies for all
releated
I think this is the way to go and roughly half of the drm bridge
drivers see
On 3/22/21 11:29 AM, Marek Vasut wrote:
On 3/22/21 2:14 AM, Laurent Pinchart wrote:
Hi Marek,
Hi,
[...]
diff --git
a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
index e5e3c72630cf..399a6528780a 100644
Hi again,
On Wed, Mar 24, 2021 at 02:56:37PM +0100, Claudius Heine wrote:
> Hi Jagan,
>
> On 2021-02-14 18:44, Jagan Teki wrote:
> > SN65DSI83/84/85 devices are MIPI DSI to LVDS based bridge
> > controller IC's from Texas Instruments.
> >
> > SN65DSI83 - Single Channel DSI to Single-link LVDS br
On Wed, 07 Apr 2021, Hans Verkuil wrote:
> It is the most complete EDID parser I know based on the various standards.
Does it support pure DisplayID in addition to DisplayID blocks embedded
to EDID extension blocks? I think we'll be needing that sometime in the
near future. (We don't yet support
Yes, that was the one I was talking about.
Ok, good to know that this is fixed.
Regards,
Christian.
Am 07.04.21 um 10:50 schrieb Chen, Guchun:
[AMD Public Use]
Hi Felix and Christian,
If the regression you are talking about is the NULL pointer problem when
running KFD tests, it should fixed
Hi,
Adding Jörg, Will and Robin,
On Wed, Mar 31, 2021 at 09:21:19AM +0800, Kevin Tang wrote:
> > > +static u32 check_mmu_isr(struct sprd_dpu *dpu, u32 reg_val)
> > > +{
> > > + struct dpu_context *ctx = &dpu->ctx;
> > > + u32 mmu_mask = BIT_DPU_INT_MMU_VAOR_RD |
> > > +
On Wed, Mar 31, 2021 at 09:49:14AM +0800, Kevin Tang wrote:
> Hi Maxime,
>
> Maxime Ripard 于2021年3月24日周三 下午7:13写道：
>
> > On Mon, Feb 22, 2021 at 09:28:21PM +0800, Kevin Tang wrote:
> > > From: Kevin Tang
> > >
> > > Adds MIPI DSI Controller
> > > support for Unisoc's display subsystem.
> > >
>
On Wed, Mar 31, 2021 at 09:47:12AM +0800, Kevin Tang wrote:
> > > diff --git a/drivers/gpu/drm/sprd/Makefile
> > b/drivers/gpu/drm/sprd/Makefile
> > > index 6c25bfa99..d49f4977b 100644
> > > --- a/drivers/gpu/drm/sprd/Makefile
> > > +++ b/drivers/gpu/drm/sprd/Makefile
> > > @@ -1,5 +1,8 @@
> > > #
Am 06.04.21 um 16:11 schrieb Carlis:
From: Xuezhi Zhang
Fix the following coccicheck warning:
drivers/gpu/drm/amd/pm//amdgpu_pm.c:1940:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/amd/pm//amdgpu_pm.c:1978:8-16:
WARNING: use scnprintf or sprintf
drivers/gpu/drm/amd/pm//amdgpu_pm.c:202
FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd
definitely be interested in using such as library. A C API with no
dependencies is pretty important from my point-of-view.
I'd prefer if C++ was not used at all (and could almost be baited into
doing the work if that were the c
On 07/04/2021 12:31, Jani Nikula wrote:
> On Wed, 07 Apr 2021, Hans Verkuil wrote:
>> It is the most complete EDID parser I know based on the various standards.
>
> Does it support pure DisplayID in addition to DisplayID blocks embedded
> to EDID extension blocks? I think we'll be needing that so
Hi,
Am 06.04.21 um 17:27 schrieb Felix Kuehling:
Am 2021-04-06 um 6:38 a.m. schrieb Thomas Zimmermann:
Hi
Am 06.04.21 um 11:35 schrieb Christian König:
Am 06.04.21 um 11:08 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers
On Tue, Apr 06, 2021 at 03:57:32PM +0200, Hans de Goede wrote:
> Hi,
>
> On 3/25/21 12:48 PM, Hans de Goede wrote:
> > After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
> > displays gracefully on reboot"), the DSI panel on a Cherry Trail based
> > Predia Basic tablet would no long
On 3/30/21 11:31 AM, Dan Carpenter wrote:
> The dp->train_set[] for this driver is only two characters, not four so
> this memsets too much. Fortunately, this ends up corrupting a struct
> hole and not anything important.
>
> Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP Di
Hi Dmitry,
On Wed, 7 Apr 2021 at 08:06, Dmitry Baryshkov
wrote:
>
> devm_clk_hw_register_fixed_factor_release(), the release function for
> the devm_clk_hw_register_fixed_factor(), calls
> clk_hw_unregister_fixed_factor(), which will kfree() the clock. However
> after that the devres functions wi
There is a error message within devm_ioremap_resource
already, so remove the dev_err call to avoid redundant
error message.
Reported-by: Hulk Robot
Signed-off-by: Wei Li
---
drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/dr
On Wed, Apr 07, 2021 at 10:59:18AM +, Simon Ser wrote:
> FWIW, with my Sway/wlroots hat on I think this is a great idea and I'd
> definitely be interested in using such as library. A C API with no
> dependencies is pretty important from my point-of-view.
>
> I'd prefer if C++ was not used at a
This patch fix coccicheck warning:
drivers/gpu/drm/msm/dp/dp_link.c:848:5-8: Unneeded variable: "ret". Return "0"
on line 880
Also remove unneeded function return value check.
Signed-off-by: Bernard Zhao
---
drivers/gpu/drm/msm/dp/dp_link.c | 15 +++
1 file changed, 3 insertions(+),
On Tue, Apr 06, 2021 at 04:21:17PM -0300, Leandro Ribeiro wrote:
> Add a small description and document struct fields of
> drm_mode_get_plane.
>
> Signed-off-by: Leandro Ribeiro
> ---
> include/uapi/drm/drm_mode.h | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/inc
Hi,
On 4/7/21 2:34 PM, Ville Syrjälä wrote:
> On Tue, Apr 06, 2021 at 03:57:32PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 3/25/21 12:48 PM, Hans de Goede wrote:
>>> After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down
>>> displays gracefully on reboot"), the DSI panel on a Cherry
On Tue, Apr 06, 2021 at 04:21:18PM -0300, Leandro Ribeiro wrote:
> Emphasize how userspace should use the plane format list
> (format_type_ptr) and the IN_FORMATS blob property.
>
> Formats exposed in the plane format list (format_type_ptr) do not
> require modifiers, and formats that are present
On Wed, Apr 07, 2021 at 03:50:35PM +0200, Hans de Goede wrote:
> Hi,
>
> On 4/7/21 2:34 PM, Ville Syrjälä wrote:
> > On Tue, Apr 06, 2021 at 03:57:32PM +0200, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 3/25/21 12:48 PM, Hans de Goede wrote:
> >>> After the recently added commit fe0f1e3bfdfe ("drm/
Alex Deucher (1):
amdgpu: update marketing names
Alistair Delva (1):
xf86drm: fix null pointer deref in drmGetBufInfo
Ashutosh Dixit (1):
intel: Keep libdrm working without pread/pwrite ioctls
Emil Velikov (3):
xf86drm: cap number of reported devices by drmGetDevice(2)
The bridge chip ANX7625 require the line packets ending at the sametime
or ANX7625 will shift the screen.
Change-Id: Ia324ad28fbff54140feedb9a1d6bfb2b246d0447
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers
Move the bus clock to mdp device node,in order to facilitate bus band
width scaling on sdm845 target.
The parent device MDSS will not vote for bus bw, instead the vote will
be triggered by mdp device node. Since a minimum vote is required to
turn on bus clock, move the clock node to mdp device fro
Currently DPU driver scales bandwidth and core clock for sc7180 only,
while the rest of chips get static bandwidth votes. Make all chipsets
scale bandwidth and clock per composition requirements like sc7180 does.
Drop old voting path completely.
Tested on RB3 (SDM845) and RB5 (SM8250).
Signed-off
Fill clk_inefficiency_factor, bw_inefficiency_factor and
min_prefill_lines in hw catalog data for sdm845 and sm8[12]50.
Efficiency factors are blindly copied from sc7180 data, while
min_prefill_lines is based on downstream display driver.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/
Move the bus clock to mdp device node,in order to facilitate bus band
width scaling on sm8250 target.
The parent device MDSS will not vote for bus bw, instead the vote will
be triggered by mdp device node. Since a minimum vote is required to
turn on bus clock, move the clock node to mdp device fro
Currently DPU driver scales bandwidth and core clock for sc7180 only,
while the rest of chips get static bandwidth votes. Make all chipsets
scale bandwidth and clock per composition requirements like sc7180 does.
Drop old voting path completely.
Changes since v1:
- Add dts changes as requested by
Hi
On 06.04.21 14:40, Laurent Pinchart wrote:
Hi Dafna,
Thank you for the patch.
On Tue, Mar 30, 2021 at 01:52:00PM +0200, Dafna Hirschfeld wrote:
drm_bridge_funcs has a function called 'hpd_notify'.
The function drm_bridge_hpd_notify does not call
'hpd_notify' but it calls 'hpd_cb'. This is
+ dri-devel since GPU scheduler is a shared component.
On Wed, Apr 7, 2021 at 9:31 AM Roy Sun wrote:
>
> Update the timestamp of scheduled fence on HW
> completion of the previous fences
>
> This allow more accurate tracking of the fence
> execution in HW
>
> Signed-off-by: David M Nieto
> Signe
Hi, Jitao:
Jitao Shi 於 2021年4月7日 週三 下午10:37寫道：
>
> The bridge chip ANX7625 require the line packets ending at the sametime
> or ANX7625 will shift the screen.
>
> Change-Id: Ia324ad28fbff54140feedb9a1d6bfb2b246d0447
> Signed-off-by: Jitao Shi
> ---
> drivers/gpu/drm/mediatek/mtk_dsi.c | 12
On Tue, Apr 6, 2021 at 10:56 AM Lee Jones wrote:
>
> On Fri, 26 Mar 2021, Lee Jones wrote:
>
> > This set is part of a larger effort attempting to clean-up W=1
> > kernel builds, which are currently overwhelmingly riddled with
> > niggly little warnings.
> >
> > Lee Jones (25):
> > HID: intel-is
On 4/6/21 5:09 AM, Thomas Zimmermann wrote:
The vmwgfx driver is the only remaining user of ttm_bo_mmap(). Inline
the code. The internal helper ttm_bo_vm_lookup() is now also part of
vmwgfx as vmw_bo_vm_lookup().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c |
On 4/6/21 5:09 AM, Thomas Zimmermann wrote:
Vmwgfx is the only user of the TTM's verify_access callback. Inline
the call and avoid the indirection through the function pointer.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 -
drivers/gpu/drm/vmwg
On 2021-04-07 01:23, Zhen Lei wrote:
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/dp/dp_display.c: In function
‘dp_display_usbpd_attention_cb’:
drivers/gpu/drm/msm/dp/dp_display.c:496:19: warning: variable ‘hpd’
set but not used [-Wunused-but-set-variable]
Fixes: c58eb1b54f
On 2021-04-07 01:33, Zhen Lei wrote:
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c: In function
‘dpu_encoder_phys_cmd_wait_for_commit_done’:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c:688:31: warning:
variable ‘cmd_enc’ set but not u
On 2021-04-07 06:06, Bernard Zhao wrote:
This patch fix coccicheck warning:
drivers/gpu/drm/msm/dp/dp_link.c:848:5-8: Unneeded variable: "ret".
Return "0" on line 880
Also remove unneeded function return value check.
Signed-off-by: Bernard Zhao
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm
On 2021-04-07 01:33, Zhen Lei wrote:
Fixes the following W=1 kernel build warning:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c: In function
‘dpu_encoder_phys_cmd_wait_for_commit_done’:
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c:688:31: warning:
variable ‘cmd_enc’ set but not u
Hi Marijn
On 2021-04-06 14:47, Marijn Suijten wrote:
Leaving this at a close-to-maximum register value 0xFFF0 means it takes
very long for the MDSS to generate a software vsync interrupt when the
hardware TE interrupt doesn't arrive. Configuring this to double the
vtotal (like some downstream k
https://bugzilla.kernel.org/show_bug.cgi?id=212077
Bat Malin (bat_ma...@abv.bg) changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolutio
Quoting Bernard Zhao (2021-04-07 06:06:21)
> This patch fix coccicheck warning:
> drivers/gpu/drm/msm/dp/dp_link.c:848:5-8: Unneeded variable: "ret". Return
> "0" on line 880
> Also remove unneeded function return value check.
>
> Signed-off-by: Bernard Zhao
> ---
Reviewed-by: Stephen Boyd
___
On Wed, Apr 7, 2021 at 3:23 AM Dave Airlie wrote:
>
> On Wed, 7 Apr 2021 at 06:54, Alex Deucher wrote:
> >
> > On Fri, Apr 2, 2021 at 12:22 PM Christian König
> > wrote:
> > >
> > > Hey Alex,
> > >
> > > the TTM and scheduler changes should already be in the drm-misc-next
> > > branch (not 100%
On 2021-04-07 7:25 a.m., Christian König wrote:
+ /*
+ * Don't verify access for KFD BOs. They don't have a GEM
+ * object associated with them.
+ */
+ if (bo->kfd_bo)
+ goto out;
Who does the access verification now?
This is somewhat confusing.
I took this check as-is
On 2021-04-07 3:34 p.m., Felix Kuehling wrote:
On 2021-04-07 7:25 a.m., Christian König wrote:
+ /*
+ * Don't verify access for KFD BOs. They don't have a GEM
+ * object associated with them.
+ */
+ if (bo->kfd_bo)
+ goto out;
Who does the access verification now?
This
On Tue, Apr 6, 2021 at 10:13 AM Carlis wrote:
>
> From: Xuezhi Zhang
>
> Fix the following coccicheck warning:
> drivers/gpu/drm/amd/pm//amdgpu_pm.c:1940:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/drm/amd/pm//amdgpu_pm.c:1978:8-16:
> WARNING: use scnprintf or sprintf
> drivers/gpu/dr
https://bugzilla.kernel.org/show_bug.cgi?id=211875
--- Comment #8 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 296273
--> https://bugzilla.kernel.org/attachment.cgi?id=296273&action=edit
dmesg (kernel 4.14.228, A10-9700E)
Traced the issue back to kernel v4.14.228 which is still
Quoting Dmitry Baryshkov (2021-04-06 16:06:06)
> devm_clk_hw_register_fixed_factor_release(), the release function for
> the devm_clk_hw_register_fixed_factor(), calls
> clk_hw_unregister_fixed_factor(), which will kfree() the clock. However
> after that the devres functions will also kfree the all
On Thu, 8 Apr 2021 at 01:41, Stephen Boyd wrote:
>
> Quoting Dmitry Baryshkov (2021-04-06 16:06:06)
> > devm_clk_hw_register_fixed_factor_release(), the release function for
> > the devm_clk_hw_register_fixed_factor(), calls
> > clk_hw_unregister_fixed_factor(), which will kfree() the clock. Howev
Quoting Dmitry Baryshkov (2021-04-06 16:06:06)
> devm_clk_hw_register_fixed_factor_release(), the release function for
> the devm_clk_hw_register_fixed_factor(), calls
> clk_hw_unregister_fixed_factor(), which will kfree() the clock. However
> after that the devres functions will also kfree the all
ROCm user mode has acquired VMs from DRM file descriptors for as long
as it supported the upstream KFD. Legacy code to support older versions
of ROCm is not needed any more.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 4 --
.../gpu/drm/amd/amdgpu/amdgpu_amd
DRM allows access automatically when it creates a GEM handle for a BO.
KFD BOs don't have GEM handles, so KFD needs to manage access manually.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 ++-
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 19
amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu needs the drm_priv to allow mmap
to access the BO through the corresponding file descriptor.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 14 ++--
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 69 +++
This shortcut is no longer needed with access managed progerly by KFD.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 936b
Quoting Dmitry Baryshkov (2021-04-07 15:57:01)
> On Thu, 8 Apr 2021 at 01:41, Stephen Boyd wrote:
> >
> > Quoting Dmitry Baryshkov (2021-04-06 16:06:06)
> > > devm_clk_hw_register_fixed_factor_release(), the release function for
> > > the devm_clk_hw_register_fixed_factor(), calls
> > > clk_hw_unr
Use devm_add_action_or_reset() instead of devres_alloc() and
devres_add(), which works the same. This will simplify the
code. There is no functional changes.
Signed-off-by: Tian Tao
Signed-off-by: Yicong Yang
---
drivers/gpu/drm/bridge/panel.c | 27 +++
1 file changed, 1
If CONFIG_DRM_LONTIUM_LT8912B=m, the following errors will be seen while
compiling lontium-lt8912b.c
drivers/gpu/drm/bridge/lontium-lt8912b.c: In function
‘lt8912_hard_power_on’:
drivers/gpu/drm/bridge/lontium-lt8912b.c:252:2: error: implicit
declaration of function ‘gpiod_set_value_cansleep’; did
On Fri, Apr 02, 2021 at 07:02:32PM +0300, Dmitry Osipenko wrote:
> 02.04.2021 00:19, Michał Mirosław пишет:
> > On Fri, Mar 26, 2021 at 04:34:13PM +0200, Mikko Perttunen wrote:
> >> On 3/23/21 12:16 PM, Thierry Reding wrote:
> >>> On Mon, Jan 11, 2021 at 03:00:01PM +0200, Mikko Perttunen wrote:
> >
On Thu, Apr 08, 2021 at 06:13:44AM +0200, Michał Mirosław wrote:
> On Fri, Apr 02, 2021 at 07:02:32PM +0300, Dmitry Osipenko wrote:
> > 02.04.2021 00:19, Michał Mirosław пишет:
> > > On Fri, Mar 26, 2021 at 04:34:13PM +0200, Mikko Perttunen wrote:
> > >> On 3/23/21 12:16 PM, Thierry Reding wrote:
>
Hi
Am 07.04.21 um 21:49 schrieb Felix Kuehling:
On 2021-04-07 3:34 p.m., Felix Kuehling wrote:
On 2021-04-07 7:25 a.m., Christian König wrote:
+ /*
+ * Don't verify access for KFD BOs. They don't have a GEM
+ * object associated with them.
+ */
+ if (bo->kfd_bo)
+ goto
Hi Dave, Daniel,
Fixes for 5.12.
The following changes since commit 6fdb8e5aba6a33fe5f1a0bd1bcf0cf2884437ead:
Merge tag 'imx-drm-fixes-2021-04-01' of
git://git.pengutronix.de/git/pza/linux into drm-fixes (2021-04-02 04:53:16
+1000)
are available in the Git repository at:
https://gitlab.f
On Wed, 7 Apr 2021 16:30:01 -0400
Alex Deucher wrote:
> On Tue, Apr 6, 2021 at 10:13 AM Carlis wrote:
> >
> > From: Xuezhi Zhang
> >
> > Fix the following coccicheck warning:
> > drivers/gpu/drm/amd/pm//amdgpu_pm.c:1940:8-16:
> > WARNING: use scnprintf or sprintf
> > drivers/gpu/drm/amd/pm//amd
On Wed, 7 Apr 2021 at 18:45, Maxime Ripard wrote:
>
> Hi,
>
> Adding Jörg, Will and Robin,
You forgot to add them actually :)
I've added Robin and Joerg.
>
> On Wed, Mar 31, 2021 at 09:21:19AM +0800, Kevin Tang wrote:
> > > > +static u32 check_mmu_isr(struct sprd_dpu *dpu, u32 reg_val)
> > > > +
From: David Stevens
This reverts commit 86bbd89d5da66fe760049ad3f04adc407ec0c4d6.
Using the singleton stub fence in drm_syncobj_assign_null_handle means
that all syncobjs created in an already signaled state or any syncobjs
signaled by userspace will reference the singleton fence when exported
t
Il 07/04/21 20:19, abhin...@codeaurora.org ha scritto:
Hi Marijn
On 2021-04-06 14:47, Marijn Suijten wrote:
Leaving this at a close-to-maximum register value 0xFFF0 means it takes
very long for the MDSS to generate a software vsync interrupt when the
hardware TE interrupt doesn't arrive. Confi
1 - 100 of 102 matches
Mail list logo
