i915_gem_evict_vm will need to be able to evict objects that are
locked by the current ctx. By testing if the current context already
locked the object, we can do this correctly. This allows us to
evict the entire vm even if we already hold some objects' locks.
Previously, this was spread over sev
I met a bug recently and the kernel log:
[ 330.171875] radeon :03:00.0: couldn't schedule ib
[ 330.175781] [drm:radeon_uvd_suspend [radeon]] *ERROR* Error destroying UVD
(-22)!
In radeon drivers, using UVD suspend is as follows:
if (rdev->has_uvd) {
uvd_v1_0_fini(rdev);
ra
Am 15.01.22 um 02:06 schrieb Hridya Valsaraju:
The optional exporter op provides a way for processes to transfer
charge of a buffer to a different process. This is essential for the
cases where a central allocator process does allocations for various
subsystems, hands over the fd to the client wh
On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote:
>
> Some audio servers like to monitor a jack device (perhaps combined with
> EDID, for audio-presence info) to determine DP/HDMI audio presence.
>
> Signed-off-by: Brian Norris
Reviewed-by: Chen-Yu Tsai
On Sat, Jan 15, 2022 at 7:03 AM Brian Norris wrote:
>
> Commit b18c6c3c7768 ("ASoC: rockchip: cdn-dp sound output use spdif")
> switched the platform to SPDIF, but we didn't fix up the device tree.
>
> Drop the pinctrl settings, because the 'spdif_bus' pins are either:
> * unused (on kevin, bob),
Am 15.01.22 um 08:02 schrieb cgel@gmail.com:
From: Changcheng Deng
'drm/drm_drv.h' included in 'amdgpu_ttm.c' is duplicated. It is also
included on 53 line.
Reported-by: Zeal Robot
Signed-off-by: Changcheng Deng
Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm
After adding device_link between the IOMMU consumer and smi,
the mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed-by: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 16
arch/arm64/boot/d
After adding device_link between the IOMMU consumer and smi, the
mediatek,larb is unnecessary now.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Tested-by: Frank Wunderlich # BPI-R2/MT7623
---
arch/arm/boot/dts/mt2701.dtsi | 2 --
arch/arm/boot/dts/mt7623n.dtsi | 5
After adding device_link between the iommu consumer and smi-larb,
the pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. we can get rid of mtk_smi_larb_get/put.
CC: Matthias Brugger
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Krzysztof Kozlowski
Acked-b
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the vcodec devices call the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Tiffany Lin
CC: Irui Wang
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the drm device calls the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: CK Hu
CC: Philipp Zabel
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Acked-by: Chun
From: Yongqiang Niu
Prepare for smi cleaning up "mediatek,larb".
Display use the dispsys device to call pm_rumtime_get_sync before.
This patch add pm_runtime_xx with ovl and rdma device whose nodes has
"iommus" property, then display could help pm_runtime_get for smi via
ovl or rdma device.
CC:
MediaTek IOMMU has already added the device_link between the consumer
and smi-larb device. If the mdp device calls the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
CC: Minghsiu Tsai
CC: Houlong Wei
Signed-off-by: Yong Wu
Reviewed-by: Evan Green
Reviewed
MediaTek IOMMU has already added device_link between the consumer
and smi-larb device. If the jpg device calls the pm_runtime_get_sync,
the smi-larb's pm_runtime_get_sync also be called automatically.
After removing the larb_get operations, then mtk_jpeg_clk_init is
also unnecessary. Remove it too
MediaTek IOMMU-SMI diagram is like below. all the consumer connect with
smi-larb, then connect with smi-common.
M4U
|
smi-common
|
-
| |...
| |
larb1 larb2
| |
vdec venc
When the consumer works, it should enab
Prepare for adding device_link.
The iommu consumer should use device_link to connect with the
smi-larb(supplier). then the smi-larb should run before the iommu
consumer. Here we delay the iommu driver until the smi driver is ready,
then all the iommu consumers always are after the smi driver.
Whe
The platform device is created at:
of_platform_default_populate_init: arch_initcall_sync
->of_platform_populate
->of_platform_device_create_pdata
When entering our probe, all the devices should be already created.
if it is null, means NODEV. Currently we don't get the fail case.
It's a
When the iommu master device enters of_iommu_xlate, the ops may be
NULL(iommu dev is defered), then it will initialize the fwspec here:
[] (dev_iommu_fwspec_set) from []
(iommu_fwspec_init+0xbc/0xd4)
[] (iommu_fwspec_init) from []
(of_iommu_xlate+0x7c/0x12c)
[] (of_iommu_xlate) from []
(of_iommu_c
After adding device_link between the consumer with the smi-larbs,
if the consumer call its owner pm_runtime_get(_sync), the
pm_runtime_get(_sync) of smi-larb and smi-common will be called
automatically. Thus, the consumer don't need this property.
And IOMMU also know which larb this consumer conne
MediaTek IOMMU block diagram always like below:
M4U
|
smi-common
|
-
| | ...
| |
larb1 larb2
| |
vdec venc
All the consumer connect with smi-larb, then connect with smi-common.
When the consumer works, it should
The pull request you sent on Sun, 16 Jan 2022 20:31:09 +0100:
> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git
> tags/fbdev-5.17-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/3c750c7b614322a4ab50be0d57a76addb598d51d
Thank you!
--
Deet-doot
When DRM_CHIPONE_ICN6211 is selected, and DRM_KMS_HELPER is not selected,
Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for DRM_PANEL_BRIDGE
Depends on [n]: HAS_IOMEM [=y] && DRM_BRIDGE [=y] && DRM_KMS_HELPER [=n]
Selected by [y]:
- DRM_CHIPONE_ICN6211 [=y]
Thank you for your reviews.
On 2022/01/14 23:16, Andy Shevchenko wrote:
On Fri, Jan 14, 2022 at 07:17:52PM +0900, Tomohito Esaki wrote:
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers.
...
+ const uint64_t default_modifiers[] = {
+ DRM_
On Sun, Jan 16, 2022 at 9:32 PM Helge Deller wrote:
>
> This pull request contains only one single initial patch which adds
> myself to the MAINTAINERS file for the FRAMBUFFER LAYER.
I'll pull this (as my test builds for other things complete), but this
is just a note to say that this pull reques
On 11/27/21 04:24, Marek Vasut wrote:
The TC358767/TC358867/TC9595 are all capable of operating in multiple
modes, DPI-to-(e)DP, DSI-to-(e)DP, DSI-to-DPI. Add support for the
DSI-to-DPI mode.
This requires skipping most of the (e)DP initialization code, which is
currently a large part of this dr
Thank you for your reviews.
On 2022/01/15 1:50, Daniel Vetter wrote:
On Wed, Dec 22, 2021 at 02:27:25PM +0900, Tomohito Esaki wrote:
The LINEAR modifier is advertised as default if a driver doesn't specify
modifiers. However, there are legacy drivers such as radeon that do not
support modifiers
> -Original Message-
> From: Michael Kelley (LINUX)
> Sent: Sunday, January 16, 2022 2:19 PM
> To: KY Srinivasan ; Haiyang Zhang
> ; Stephen
> Hemminger ; wei@kernel.org; Wei Hu
> ; Dexuan
> Cui ; drawat.fl...@gmail.com; hhei ;
> linux-
> ker...@vger.kernel.org; linux-hyp...@vger
https://bugzilla.kernel.org/show_bug.cgi?id=215499
--- Comment #1 from Alexandre Demers (alexandre.f.dem...@gmail.com) ---
Also, the kernel provided by ArchLinux is built with CONFIG_DRM_AMDGPU_SI=y
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are wa
https://bugzilla.kernel.org/show_bug.cgi?id=215499
Alexandre Demers (alexandre.f.dem...@gmail.com) changed:
What|Removed |Added
CC||alexandr
https://bugzilla.kernel.org/show_bug.cgi?id=215499
Bug ID: 215499
Summary: AMDGPU: Tahiti flagged as "[drm] Unsupported asic.
Remove me when IP discovery init is in place."
Product: Drivers
Version: 2.5
Kernel Version: 5.16
Hi Linus,
The fbdev layer is orphaned, but seems to need some care.
So I'd like to step up as new maintainer.
This pull request contains only one single initial patch which adds
myself to the MAINTAINERS file for the FRAMBUFFER LAYER.
This was
Acked-by: Geert Uytterhoeven
Thanks,
Helge
---
In the WIN10 version of the Synthetic Video protocol with Hyper-V,
Hyper-V reports a list of supported resolutions as part of the protocol
negotiation. The driver calculates the maximum width and height from
the list of resolutions, and uses those maximums to validate any screen
resolution specifie
The function performs a check on the "phy" input parameter, however, it
is used before the check.
Initialize the "dev" variable after the sanity check to avoid a possible
NULL pointer dereference.
Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files")
Addresses-Coverity-ID: 149
Hi Tommaso,
On Sat, Jan 15, 2022 at 8:23 PM Tommaso Merciai wrote:
> Hi Fabio,
> I'm working on bring up urt,umsh-8596md-20t lvds kit panel, but after enable
> following node I get the following error:
I assume you are trying to connect an external panel via connector CN3.
This connector is fo
https://bugzilla.kernel.org/show_bug.cgi?id=215492
Artem S. Tashkinov (a...@gmx.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
Reso
35 matches
Mail list logo
